The 'Security Digest' Archives (TM)

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

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

START OF DOCUMENT

-----------[000000][next][prev][last][first]----------------------------------------------------
Date:      Sat, 1 May 1993 12:34:33 GMT
From:      "Jim Leeper" <p00439@psilink.com>
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.domains,comp.protocols.tcp-ip.ibmpc
Subject:   TCP-IP Technical Professional wanted to Teach

I am looking for experienced TCP/IP technical professionals
who would like to instruct part-time.

Specifically, I am looking for technical professionals with the
following experience:

      1) 4+ years experience configuring, using, installing TCP/IP 
      software and networks. 
      2) Experienced configuring, installing TCP/IP applications, 
      FTP,TELNET, R* utilities.
      3) Experienced configuring , using NFS, DNS, BLIND, and SNMP.
      4) Protocol analysis and troubleshooting experience of      
      TCP/IP-based networks
      5)Router configuration, troubleshooting experience.
      6)Experienced using DOS/Windows TCP/IP packages including   
      FTP, NCSA, and/or WINQVT.
      7) Experienced as a systems administrator of a UNIX and     
      TCP/IP configuration. Knows NetWare v3.x and NetWare NFS.

Interested? Our Instructors are asked to teach 4 to 20 times a
year.  TCP/IP courses run weekly on 4 consecutive days, generally
Tuesday through Friday, at various times throughout the year.
We do accommodate our instructor's full time schedule as required.

Relocation is not required, we pay hotel, travel and per diem costs
to our course sites located throughout the US, Canada, and Europe.
We are looking for pros to train the not so pros. We provide
training to new instructors.

If you are interested and have some availability, please contact
me, I will get you more information. Also, if you know a better way
to get the word out that I am looking for TCP/IP Instructors,
please let me know. I am a new user of Internet.

Thanks

Jim Leeper


-----------[000001][next][prev][last][first]----------------------------------------------------
Date:      1 May 1993 14:12:15 GMT
From:      trier@odin.ins.cwru.edu (Stephen C. Trier)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject:   Re: Looking for free PC client software aka free PCNFS

In article <C6AwDw.K85@sdf.lonestar.org> copeland@sdf.lonestar.org (Charles Copeland) writes:
>I have been looking for free client software to replace PCNFS on a few PC's
>at work.

There is no free NFS client for MS-DOS.  If you want one, you will have
to write it yourself or contract with someone to write it for you.

Followups to comp.protocols.tcp-ip.ibmpc.

-- 
Stephen Trier                     Work: trier@ins.cwru.edu
Network Software Engineer         Home: sct@po.cwru.edu
IRIS/INS/T
Case Western Reserve University

-----------[000002][next][prev][last][first]----------------------------------------------------
Date:      Sat, 1 May 1993 17:34:35 GMT
From:      jbreeden@netcom.com (John Breeden)
To:        comp.protocols.tcp-ip
Subject:   looking for (r)telnet/(pseudo)telnet

I've been told that a piece of software exists that accepts a telnet
to a peticular socket number and reroutes the connection to a specific
ipaddress. They said it was called either 'rtelnet' or 'pseudotelnet'.

No luck with archie *at all*, so if some kind carbon based life form has
the answer (like where it is and/or what it's called), please post or 
email to me.

Thanx in advance.
-- 

                    John Robert Breeden, Hughes Lan Systems

         jbreeden@kailua.hls.com, jbreeden@hls.com, jbreeden@netcom.com

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

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

-----------[000003][next][prev][last][first]----------------------------------------------------
Date:      Sat,  1 May 93 14:52:00 +0200
From:      rune.mossige@euronetis.no (Rune Mossige)
To:        comp.protocols.tcp-ip
Subject:   NIS & DNS questions

Hello, networld.

I have a few questions regarding NIS. We currently have 3 Sun Sparc's 
(1 x 4/330, 1 x IPC and 1 x Sparc 2) running SunOS 4.1.3, 2 SDI 
80486'es running SCO unix, 1 RS/6000 running AIX 3.2.3 and about 30 
PC's running FTP's PC/TCP. Our office is connected to our main office 
through a NS6607 router. We have used two ports on the router, so we 
have two subnets. One subnet have both SCO unix boxes and the Sun 
4/330, and the other subnet have all other machines. All PC-users 
mount drives off the RS/6000 and the Sun 4/330, and don't need access 
to the other unix boxes, except for occational telnet sessions. The 
two SCO boxes are only used as plot servers, and FTP files from 
Arlington, Texas and Bedford, UK (we are located in Norway). We are 
not connected to the Internet, but are connected via our internal 
world-wide network. The IP addresses we use should be legal. Our site 
have been assigned IP addresses 34.2.208.0 -> 34.2.211.254 and 
34.3.160.0 -> 34.3.163.254, using 14-bits subnet mask (255.255.252.0). 
I have been told that we will get an official Internet connection in 
the near future, probably within this or next month. So, prior to this 
connection, I'd like to have our local network prepared and ready to 
go. I have purchased O'Reily's 'Managing NIS and NFS' and 'Managing 
DNS' and find them quite useful, but don't understand everything yet 
(!). We have DNS up and running on our RS/6000, but I know it is not 
configured correct. It works, but it is not according to 'standard' if 
i understand the books correct. I am now gathering 
information/tips/suggestions of how to proceed.

I have also set up two of the Sun's (one on each side of the 
router...) with NIS, and stumbled into a problem when I was going to 
add the other unix boxes to NIS. First, the login shell problem. From 
what I understand, the NIS passwd map will be the same on all 
machines, so all users must use the same login shell. But, SUN have 
the C-shell as default and have not even included the Korn shell, 
while the RS have the Korn shell as default. We have had these 
nachines for a couple of years now, and the users have gotten used to 
the default login shells. So the question is: Should I force all users 
to use the C-shell, or is there a way around this? The applications 
run on the Sun's depend very heavily on that the users use the C-
shell, while the RS applications depend on that the users use the Korn 
shell. Does anyone have a good suggestion?

The next question is the home directory. There seems to be two 
suggestions out there, /home/<machine>/<user> and /home/<user>. I also 
plan to use the Automounter, so what naminc scheme should I use??

This was not a very clear question, but I'm really new to this game. 
Any suggestions/comments/tips would be greatly appreciated.

Rune Mossige

 * 1st 1.10b #274 * Luxuriantly hand-crafted from only the finest ASCII.

-----------[000004][next][prev][last][first]----------------------------------------------------
Date:      1 May 1993 20:24:04 GMT
From:      barr@pop.psu.edu (David Barr)
To:        comp.protocols.tcp-ip
Subject:   Re: Asking nameservers for domains

Just a small correction...

In article <1rs62r$shg@genesis.ait.psu.edu> I write:
>If I am in the domain "math.uwaterloo.ca" (logged on, say, cantor), and I
>say "telnet gauss", the resolver will first try "gauss.math.uwaterloo.ca"
>If that exists, it will return that.  It will then try "gauss.uwaterloo.ca".
>If that exists, it will return that.  Failing that, it will return "host
>unknown".  If say "telnet joe.cs", the resolver will first try
>"joe.cs.math.uwaterloo.ca", then "joe.cs.uwaterloo.ca".

If the resolver is passed a hostname with a dot in it, then it will
(after going through RES_DNSRCH) will try to see if it is an FQDN.
So, the final check the resolver would take would be to see if "joe.cs."
is a valid address.  (In Czechoslovakia)

--Dave
-- 
System Administrator, Penn State Population Research Institute
#define ENOTTY          25              /* Not a typewriter */

-----------[000005][next][prev][last][first]----------------------------------------------------
Date:      1 May 1993 20:28:17 GMT
From:      barmar@think.com (Barry Margolin)
To:        comp.protocols.tcp-ip
Subject:   Re: NIS & DNS questions

In article <4.473.362.0N565040@euronetis.no> rune.mossige@euronetis.no (Rune Mossige) writes:
>I have also set up two of the Sun's (one on each side of the 
>router...) with NIS, and stumbled into a problem when I was going to 
>add the other unix boxes to NIS. First, the login shell problem. From 
>what I understand, the NIS passwd map will be the same on all 
>machines, so all users must use the same login shell. But, SUN have 
>the C-shell as default and have not even included the Korn shell, 
>while the RS have the Korn shell as default. 

Korn shell is available for Suns; I think we got it from the AT&T
Toolchest.  I believe it's bundled with Solaris 2.x as well.

>					      We have had these 
>nachines for a couple of years now, and the users have gotten used to 
>the default login shells. So the question is: Should I force all users 
>to use the C-shell, or is there a way around this? 

Set everyone's shell to /usr/local/bin/default_shell.  Then on each
machine, make a symbolic link from /usr/local/bin/default_shell to
whichever shell you want as a default on that machine.  Also, make sure you
add /usr/local/bin/default_shell to /etc/shells everywhere.

>						    The applications 
>run on the Sun's depend very heavily on that the users use the C-
>shell, while the RS applications depend on that the users use the Korn 
>shell. Does anyone have a good suggestion?

How do applications depend on the shell that they were called from?
-- 
Barry Margolin
System Manager, Thinking Machines Corp.

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

-----------[000006][next][prev][last][first]----------------------------------------------------
Date:      2 May 93 11:08:37 CST
From:      phe@kuhub.cc.ukans.edu
To:        comp.protocols.tcp-ip
Subject:   Internet connection

Hi:

One of my friends wants to set up an Internet connection. In his location, there are about 30 - 40 PCs ( they are on Ethernets running on IPX and some other stacks). My advice to him is that he needs to apply for a class-C IP address and gets an Internet feed from someone (He is working for a commertial company located at Kansas City area -- Overland Park.) He is writing a proposal and needs your help...

1. Who provides Internet services in the area? 

2. Hardware: 
   -leased phone line ( fractional T1?), 
   -router ( Cisco routers ...)
   -server machine ( Sun station in order to set up a ftp server 
                     and news server?  how about a fast PC to be a server? 
                     any ftp server and news server software running on a PC?)
   -other suggestions?

3. Software:
    -news server
    -other common servers (NFS, FTP, Telnet and etc.  if a PC can be a server machine)
    -other suggestions?


4. Whom should he talk to? ( someone who can provide this kind of simple
                             Internet design info.)

Thank you in advance for any of your suggestions.


P.S. please send your suggestions directly to me since my friend doesn't have Internet access -- not yet :-)


BTW, do you know any other news groups I should post this message to?

Ping

-----------[000007][next][prev][last][first]----------------------------------------------------
Date:      Sun,  2 May 93 12:14:00 +0200
From:      rune.mossige@euronetis.no (Rune Mossige)
To:        comp.protocols.tcp-ip
Subject:   Re: NIS & DNS questions

Subject: 

 
BMRM´Korn shell is available for Suns; I think we got it from the AT&T
  RM´Toolchest.  I believe it's bundled with Solaris 2.x as well.

I know it is bundled with Solaris 2.x, but the applications we run 
will not run under Solaris for at least another month. I don't have 
FTP access, so I have not been able to get a Korn shell for the sun's.

BMRM´Set everyone's shell to /usr/local/bin/default_shell.  Then on each

Very good idea. I'll look into this as soon as possible.

BMRM´How do applications depend on the shell that they were called from?

It's probably me that was unclear. What I meant was that all 
documentation, manuals and tutorials are based on one shell (c-shell 
on Sun and K-shell on the RS) and have alot of environment variables 
set and other examples. Users just follow the book, and don't really 
understand the different shells. I guess some more taining is 
needed...Your comment made me think, and I agree with you. I think I 
have to modify the way all these environment variables are set. Thanks 
for the comment.

Rune Mossige

 * 1st 1.10b #274 * Keyboard not found...THINK F1 to continue.

-----------[000008][next][prev][last][first]----------------------------------------------------
Date:      2 May 93 18:10:59 GMT
From:      art@acc.com (Art Berggreen)
To:        comp.protocols.tcp-ip
Subject:   Re: Wanted: to identify routers in a path

In article <C69ItC.9Gt@aaahq05.aaa.com> mikel@aaahq05.aaa.com writes:
>There was a program I've seen at USENIX (which I think comes from Solbourne)
>which tells you the names (or addresses) of the routers allong a certain path.
>
>You give it an address, like "kgbvax.kgb.org.su" and it will identify all
>of the routers allong the path taken.

Sounds like you are talking about "traceroute" (originally created by
Van Jacobsen).

>Can anyone tell me where I can get this?

Check with an Archie server for an FTP server near you.

Art

-----------[000009][next][prev][last][first]----------------------------------------------------
Date:      2 May 93 19:13:21 GMT
From:      guy@Auspex.COM (Guy Harris)
To:        comp.protocols.tcp-ip
Subject:   Re: SUN's TCP BUG ??

>Years ago we found that logins were slow because the system had to
>check the quota of all NFS mounted partitions. We fixed this by making
>/usr/ucb/quota a do nothing routine.

You can also mount the file systems on the client with the "noquota"
option (i.e., the *NFS* mount done by the *client* should have the
"noquota" option; that's unrelated to the "quota" option, which, when
used on the *server*, specifies that quotas should be used).

That option causes the "quota" program not to bother checking whether
the user is over quota on that particular file system.  The *server*
will still check whether they're over quota, of course....

-----------[000010][next][prev][last][first]----------------------------------------------------
Date:      Mon, 3 May 1993 02:09:25 GMT
From:      rlm@helen.surfcty.com (Robert L. McMillin)
To:        comp.protocols.tcp-ip
Subject:   Re: NIS & DNS questions

On 1 May 1993 20:28:17 GMT, barmar@think.com (Barry Margolin) said:

> In article <4.473.362.0N565040@euronetis.no> rune.mossige@euronetis.no (Rune Mossige) writes:
>>I have also set up two of the Sun's (one on each side of the 
>>router...) with NIS, and stumbled into a problem when I was going to 
>>add the other unix boxes to NIS. First, the login shell problem. From 
>>what I understand, the NIS passwd map will be the same on all 
>>machines, so all users must use the same login shell. But, SUN have 
>>the C-shell as default and have not even included the Korn shell, 
>>while the RS have the Korn shell as default. 
 
> Korn shell is available for Suns; I think we got it from the AT&T
> Toolchest.  I believe it's bundled with Solaris 2.x as well.

Another solution to this problem is to force everyone to use GNU bash,
which (IMHO) is better than either the C shell or the Bourne shell; it
retains the Bourne shell's robustness with the C shell's history
mechanism, and skips the C shell's lamer extensions.
--

Robert L. McMillin | Surf City Software | rlm@helen.surfcty.com | Dude!
"What's taking so long?  It's only typing!"
	-- a marketing manager posing as a software manager


-----------[000011][next][prev][last][first]----------------------------------------------------
Date:      Mon, 3 May 1993 04:43:48 GMT
From:      andy@research.canon.oz.au (Andy Newman)
To:        comp.protocols.tcp-ip
Subject:   Re: Summary: ALLO and FTP



Last week I posted a query on the use of the ALLO command in various
FTP servers and clients. Here is a summary of the (two) responses ;-)

To sum up you can say that the ALLO command is generally ignored as
not many real systems require it. Only MVS-hosted servers were noted
as requiring it.

Thanks to 

	Gordon C. Spoelhof <spoelhof@Kodak.COM>
	Stephen C. Trier <trier@slc6.INS.CWRU.Edu>


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

>  I have a question about the ALLO ("allocate") command in FTP. Although
> there is a brief mention of ALLO in the RFC that's about all I can
> find.

The wording is rather loose...  Basiclly it is provided for servers
which "can" use it and clients which know that servers should use
it...  Although required in RFC 1122, most servers return the 202
reply (vacuuous support) rather than the 200 reply (supported positive
response)...

> We have a system that is a potential FTP server but due to the simple
> file system it uses space must be allocated prior to sending the file.
> I've been over the RFCs and can find very little mention of ALLO but
> I'm sure others have come across this before.
> 
> Questions:
> 
>     What other FTP servers require ALLOs?

Few modern servers require the use of ALLO.  The notion of cheap disk space in 
this new "virtual" resource world has virtually %^) wiped out its
use... Except for servers like mine, and yours...  Of those which
implement ALLO, the only ones I have seen are those which use the
basic form of ALLO --

                 "ALLO <bytes>".

I have never seen a server which requires the record format:

                 "ALLO <records> R <bytes>

>     How do they handle  this at the user interface? 

Since few servers support it, few clients support it as well.

>     Do they force the users to use the QUOTE command?

Yes, although I am fortunate as most of my users are automated or known, in 
which case I put the ALLO command in the .netrc (unix based clients)...

I now work with default allocations depending on transfer type, for example I 
start with 32K for ASCII files and 1MB  for binary files.   I have been working 
toward providing file growth capabilities.  This effort has proved helpful in 
working around resource problems (as above) but also enabled me to improve I/O 
and reduce buffer copying -- a real boon to FTP performance!

Example:  New code (my own I/O) took 4 weeks to design, document, develop, 
and test.  Binary transfer rates went from 600KByte/sec to 850+KByte/sec...  
Only 500 lines of C code to implement on small real time kernel...

I hope to eleminate the absolute need default allocations (or required use of 
ALLO) for my server soon.  I will keep default allcations (albiet smaller sizes) 
and ALLO available for performance reasons, however.


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

From: Stephen C. Trier <trier@slc6.INS.CWRU.Edu>

MVS requires it.  It, too, requires preallocation of files in an effort
to avoid fragmentation.

Every FTP client I've seen requires use of the quote command in order to
use ALLO.  I'd guess the MVS FTP client uses it, but I just managed to
get myself locked out of my MVS account, so I can't check.  :-(

The FTP server on our Suns accepts ALLO but ignores it, as does our local
DOS FTP server.

-- 
Andy Newman (andy@research.canon.oz.au)
"gentle suggestions being those which are written on rocks of less than 5lbs"
				Tracy Nelson in comp.lang.c

-----------[000012][next][prev][last][first]----------------------------------------------------
Date:      3 May 93 06:44:50 GMT
From:      melman@FibHaifa.com (David Melman)
To:        comp.protocols.tcp-ip
Subject:   Comer's/Stevens's TCP implementation

I am interested in hearing from anybody who has used or considered
using this TCP (just TCP, not IP etc...)  implementation from
Comer/Stevens "Internetworking with TCP/IP Volume II in a real
product, e.g. a router?

Can this code be considered "commercial quality"?

Are there good alternatives?

Thanks for sharing,

David Melman 

Fibronics
Matam Industrial Park
Haifa 31905, Israel

Internet: melman@FibHaifa.com
Tel:      Intl+972+4-313313
Direct:   Intl+972+4-313642
Fax:      Intl+972+4-550550
Telex:    46857 FIBRO IL

-----------[000013][next][prev][last][first]----------------------------------------------------
Date:      Mon, 3 May 1993 06:58:53 GMT
From:      ben@rex.uokhsc.edu (Benjamin Z. Goldsteen)
To:        comp.protocols.tcp-ip
Subject:   Proper TCP/IP ports for LPD

     I am looking into using the PLP print spooler.  It looks pretty
good, but now I finding these weird inconsistencies in the general
protocol (or rather the way it is implemented).  According to the RFC
(don't have # handy, sorry), all ports must be in [721,731] (I think
that was the range).  This jived with what I was seeing when I tried to
test various things out -- I couldn't contact other machines when I
tried to work outside that range.  A small change to the source and
things were on there way again...except...now, other machines are trying
to access PLP on a reserved port outside that range...and it is
refusing... 

     So my question is: what is the standard?  Should I just make PLP
stick to [721,731] for initiating, but allow any connection < 1024?  It
seems my other machines are acting the exact opposite way -- initiating
connections on any port, but only accepting on [721,731]...

Thanks
P.S.Other machines include SGI w/Berkeley LPD and VAX/VMS w/UCX 2.0.  I
hanv't tried my SVR4 machine...nor my AIX box since we only have one and
that is the machine where I am trying PLP first....
-- 
Benjamin Z. Goldsteen

-----------[000014][next][prev][last][first]----------------------------------------------------
Date:      Mon, 3 May 1993 08:01:02 GMT
From:      skl@wimsey.bc.ca (Samuel Lam)
To:        comp.unix.sysv386,comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc,comp.sys.novell
Subject:   Re: SCO TCP/IP <> Netware TCP/IP problem

In article <3@mhinfo.UUCP>, carrato@mhinfo.UUCP (Tony Carrato) wrote:
>It appears that either a) the SCO system is set up wrong somehow ...

That's probably it.  Check the SCO box's subnet mask to make sure
it's using the correct value.  Also check its routing table for a
route to the other network via the Novell router.

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

"NetNews on CD's" product information: <NewsCD@CDPublishing.COM>


-----------[000015][next][prev][last][first]----------------------------------------------------
Date:      2 May 1993 20:02:52 +0930
From:      hart@flash.pax.tpa.com.au (Leigh M Hart)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject:   PC-Based Terminal Server Software: In Production


I have read several postings in tcp-ip newsgroups regarding the
(non)existence of PC based terminal server software (that is,
software running on an IBM PC, with network card, and multi-port
serial board, to act as a terminal server - similar to xyplex/annex/etc).

I did some hunting around, and as far as I know there are no PC terminal
server packages around, so I have started production on a PC based
terminal server.

The server will include the stanard features that most existing (real)
termainl servers have - TCP/IP and DECNET/LAT support, SLIP and
standard interactive lines, multi-level help, multiple sessions,
support for a wide variety of multi-port cards (ie: Stallion cards,
etc).

Any suggestions anyone might have will be taken into consideration,
as it is often the users of such products that come up with the good
ideas, not the programmers!

The server is as yet un-named, so name suggestions are also welcome.

The server currently supports 2-4 standard RS232 ports, TCP/IP (telnet,
rlogin).  It is definately still in the infancy stage.

There is one suggestion that I have received that I still am not sure
about - that is to allow the PC to monitor the sessions - ie: at a
touch of a key, display what is happening on any given port.

I would appreciate any input on the moral/legal/whatever implications the 
above "feature" would have :)

Email replies prefered.

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

-----------[000016][next][prev][last][first]----------------------------------------------------
Date:      Mon, 3 May 1993 14:05:44 GMT
From:      burt@hart.Princeton.EDU (Burton Rosenberg)
To:        comp.protocols.tcp-ip
Subject:   Two IP networks -> one physical network

Is it possible for a single physical ethernet to be associated
with two or more IP networks? In our situation, as it is, if
the sender's IP network address matches that of any of several
IP addresses, ARP should be queried for the ethernet address
of the destination host. As a receiver, a single ethernet
port should be able to receive packets with any of two or more
IP addresses.

We are in the process of merging networks and this would permit
this operation to go smoothly, without reassigning IP addresses
to machines on defunct networks, as well as allow us to maintain
"control" over a network, essentially for assigning IP addresses
out of our private subnet IP addresses.

Thanks.

-burt


-----------[000017][next][prev][last][first]----------------------------------------------------
Date:      Mon, 3 May 1993 14:21:18 GMT
From:      heka@ost.NoSubdomain.NoDomain (hedie kamoun)
To:        comp.protocols.tcp-ip
Subject:   Toggle of Nagle option

Hi TCP-wiz:es,
	I turning to this community in hope that you'll be able to 
help me out with a few things (clear things up).

	I've been told that it is possible to turn on/off the Nagle-
algoritm using berkeley sockets, in my case SunOS. My question is if
anybody out there might have any experience with "toggling" of this 
alleged socket-option for which I can't find any documentation.
I'd also appreciate a hint on where to find some pragmatic info on this
algoritm.

	My second question is maybe even less well defined but I'll give
it a shot anyway. Does anybody know how to read an allocated socket from
the kernels memory, I guess with /dev/kmem, but if so where what offset 
should I use if this is at all possible.

 Thank you for any light you might shed on these subjects, whatever you 
and are willing to share bordering this area.
  
   	Best regards Hedie Kamoun
		Email: heka@ppvku.ericsson.se 



-----------[000018][next][prev][last][first]----------------------------------------------------
Date:      3 May 93 21:20:53 MDT
From:      jrd@cc.usu.edu (Joe Doupnik)
To:        comp.protocols.tcp-ip
Subject:   Re: Two IP networks -> one physical network

In article <1993May3.140544.20097@Princeton.EDU>, burt@hart.Princeton.EDU (Burton Rosenberg) writes:
> Is it possible for a single physical ethernet to be associated
> with two or more IP networks? In our situation, as it is, if
> the sender's IP network address matches that of any of several
> IP addresses, ARP should be queried for the ethernet address
> of the destination host. As a receiver, a single ethernet
> port should be able to receive packets with any of two or more
> IP addresses.
> 
> We are in the process of merging networks and this would permit
> this operation to go smoothly, without reassigning IP addresses
> to machines on defunct networks, as well as allow us to maintain
> "control" over a network, essentially for assigning IP addresses
> out of our private subnet IP addresses.
> 
> Thanks.
> 
> -burt
-----------
	It's called "multiple homing" and few machines support it. Instead
take your friendly router (say a cisco or equivalent) and ask it to fake
the second network on the same wire. That's a popular trick, even if it
is to be regretted technically. Different IP "networks" result in ARPing
for a router rather than a host. If you can most of us would recommend
bringing net.sanity to the wire with but one IP "network" on it. Having
multiple nets on the same wire characteristically doubles the network traffic:
pkt to the router, pkt back from the router to the destination.
	Joe D.

-----------[000019][next][prev][last][first]----------------------------------------------------
Date:      3 May 93 17:35:48 GMT
From:      my00@gte.com (Michael Yuen)
To:        comp.protocols.tcp-ip
Subject:   rfc for ip protocol ID

Can someone refer me to a RFC that documents all the ip protocol id's?
Thanks in advance.

-Mike

-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Michael Yuen                   Tel - (617)466-2919
GTE Labs                          Internet - my00@gte.com
40 Sylvan Road                 FAX - (617)466-2130
Waltham, MA 02254

-----------[000020][next][prev][last][first]----------------------------------------------------
Date:      Mon, 03 May 1993 22:04:52 GMT
From:      gryphon@openage.openage.com (The Golden Gryphon)
To:        comp.unix.sysv386,comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc,comp.sys.novell
Subject:   Re: SCO TCP/IP <> Netware TCP/IP problem

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

>In article <3@mhinfo.UUCP>, carrato@mhinfo.UUCP (Tony Carrato) wrote:
>>It appears that either a) the SCO system is set up wrong somehow ...
 
>That's probably it.  Check the SCO box's subnet mask to make sure
>it's using the correct value.  Also check its routing table for a
>route to the other network via the Novell router.

I think not.  Your Novell is probably acting as a learning bridge.  It knows
which machines are on each side of the LAN as soon as they talk.  If you moved
PC-1 to the non-SCO segment and rebooted the Novell server and tried again,
then you could be sure this was the case if it worked.

-- 
The Golden Gryphon 				gryphon@openage.COM
"The Crown Jewel of the American Prison System." - President Bill
Clinton on living in The White House.
Openage - The Premier SCO UNIX integrator in the Washington D.C. area

-----------[000021][next][prev][last][first]----------------------------------------------------
Date:      Mon, 3 May 1993 23:45:11 GMT
From:      sekine@gumby.dsd.trw.com (Nancy Y. Sekine)
To:        comp.protocols.ibm,comp.protocols.misc,comp.protocols.tcp-ip
Subject:   Printing from an IBM mainframe to printers on an Ethernet backbone



I'm looking for info on products that will enable printing from IBM
mainframe applications to various printers on an Ethernet backbone 
(AppleTalk printers, Banyan VINES printers, UNIX lpd-served printers, etc.).

Right now we're evaluating Interlink Computer Sciences' Enterprise Print
Services software which runs on the mainframe and implements lpr and lpd
through a TCP/IP interface.  We've investigated lpd servers to serve
the printers (Incognito Software's UNIX-to-VINES Print Service to
provide lpd capability to Banyan VINES printers;  CAP on a UNIX platform
to provide lpd capability to AppleTalk printers;  etc....).
We have Interlink's SNS/TCPaccess providing the TCP/IP capability on the
mainframe.  Our SNA network is separate from our Ethernet backbone (i.e.,
we're not running SNA over Ethernet).

Our goal is to find a solution to allow our customers to print from
any mainframe application (such as report generation facilities on TSO
and various transactions on IMS) to their "local" network printers, no
matter what protocol.  I realize that there may be some "adjustments"
involved (such as implementing lpd servers on the customer side in the
case I mentioned above), but I'm open to any potential solutions out there.

It's been a while since I've checked what's out there, so I was wondering
if there are any new products that will provide this capability, or maybe
there are some older products that I missed...

Thanks!  And please send replies directly to me at sekine@gumby.dsd.trw.com.

Nancy Sekine
TRW Space and Electronics Group
Communications Services
One Space Park
Redondo Beach, CA 90278
sekine@gumby.dsd.trw.com

-----------[000022][next][prev][last][first]----------------------------------------------------
Date:      4 May 1993 01:42:50 GMT
From:      trier@odin.ins.cwru.edu (Stephen C. Trier)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc,comp.sys.novell
Subject:   Re: SCO TCP/IP <> Netware TCP/IP problem

In article <1993May03.220452.28684@openage.openage.com> gryphon@openage.openage.com (The Golden Gryphon) writes:
>I think not.  Your Novell is probably acting as a learning bridge.

Novell servers route.  They don't bridge, even though older Novell manuals
call NetWare IPX routers "bridges".  When they handle TCP/IP, they
definitely route.

-- 
Stephen Trier (trier@ins.cwru.edu)   Star Trek dialog mistake of the week:
Network Software Engineer              "We've tried every decryption key
IRIS/INS/T                               on record, Captain."
Case Western Reserve University             - Geordi LaForge, ST:TNG, 5/1/93

-----------[000023][next][prev][last][first]----------------------------------------------------
Date:      Tue, 4 May 1993 04:05:28 GMT
From:      vjs@rhyolite.wpd.sgi.com (Vernon Schryver)
To:        comp.protocols.tcp-ip
Subject:   Re: Two IP networks -> one physical network

In article <1993May3.140544.20097@Princeton.EDU>, burt@hart.Princeton.EDU (Burton Rosenberg) writes:
> Is it possible for a single physical ethernet to be associated
> with two or more IP networks? In our situation, as it is, if
> the sender's IP network address matches that of any of several
> IP addresses, ARP should be queried for the ethernet address
> of the destination host. As a receiver, a single ethernet
> port should be able to receive packets with any of two or more
> IP addresses.
> 
> We are in the process of merging networks and this would permit
> this operation to go smoothly, without reassigning IP addresses
> to machines on defunct networks, as well as allow us to maintain
> "control" over a network, essentially for assigning IP addresses
> out of our private subnet IP addresses.


Yes, this technique works great for such transitions.

There are some oddities associated with machines seeing
broadcasts for the wrong network, but none that are likely
to be noticed during a few weeks or even months during
renumbering.

It's often easier to just use two different ethernet interfaces
on your router, both connected to the same physical wire to
manage the gatewaying between the old and the new IP networks.


Vernon Schryver,  vjs@sgi.com

-----------[000024][next][prev][last][first]----------------------------------------------------
Date:      Tue, 4 May 1993 04:10:56 GMT
From:      dls@mentor.cc.purdue.edu (David L Stevens)
To:        comp.protocols.tcp-ip
Subject:   Re: Comer's/Stevens's TCP implementation

In article <690@ariadna.FibHaifa.com>, melman@FibHaifa.com (David Melman) writes:
> ....
> Comer/Stevens "Internetworking with TCP/IP Volume II in a real
> product, e.g. a router?
>
> Can this code be considered "commercial quality"?
> 

	Well, I wrote it, and I can say "no." It wasn't designed to be a
commercial product-- it's designed to illustrate the concepts of the
protocol suite and the issues involved in implementing them. It is not
particularly fast (not extremely slow, either), and there are certainly places 
where both space and time optimizations could be made, but most at the expense
of clarity.
	It also has not been through 10 years of production use, and has not
had the benefit of hundreds of people debugging and improving it and exercising
it on tens of thousands of machines, like, for example, the BSD code. Nor does
it have the kind of support that commercial products do-- it has one person
working on it very occasionally in his spare time.
	That said, it is small, and probably better documented (by the book)
than any other implementation, and it should be fairly easy to modify. That
makes it a good choice for developing new protocols, or extending and testing
old ones. It also may help in understanding what other implementations are
doing in a different way to get the same effect.
	It has been used in commercial products, usually where its
small size and simplicity is a necessity, but if you're looking for highly
reliable, high-performance networking code, you really want a commercial
implementation. Or perhaps the Berkeley code and someone who knows it well
to maintain it for you.
-- 
					+-DLS  (dls@mentor.cc.purdue.edu)

-----------[000025][next][prev][last][first]----------------------------------------------------
Date:      4 May 93 11:55:43
From:      jim@cs.strath.ac.uk (Jim Reid)
To:        comp.protocols.tcp-ip
Subject:   Re: Two IP networks -> one physical network

In article <hmb423s@rhyolite.wpd.sgi.com> vjs@rhyolite.wpd.sgi.com (Vernon Schryver) writes:

   In article <1993May3.140544.20097@Princeton.EDU>, burt@hart.Princeton.EDU (Burton Rosenberg) writes:
   > Is it possible for a single physical ethernet to be associated
   > with two or more IP networks?

   There are some oddities associated with machines seeing
   broadcasts for the wrong network, but none that are likely
   to be noticed during a few weeks or even months during
   renumbering.

Er... I hope you don't consider a broadcast storm as something that's
likely to go unnoticed. If you have two or more IP networks on the
once cable, *everyone* has to take care over broadcast addresses.
Suppose something like routed or rwhod broadcasts on one of the IP
networks. A host on another IP network will see this broadcast - it's
on the same cable. If it's not configured properly, the host may
decide to forward this packet back into the network it came from,
causing a flurry of broadcasts. [It might even forward the broadcast
packet that it sent too....] This can lead to an infinite loop and a
saturated network.

Even if you can avoid the broadcast problems, you may need to think
carefully about ICMP redirects and routing between the IP networks.

It's probably better and safer all round if you separate the IP
networks on to physically separate networks.

		Jim

-----------[000026][next][prev][last][first]----------------------------------------------------
Date:      Tue, 4 May 1993 07:49:00 GMT
From:      karl@empirical.com  (Karl Auerbach)
To:        comp.protocols.tcp-ip
Subject:   Re: Interoperability Convention

> Does anyone has the info on the interoperability convention ? (tie, date, location, 
> etc.) Or did I miss it ? Thank you. 
Are you talking about the TCP/IP bakeoff?  If so, you missed it.
The first annual TCP/IP bakeoff was held -- let me read my t-shirt --
Feb 8-12 of this year at FTP Software.  It was sponsered by TGV,
Empirical Tools and Technologies, FTP, and Intercon.
Overall, it was a pretty useful event.
There will be another bakeoff.  Notice will be posted far and wide.
			--karl--

-----------[000027][next][prev][last][first]----------------------------------------------------
Date:      Tue, 4 May 1993 09:49:46 GMT
From:      queloz@bernina.ethz.ch (Ronald Queloz)
To:        comp.protocols.tcp-ip,comp.unix.programmer
Subject:   Broadcast using TCP/IP sockets, how to do?

Hi netlanders,

Can somebody tell me how to do a broadcast send using berkeley sockets
running on a tcp/ip protocol stack? Is there some sample code available?
Anybody having some experience in doing this with XTI/TLI?

Thanks in advance

Ron.

-----------[000028][next][prev][last][first]----------------------------------------------------
Date:      Tue, 4 May 1993 11:26:25 GMT
From:      frisicej@ldoc03.ldc.dupont.com
To:        comp.protocols.tcp-ip
Subject:   question Regarding BIN

We are currently testing TGV Multinet V3.2 with the
load balancing feature for VAX Clusters.

The way this works is that the cluster IP name is
defined in the authoritative DNS as a list of NS
records, each pointing to a cluster member.

The query from a resolver is answered by TGV with the
list of cluster members in order of preference. The TTL
of those records is 5 secondes.

Now this is where the problem starts. The first query
is coming from TGV via a number of Name Servers and has
the original TTL of 5 sec. Subsequent queries, however,
are answered by the Name Servers from their cache and
the TTL is 5 Minutes, due to the BIND V 4.8.1 minimum TTL.

We asked TGV to use a TTL of 0 so that (RFC 1035) it
signals the Name Servers and resolvers not to cache the
record. This is what they answered:


    "BIND (basically what 99.9% of the nameservers on
the Internet are based on) doesn't properly handle
records with zero TTL. The BIND implementation takes
all responses and caches them, and then generates
answers from that cache. It would be difficult to fix
BIND to take zero TTL records and let them bypass this
cache, and it would be impossible to get every
nameserver on the Internet upgraded."

I wonder if this is really true and if so how come that
the vendors are not following RFC 1035. Does anybody
have any input on this? I would be glad to receive some
socond opinions.

A second issue. Does anybody know about DNS resolver
implementations (PC TCP/IP stacks, workstations,
Terminal Servers, etc.) that cache answers to DNS
queries?

Thank you.

-----------[000029][next][prev][last][first]----------------------------------------------------
Date:      Tue, 4 May 1993 11:49:36 GMT
From:      petervc@sci.kun.nl (Peter van Campen)
To:        comp.protocols.tcp-ip
Subject:   Re: RARP through a Router?

In <fred_sC5vKwt.GL7@netcom.com> fred_s@netcom.com (Frederick Scott) writes:

>tli@cisco.com (Tony Li) writes: 
 
>>In article <1qeqbaINNkka@charnel.ecst.csuchico.edu>
>>dpike@oavax.csuchico.edu (Dan Pike) writes: 
>>    Why am I not able to RARP across a router?  I have a bridge and our
>>    management station on the same Cabletron MMAC, but I'm still not able to
>>    RARP an IP address to the bridge.  The two devices are in different
>>    subnets (one is in .78.xxx and the other is in .80.xxx).  Interface 0 of
>>    our AGS+ goes to a port on the FOMIM which also connects all of our
>>    buildings via fiber.  The subnet mask of each of the buildings on campus
>>    is set up as though it was a class c address.  Why will the router not
>>    allow the management station to RARP an IP address to the bridge?  Any
>>    help you can offer would be greatly appreciated.
>>    
>>RARP is an unroutable protocol.  It must be bridged.
 
>More specifically, I believe RARP is a *broadcast* protocol (at least the
>request is).  Broadcast packets are not normally routed, the reasoning being
>that if they were, one broadcast on some little net somewhere would eventually
>make its way to every net in the universe.  Worse yet, any redundant network
>routed links (and we know there are plenty in the Internet), they would
>rebroadcast them 'round and 'round forever (as RARP has no time-to-live
>counter, as IP does) repeating them back to their source and everywhere else
>on every cycle, eventually destroying the network.  Bridges have protection
>against this phenomenon designed in.

I thought it could be of interest to share my experiences:
- Some time ago we booted a diskless Sun-SLC (SunOS4.0.3) through a
  cisco AGS+, without any help from a server on its own subnet, just to
  see if it worked. It did!
  Of course we needed to bridge RARP, and forward some other UDP-broadcasts
  to a server on a different subnet.
- When we tried it out again on SunOS4.1.2 the SunOS rarpd refused to
  give a RARP reply, because the client was not on his subnet.

I think a rarpd should not know anything about subnet-masks, since
RARP is not IP, but I'm not sure whether Sun will change this.


			Regards,
			Peter van Campen
-----------------------------------------------------------------------------
Peter van Campen, petervc@sci.kun.nl,  Computer and Communications Department
Faculty of Science, University of Nijmegen, 6525 ED NIJMEGEN, The Netherlands
-----------------------------------------------------------------------------

-----------[000030][next][prev][last][first]----------------------------------------------------
Date:      4 May 93 20:42:32 -0500
From:      harvey@indyvax.iupui.edu
To:        comp.protocols.tcp-ip
Subject:   Re: Two IP networks -> one physical network

In article <1993May4.195123.25003@frcs.Alt.ZA>, paul@frcs.Alt.ZA (Paul Nash) writes:
> jim@cs.strath.ac.uk (Jim Reid) writes:
>
>> Er... I hope you don't consider a broadcast storm as something that's
>> likely to go unnoticed. If you have two or more IP networks on the
>> once cable, *everyone* has to take care over broadcast addresses.
>
> I recently saw something like this with two IP subnets on the same
> physical wire, a PC-Router with two legs onto that wire, and RIP.
> Whenever a big Cisco sent out a RIP update, one leg would pick it
> up, re-broadcast out the other leg, which the first would pick up
> again, and re-broadcast ... until the hopcount exceeded 16.  This
> would take a second or two at a time, and was quite fun to watch.

If you are using Ciscos you can have multiple subnets on one physical
cable by setting a "secondary address" on that subnet on the interface
on that cable.  Each Cisco on the physical cable has to have a secondary
address set on its interface on that cable.  I don't know how it works
with RIP but it works fine with IGRP.  We've used this feature here at
IUPUI mostly for bridging a new subnets onto the backbone until a building's
router is in place.  It would seem to be ideal for migrating from one set
of addresses to another as well.  I would expect that other brands of
dedicated routers have similar features.
--
James Harvey    IUPUI OIT Technical Support -- VMS/Unix/Networks
harvey@iupui.edu  uucp:iugate!harvey  bitnet:harvey@indyvax

-----------[000031][next][prev][last][first]----------------------------------------------------
Date:      Tue, 4 May 1993 12:57:37 GMT
From:      sls@tct.com (Scot Schneebeli)
To:        comp.protocols.tcp-ip
Subject:   tcp checksum errors

 I'm not sure that this is the correct place for the following question, but
 there didn't seem to be a better one, so .....

 I've been getting checksum errors when sending data to other machines on our
 network. I've RTFM and it's useless (unless you need to know how to ping).

 What is weird is that if the file I'm transmitting has a size >= 4096 it
 gets the checksum errors on the other side and keeps resending/getting errors
 until it times out. I can _receive_ a file of _any_ size, no problem. Small
 files transmit without problems. NFS works. I've swapped out ethernet cards,
 no help. I've compared kernel configurations with other computers here which
 don't have the problem. Can't see any real differences which should cause these
 problems. 

 I'm running Interactive's V.3 on a 486, the other machines are 386s. I'm not
 knowledgeable enough to know if this would cause problems. HELP!

 I'm open to any suggestions on how to solve this or if there is a better
 place to ask this question. Thanks.

 Scot Schneebeli                         <sls@tct.com>


-----------[000032][next][prev][last][first]----------------------------------------------------
Date:      4 May 1993 14:10:51 GMT
From:      dwolfe@lerc.nasa.gov
To:        comp.protocols.tcp-ip
Subject:   DCE RPC vs ONC RPC ?

Could someone post a summary of these ? 

	What level of interoperability, if any...
	
	Session layer protocol differences ....

Thanks.

===========================================================================
Dana Wolfe                                                                                                   dwolfe@lerc.nasa.gov
Telecommunications and Networking                     
NASA Lewis Research Center                                                                      Phone: (216) 433-8270
Cleveland, OH                                                                                               FAX: (216) 433-8000
===========================================================================


-----------[000033][next][prev][last][first]----------------------------------------------------
Date:      Tue, 4 May 1993 14:11:41 GMT
From:      vjs@rhyolite.wpd.sgi.com (Vernon Schryver)
To:        comp.protocols.tcp-ip
Subject:   Re: Two IP networks -> one physical network

In article <JIM.93May4115543@lister.cs.strath.ac.uk>, jim@cs.strath.ac.uk (Jim Reid) writes:
> In article <hmb423s@rhyolite.wpd.sgi.com> vjs@rhyolite.wpd.sgi.com (Vernon Schryver) writes:
>    In article <1993May3.140544.20097@Princeton.EDU>, burt@hart.Princeton.EDU (Burton Rosenberg) writes:
>    > Is it possible for a single physical ethernet to be associated
>    > with two or more IP networks?
> 
>    There are some oddities associated with machines seeing
>    broadcasts for the wrong network, but none that are likely
>    to be noticed during a few weeks or even months during
>    renumbering.
> 
> Er... I hope you don't consider a broadcast storm as something that's
> likely to go unnoticed. If you have two or more IP networks on the
> once cable, *everyone* has to take care over broadcast addresses.
> Suppose something like routed or rwhod broadcasts on one of the IP
> networks. A host on another IP network will see this broadcast - it's
> on the same cable. If it's not configured properly, the host may
> decide to forward this packet back into the network it came from,
> causing a flurry of broadcasts. [It might even forward the broadcast
> packet that it sent too....] This can lead to an infinite loop and a
> saturated network.
> 
> Even if you can avoid the broadcast problems, you may need to think
> carefully about ICMP redirects and routing between the IP networks.
> 
> It's probably better and safer all round if you separate the IP
> networks on to physically separate networks.
> 
> 		Jim


Sure, and it's better to have just one IP network to not waste IP
numbers.  It's better and safer to not have any misconfigured
machines.  While we're wishing for nice things, let's also make me rich.

Broadcast storms can be a problem, but if your routers are so broken
that they forward broadcasts, then you don't need to have two networks
on one wire to have problems.

If you need to renumber a few hundred or even a just a few dozen hosts,
to move them logically but not physically from one IP network to
another, the hack of using 2 IP networks on one wire is in fact the
most reliable solution.  The other solutions are:

    -string another wire, and as each host is renumbered, physically move it,
      probably leaving the old wire in place when finished.

	It's obviously far more expensive and quite unreliable to pull
	a new wire, not to mention fiddling with drop cables and so on.

	If you're using hubs (e.g. 10BaseT), you could buy a second
	hub, and re-punch each host as it's renumbered.  Hubs are not
	cheap, take precious closet space and power, and at least with
	some punch down blocks, you only get a few punches before they
	must be replaced.  Punch down blocks are cheap, but the labor
	to replace them is anything but cheap.  The inevitable hassles
	when someone makes the wrong new punches are worse than when
	some uses the wrong new host number.

    -renumbering all of the hosts at once.

	This works fine for a handful of machines, or if all of the
	machines are toys or there are other reasons why no one cares
	if they work for a week.

	In real life, where the machines must stay up, you simply can't
	use red letter days.


I've seen and helped with moves with all 3 techniques, and the clear
winner has been kludging the IP addresses, not extra hardware or
red-letter days.


Vernon Schryver, vjs@sgi.com

-----------[000034][next][prev][last][first]----------------------------------------------------
Date:      4 May 93 19:32:08
From:      amoss@shuldig.cs.huji.ac.il (Amos Shapira)
To:        comp.protocols.tcp-ip,comp.unix.programmer
Subject:   Re: Broadcast using TCP/IP sockets, how to do?

queloz@bernina.ethz.ch (Ronald Queloz) writes:

   Can somebody tell me how to do a broadcast send using berkeley sockets
   running on a tcp/ip protocol stack? Is there some sample code available?
   Anybody having some experience in doing this with XTI/TLI?

You mean TCP broadcast??  No such thing.

UDP broadcast means you either "connect" to the broadcast address (that's
virtual since you don't actually connect to this address but tell the kernel
that this is the address for packets, so you can use write(2) and send(2))
or do sendto(2) to the broadcast address.  Old BSD systems required superuser
and doing "setsockopt(s, ..., SO_BROADCAST)" to make broadcasts work, "newer"
systems (most of the "common" systems today, as far as I know) will let any
user just do "sendto" to the broadcast address.

Maybe you would like to look in the examples from Stevens' and/or Comer which
should be available for anonymous from ftp.uu.net.

Hope this helps,

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

-----------[000035][next][prev][last][first]----------------------------------------------------
Date:      Tue, 4 May 1993 16:15:17 GMT
From:      erick@sunee.uwaterloo.ca (Erick Engelke)
To:        comp.protocols.tcp-ip
Subject:   Re: Two IP networks -> one physical network

 vjs@rhyolite.wpd.sgi.com (Vernon Schryver) writes:
>, jim@cs.strath.ac.uk (Jim Reid) writes:
>> vjs@rhyolite.wpd.sgi.com (Vernon Schryver) writes:
>>    burt@hart.Princeton.EDU (Burton Rosenberg) writes:
 
>>    > Is it possible for a single physical ethernet to be associated
>>    > with two or more IP networks?
>> 
>>    There are some oddities associated with machines seeing
>>    broadcasts for the wrong network, but none that are likely
>>    to be noticed during a few weeks or even months during
>>    renumbering.
>> 
>> Er... I hope you don't consider a broadcast storm as something that's
>> likely to go unnoticed. 
>> ...
>> causing a flurry of broadcasts. [It might even forward the broadcast
>> packet that it sent too....] This can lead to an infinite loop and a
>> saturated network.

Actually, no.  IP's TTL means you would have to have a pretty broken
router to have such an infinite loop.  In practice, even with lots
of unknown hardware and software, it works out pretty easy.

>> It's probably better and safer all round if you separate the IP
>> networks on to physically separate networks.

This is really not so bad.  There is a lot of extra traffic, but
it's workable for the period of renumberring, say a few days up
to a month or so.

I've had to do this several times too, Vernon's method is simple
and workable.

My only advice is to keep a network monitor on the net and look
at your biggest packet producers if they seem to be excessive.  And
the only special attention has to be paid to devices which connect
the two subnets, like routers.

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

-----------[000036][next][prev][last][first]----------------------------------------------------
Date:      Tue, 4 May 1993 16:22:26 GMT
From:      cpearce@nemesis.acs.unt.edu (Chris Pearce)
To:        comp.unix.admin,comp.protocols.tcp-ip,alt.internet.access.wanted
Subject:   Help with non-conformant IP addresses

Please excuse me if I have posted this article to an inappropriate group. It
concerns a subject for which I could not determine a completely appropriate
newsgroup.

I'm currently trying to get my company connected to the Internet. The problem
is that we currently have an IP network in place that uses IP addresses not
assigned to our company by NIC. This network of about 200 machines may
require significant effort to reconfigure to conform to the class C address
currently assigned to us.

One possibility I've been looking into is that of using a router to hide
non-conformant addresses from the Internet. Hosts that can connect to the
Internet would have conformant IP addresses, of course, but it should be
possible to set up a router so that if a local host wished to talk to one
of the non-conformant machines, the router could place the packet on the
non-conformant network. This, of course, would create a blind spot for us
in the Internet, but such a blind spot is an acceptable loss.

However, I am not sure whether this scheme does not have costs of its own.
Several questions remain in my mind. Would such a scheme have other, more
dangerous side effects? How high would the maintenance costs of such a scheme
be? Would this scheme work at all? Does anyone have any horror stories about
maintaining a non-conformant IP address? And how does this scheme balance
against the short-term pain of bringing our IP network into conformance?

If you know of a more appropriate group to post this question, please let
me know. I prefer email replies to posted replies, but if that means you
won't reply, then by all means post!

Eagerly awaiting your comments,
Chris Pearce, cpearce@nemesis.acs.unt.edu
-- 
Chris Pearce -- cpearce@nemesis.acs.unt.edu
How do you say delicious?                          How do you say delovely? 
How do you say delectable, define?             How do you say - deGORgeous? 
How do you say dewith-it?                            How do you say Delite?

-----------[000037][next][prev][last][first]----------------------------------------------------
Date:      4 May 1993 18:50:54 GMT
From:      eoq@vthnw.cvm.msu.edu (Edward Quillen)
To:        comp.protocols.tcp-ip
Subject:   Remote BACKUP server software

Is there anything out there that is wide spread and well defined that
handles backing up systems from different platforms.

More specifically, a TCP/IP server program (like FTPD or RCPD) that accepts
backup requests from clients and backs up data and/or files from the clients.

I'm about to begin developing one, but thought I would check the net first.

Some things it would handle:
  +Multi-user/security (different clients use same server)
  +Files with arbitrary data attached (permissions-unix,trustees-novell,...)
  +Storage to files or devices (at server)
  +Backup,Restore,List,... from client or server

Any references would be greatly appreciated!

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
|  ED (Edward Quillen)   (517) 336-1293 || "I'll see you again when the |
|  Vet Teaching Hosp.    System Admin.  ||  stars fall from the sky"    |
|  Email: quillen@cps.msu.edu           ||          U2 / ONE TREE HILL  |
 =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

-----------[000038][next][prev][last][first]----------------------------------------------------
Date:      4 May 93 19:51:23 GMT
From:      paul@frcs.Alt.ZA (Paul Nash)
To:        comp.protocols.tcp-ip
Subject:   Re: Two IP networks -> one physical network

jim@cs.strath.ac.uk (Jim Reid) writes:

> Er... I hope you don't consider a broadcast storm as something that's
> likely to go unnoticed. If you have two or more IP networks on the
> once cable, *everyone* has to take care over broadcast addresses.

I recently saw something like this with two IP subnets on the same
physical wire, a PC-Router with two legs onto that wire, and RIP.
Whenever a big Cisco sent out a RIP update, one leg would pick it
up, re-broadcast out the other leg, which the first would pick up 
again, and re-broadcast ... until the hopcount exceeded 16.  This 
would take a second or two at a time, and was quite fun to watch.

It was equally fun to watch the person who had re-arranged the cabling
be re-arranged by one of the technicians, wielding a fibre-optic repeater.
 
 Paul Nash                    network grunt and bit-pusher extraordinaire
 paul@frcs.alt.za          PO Box 12475, Onderstepoort, 0110 South Africa

-----------[000039][next][prev][last][first]----------------------------------------------------
Date:      4 May 1993 20:56:45 GMT
From:      marmary@kaa.informatik.rwth-aachen.de (Mahmoud-Reza Nazeman)
To:        comp.protocols.tcp-ip
Subject:   unnecessary Retransmission Timeouts

I am running a simulation program, where two workstations on different
ethernet-segments are interconnected through a satellite link.

There I am wondering, why so many unnecessary TCP-Retransmission-Timeouts
occur, even under the assumption of an error-free (!) connection.

The RTO-value is always calculated as in the revised paper of V. Jacobsen ('88)
is suggested (for bandwidth-dominated paths):

                RTO = SRTT + 4 * RTT_VAR        .

Here's an example, which is representative:

As a segment ist sent, the most recent values are:  RTT    ~= 0.58 s
                                                    SRTT   ~= 0.58 s
                                                    DEV    ~= 0.02 s

                                                    => RTO ~= 0.67 s

The acknowledgement for that segment arrives after about 0.7 s
(e.g. because of a suddenly increased load/traffic in the ethernet),
so it is just 0.03 seconds too late. An unnecessary Timeout has occured
(=> Slow Start => Throughput will go down).

My suggestion (for discussion):

How about taking the most recent calculated RTO-value, even for segments
which are sent in the past.

In the example above that would mean, that for the decision, wether a Timer
has expired I would not take into account the 0.67 seconds which I have
calculated in the past, but I would look at the most recent RTO-value which
represents the presnt traffic.

In this example the last RTO was about 0.95 seconds. That means that there is
no reason for a timer to expire at this time.

Any comments about this suggstion are appreciated.
Which are the disadvantages of this suggestion?
Did I make any logical mistake?

thanks in advance,

- marmary
marmary@kaa.informatik.rwth-aachen.de


-----------[000040][next][prev][last][first]----------------------------------------------------
Date:      4 May 93 22:57:11 GMT
From:      wca0@ns1.cc.lehigh.edu (W. Cody Anderson)
To:        comp.protocols.tcp-ip
Subject:   Re: Printing from an IBM mainframe to printers on an Ethernet bac

In article <1993May3.234511.28914@gumby.dsd.trw.com>, sekine@gumby.dsd.trw.com (
Nancy Y. Sekine) writes:
>
>
>I'm looking for info on products that will enable printing from IBM
>mainframe applications to various printers on an Ethernet backbone
>(AppleTalk printers, Banyan VINES printers, UNIX lpd-served printers, etc.).
>
>Right now we're evaluating Interlink Computer Sciences' Enterprise Print
>Services software which runs on the mainframe and implements lpr and lpd
>through a TCP/IP interface.  We've investigated lpd servers to serve
>the printers (Incognito Software's UNIX-to-VINES Print Service to
>provide lpd capability to Banyan VINES printers;  CAP on a UNIX platform
[etc...]

BAH!  Who needs commercial software??  Use Simple Queue Transfer Protocol
(SQTP).  The systems programmers here at Lehigh developed it for
multi-platform print-sharing.  The SQTP distribution is available via
anonymous ftp from ftp.lehigh.edu:/pub/sqtp/sqtp34.tar.Z.

Use it in good health!!  It works VERY WELL in Lehigh's distributed
environment.

Cody A

-- 
$ drink < bottle; opener
bottle: cannot open
opener: not found
panic: restarting...

***************************************************************************
W. Cody Anderson            |  LUCC User Services

-----------[000041][next][prev][last][first]----------------------------------------------------
Date:      5 May 93 01:35:57 GMT
From:      rao@spectrum.CMC.COM (Parik Rao)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject:   Re: PC-Based Terminal Server Software: In Production

In <1s080kINNeoa@flash.pax.tpa.com.au> hart@flash.pax.tpa.com.au (Leigh M Hart) writes:

>Any suggestions anyone might have will be taken into consideration,
>as it is often the users of such products that come up with the good
>ideas, not the programmers!

PPP support is important I think.  CSLIP support (compressed SLIP).
Perhaps later on, things like callback (for security).

Most importantly, easy to configure.  

-- 
parik rao				          prao@cs.ucsb.edu, rao@cmc.com

-----------[000042][next][prev][last][first]----------------------------------------------------
Date:      Wed, 5 May 1993 02:52:54 GMT
From:      vjs@rhyolite.wpd.sgi.com (Vernon Schryver)
To:        comp.protocols.tcp-ip
Subject:   Re: Two IP networks -> one physical network

In article <1993May4.195123.25003@frcs.Alt.ZA>, paul@frcs.Alt.ZA (Paul Nash) writes:
> jim@cs.strath.ac.uk (Jim Reid) writes:
> 
> > Er... I hope you don't consider a broadcast storm as something that's
> > likely to go unnoticed. If you have two or more IP networks on the
> > once cable, *everyone* has to take care over broadcast addresses.
> 
> I recently saw something like this with two IP subnets on the same
> physical wire, a PC-Router with two legs onto that wire, and RIP.
> Whenever a big Cisco sent out a RIP update, one leg would pick it
> up, re-broadcast out the other leg, which the first would pick up 
> again, and re-broadcast ... until the hopcount exceeded 16.  This 
> would take a second or two at a time, and was quite fun to watch.
> 
> It was equally fun to watch the person who had re-arranged the cabling
> be re-arranged by one of the technicians, wielding a fibre-optic repeater.


You could probably get just about as much fun watching that
broken PC-Router break things even without the aid of the
doubled wire.


Vernon Schryver,  vjs@sgi.com

-----------[000043][next][prev][last][first]----------------------------------------------------
Date:      Wed,  5 May 1993 10:02:54 -0400
From:      Lyle_Seaman@transarc.com
To:        comp.protocols.tcp-ip
Subject:   Re: tcp checksum errors

sls@tct.com (Scot Schneebeli) writes:
>  I've been getting checksum errors when sending data to other machines on our
>  network. I've RTFM and it's useless (unless you need to know how to ping).

What do you mean by "sending data"?  Are you using an application such
as ftp or rcp, or are you opening a socket and writing to it?  TCP or
UDP?  How have you determined that you are getting checksum errors?
By "on our network" do you mean that the machines are on the same
Ethernet segment, or do they have a bridge or a router between them?
Are you using Ethernet, in fact, or some other medium?

>  files transmit without problems. NFS works. I've swapped out ethernet cards,

Do you have UDP checksums enabled in the kernels?  (I think this is a
Lachman IP suite, but I don't remember how they control this.  udp_cksum or
udpcksum, probably, or else it's a kernel tunable variable that gets
set in some file in conf.d)

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

-----------[000044][next][prev][last][first]----------------------------------------------------
Date:      Wed, 5 May 1993 03:39:54 GMT
From:      cschk@lux.latrobe.edu.au (Han)
To:        comp.protocols.tcp-ip
Subject:   How To Change IP address?

I just wanted to ask you all out there....is there a way of changing my
  IP address ? Is it an action frowned upon?  Is there some programs or
  tools out there which help me out achive this change ...? 

Thanx in advance ....

-----------[000045][next][prev][last][first]----------------------------------------------------
Date:      Tue, 04 May 93 23:40:32 HKT
From:      thomason@gnct.com (thomason)
To:        comp.protocols.tcp-ip
Subject:   UNIX tape server access from VMS clients.

Hello,

I have a problem regarding the remote tape access of tape in unix server
from VMS system.

A tape library is physically connected to a sun workstation and access to
it from other UNIX system is possible. But there are VMS VAXes within the
same network, and the VMS userwould like to access the tape library in
Sun workstation.

Are there any software available for this purpose ?

Sorry for wasting the bandwidth here since I don't know which news group
is appropriate and don't have access to those news groups!!

Thanks in advance.


Thomason FAN.

thomason@gnct.com (thomason)
GloCom BBS - (852)4925025 

-----------[000046][next][prev][last][first]----------------------------------------------------
Date:      5 May 1993 09:00:36 GMT
From:      julian@math.uni-muenster.de (Julian F. Reschke)
To:        comp.protocols.tcp-ip
Subject:   Looking for rstat() programming exemple

Sorry if this is not 100% the correct newsgroup for asking this:

I'm looking for working example code for calling rstat() on SunOS 4.1.3 (something
perfmeter seems to do). In my code, rstat() returns 0, but the structure returned
(filled in) always contains the same values.

Any help appreciated, preferably by email.

Thanx.


---
-----------------------------------------------------------------------------
Julian F. Reschke, Hensenstr. 142, D-W4400 Muenster (from July, 1st: D-48161)
         eMail: julian@math.uni-muenster.de, jr@ms.maus.de
_____________________________________________________________________________


-----------[000047][next][prev][last][first]----------------------------------------------------
Date:      5 May 1993 14:07:10 GMT
From:      trier@odin.ins.cwru.edu (Stephen C. Trier)
To:        comp.protocols.tcp-ip
Subject:   Re: unnecessary Retransmission Timeouts

Berkeley's TCP times only one packet per window, so implementing the
algorithm as you suggest would be hard.  However, I do it in my MS-DOS
TCP and it works well.

The biggest problem with this approach is that it requires an extra
addition in the timeout computations.  I was willing to accept that
cost for better adaptation to sudden congestion.  Besides, timing out
packets based on the most recent RTO estimate, rather than the one in
effect when the packet was sent, seems "more accurate".

If your network is prone to sudden delay changes, you might want to
look at the 1992 revision of "Karn's algorithm".  A paper describing
it appeared in ACM TOCS, in November 92, I think.

-- 
Stephen Trier (trier@ins.cwru.edu)   Star Trek dialog mistake of the week:
Network Software Engineer              "We've tried every decryption key
IRIS/INS/T                               on record, Captain."
Case Western Reserve University             - Geordi LaForge, ST:TNG, 5/1/93

-----------[000048][next][prev][last][first]----------------------------------------------------
Date:      5 May 1993 14:58:23 GMT
From:      hans@anest4.anest.ufl.edu (Hans van Oostrom)
To:        comp.protocols.tcp-ip
Subject:   RARP enet protocol number 8035, 0806 or both?

The RARP protocol uses the same packet as the ARP protocol, but with 
different op-codes.  Does the standard specify that I have to use ethernet 
protocol number 8035 or can I also use 0806?

I see some RARP packets on my net that use 0806, and they are being 
interpreted by some tcp/ip implementation as ARP packet, inserting an 
address of 00:00:00:00:00:00 in the table.
There are other implementations that do not handle rarp packets with type 
0806.

What is correct?

Hans.

-----------[000049][next][prev][last][first]----------------------------------------------------
Date:      Wed, 5 May 1993 16:16:10 GMT
From:      jlt1@crosfield.co.uk (john tricker)
To:        comp.unix.questions,comp.protocols.tcp-ip
Subject:   Interface names for a UNIX machine with more than one interface.

A question for the joint wisdom of the net ...

We have a UNIX workstation which has an ethernet interface and to which will 
are adding an FDDI interface. The machine will now have three, textual, names.

	1. Its ethernet interface name ( in the hosts file ).
	2. Its FDDI interface name ( in the hosts file ).
	3. Its machine name ( as returned by hostname ).

If the machine name is 'fred' how should the other two names be set up ? I am
aware of several proprietary conventions but is there a standard governing 
this situation ?

		Thanks for any help

-- 
---------------------------------------------------------------------------
#include <discliamer.std>  \_^o.  ->>>	jlt1@crosfield.co.uk	<<<-
--------------------------_ LL __------------------------------------------

-----------[000050][next][prev][last][first]----------------------------------------------------
Date:      Wed, 5 May 1993 17:25:08 GMT
From:      tim@unipalm.co.uk (Tim Goodwin)
To:        comp.dcom.sys.cisco,comp.protocols.tcp-ip
Subject:   Cisco IP filtering, the "established" criterion, and FTP

Cisco routers can filter TCP packets according to whether they
relate to an established connection (on the basis of the ACK and RST
bits).

I hoped to use this as the basis of a filtering scheme for a Cisco
connecting a LAN to the Internet: only "established" packets are
permitted onto the LAN (plus, for instance, any TCP packet to port 25
on the mail server).

When I put this in place, FTP suddenly stopped working.  A quick
glance at RFC 959 suggest that FTP works in a somewhat bizarre way.
When I type "get file", my client obtains an unprivileged port from
the OS, sends the address of that port down the control channel, and
waits for the server to initiate a data connection from port 20 back
to that unprivileged port.  (Are these details correct?)

So far as I can see, this completely foils my use of the "established"
filter criterion.  The only way I can find to reinstate FTP is to
permit any packets going to unprivileged ports (the Cisco can only
filter on destination port).

Is my reading of the situation correct?  Is there a better solution?

Any ideas appreciated.

Tim.
-- 
Tim Goodwin | tim@pipex.net  or | OSI is now more of a problem than
PIPEX Ltd   | tim@unipalm.co.uk | a solution - Marshall T Rose.

-----------[000051][next][prev][last][first]----------------------------------------------------
Date:      Wed, 5 May 1993 17:48:11 GMT
From:      leilabd@syma.sussex.ac.uk (Leila Burrell-Davis)
To:        comp.protocols.tcp-ip
Subject:   Re: Looking for TCP/IP source code

Nik Shaylor (nshaylor@fabcab.demon.co.uk) wrote:
: I am looking for a nicely written public domain implementation of
: TCP/IP that I can port to a network of embedded controllers that are based
: on the ARM 6 processor. I have looked at KA9Q but I would like to know of
: any other sources that might be appropriate. It must be in C and easily
: comprehended.

Have a look at NCSA Telnet, Clarkson University TCP (very closely
related to it) and Waterloo University TCP.

Let me know if you need help finding them. They should all be on
src.doc.ic.ac.uk which you can anonymous ftp to.

Leila
-- 
Leila Burrell-Davis, Computing Service, University of Sussex, Brighton, UK
Tel:   +44 273 678390              Fax:   +44 273 678470
Email: leilabd@syma.sussex.ac.uk  (JANET: leilabd@uk.ac.sussex.syma)

-----------[000052][next][prev][last][first]----------------------------------------------------
Date:      Wed, 5 May 1993 18:00:38 GMT
From:      "Philip Munts" <p00246@psilink.com>
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject:   IP over ARDIS?

Anybody have experience with sending TCP/IP over the ARDIS wireless
network?  I am thinking about drafting an RFC regarding this if no
one else has done any work with it.  Please respond by email.  I will
summarize to the net if anyone else is interested.

-----------[000053][next][prev][last][first]----------------------------------------------------
Date:      5 May 93 18:33:23 GMT
From:      sam@bsu-cs.bsu.edu (B. Samuel Blanchard)
To:        comp.protocols.tcp-ip
Subject:   Re: tcp checksum errors

In article <C6I6o1.67s@tct.com> sls@tct.com (Scot Schneebeli) writes:
>
> I've been getting checksum errors when sending data to other machines on our
> network. I've RTFM and it's useless (unless you need to know how to ping).
>
> What is weird is that if the file I'm transmitting has a size >= 4096 it
> gets the checksum errors on the other side and keeps resending/getting errors
> until it times out. I can _receive_ a file of _any_ size, no problem. Small
> files transmit without problems. NFS works. I've swapped out ethernet cards,
> Scot Schneebeli                         <sls@tct.com>

Is there a MTU/MRU smaller than your Max Packet.  We have a Motorola using
slip (unsupported) where the MRU is < MTU's smallest value on connected
system.  The motorola can send files/etc fine.  Keystrokes to the motorola
are fine.  Try varying the data sent with ping until you start getting
errors.

Detail attempt:
  sys-one MRU = 100
  sys-two MTU = 110

  ping data size <=100 from sys-two to sys-one will work.
  ping data size between 101 and 110 will fail, sys-one will only get 100 bytes.
    seems reasonable that checksum would fail. crc(110bytes) != crc(100bytes)

I also agree with prior posting, more info might help if this does not work.
-- 
B. Sam Blanchard        sam@bsu-cs.bsu.edu
418 Winfield Dr         (317) 284-7131   work
Greenfield, IN 46140

-----------[000054][next][prev][last][first]----------------------------------------------------
Date:      Wed, 05 May 93 19:15:17 GMT
From:      pete@wvus.org (Pete Gregory)
To:        comp.protocols.tcp-ip
Subject:   multiple control packets


While analysing Ethernet TCP/IP traffic using traces from LanWatch, 
I noticed something that seems a little odd to me.  It's most 
pronounced coming from a Xircom PE3-10BT Pocket Ethernet adaptor 
(plugs into the parallel port of a laptop).  However I have seen the 
same oddity coming from Racal Interlan NI6510 NICs and the Sequent 
boxes at less frequent intervals.  We are running 10baseT using 
Synoptics 3000 concentrators and cards.

What happens is that the sending device will, on occasion, send two or
more consecutive control packets (usually IP ACK or ACK/PUSH but never
any data) that are identical except for the packet ID. There is a time
separation of usually 0 to 5 milliseconds (ms is as fine as LanWatch
times the packets so anything less than 1ms is probably listed as 0ms)
between these packets. There are no responses from the receiving
device during these bursts. If these were retransmits due to
collisions, then our network management software would detect those
and the collision rate would be extreemly high. This is not the case.

Are these "retransmits" normal, or is there some condition that might
cause this kind of behaviour?~

Thanks...
-- 

Pete Gregory, UNIX System Admin.    Internet:  pete@wvus.org
World Vision U.S.                   Bangnet:   {decwrl,ames}!elroy!wvus!pete

No Admittance.  Admittance by Appointment Only.  No Appointments.

-----------[000055][next][prev][last][first]----------------------------------------------------
Date:      Wed, 5 May 1993 19:41:49 GMT
From:      fred_s@netcom.com (Frederick Scott)
To:        comp.dcom.sys.cisco,comp.protocols.tcp-ip
Subject:   Re: Cisco IP filtering, the "established" criterion, and FTP

tim@unipalm.co.uk (Tim Goodwin) writes: 

>Cisco routers can filter TCP packets according to whether they
>relate to an established connection (on the basis of the ACK and RST
>bits).
>
>I hoped to use this as the basis of a filtering scheme for a Cisco
>connecting a LAN to the Internet: only "established" packets are
>permitted onto the LAN (plus, for instance, any TCP packet to port 25
>on the mail server).
>
>When I put this in place, FTP suddenly stopped working.  A quick
>glance at RFC 959 suggest that FTP works in a somewhat bizarre way.
>When I type "get file", my client obtains an unprivileged port from
>the OS, sends the address of that port down the control channel, and
>waits for the server to initiate a data connection from port 20 back
>to that unprivileged port.  (Are these details correct?)
>
>So far as I can see, this completely foils my use of the "established"
>filter criterion.  The only way I can find to reinstate FTP is to
>permit any packets going to unprivileged ports (the Cisco can only
>filter on destination port).
>
>Is my reading of the situation correct?

Substantially, I believe it's correct.

>Is there a better solution?
>
>Any ideas appreciated.

The typical solution is to exempt one machine on your net from the effects
of the firewall.  I've never worked with these kinds of things myself, but
I was told by Network Admins in the past that the cisco routers can be
programed to disallow connections based on port # *OR* IP address.

Typically, the Network Administrator will exempt one machine in the domain
and WATCH IT LIKE A HAWK.  For instance, it has its own password file if
it's a Sun Workstation - NIS *doesn't* run on it.  No NFS file systems are
mounted on it or exported from it.  And the passwd file is strictly limited
to those requiring access to the internet.  (Partly for security but mostly
so the Network Admin isn't changing it every 2 1/2 minutes.)  No guest access.
All annonymous ftp to your site must be set up on this machine and this
machine only.

Folks needing to ftp or telnet to other internet sites telnet to the "gateway"
machine first and from there to whereever.  ftp therefore usually takes two
steps - ftp from the gateway to the remote internet site, grab the file,
then ftp from your own internal host to the gateway and move it to where you
want it.

The problems with the two-step ftp or telnet access can either be written off
as an annoyance or you can get hold of utilities call "rftp" and "rtelnet".
Apparently, some sort of daemon is installed on the gateway machine which
will accept connections from local hosts only and translate them do the
standard ftp and telnet functions by proxy.  The result is that rftp and
rtelnet work exactly like ftp and telnet, respectively, but your firewall is
completely functional.

Unforunately, I can't tell you where to get these.  You could probably check
in comp.sources.wanted or comp.sources.misc or someplace like that.  I've
heard they're public domain utilities.

Fred

-----------[000056][next][prev][last][first]----------------------------------------------------
Date:      Wed, 5 May 1993 19:42:28 GMT
From:      bashford@srs.loral.com (Dave Bashford)
To:        comp.protocols.tcp-ip
Subject:   Sanity check on UDP reliability estimates ?

I'm trying to come up with an order-of-magnitude estimates of the reliability
of a system we are designing that will use UDP sockets on HP-UX.

I did a "netstat -s" to find out how many packets TCP had to retransmit
compared to how many it sent and got 0.000404 retransmits per packet sent.

My question is: can I extrapolate that to mean 0.000404 packets lost per
packet sent, if the protocol were UDP instead of TCP ? If not, what can I
look at to get rough estimate of UDP's reliability on my system ?

Here is a partial listing of my "netstat -s":
	tcp:
		88956 packets sent
			73884 data packets (3577628 bytes)
			36 data packets (6390 bytes) retransmitted
			12467 ack-only packets (8902 delayed)
			0 URG only packets
			0 window probe packets
			681 window update packets
			1888 control packets
		97970 packets received
			58869 acks (for 2638106 bytes)
			1177 duplicate acks
			0 acks for unsent data
			28942 packets (3369405 bytes) received in-sequence
			88 completely duplicate packets (2347 bytes)
			0 packets with some dup. data (0 bytes duped)
			1684 out-of-order packets (162673 bytes)
	ip:
		203776 total packets received
		92679 packets not forwardable

thanks,
-- 

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

-----------[000057][next][prev][last][first]----------------------------------------------------
Date:      5 May 1993 20:51:09 GMT
From:      mjr@tis.com (Marcus J Ranum)
To:        comp.protocols.tcp-ip
Subject:   Re: Remote BACKUP server software

>Is there anything out there that is wide spread and well defined that
>handles backing up systems from different platforms.

	I'd look at the man pages for rmt(8) for a starting point.
I did a mess of hacking on it to turn it into a general purpose
program with virtual devices and volumes. Take a look on decuac.dec.com
in pub/sources/rmtwrite.shar.Z

mjr.

-----------[000058][next][prev][last][first]----------------------------------------------------
Date:      5 May 1993 20:54:40 GMT
From:      trier@slc6.ins.cwru.edu (Stephen C. Trier)
To:        comp.protocols.tcp-ip
Subject:   Re: multiple control packets

If these "bursts" of acks are followed by a retransmission, they are
probably the result of the "agressive ack" policy proposed by Jacobson.
This policy permits some TCPs to determine that a packet has gotten
lost without waiting for a full retransmission timeout.

It is also possible that it is a TCP bug or that it is caused by a flaky
piece of network hardware somewhere.

-- 
Stephen Trier (trier@ins.cwru.edu)   Star Trek dialog mistake of the week:
Network Software Engineer              "We've tried every decryption key
IRIS/INS/T                               on record, Captain."
Case Western Reserve University             - Geordi LaForge, ST:TNG, 5/1/93

-----------[000059][next][prev][last][first]----------------------------------------------------
Date:      Wed, 5 May 1993 20:57:45 GMT
From:      mskucher@math.uwaterloo.ca (Murray S. Kucherawy [MFCF])
To:        comp.unix.questions,comp.protocols.tcp-ip
Subject:   Re: Interface names for a UNIX machine with more than one interface.

jlt1@crosfield.co.uk (john tricker) writes:
>A question for the joint wisdom of the net ...
>
>We have a UNIX workstation which has an ethernet interface and to which will 
>are adding an FDDI interface. The machine will now have three, textual, names.
>
>	1. Its ethernet interface name ( in the hosts file ).
>	2. Its FDDI interface name ( in the hosts file ).
>	3. Its machine name ( as returned by hostname ).
>
>If the machine name is 'fred' how should the other two names be set up ? I am
>aware of several proprietary conventions but is there a standard governing 
>this situation ?

We've chosen to append the network name for each address; for example:

129.97.140.49   cayley cayley.uwaterloo.ca cayley-mathnet
129.97.204.6    cayley cayley.uwaterloo.ca cayley-descartesnet

...where 129.97.140 is "mathnet" in /etc/networks, and 129.97.204 is
   "descartesnet".  On that host, gethostname() returns just "cayley".

The nameservers know "cayley" as both addresses, but the addition of the
alias allows us to specify a particular interface if that is desired for
traffic control (eg. NFS mounts).

-- Murray S. Kucherawy ----------------------------------------+--------------
Software Systems Co-op, Math Faculty Computing Facility [MFCF] | All spelling
University of Waterloo, Ontario, Canada                        | errors caused
E-mail: mskucherawy@{math,watdragon}.UWaterloo.ca              | by Pnews.
---------------------------------------------------------------+--------------

-----------[000060][next][prev][last][first]----------------------------------------------------
Date:      5 May 1993 21:04:11 GMT
From:      alpham@nic.cerf.net (Alpha Microsystems)
To:        comp.protocols.tcp-ip
Subject:   Re: multiple control packets

In article <1993May05.191517.26936@wvus.org> pete@wvus.org (Pete Gregory) writes:
>
>
>What happens is that the sending device will, on occasion, send two or
>more consecutive control packets (usually IP ACK or ACK/PUSH but never

It sounds like the PC is sending a zero window, then following it with
a gratuitous ACK advertising a larger window.  I have seen it myself
and think it happens alot on PC implementations due to memory limitations
one must consider (there's never enough room for buffers and applications

- Steve


-----------[000061][next][prev][last][first]----------------------------------------------------
Date:      Wed, 5 May 1993 21:19:16 GMT
From:      remy@orion.poly.edu (Remy Le Flem)
To:        comp.protocols.tcp-ip
Subject:   Object through RPC

	Can you pass C++ objects in a RPC function call.
	Is there a way to build a XDR filter for this C++ object.
	Which are the protocols (if not RPC) that can support the transmission
	of this kind of "Objects" (always with C++ langage).

	Thanks!

	Remy Le Flem
	Polytechnic University
	New York

-----------[000062][next][prev][last][first]----------------------------------------------------
Date:      Wed, 5 May 93 21:55:35 GMT
From:      dmo@nazareth.cc.rochester.edu (Denise Ondishko)
To:        comp.protocols.tcp-ip
Subject:   tcp/ip training

here at the university of rochester, we've enlarged our
network engineering group by adding three new members and
by cross-training our two ROLM voice/data engineers. 
we'd like to find out which training seminars are the best, and which
ones to avoid.  if there are CBT's or books which serve the same
purpose and have proved more valuable, i'd appreciate hearing about
them, too.

the training we're considering includes:
American Institute Hands-on TCP/IP
American Institute Hands-on SNMP
American Institute Hands-on Novell II or III
American Research Group Hands-on Introduction to SNMP
American Research Group Hands-on Internetworking with TCP/IP
American Research Group Hands-on Troubleshooting TCP/IP networks
INTEROP tutorials

we'd also like some advanced appletalk training, but haven't identified any
yet.

my thanks in advance!
[direct email to dmo@cc.rochester.edu is appreciated; i'll post a
summary.]

--
-d
denise ondishko, phd
Network Engineering
University of Rochester Telecommunications

-----------[000063][next][prev][last][first]----------------------------------------------------
Date:      5 May 93 22:39:10 GMT
From:      art@acc.com (Art Berggreen)
To:        comp.protocols.tcp-ip
Subject:   Re: unnecessary Retransmission Timeouts

In article <1s6lad$m5@urmel.informatik.rwth-aachen.de> marmary@kaa.informatik.rwth-aachen.de (Mahmoud-Reza Nazeman) writes:
>I am running a simulation program, where two workstations on different
>ethernet-segments are interconnected through a satellite link.
>
>There I am wondering, why so many unnecessary TCP-Retransmission-Timeouts
>occur, even under the assumption of an error-free (!) connection.
>
>The RTO-value is always calculated as in the revised paper of V. Jacobsen ('88)
>is suggested (for bandwidth-dominated paths):
>
>                RTO = SRTT + 4 * RTT_VAR        .

Hmmm, I wonder if Van ever considered that as RTT_VAR approeaches 0, that RTO
approaches SRTT (creating a potential race condition).  Seems like this function
should be bounded such that RTO is never less than, say, 1.25 SRTT.

Art

-----------[000064][next][prev][last][first]----------------------------------------------------
Date:      5 May 93 22:46:37 GMT
From:      jaques@alantec.com (Robert Jaques)
To:        comp.protocols.tcp-ip
Subject:   should a router reply to this arp request


 router with proxy arp configured on.
Should it reply to this arp packet>>>

... partial arp packet
sender hardware address:  the requester boxes ethernet address
sender Protocol address: 0.0.0.0
targer hardware address: 00-00-00-00-00-00
target protocol address: senders proposed ethernet address

The RFC is a little ambigous on this. 

thanks

bob

-----------[000065][next][prev][last][first]----------------------------------------------------
Date:      5 May 93 22:47:46 GMT
From:      art@acc.com (Art Berggreen)
To:        comp.dcom.sys.cisco,comp.protocols.tcp-ip
Subject:   Re: Cisco IP filtering, the "established" criterion, and FTP

In article <1993May5.172508.17650@unipalm.co.uk> tim@unipalm.co.uk (Tim Goodwin) writes:
>Cisco routers can filter TCP packets according to whether they
>relate to an established connection (on the basis of the ACK and RST
>bits).
>
>I hoped to use this as the basis of a filtering scheme for a Cisco
>connecting a LAN to the Internet: only "established" packets are
>permitted onto the LAN (plus, for instance, any TCP packet to port 25
>on the mail server).
>
>When I put this in place, FTP suddenly stopped working.  A quick
>glance at RFC 959 suggest that FTP works in a somewhat bizarre way.
>When I type "get file", my client obtains an unprivileged port from
>the OS, sends the address of that port down the control channel, and
>waits for the server to initiate a data connection from port 20 back
>to that unprivileged port.  (Are these details correct?)
>
>So far as I can see, this completely foils my use of the "established"
>filter criterion.  The only way I can find to reinstate FTP is to
>permit any packets going to unprivileged ports (the Cisco can only
>filter on destination port).
>
>Is my reading of the situation correct?  Is there a better solution?

Even worse if the server uses an arbitrary socket at it's end.  The
FTP data transfer then happens between two random sockets.  So even
if you filter on source and destination sockets, FTP can be a big
problem.

Art

-----------[000066][next][prev][last][first]----------------------------------------------------
Date:      Thu, 6 May 1993 04:59:24 +0000
From:      vadim@cix.compulink.co.uk (Vadim Lebedev)
To:        comp.protocols.tcp-ip
Subject:   Re: Two IP networks -> one phy


In-Reply-To: <JIM.93May4115543@lister.cs.strath.ac.uk> jim@cs.strath.ac.uk (Jim Reid)

In article   : <JIM.93May4115543@lister.cs.strath.ac.uk>
  jim@cs.strath.ac.uk (Jim Reid)
writes:
> 
 
> In article <hmb423s@rhyolite.wpd.sgi.com> vjs@rhyolite.wpd.sgi.com (Vernon Schryver
 ) writes:
> 
>    In article <1993May3.140544.20097@Princeton.EDU>, burt@hart.Princeton.EDU (Burto
 n Rosenberg) write
> s:
>    > Is it possible for a single physical ethernet to be associated
>    > with two or more IP networks?
> 
>    There are some oddities associated with machines seeing
>    broadcasts for the wrong network, but none that are likely
>    to be noticed during a few weeks or even months during
>    renumbering.
> 
> Er... I hope you don't consider a broadcast storm as something that's
> likely to go unnoticed. If you have two or more IP networks on the .....


I wonder if that broadcast storm problem could bot be resolved by using
ethernet MULTICASTING instead of BROADCASTING.
E.G. configure all host to the IP net 1 to use MULTICAST ADRESS1 in place
of BROADCAST and all hosts on the IP net 2 to use MULTICAST ADDRESS 2....
That way the broadcasts from one 'net' will not be visible on the second
'net'...

  Vadim.



-----------[000067][next][prev][last][first]----------------------------------------------------
Date:      6 May 93 05:40:36 GMT
From:      claude@bauv.unibw-muenchen.de (Claude Frantz)
To:        comp.unix.admin,comp.protocols.tcp-ip,alt.internet.access.wanted
Subject:   Re: Help with non-conformant IP addresses

cpearce@nemesis.acs.unt.edu (Chris Pearce) writes:

>Please excuse me if I have posted this article to an inappropriate group. It
>concerns a subject for which I could not determine a completely appropriate
>newsgroup.
 
>I'm currently trying to get my company connected to the Internet. The problem
>is that we currently have an IP network in place that uses IP addresses not
>assigned to our company by NIC. This network of about 200 machines may
>require significant effort to reconfigure to conform to the class C address
>currently assigned to us.

Sure, but it's probably the most simple and economical method.

-----------[000068][next][prev][last][first]----------------------------------------------------
Date:      6 May 93 11:44:39
From:      jim@cs.strath.ac.uk (Jim Reid)
To:        comp.protocols.tcp-ip
Subject:   Re: Two IP networks -> one phy

In article <memo.195372@cix.compulink.co.uk> vadim@cix.compulink.co.uk (Vadim Lebedev) writes:

  In-Reply-To: <JIM.93May4115543@lister.cs.strath.ac.uk> jim@cs.strath.ac.uk (Jim Reid)
   > In article <hmb423s@rhyolite.wpd.sgi.com> vjs@rhyolite.wpd.sgi.com (Vernon Schryver
 ) writes:
   >    In article <1993May3.140544.20097@Princeton.EDU>, burt@hart.Princeton.EDU (Burto
 n Rosenberg) write
   > s:
   >    > Is it possible for a single physical ethernet to be associated
   >    > with two or more IP networks?
   > 
   >    There are some oddities associated with machines seeing
   >    broadcasts for the wrong network, but none that are likely
   >    to be noticed during a few weeks or even months during
   >    renumbering.
   > 
   > Er... I hope you don't consider a broadcast storm as something that's
   > likely to go unnoticed. If you have two or more IP networks on the .....

   I wonder if that broadcast storm problem could bot be resolved by using
   ethernet MULTICASTING instead of BROADCASTING.

Not really. All that would do is shift the goalposts. 

First of all, IP multicasting is somewhat experimental and few
commercially available TCP/IP implementations support it.

   E.G. configure all host to the IP net 1 to use MULTICAST ADRESS1 in place
   of BROADCAST and all hosts on the IP net 2 to use MULTICAST ADDRESS 2....
   That way the broadcasts from one 'net' will not be visible on the second
   'net'...

Alas no. To transmit an IP broadcast on ethernet, the IP packet is
encapsulated in an ethernet frame which has the broadcast ethernet
destination address: ff:ff:ff:ff:ff:ff. EVERY host on that physical
network will see that broadcast packet. The network interfaces will
pull the packet off the wire and hand it to the IP software in the
kernel. Depending on the addressing information in the IP packet, this
software will choose to discard the IP packet or forward it or pass it
up to some higher-level software such as TCP and then to a telnet
application (say).

Wth multicasting, the IP multicast address is usually encapsulated
inside an ethernet broadcast packet. This means that, as far as the
ethernet is concerned, there is no real difference between the IP
broadcast and multicast. It follows that it is up to each host's IP
software to make sense of the IP packet and drop/process/route the
packet. The bottom line is that each host has to know the broadcast
and multicast addresses for each IP network on the ethernet and,
critically, know not to forward these packets. This is not much
different from telling each host about the other IP networks sharing
the cable.

		Jim

-----------[000069][next][prev][last][first]----------------------------------------------------
Date:      Thu, 6 May 1993 07:07:55 GMT
From:      kaiwan@ee.fit.edu (Kaiwan Hongladaromp.)
To:        comp.protocols.tcp-ip
Subject:   How to determine the path of each packet?

Hi all....

As the subject said.. How can I acquire the path that my packet go thru?
I like to know (if possible) from both side views, ie. sender and receiver.
And is this possible both on datadram and connected-orientd protocol..

I'd be appreciated if the answer is directly to my mbox (kaiwan@ee.fit.edu).
Because this group is not my regular basis group :-) anyway I'll keep looking
from time to time...

Thanks..


-----------[000070][next][prev][last][first]----------------------------------------------------
Date:      Thu, 6 May 1993 08:13:31 GMT
From:      ddr@informatik.uni-rostock.de (Detlef Drewanz)
To:        comp.protocols.tcp-ip
Subject:   Re: RARP enet protocol number 8035, 0806 or both?

In article <hans.17.0@anest4.anest.ufl.edu>, hans@anest4.anest.ufl.edu (Hans van Oostrom) writes:
> The RARP protocol uses the same packet as the ARP protocol, but with 
> different op-codes.  Does the standard specify that I have to use ethernet 
> protocol number 8035 or can I also use 0806?
> 
> I see some RARP packets on my net that use 0806, and they are being 
> interpreted by some tcp/ip implementation as ARP packet, inserting an 
> address of 00:00:00:00:00:00 in the table.
> There are other implementations that do not handle rarp packets with type 
> 0806.
> 
> What is correct?

I think that 8035 is correct. Most rarp-codes
(and /usr/include/netinet/if_ether.h ) use this code and it would be the
best to use this.

-- 

	Detlef

+---------------------------------------------------------------+
| Detlef Drewanz	e-mail:	ddr@informatik.uni-rostock.de	|
| University of Rostock, Dept. of CS, Germany			|
+---------------------------------------------------------------+

-----------[000071][next][prev][last][first]----------------------------------------------------
Date:      Thu, 6 May 1993 08:16:24 GMT
From:      ddr@informatik.uni-rostock.de (Detlef Drewanz)
To:        comp.protocols.tcp-ip
Subject:   ETHERNET-TYPCODES


Where can I get all the used the Ethernet-Typcodes. Is there a rfc or .. where
are the Codes are listed ?

- 

	Detlef

+---------------------------------------------------------------+
| Detlef Drewanz	e-mail:	ddr@informatik.uni-rostock.de	|
| University of Rostock, Dept. of CS, Germany			|
+---------------------------------------------------------------+

-----------[000072][next][prev][last][first]----------------------------------------------------
Date:      Thu, 6 May 1993 10:39:22 GMT
From:      ddr@informatik.uni-rostock.de (Detlef Drewanz)
To:        comp.sys.hp,comp.protocols.tcp-ip
Subject:   Diskless Hp-Bootprotocol

Hi,

i have a question to HP 9000/series300:

Does anybody know, which protocol the diskless HP 9000/3xx use for
loading the kernel. The motivation is to boot a HP from a SUN or DECstation.
Our HP-Server is very slow (nfs,...) and we think that we can get more
availability for our HP-workstations, if we could boot and serve they by
faster machines.

Thanks in advance.

-- 

	Detlef

+---------------------------------------------------------------+
| Detlef Drewanz	e-mail:	ddr@informatik.uni-rostock.de	|
| University of Rostock, Dept. of CS, Germany			|
+---------------------------------------------------------------+

-----------[000073][next][prev][last][first]----------------------------------------------------
Date:      6 May 1993 13:30:54 GMT
From:      mjr@tis.com (Marcus J Ranum)
To:        comp.dcom.sys.cisco,comp.protocols.tcp-ip
Subject:   Re: Cisco IP filtering, the "established" criterion, and FTP

>I hoped to use this as the basis of a filtering scheme for a Cisco
>connecting a LAN to the Internet: only "established" packets are
>permitted onto the LAN
>When I put this in place, FTP suddenly stopped working.  A quick
>glance at RFC 959 suggest that FTP works in a somewhat bizarre way.

	Correct. FTP is rather unique in its use of the network. ;)

	Generally this problem is solved either by putting a proxy
FTP service on your firewall machine, or by jiggering FTP to only
bind ports (on the client side) within a specified range, and then
permitting the screening router to let them through. The latter
approach means you can still be reached via non-established
connections on a small range of ports - which has a certain risk
associated with it.

	There are lengthy discussions of this issue archived in
the firewalls mailing list archives, on ftp.greatcircle.com.

mjr.

-----------[000074][next][prev][last][first]----------------------------------------------------
Date:      Thu, 6 May 1993 14:35:55 GMT
From:      clfang@csie.nctu.edu.tw (Chien-Lu Fang)
To:        comp.protocols.tcp-ip
Subject:   HELP: socket buffer overflow ?

   How to solve the problem that ...

     In the condition that many processes send MESSAGE to

   one process at the same time. Cause the "socket buffer

   overflow" , when using "socket UDP" protocal.

     How to increase the "socket buffer size" ?

     Help !!!.....



     Wood Chen
         woodchen@csie.nctu.edu.tw
         woodchen@arch9.csie.nctu.edu.tw


-----------[000075][next][prev][last][first]----------------------------------------------------
Date:      Thu, 6 May 1993 15:00:51 GMT
From:      vjs@rhyolite.wpd.sgi.com (Vernon Schryver)
To:        comp.protocols.tcp-ip
Subject:   Re: Two IP networks -> one phy


I also doubt that it would be practical to change the broadcast address
to a MAC multicast address.  Setting asside how you might convince most
implementations to use anything other than their usually hard-coded
ff:ff:ff:ff:ff:ff as the MAC address for IP or ARP broadcasts, the
whole reason to use the 2-IP-networks-on-one-wire kludge was to avoid
having to re-configure a lot of machines simultaneously.


However, ...

In article <JIM.93May6114439@lister.cs.strath.ac.uk>, jim@cs.strath.ac.uk (Jim Reid) writes:
> ...
> Wth multicasting, the IP multicast address is usually encapsulated
> inside an ethernet broadcast packet. This means that, as far as the
> ethernet is concerned, there is no real difference between the IP
> broadcast and multicast. It follows that it is up to each host's IP
> software to make sense of the IP packet and drop/process/route the
> packet.

This is false, at least for any reasonable TCP/IP implementation, or
any unreasonable TCP/IP implementation that wants to multicast to or
from a reasonable TCP/IP implemenation.  (Of, course, you use multicast
addresses with UDP/IP datagrams, not TCP/IP segments.)

An IP multicast packet should be transmitted using the appropriate
class-D address, which should be translated into the appropriate
Ethernet or FDDI MAC-level multicast address with simple masking
operations.

See, for example, RFC-1112 and RFC-1075.  For a real application, try,
for example, the Internet "mbone" audio and video.

It is also false that all machines on a wire hear all multicasts.  The
whole purpose of using multicast instead of broadcast is to reduce the
number of machines that receive the packets.  Very old hardware (e.g.
VAX's) were unable to listen for more than a small number of multicast
addresses at one time.  Some newer hardware is similarly crippled.
However, reasonable, modern hardware and/or firmware can filter at
least dozens of multicast Ethernet or FDDI addresses at the speed of
the media.


>         The bottom line is that each host has to know the broadcast
> and multicast addresses for each IP network on the ethernet and,
> critically, know not to forward these packets. This is not much
> different from telling each host about the other IP networks sharing
> the cable.

Depending on what is intended, this is partly false.  The Host
Requirements RFC requires that a host or router pay attention to to the
multicast bit in the MAC address that came with an IP packet, and to
refuse to forward the packet if the MAC address was a multicast or
broadcast address.  (Subject, of course, to the special considerations
of forwarding class D IP addresses.)


Vernon Schryver,  vjs@sgi.com

-----------[000076][next][prev][last][first]----------------------------------------------------
Date:      Thu, 6 May 1993 15:02:43 GMT
From:      yost@netcom.com (David Yost)
To:        comp.protocols.ppp,comp.protocols.tcp
Subject:   bad ppp telnet performance

I used MacPPP for the first time yesterday.  It's a neat thing,
and I want to thank its authors and all the contributors to PPP.

There's just this one thing that I hope can be
improved:  If I start up an ftp, then go back to my
telnet window while the ftp is still going, the telnet
performance goes to hell.  It appears that the echoes
for the characters I type get queued up as single
packets and delivered as such, interleaved with the ftp
packets, and delayed by several seconds!  Such packets
should be coalesced in the queue so that when the data
finally can be sent, it all goes at once.  Furthermore,
it seems to me there really should be some way of
prioritizing streams, or at least a way of designating
one stream as higher priority than all others.  I realize
that this may be a hard problem because it may require
cooperation among different layers and across the
connection, and that this may seem inelegant, but the
principle of User Centered Design suggests that the most
dominant concern for elegance here should be the fact
that the performance is so bad for humans.

Anyone know how to fix this?  Is ther any ongoing work?

 --dave yost

P.S.  The host software is SunOS 4.1.3.  Don't know
      what PPP we're running.

-----------[000077][next][prev][last][first]----------------------------------------------------
Date:      Thu, 6 May 1993 15:49:19 GMT
From:      vjs@rhyolite.wpd.sgi.com (Vernon Schryver)
To:        comp.protocols.tcp-ip
Subject:   Re: Wanted: to identify routers in a path

In article <1993May2.181059.26699@acc.com>, art@acc.com (Art Berggreen) writes:
> In article <C69ItC.9Gt@aaahq05.aaa.com> mikel@aaahq05.aaa.com writes:
> >There was a program I've seen at USENIX (which I think comes from Solbourne)
> >which tells you the names (or addresses) of the routers allong a certain path.
> >
> >You give it an address, like "kgbvax.kgb.org.su" and it will identify all
> >of the routers allong the path taken.
> 
> Sounds like you are talking about "traceroute" (originally created by
> Van Jacobsen).


Traceroute is good for identifying gateways on the out-bound path.
Traceroute doesn't help on the return path, unless you can log onto
the remote machine and fire traceroute back toward your home.

`ping -R` (see recent BSD source) works on both directions, provided
the round trip path is not too long, and the remote end and all
intermediates do not mess up the record-route option.  In recent years,
it seems few systems mess up the RR option.


Vernon Schryver,  vjs@sgi.com

-----------[000078][next][prev][last][first]----------------------------------------------------
Date:      6 May 93 15:53:54 GMT
From:      art@acc.com (Art Berggreen)
To:        comp.protocols.tcp-ip
Subject:   Re: How to determine the path of each packet?

In article <kaiwan.736672075@yacht> kaiwan@ee.fit.edu (Kaiwan Hongladaromp.) writes:
>Hi all....
>
>As the subject said.. How can I acquire the path that my packet go thru?
>I like to know (if possible) from both side views, ie. sender and receiver.
>And is this possible both on datadram and connected-orientd protocol..
>
>I'd be appreciated if the answer is directly to my mbox (kaiwan@ee.fit.edu).
>Because this group is not my regular basis group :-) anyway I'll keep looking
>from time to time...
>
>Thanks..

The most common first order approximation is to run the traceroute program
from both ends.  If there is really only one possible path, this works well.

Be aware though, that every IP packet is routed independently and the paths
taken by two packets may differ.  Traceroute doesn't really deal with this
because it sends a whole series of packets.  With the growth of the Internet
and the use of more intelligent routing and loadsharing, this phenonmenon is
likely to become more common.  The most accurate way to capture this information
would be to use the Record Route IP option, but the size of the Internet has
long since exceeded the capability of that mechanism (except in very short
paths).

As for CO vs DG protocol traffic, it is all carried by IP at the network level,
and IP is inherently datagram based.

Art

-----------[000079][next][prev][last][first]----------------------------------------------------
Date:      6 May 93 17:16:15 GMT
From:      jessea@u013.me.vp.com (Jesse W. Asher)
To:        comp.unix.admin,comp.protocols.tcp-ip
Subject:   Matching netstat display with process ids.

If I do a netstat and see some connections that I know shouldn't be there
(like they are hung, etc) how can I match what I see in the netstat display
with a process id so I can kill the offending process?  Any ideas on how to
do this??

-- 
      Jesse W. Asher                                          (901)762-6000
                             Varco-Pruden Buildings
                 6000 Poplar Ave., Suite 400, Memphis, TN  38119
    Internet: jessea@vpbuild.vp.com                   UUCP: vpbuild!jessea

-----------[000080][next][prev][last][first]----------------------------------------------------
Date:      Thu, 6 May 1993 17:18:41 GMT
From:      Carlos Reed <creed@fse.ulaval.ca>
To:        comp.protocols.tcp-ip
Subject:   CAPS on phase I, I can't see my server on localtalk

Hi gang!


I'm posting the following mesage from a friend of mine.



Hello CAP managers!

I have installed CAP Native EtherTalk on a SUN IPC SunOS4.1.2 with NIS.
Everything look fine but I can't see my SUN from any of my  Macs ,on the
lacaltalk side. It is like if the NBP of appletalk don't registed me on
the localtalk side.. 

Where is the NBP service in CAP and how can I configure it? 
We are using phase I , if it can help .


Thanks!
Louis Demers
Universite Laval
Tel: (418)656-2074
FAX: (418)656-2018
louis@mobil.arc.ulaval.ca


Here a ouput of my system:


mobil# aarpd "le0" "EtherTalk"

mobil# atis
abInit: [ddp:   0.00, 18], [GW:   0.00, 4] starting
11:35:28 05/06/93  Reply num max for lkup reply is 5 (based on 104)

mobil# snitch -S -f "SUNMobil" 

mobil# aufs
Apple Unix File Server (mobil Aufs:AFPServer@*) starting

mobil# atlook
abInit: [ddp:   0.40, 18], [GW:   0.40, 26] starting
Looking for =:=@* ...
  1 - Martin:-BroadCast@*                      [Net:  0.6   Node: 27
Skt:252]
  2 - GSTH (Mac):AFPServer@*                   [Net:  0.40  Node: 16
Skt:248]
  3 - MMGP:AFPServer@*                         [Net:  0.6   Node: 22
Skt:251]
  4 - Quadra Martin:AFPServer@*                [Net:  0.6   Node: 27
Skt:249]
  5 - S_CCISD:AFPServer@*                      [Net:  0.52  Node:129
Skt:129]
  6 - S_CLIENT:AFPServer@*                     [Net:  0.40  Node:215
Skt:129]
  7 - S_CTI:AFPServer@*                        [Net:  0.40  Node:168
Skt:129]
  8 - S_FACMED:AFPServer@*                     [Net:  0.6   Node:128
Skt:129]
  9 - S_LAVAL_2:AFPServer@*                    [Net:  0.40  Node:129
Skt:129]
 10 - YDas (Mac):AFPServer@*                   [Net:  0.40  Node:125
Skt:248]
.
.
.
...
 63 - gwfsg:ciscoRouter@EtherTalk              [Net:  0.250 Node:  2
Skt:254]
 64 - gwjdu.Ethernet0:ciscoRouter@EtherTalk    [Net:  0.54  Node:  1
Skt:254]
 65 - gwpde:ciscoRouter@EtherTalk              [Net:  0.52  Node:  1
Skt:254]

mobil# getzones
abInit: [ddp:   0.40, 18], [GW:   0.40, 26] starting
Count is 52
ZONE FORESTERIE
.
.
.
...
ZONE FSA_AGRICULTURE
ZONE ETHERTALK
ZONE COMTOIS

-----------[000081][next][prev][last][first]----------------------------------------------------
Date:      Thu, 6 May 93 17:57:26 BST
From:      pjc@cc.ic.ac.uk (Peter Churchyard)
To:        comp.protocols.tcp-ip
Subject:   Re: multiple control packets

This thread reminded my of a feature of reliable protocols with error
recovery (also applicable to other areas where error recovery is in use)
which is that often the error processing and recovery activity often masks
implementation failures since these can also be taken as 'line noise' etc. 

So just because it works, doesn't mean that it not generating spurious
packets/frames as well.  With pocket ether adapters I have used I have
found them to be slow and sometimes get connections timed out. Since I
don't know how these adapters talk over the parallel port I have always
assumed that the parallel port was the bottleneck.

Pete.

-----------[000082][next][prev][last][first]----------------------------------------------------
Date:      Thu, 6 May 1993 19:43:12 GMT
From:      sls@tct.com (Scot Schneebeli)
To:        comp.protocols.tcp-ip
Subject:   Re: tcp checksum errors

In article <4299@bsu-cs.bsu.edu> sam@bsu-cs.bsu.edu (B. Samuel Blanchard) writes:
>In article <C6I6o1.67s@tct.com> sls@tct.com (Scot Schneebeli) writes:
>>
>> I've been getting checksum errors when sending data to other machines on our
>> network. I've RTFM and it's useless (unless you need to know how to ping).
>>
>> What is weird is that if the file I'm transmitting has a size >= 4096 it
>> gets the checksum errors on the other side and keeps resending/getting errors
>> until it times out. I can _receive_ a file of _any_ size, no problem. Small
>> files transmit without problems. NFS works. I've swapped out ethernet cards,
>> Scot Schneebeli                         <sls@tct.com>
>
>Is there a MTU/MRU smaller than your Max Packet.  We have a Motorola using
>slip (unsupported) where the MRU is < MTU's smallest value on connected
>system.  The motorola can send files/etc fine.  Keystrokes to the motorola
>are fine.  Try varying the data sent with ping until you start getting
>errors.
>
>Detail attempt:
>  sys-one MRU = 100
>  sys-two MTU = 110
>
>  ping data size <=100 from sys-two to sys-one will work.
>  ping data size between 101 and 110 will fail, sys-one will only get 100 bytes.
>    seems reasonable that checksum would fail. crc(110bytes) != crc(100bytes)
>
>I also agree with prior posting, more info might help if this does not work.

Ok here is the info for this and the other posting.

I'm using rcp and ftp. There are no sockets, the TCP/IP is going over a local
ethernet network, and is on the same segment. We know there are checksum errors
due to the fact that error messages came up on the console of one of the 
machines that I send data to. We have already tried the ping with different
packet sizes (1470 would send 1471+ wouldn't) and I have no idea what the
MRU and MTU are, they don't exist in the kernel tunable parameters for my
system.

>-- 
>B. Sam Blanchard        sam@bsu-cs.bsu.edu
>418 Winfield Dr         (317) 284-7131   work
>Greenfield, IN 46140

--
Scot Schneebeli                   <sls@tct.com>


-----------[000083][next][prev][last][first]----------------------------------------------------
Date:      6 May 1993 20:26:05 GMT
From:      barmar@think.com (Barry Margolin)
To:        comp.dcom.sys.cisco,comp.protocols.tcp-ip
Subject:   Re: Cisco IP filtering, the "established" criterion, and FTP

In article <1sb3ue$4ep@sol.TIS.COM> mjr@tis.com (Marcus J Ranum) writes:
>	Correct. FTP is rather unique in its use of the network. ;)

Not completely unique.  Rsh also uses a second connection for the standard
error stream, and it is also a connection from the server to the client.
-- 
Barry Margolin
System Manager, Thinking Machines Corp.

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

-----------[000084][next][prev][last][first]----------------------------------------------------
Date:      Thu, 06 May 93 20:49:00 GMT
From:      amod@grok123.ColumbiaSC.NCR.COM ()
To:        comp.protocols.tcp-ip
Subject:   Re: HELP: socket buffer overflow ?

In article <C6M0Jw.LFs@csie.nctu.edu.tw>, clfang@csie.nctu.edu.tw (Chien-Lu Fang) writes:
|>    How to solve the problem that ...
|> 
|>      In the condition that many processes send MESSAGE to
|> 
|>    one process at the same time. Cause the "socket buffer
|> 
|>    overflow" , when using "socket UDP" protocal.
|> 
|>      How to increase the "socket buffer size" ?
 
     Try using setsockopt() call using SO_SNDBUF, SO_RCVBUF parameters.
     This call allows the process to set the receive and trasmit buffers for
     socket.
- Amod
|> 
|>      Help !!!.....
|> 
|> 
|> 
|>      Wood Chen
|>          woodchen@csie.nctu.edu.tw
|>          woodchen@arch9.csie.nctu.edu.tw
|> 
 
-- 

----------------------------------------------------------------------------
* Amod Bodas.                    Email : amod@yesac.ColumbiaSC.NCR.COM     *
* NCR  E&M Columbia              Tel   : 803-791-6887 (Office)             *
* 3325 Platt Spring Road                 803-791-6503 (Lab)                *
* West Columbia, S.C. 29169                                                *
*---------------------------------------------------------------------------

-----------[000085][next][prev][last][first]----------------------------------------------------
Date:      Thu, 6 May 1993 21:48:05 GMT
From:      vjs@rhyolite.wpd.sgi.com (Vernon Schryver)
To:        comp.unix.admin,comp.protocols.tcp-ip
Subject:   Re: Matching netstat display with process ids.

In article <1993May06.171615.8429@vpbuild.vp.com>, jessea@u013.me.vp.com (Jesse W. Asher) writes:
> If I do a netstat and see some connections that I know shouldn't be there
> (like they are hung, etc) how can I match what I see in the netstat display
> with a process id so I can kill the offending process?...


It depends on the operating system.  Source for a program named
something I can't think of for BSD systems is floating around.  SGI's
IRIX has `fuser`.  No doubt many others have their own versions.



Vernon Schryver,  vjs@sgi.com

-----------[000086][next][prev][last][first]----------------------------------------------------
Date:      Thu, 6 May 1993 22:15:40 GMT
From:      bob@MorningStar.Com (Bob Sutterfield)
To:        comp.protocols.ppp,comp.protocols.tcp
Subject:   Re: bad ppp telnet performance

In article <yostC6M1sK.8KD@netcom.com> yost@netcom.com (David Yost) writes:
   I used MacPPP for the first time yesterday.  It's a neat thing, and
   I want to thank its authors and all the contributors to PPP.

I've heard good things about it too.  Lots of our customers use it to
connect their Macs to their UNIX systems (and thence the Internet)
over dialup lines.  Larry has obviously put lots of hard work into it.

   If I start up an ftp, then go back to my telnet window while the
   ftp is still going, the telnet performance goes to hell.
   ...
   It appears that the echoes for the characters I type get queued up
   as single packets and delivered as such, interleaved with the ftp
   packets, and delayed by several seconds!

Your diagnosis is basically correct.  Unless your Sun's PPP
implementation is doing something special (see below), the packets are
being transmitted across the PPP link in the order they were received.

   Such packets should be coalesced in the queue so that when the data
   finally can be sent, it all goes at once.  

That sort of packet coalescing is very hard to do in the current IP
networking environment.  Rather than trying to coalesce telnet
packets, you might try a protocol like SUPDUP to replace telnet, if
you can find both a server for your Sun and a client for your Mac.
See nic.ddn.mil:rfc/rfc-index.txt for a listing of SUPDUP-related
references.  Ask archie for UNIX SUPDUP implementations.

   ...there really should be some way of prioritizing streams, or at
   least a way of designating one stream as higher priority than all
   others.

Van Jacobson's old CSLIP example code implemented a priority queueing
mechanism, and some UNIX SLIP and PPP packages (e.g. ours) include
that facility.  It delivers telnet, rlogin, and FTP (the command
stream, not the data stream) to the link encapsulator before anything
else in the interface queue.  Some vendors' routers do that for you
too, sometimes with more configurable lists of packet types that
should be given preferential treatment.

In order for packet priority queueing to have any effect at all, you
must decrease the MRU/MTU (max packet size) from the default 1006 or
1500, to something more like 256.  This way, the interactive packets
will have more frequent opportunities to elbow their way into the
transmission stream, between batch packets.  Your FTP throughput will
decrease a little but your interactive responsiveness should improve.
--
Bob Sutterfield, Morning Star Technologies            +1 614 451 1883
1760 Zollinger Rd, Columbus Ohio USA, 43221-2856      +1 800 558 7827
bob@MorningStar.Com                                   +1 614 459 5054 (FAX)

-----------[000087][next][prev][last][first]----------------------------------------------------
Date:      Thu, 6 May 1993 22:35:51 GMT
From:      emeinfel@fomalhaut.gb.nrao.edu (Edmond L. Meinfelder)
To:        comp.protocols.tcp-ip
Subject:   Keep Alive Packets

I am working on a client application that runs under SunOS 4.1.2 that 
communicates with a dos server with the TCP/IP by FTP Software.  The
server is using keep alive packets to detect a disconnection.

The problem is if, due to net death, the server loses the client connection,
the server does not seem to notice.  This seems to suggest that somewhere
in the SunOS the Keep Alive packets are being answered somewhere somehow.
When a similiar client is made using the FTP Software on another PC it
does work.

Anyone have any experience with keep alive packets on Suns?

-- 
Edmond L. Meinfelder                         Programmer, Virtual Guy,
"My aardvark is bigger." -Anon.              Hack for hire.

-----------[000088][next][prev][last][first]----------------------------------------------------
Date:      Thu, 6 May 1993 23:59:55 GMT
From:      iand@labtam.labtam.oz.au (Ian Donaldson)
To:        comp.protocols.ppp,comp.protocols.tcp
Subject:   Re: bad ppp telnet performance

yost@netcom.com (David Yost) writes:

>I used MacPPP for the first time yesterday.  It's a neat thing,
>and I want to thank its authors and all the contributors to PPP.
 
>There's just this one thing that I hope can be
>improved:  If I start up an ftp, then go back to my
>telnet window while the ftp is still going, the telnet
>performance goes to hell.  It appears that the echoes
>for the characters I type get queued up as single
>packets and delivered as such, interleaved with the ftp
>packets, and delayed by several seconds!  Such packets
>should be coalesced in the queue so that when the data
>finally can be sent, it all goes at once.  Furthermore,
>it seems to me there really should be some way of
>prioritizing streams, or at least a way of designating
>one stream as higher priority than all others.  I realize
>that this may be a hard problem because it may require
>cooperation among different layers and across the
>connection, and that this may seem inelegant, but the
>principle of User Centered Design suggests that the most
>dominant concern for elegance here should be the fact
>that the performance is so bad for humans.
 
>Anyone know how to fix this?  Is ther any ongoing work?
 
>P.S.  The host software is SunOS 4.1.3.  Don't know
>      what PPP we're running.

This sort of problem is usually due to one or two things:  IP packet queue 
ordering, and modem buffering.

Many PPP's will queue telnet/rlogin and Type-Of-Service == LowDelay packets
at the head of the queue, so that they get transmitted ahead of other packets.

However there are many modems on the market with huge input buffers (eg: 15K)
and this is usually the killer.  ie: you have to wait for 15K of data
to travel throught the modems before your telnet echo comes back.
This can take a few seconds even with V.32bis/V.42bis enabled.

A solution here is to reduce the input buffer size of the modem, if you can.

Ian Donaldson

Systems Programmer
Labtam Australia Pty Ltd,
41-43 Malcolm Rd. Braeside
P.O. Box 297, Mordialloc, 3915
Melbourne, Australia

Email:  iand@labtam.labtam.oz.au
Phone:  +61-3-587-1444
Fax:    +61-3-580-5581

-----------[000089][next][prev][last][first]----------------------------------------------------
Date:      Fri, 7 May 1993 01:19:39 GMT
From:      atkinson@itd.nrl.navy.mil (Randall Atkinson)
To:        comp.mail.mime,comp.protocols.tcp-ip
Subject:   Re: Commercial Multimedia Software for teleconferencing

In <1993May6.112634.5471@nuscc.nus.sg> isc40019@nusunix1.nus.sg (THAI LING) writes:
>
>I would just like to find out if ther are any commercial software
>available for multimedia teleconferencing. Thanks for your time.

  BBN sells software called PictureWindow that implements audio/video
conferencing over UDP/IP in conformance with the conferencing
protocols currently being developed by the Internet Engineering Task
Force (IETF).  Note that you can use the IETF video conferencing
protocols quite effectively over as little as 40-60 Kbps of bandwidth
(the reports that one needs ATM networks for video conferencing are a
myth promoted by marketing droids) and since the IETF work is based on
UDP and IP, you can use it over whichever LAN, MAN, or WAN technology
you already have.

  All other commercial products that I know of use proprietary
protocols that aren't particularly better than those that the IETF is
developing.  Folks who are into vendor-independence and open systems
and less expensive software will naturally avoid products which
implement proprietary protocols.

  Freely distributable (though experimental as yet) software
that does audio/video conferencing and uses protocols being developed
by the IETF include:

NAME	PURPOSE					Developer
----	----------------------			------------------
sd	conferencing session directory tool	Lawrence Berkeley Laboratory
vat	audio multicasting/conferencing		Lawrence Berkeley Laboratory
wb      conferencing white board tool		Lawrence Berkeley Laboratory
nevot     "        "           "		Computer Science, U. of Mass.
nv	audio/video multicasting/conferencing	Xerox Palo Alto Research Center
???	  "     "        "           "		INRIA in France

  There are discussions of remote conferencing on the rem-conf and
mbone mailing lists, but I forget what the full addresses of those
lists are.

  Followups are directed to comp.protocols.tcp-ip, I'm not sure what
the original poster thought this had to do with MIME email.

Ran
atkinson@itd.nrl.navy.mil

-----------[000090][next][prev][last][first]----------------------------------------------------
Date:      Fri, 7 May 1993 03:46:55 GMT
From:      beattie@franklin.ml.csiro.au (Bob Beattie)
To:        comp.protocols.tcp-ip,comp.dcom.servers
Subject:   Micro Annex tcp retransmit timeouts - HELP!

Micro Annex We are using sockets to read and write to ports on a Micro Annex 
terminal server. 

The writing program always fails with a 'Broken Pipe' error after 667 
secs. If the reading program has received no data, it fails after a 
similar time with a 'Connection reset by Peer'.

Running 'netstat -s' on the Annex shows a number of retransmit 
timeouts and a lesser number of 'connections dropped by retransmit 
timeouts'. The number of dropped connections is the same as the 
number of program failures.

A couple of questions

	Are the retransmit timeouts the source of the problem?

	What is their significance?

	What can I do about them?

The host is a Sun SPARC2 running SunOS 4.1.3

Thanks in advance. 

Bob Beattie
 



-----------[000091][next][prev][last][first]----------------------------------------------------
Date:      Fri, 7 May 93 04:07:36 GMT
From:      dsew@troi.cc.rochester.edu (David Sewell)
To:        comp.protocols.tcp-ip
Subject:   FTP "hash" lies through its teeth

I've finally gotten irritated enough about this to wonder
what's going on.  Does the ftp "hash" toggle serve any useful
purpose other than to keep you entertained watching the screen
if the number of bytes per hash mark is both non-standard and
unpredictable?  Just now--and this is typical--I did a download
where I set hash on and got a "Hash mark printing on (8192 bytes
per hash mark)" message.  So of course a transfer of 148723 bytes
goes through 268 little #'s--which isn't even 512 bytes/hash,
it's 554...  

Is there some programmer's cabal that says "hey, let's implement
the hash feature with a call to rand() and have some big fun!"???

-----------[000092][next][prev][last][first]----------------------------------------------------
Date:      7 May 93 04:18:46 GMT
From:      sun@ivory.ee.sophia.ac.jp (sun jian)
To:        comp.protocols.tcp-ip
Subject:   about the protocol simulatiom

Hi!
I want to know protocol simulation that the protocol designer can specify,
validate and analyze the performance on the user level. But I do not know
where I can find material on that.
thanks ny any advance.


				       SUN JIAN
                                       E-mail: sun@bob.ee.sophia.ac.jp
                                       Sophia University 


--


Yours faithfully,
                                       SUN JIAN
                                       E-mail: sun@bob.ee.sophia.ac.jp
                                       Sophia University

-----------[000093][next][prev][last][first]----------------------------------------------------
Date:      7 May 93 06:11:31 GMT
From:      lars@spectrum.CMC.COM (Lars Poulsen)
To:        comp.unix.admin,comp.protocols.tcp-ip,alt.internet.access.wanted
Subject:   Re: Help with non-conformant IP addresses

cpearce@nemesis.acs.unt.edu (Chris Pearce) writes:
>>I'm currently trying to get my company connected to the Internet. The problem
>>is that we currently have an IP network in place that uses IP addresses not
>>assigned to our company by NIC. This network of about 200 machines may
>>require significant effort to reconfigure to conform to the class C address
>>currently assigned to us.

In actuality, you probably would not wnat all hosts to be visible to the
Internet, but you would put a security firewall in place. Create a new
subnet with the registered class C addresses, and connect THAT network
to the Internet.

Address translation, or masking of the outside network that clashes with
your unregistered network number are likely to be ticking time bombs
under you. The illegal IP addresses will turn up in strange places (like
your local RIP packets) and confuse well-meaning routers outside of your
plant.

In article <claude.736666836@bauv106>
   claude@bauv.unibw-muenchen.de (Claude Frantz) writes:
>Sure, but [remnumbering] is probably the most simple and economical method.

Exactly. You can do it right up front, or pay more to do it later. You
cheated and did not do it up front. Now you pay the price. Please smile
and pay it gladly :-).
-- 
/ 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

-----------[000094][next][prev][last][first]----------------------------------------------------
Date:      Fri, 7 May 1993 06:19:59 GMT
From:      houten@prso.pttnwb.nl (K. van Houten)
To:        comp.sys.hp,comp.protocols.tcp-ip
Subject:   Re: Diskless Hp-Bootprotocol

 ddr@informatik.uni-rostock.de (Detlef Drewanz) writes:
|> 
|> Does anybody know, which protocol the diskless HP 9000/3xx use for
|> loading the kernel. The motivation is to boot a HP from a SUN or DECstation.
|> Our HP-Server is very slow (nfs,...) and we think that we can get more
|> availability for our HP-workstations, if we could boot and serve they by
|> faster machines.

Simply, forget it.
This can't be done. The protocol used is called DUX, and runs
on top of the ethernet, NOT TCP/IP. Use the sun ethernet analyse tool
(I forgot the name), and look in the column Unkown Protocol, that are
usually DUX packets.
The best way to speed up a 300 cluster, is to add local swap, and use
a 433 system with enough memory as server.

-- 
Karel van Houten, 		DOMAIN:	houten@pttnwb.nl
PTT Telecom b.v.		UUCP:	uunet!mcsun!sun4nl!pttdis!houten
's-Gravenhage, The Netherlands	VOICE:	+31 70 3434947

-----------[000095][next][prev][last][first]----------------------------------------------------
Date:      7 May 93 06:37:08 GMT
From:      martind@nsg.nsg.com.au ( NSA)
To:        comp.protocols.tcp-ip
Subject:   reverse telnet - TAHOE distrib

Some time ago I enquired into the availaability of source code for reverse
telnet., The environment I need it for is SUN.
I've received a reply stating to try the TAHOE release. I'm unable to locate
where this host is, and wherein this host do I search for the program code.

That's under the assumption this code is available for distribution.

Thank you.
-- 
Martin P Drenovac             PHONE: (612) 415-0500
                              FAX:   (612) 417-8635
			      EMAIL: martind@nsg.oz.au
GEC Alsthom I.T. 	      UUNET: !uunet!munnari!nsg.oz.au!martind

-----------[000096][next][prev][last][first]----------------------------------------------------
Date:      Fri, 7 May 1993 06:39:26 GMT
From:      agiraud@hpgnux65.grenoble.hp.com (Armand Giraud)
To:        comp.protocols.tcp-ip
Subject:   Re: Remote BACKUP server software

Hi

If you don't want to redo the wheel...

hp omniback is a good tool, other vendor have the same kind of software.

Regards
  Armand

-----------[000097][next][prev][last][first]----------------------------------------------------
Date:      7 May 93 10:34:30 GMT
From:      joho@kobe (Hans ter Horst)
To:        comp.protocols.tcp-ip
Subject:   FTP archive for RFCs


I'm afraid that this is probably a FAQ, but can somebody inform me
where I can find the RFCs.

/Hans
--
  joho@pfbs.philips.se

-----------[000098][next][prev][last][first]----------------------------------------------------
Date:      Fri, 7 May 1993 11:04:04 GMT
From:      luigi@pical2.iet.unipi.it (Luigi Rizzo)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject:   Yet another version of PCBRIDGE...

We are pleased to announce a new, ROMable version of PCBRIDGE, with
some additional features over the original software. We still plan some
enhancements and changes, but the program is fairly stable at this
point, thus we think it's time to release it.

The software is available by anonymous ftp from pical3.iet.unipi.it
(131.114.9.12), in the directory /pub/bridge.

The following notes apply to PCBRIDGE v.2.77 and higher:

PCBRIDGE v.2.77    by Alessandro Fanelli, Luigi Rizzo (luigi@iet.unipi.it)
05 may 93 18:00   Universita` di Pisa - via Diotisalvi 2, 56126 Pisa, Italy
                         Tel. +39-50-568533  -- Fax +39-50-568522
                (original sources by Vance Morrison, Northwestern University)

Please send your comments and requests to luigi@iet.unipi.it


1. Motivation
=============

PCBRIDGE, in the original version by Vance Morrison, is a quite useful piece
of software. We have been using it for a long time, with great success.
There were, however, a few features we missed:

	- ROMable code. A learning bridge doesn't need any
	  configuration, data, thus it is suitable for a ROM
	  implementation. Also, given that the bridge is usually a
	  unattended device, not having a disk means an increased
	  reliability. Finally, no disk means no MSDOS or other OS license is
	  necessary for the bridge.

	- Auto configuration. It is useful that the bridge can
	  detect its configuration (basically the number of ports) at
	  run time, rather than being forced to have a separate
	  executable for each configuration. This is especially true
	  for a ROM version.

	- Traffic statistics. As the bridge has to analyze
	  all the traffic on the networks it is connected to, it
	  becomes a good candidate for collecting statistics on the
	  traffic. Also, it is important to know informatio on how
	  the bridge is working, e.g. the effectiveness of
	  the filtering performed by the bridge.

	- Remote management. It is useful that the bridge
	  can be managed through the network: it should send
	  its statistics and accept configuration commands
	  from a host on the network.

In the current version of PCBRIDGE, all of these issues have been
solved to some degree. Of course, there are still other features (e.g.
spanning tree algorithm, increased filtering capabilities, etc) that
would be useful and we didn't implement yet.

2. New features

Our PCBRIDGE is based on version 1.21 of PCBRIDGE. The enhancements we made
are mainly related to the WD80x3 version of the bridge, due to the lack
of hardware and interest for other versions of the bridge. We are
confident that the changes we introduced should be easily portable to
other versions of the bridge, but make no promises about them.

We will illustrate the advantages of the new version in some detail.

-- ROMABLE code --
	The sources have been modified in order to produce a ROMable
	code. To this purpose, our code compiles to a .COM file, using
	dynamic allocation for some data blocks (e.g. the filtering
	table) that would not fit into the .COM
		The .COM executable can be run from a disk, or put onto
	an EPROM together with a very simple loader that we include.
	The loader simply copies the .COM bridge code to RAM,
	initializes registers as DOS would do, and jumps to the bridge
	code. The loader can be used for other programs than PCBRIDGE,
	with no changes.

-- Automatic configuration --
	We have added a probe routine (for WD cards) so that the program
	will auto detect, at boot time, which cards are present and
	which ones are not, thus simplifying the use of the bridge. We
	currently use a single executable, compiled for up to 5 card.
	At run time, only existing cards will be used.

-- Loop detection --
	Bridged networks shouldn't have (active) loops, although these
	may be created either by mistake, or on purpose in order to
	increase reliability. If loops are present, bridges must find
	an acyclic graph out of the existing network and work only on
	this graph.
		We don't implement the standard Spanning Tree
	Algorithm, but we DO detect loops and avoid that a bridge will
	retransmit the same packet forever. Loops are detected when a
	bridge sees the same source address on two of its ports. In
	this case, the bridge will disable one of the ports involved in
	the loop, resetting to normal conditions after 10 seconds in
	the hope the loop has been removed. If not, the port will be
	disabled again and again, without retransmitting any packet.
	Note that the loop-detection code is very primitive at this
	time, and we are still working on it. In presence of a loop, a
	multiport bridge is not guaranteed to work, but at least it
	tries not to disturb other stations!

-- Filtering --
	The bridge can be configured in order to pass all packets, or
	filter them depending on ethernet type. Currently this can only
	be set by recompiling the code, or patching it, but we plan to
	make this more easily configurable.

-- Statistics --
	Statistics are accumulated in a set of 48-bit counters. These
	parameters cover both network traffic (# of received packets and
	bytes), and bridge behaviour (# of forwarded, dropped,
	broadcast packets, hash table collisions, interface status).  The
	latter two are of particular importance in measuring the
	effectiveness of the filtering capabilities of the bridge, and
	for monitoring the network.

		Statistics are shown on the screen of the bridge, if
	present.  The software will auto detect a BW or Color screen,
	printing counters in HEX format (because we don't want to waste
	time doing a binary-to-decimal conversion; after all, we only
	want a feeling of what's going on).

		Statistics data are also sent on all the network
	interfaces every 10 seconds, using a proprietary format (which
	is not SNMP). A simple daemon program (also included in the
	sources) running on Unix can monitor the status of all the
	bridges in the network, being extremely helpful in problem
	determination.

-- Remote management --
	The same daemon program which receives statistics is also
	reported of the status of the interfaces: the bridge recognizes
	an open- or short-circuit on the wire (because this gives rise
	to transmission failures due to too many collisions) and also
	reports whether a port is disabled (because of a loop) or not.

		The bridge also accepts a few command from the network:
	DUMP_DATA_SEG	dumps part of the bridge's data structure.
	DUMP_TABLE	dumps part of the bridge's filtering table.
	FLUSH_TABLE	flushes the filtering table.
	RESET		performs a cold reset of the bridge.

	These commands have been inserted mainly for testing purposes,
	and are not really needed during regular use. Actually, we plan
	to remove them in the future.

3. Setting up a bridge

In order to build our bridge, you need:

- a 286+ motherboard with at least 256K RAM, and a power supply.
  We are currently using 386sx-33 motherboards, which prove effective.

- 1(yes, one)..5 ethernet cards (SMC-Elite WD8013 or
  compatibles) configured at any of the following IO addresses:
	0x280, 0x2a, 0x300, 0x320, 0x340.
  Of course, a bridge with one card won't bridge anything, but it will
  monitor network traffic, if you like it.
	We have had very good success with SMC-Elite cards, while older
  WD80x3 clones proved unreliable (i.e. the bridge hangs every now and
  then). This is due to a bug in the old 8390 controllers which is not
  properly dealt with by the bridge software. We didn't fix the bug,
  because we don't know much about it,  and since our bridges with SMC
  cards have been working continuously for over 8 months, we're not too
  concerned about this problem.

- the BRIDGE eprom, or a floppy disk with the BRIDGE software.
  The eprom can be build as indicated in the next section.
  Alternatively, you can put a floppy controller and prepare a bootable
  floppy with the PCbridge code on it.  Either case, the bridge will
  autodetect the existing hardware and start working -- no
  configuration is required.

A video card and monitor, floppy disk, and keyboard are optional
and not required at all for using the bridge.

With all the elements available, you need to:
- configure the ethernet cards with the appropriate IO
  addresses. No interrupts are used, and memory addresses are set at
  run time by the sorftware. Remember to put the eprom on one of them
  (any one) and enable it at address 0xD800.

- assemble the PC with RAM and ethernet cards;
- temporarily using using a video card and keyboard, configure the
  CMOS in order to boot without video, keyboard and disks.
- disconnect video card and keyboard. The bridge is ready.

4. Building the EPROM

The program comes both in source format and executable code. The
assembler requires at least MASM 6.0 to be compiled. Options are

	ml -VM -Duse_filters -Dno_loops bridge.asm

which produces a bridge.com file of about 20K

You can alter the configuration of the bridge which is stored in the
DECLARE.INC file. See the original PCBRIDGE documentation for this.
The binary file (bridge.com) included in the distribution is configured
for passing all packets. If you want to change it, simply recompile the
sources as shown above. Also, have a look at the filtering code in
BRIDGE.INC and CT.INC

In order to produce the eprom, you need to do the following:

- build an eprom image, by compiling and running 'image.c'
- download the image to a eprom programmer. You need a 32K eprom for
  this version of pcbridge.
- burn the eprom.

5. Monitoring the network.

Statistics are sent over the network, via UDP on port 2299, every 10
seconds. A simple program, called pcbridged, will allow you to collect
statistics. pcbridged has been taken from bootpd sources and modified to
serve our purposes. It is a hack, but it works for our purposes.

Commands are accepted via UDP. Check pcbridged.c for more
informations.

6. Future extensions

We are planning the following additions to the bridge code (in order of
importance):

- enable new commands from a manager host.
  Among these commands are:
  - enable/disable bridging on selected ports/hosts.
  - We are very dubious about giving a bridge the ability to download
    and run new code. While it eases management, it can kill a bridge
    (say, if some buggy code is loaded), requiring manual intervention.
- enable software configuration of filtering code.
- add better code for loop detection.
- fix the behaviour for old WD cards

At the moment we don't know whether or not we will be able to add SNMP
support, or the real spanning tree algorithm, or more filtering
capabilities. For some of these issues, you may find it useful some of
the other PD PC-based bridges, such as

- the OSU KarlBridge program, which can be obtained via anonymous ftp
  from nisca.acs.ohio-state.edu, 128.146.1.7, in /pub/kbridge.  Please
  send e-mail to kbridge@osu.edu with questions and comments about it.

- the TAMU bridge and associate software, available via
  anonymous ftp in sc.tamu.edu:pub/security/TAMU

--- end of file ---


-----------[000099][next][prev][last][first]----------------------------------------------------
Date:      Fri, 7 May 1993 11:29:47 GMT
From:      luigi@pical2.iet.unipi.it (Luigi Rizzo)
To:        comp.dcom.lans.ethernet,comp.protocols.tcp-ip
Subject:   DECbridge90 filtering strategy ?

While developing our own version of PCBRIDGE (see my posting in
comp.protocols.tcp-ip), I've come across a 'feature'
of a DECbridge90 which is present in our network.

In short, I suspect this bridge doesn't learn that a node
is on a given port unless this node sends some particular
packet (a broadcast, or a packet to a node which is known
to be on the other side of the bridge).
     While this constitutes no problem in a normal environment,
it was a problem for because we have two IP subnetworks on the
same (bridged) ethernet, and the router almost never flushes
its ARP tables and doesn't need to send broadcasts.

Of course I may be totally wrong, but after 10 days of tracing
ethernet packets I'm pretty confident there's something non obvious
with the learning strategy of the DECbridge90 (mainly because
once it has been replaced with a PCBRIDGE, all the strange things
have disappeared!).

I'd really appreciate suggestions (other than RTFM -- I don't have
them) from people in the know; and particularly I'd like to know
if what I suspect is true.

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

-----------[000100][next][prev][last][first]----------------------------------------------------
Date:      7 May 93 12:16:03 GMT
From:      J.Crowcroft@cs.ucl.ac.uk (Jon Crowcroft)
To:        comp.protocols.tcp-ip
Subject:   Re: Two IP networks -> one phy/multicast



 >Not really. All that would do is shift the goalposts. 
 >
 >First of all, IP multicasting is somewhat experimental and few
 >commercially available TCP/IP implementations support it.

like sun post solaris and Silicon graphics on unix systems, and at
least ftp s/w on PCs...
 
 >Wth multicasting, the IP multicast address is usually encapsulated
 >inside an ethernet broadcast packet. This means that, as far as the
 >ethernet is concerned, there is no real difference between the IP
 >broadcast and multicast. 

nope - its puit i na multicast packet, so it doesnt hit on the
ethernet handler with interrupts unelss they've programmed their
address recongintion for that multicast (or all multicasts)

there are fairly simpole mappings from ip grou pto ethernet group
since there's more than enuff ethernet address bits (praise be to
xerox!), but many ethernet hardware's unfortunaltey have very limited
size address recog list, so end up having to use a single multicast
addr - but still doesnt clobber the whole netfull of hosts... 

 >and multicast addresses for each IP network on the ethernet and,
 >critically, know not to forward these packets. This is not much
 >different from telling each host about the other IP networks sharing
 >the cable.
 
and IGMP tells everyone nicely about the presence of multicast groups
and group members using the well known multicast address concept...

cheers

 jon


-----------[000101][next][prev][last][first]----------------------------------------------------
Date:      7 May 1993 12:56:50 GMT
From:      upi@fm11pc22.tu-graz.ac.at (Norbert Harrer)
To:        comp.protocols.tcp-ip
Subject:   Re: FTP archive for RFCs

In article <1098@idanm.pfbs.philips.se> joho@kobe (Hans ter Horst) writes:

>I'm afraid that this is probably a FAQ, but can somebody inform me
>where I can find the RFCs.
>
>/Hans
>--
>  joho@pfbs.philips.se

Take a look at nic.ddn.mil (192.112.36.5) !

                     #
                      #
                       #
#########################  Dead End. 
                       # 
                      #
                     #

-----------[000102][next][prev][last][first]----------------------------------------------------
Date:      7 May 1993 13:07:55 GMT
From:      trier@odin.ins.cwru.edu (Stephen C. Trier)
To:        comp.protocols.tcp-ip
Subject:   Re: FTP "hash" lies through its teeth

In article <1993May7.040736.4067@galileo.cc.rochester.edu> dsew@troi.cc.rochester.edu (David Sewell) writes:
>Is there some programmer's cabal that says "hey, let's implement
>the hash feature with a call to rand() and have some big fun!"???

It's a bug.  If you can't deal with that, you need to find something else
to keep yourself entertained -- alt.conspiracy might be a good choice. :-)

Not all FTPs have this bug, so it would have been quite appropriate to
mention which one you were using.

(The bug, for those who might care, is that some versions of Berkeley
FTP do a read for one hashmark's worth of data, then print the
hashmark.  Since reads don't always read as much as is requested, those
hash marks might not represent as much data as is claimed.  They better
represent successful read calls than bytes received.  I think they have
useful diagnostic value even with the bug.  FWIW, some MS-DOS FTPs make
the same mistake.)

-- 
Stephen Trier (trier@ins.cwru.edu)   Star Trek dialog mistake of the week:
Network Software Engineer              "We've tried every decryption key
IRIS/INS/T                               on record, Captain."
Case Western Reserve University             - Geordi LaForge, ST:TNG, 5/1/93

-----------[000103][next][prev][last][first]----------------------------------------------------
Date:      Fri, 7 May 1993 16:11:02 GMT
From:      rlm@helen.surfcty.com (Robert L. McMillin)
To:        comp.protocols.tcp-ip
Subject:   SLIP IP addresses

Is it in general necessary to use a different network name for SLIP?  I
am presently working on a network that has a bunch of modems attached to
many machines; each is SLIP-capable, but the interesting thing about it
is that each machine is registered in the hosts database as

	147.11.22.33	hal
	165.11.22.33	hal-sl

That is, if hal uses SLIP, it's known as hal-sl.  Is this standard
practice?

I apologize for my lack of knowledge about such things, but I'm
something of a newcomer in this arena.


	
--

Robert L. McMillin | Surf City Software | rlm@helen.surfcty.com | Dude!
"What's taking so long?  It's only typing!"
	-- a marketing manager posing as a software manager


-----------[000104][next][prev][last][first]----------------------------------------------------
Date:      7 May 1993 16:12:19 GMT
From:      barmar@think.com (Barry Margolin)
To:        comp.protocols.tcp-ip
Subject:   Re: FTP "hash" lies through its teeth

In article <1993May7.040736.4067@galileo.cc.rochester.edu> dsew@troi.cc.rochester.edu (David Sewell) writes:
>I've finally gotten irritated enough about this to wonder
>what's going on.  Does the ftp "hash" toggle serve any useful
>purpose other than to keep you entertained watching the screen
>if the number of bytes per hash mark is both non-standard and
>unpredictable?  

Yes, it lets you know whether the transfer is actually progressing or is
hung.

>		 Just now--and this is typical--I did a download
>where I set hash on and got a "Hash mark printing on (8192 bytes
>per hash mark)" message.  So of course a transfer of 148723 bytes
>goes through 268 little #'s--which isn't even 512 bytes/hash,
>it's 554...  

When receiving a file, a hash mark is printed whenever the read() on the
network connection returns successfully.  Although the routine asks for 8K
bytes, read() is permitted to return less than is requested, and often
does.

When sending a file the hashes probably do happen every 8K bytes, since
they're printed after every write() call.
-- 
Barry Margolin
System Manager, Thinking Machines Corp.

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

-----------[000105][next][prev][last][first]----------------------------------------------------
Date:      Fri, 7 May 1993 17:51:08 GMT
From:      mcollins@db (Marty Collins)
To:        comp.unix.sysv386,comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc,comp.sys.novell
Subject:   Re: SCO TCP/IP <> Netware TCP/IP problem

gryphon@openage.openage.com (The Golden Gryphon) writes:
: skl@wimsey.bc.ca (Samuel Lam) writes:
: 
: >In article <3@mhinfo.UUCP>, carrato@mhinfo.UUCP (Tony Carrato) wrote:
: >>It appears that either a) the SCO system is set up wrong somehow ...
 
: >That's probably it.  Check the SCO box's subnet mask to make sure
: >it's using the correct value.  Also check its routing table for a
: >route to the other network via the Novell router.
: 
: I think not.  Your Novell is probably acting as a learning bridge.  It knows
: which machines are on each side of the LAN as soon as they talk.  If you moved
: PC-1 to the non-SCO segment and rebooted the Novell server and tried again,
: then you could be sure this was the case if it worked.


Novell does not have a bridge product for TCPIP. Novell currently only supports
bridging IPX or routing IP IPX Appletalk or OSI. It is possible that
the overall TCPIP setup for NetWare and SCO is not correct. However
I came into this thread about 10 days late so I don't know what the
real issue is.
: 
: -- 
: The Golden Gryphon 				gryphon@openage.COM
: "The Crown Jewel of the American Prison System." - President Bill
: Clinton on living in The White House.
: Openage - The Premier SCO UNIX integrator in the Washington D.C. area

--
	   A woman needs a man like a fish needs a bicycle.

   Marty Collins	       				U2 
   Product Support                                      Tryin to throw your
   NOVELL, INC.  San Jose, CA.				arms around the world.
   mcollins@novell.com   or
   Marty_Collins@SJF.Novell.COM
   1-800-NETWARE  

-----------[000106][next][prev][last][first]----------------------------------------------------
Date:      Fri, 7 May 1993 18:25:49 GMT
From:      evans@tsd.arlut.utexas.edu (Eric Evans)
To:        comp.protocols.tcp-ip
Subject:   Re: HELP: socket buffer overflow ?

clfang@csie.nctu.edu.tw (Chien-Lu Fang) writes:

>   How to solve the problem that ...
>     In the condition that many processes send MESSAGE to
>   one process at the same time. Cause the "socket buffer
>   overflow" , when using "socket UDP" protocal.
>     How to increase the "socket buffer size" ?
>     Help !!!.....



After you have opened your socket, use setsockopt() thusly:

    setsockopt (sd, SOL_SOCKET, SO_RCVBUF, &rcvq_max, sizeof rcvq_max) 

where 

    int rcvq_max = ***** ;   /* Limit on socket receive     */
                             /* queue allocation (in bytes) */

The default value will vary among UNIXes.  Your UNIX might also restrict 
how high it can be set.

Increasing this limit might not help much, if your UNIX implementation 
does not actually pre-allocate this many bytes for the queue.  You could 
still lose packets if the kernel can't allocate buffers fast enough to 
keep up with the incoming burst of packets.


BTW, if you use TLI instead of sockets, increasing this limit looks like 
the following (at least it does in SCO UNIX):


    struct opthdr  *ohdr ;    /* Pointer to option buffer */

   /* Allocate the option management request structure */
    if ((opt = (struct t_optmgmt *) t_alloc (fd, T_OPTMGMT, T_ALL)) < 0) {
	t_error ("\n t_alloc/T_OPTMGMT ERROR ") ;
	exit (1) ;
    }

   /* Specify the broadcast option */
    ohdr        = (struct opthdr *) opt->opt.buf ;
    ohdr->level = SOL_SOCKET ;
    ohdr->name  = SO_RCVBUF ;
    ohdr->len   = OPTLEN (sizeof (int)) ;

   /* Set the option value */
    *((int *) OPTVAL (ohdr)) = ***** ;  /* Max queue size in bytes */

    opt->opt.len = sizeof (struct opthdr) + OPTLEN (sizeof (int)) ;
    opt->flags   = T_NEGOTIATE ;

    if (t_optmgmt (fd, opt, opt) < 0) {
	t_error ("\n t_optmgmt ERROR ") ;
	exit (2) ;
    }

-------------------------------------------------------------------------
Eric Evans                        evans@titan.tsd.arlut.utexas.edu
Applied Research Laboratory
University of Texas at Austin




-----------[000107][next][prev][last][first]----------------------------------------------------
Date:      Fri, 7 May 1993 19:39:13 GMT
From:      daniel@nstn.ns.ca (Daniel MacKay)
To:        comp.protocols.tcp-ip
Subject:   Re: RARP through a Router?

In <C6I3Io.BoF@sci.kun.nl> petervc@sci.kun.nl (Peter van Campen) writes:

>- When we tried it out again on SunOS4.1.2 the SunOS rarpd refused to
>  give a RARP reply, because the client was not on his subnet.

Hey, I just discovered this for myself a couple weeks ago!!  I have a whole
slew of Ether bridges that need RARP, but I can't put a server on every
segment.  Does anyone have any suggestions?  I've been looking for working
rarpd code, but haven't found anything yet.  Any suggestons or pointers
would be very much appreciated.
--
	Daniel MacKay				daniel@nstn.ns.ca
	NOC Manager, NSTN Operations Centre	902-494-NSTN
	Dalhousie University, Halifax, Nova Scotia, Canada

-----------[000108][next][prev][last][first]----------------------------------------------------
Date:      Fri, 7 May 1993 19:44:05 GMT
From:      daniel@nstn.ns.ca (Daniel MacKay)
To:        comp.dcom.lans.ethernet,comp.protocols.tcp-ip
Subject:   Wanted: working RARPD source code

Hello!

I need a slightly hacked up RARPD -- one that'll return the RARPs to a
machine that's on a different network (cisco will bridge the RARP for me)
-- and I can't find working source anywhere on the Internet- they all
have missing or weird libraries.  The one I'm using on the Sun won't send
one to a machine on a different subnet, which is pretty silly considering
that RARP's a bridged protocol.

Does anyone have working source?  I'd very much appreciate some pointers.
ADthanksVANCE!
--
	Daniel MacKay				daniel@nstn.ns.ca
	NOC Manager, NSTN Operations Centre	902-494-NSTN
	Dalhousie University, Halifax, Nova Scotia, Canada

-----------[000109][next][prev][last][first]----------------------------------------------------
Date:      Fri, 7 May 1993 20:13:47 GMT
From:      vjs@rhyolite.wpd.sgi.com (Vernon Schryver)
To:        comp.protocols.tcp-ip
Subject:   Re: NIS & DNS questions

In article <RLM.93May2210925@helen.surfcty.com>, rlm@helen.surfcty.com (Robert L. McMillin) writes:
> 
> Another solution to this problem is to force everyone to use GNU bash,
> which (IMHO) is better than either the C shell or the Bourne shell; it
> retains the Bourne shell's robustness with the C shell's history
> mechanism, and skips the C shell's lamer extensions.


As an extra, added attraction, the incredible wealth of features in
bash make it incredibly slow to start, compared to /bin/sh or ash.
Bash even makes csh look fast.


Vernon Schryver,  vjs@sgi.com

-----------[000110][next][prev][last][first]----------------------------------------------------
Date:      Fri, 7 May 1993 21:19:35 GMT
From:      wbrand@krishna.shearson.com (Willy Brandsdorfer)
To:        comp.protocols.tcp-ip
Subject:   Re: Commercial Multimedia Software for teleconferencing

In article <C6MuCs.L01@ra.nrl.navy.mil> atkinson@itd.nrl.navy.mil (Randall Atkinson) writes:

     Freely distributable (though experimental as yet) software
   that does audio/video conferencing and uses protocols being developed
   by the IETF include:

   NAME	PURPOSE					Developer
   ----	----------------------			------------------
   sd	conferencing session directory tool	Lawrence Berkeley Laboratory
   vat	audio multicasting/conferencing		Lawrence Berkeley Laboratory
   wb      conferencing white board tool		Lawrence Berkeley Laboratory
   nevot     "        "           "		Computer Science, U. of Mass.
   nv	audio/video multicasting/conferencing	Xerox Palo Alto Research Center
   ???	  "     "        "           "		INRIA in France


??? = ivs

----------------------------------------------------------------------
William Brandsdorfer            | UUCP:    !uunet!lehman.com!wbrand
Lehman Brothers                 | INET:    wbrand@lehman.com
388 Greenwich St.               | Voice:   (212) 464-3835
New York, N.Y. 10013            | 
----------------------------------------------------------------------

-----------[000111][next][prev][last][first]----------------------------------------------------
Date:      Fri, 7 May 1993 22:58:38 GMT
From:      wcs@anchor.ho.att.com (Bill Stewart +1-908-949-0705)
To:        comp.protocols.tcp-ip
Subject:   Re: FTP "hash" lies through its teeth

   In article <1993May7.040736.4067@galileo.cc.rochester.edu> dsew@troi.cc.rochester.edu (David Sewell) writes:
   >Is there some programmer's cabal that says "hey, let's implement
   >the hash feature with a call to rand() and have some big fun!"???

The important thing the hashmark tells you is
	"I'm not dead yet!"
which is nice to know if your firewall or the ftp server occasionally
drops sessions.
--
#				Pray for peace;      Bill
# Bill Stewart 1-908-949-0705 wcs@anchor.att.com AT&T Bell Labs 4M312 Holmdel NJ
#	              No, I'm *from* New Jersey, I only *work* in cyberspace....
# White House Commect Line 1-202-456-1111  fax 1-202-456-2461

-----------[000112][next][prev][last][first]----------------------------------------------------
Date:      Sat, 8 May 1993 03:11:25 GMT
From:      atkinson@itd.nrl.navy.mil (Ran Atkinson)
To:        comp.protocols.tcp-ip
Subject:   Re: NIS & DNS questions

In article <RLM.93May2210925@helen.surfcty.com>, rlm@helen.surfcty.com (Robert L. McMillin) writes:
>> 
>> Another solution to this problem is to force everyone to use GNU bash,
>> which (IMHO) is better than either the C shell or the Bourne shell; it
>> retains the Bourne shell's robustness with the C shell's history
>> mechanism, and skips the C shell's lamer extensions.

In article <hooiv36@rhyolite.wpd.sgi.com> vjs@rhyolite.wpd.sgi.com (Vernon Schryver) writes:
>As an extra, added attraction, the incredible wealth of features in
>bash make it incredibly slow to start, compared to /bin/sh or ash.
>Bash even makes csh look fast.

  Vern forgot to mention BASH's other two features.  It is a great way
to see if you really have enough memory in your machine (count how
many shells are running before you start to thrash memory) and it is
also a way to use up disk space quickly so you don't have space to
install those applications things that lusers keep asking for.  :-)
:-)

  GNU does make a popular and fairly good shell though.  At least one
of the lisp hacks on our CM-5 has been known to use GNU Emacs as his
login shell...

Ran
atkinson@itd.nrl.navy.mil



-----------[000113][next][prev][last][first]----------------------------------------------------
Date:      Sat, 8 May 1993 03:19:27 GMT
From:      vjs@rhyolite.wpd.sgi.com (Vernon Schryver)
To:        comp.protocols.tcp-ip
Subject:   Re: How to determine the path of each packet?

> In article <kaiwan.736672075@yacht> kaiwan@ee.fit.edu (Kaiwan Hongladaromp.) writes:
> >As the subject said.. How can I acquire the path that my packet go thru?
> >I like to know (if possible) from both side views, ie. sender and receiver.
> >And is this possible both on datadram and connected-orientd protocol..
> > ...

In article <1993May6.155354.10641@acc.com>, art@acc.com (Art Berggreen) writes:
> 
> The most common first order approximation is to run the traceroute program
> from both ends.  If there is really only one possible path, this works well.

More than one person has pointed out to me that I'm wrong when I wrote
the same thing.  You can use `traceroute -g` to measure the round trip.


> Be aware though, that every IP packet is routed independently and the paths
> taken by two packets may differ.  Traceroute doesn't really deal with this
> because it sends a whole series of packets.  With the growth of the Internet
> and the use of more intelligent routing and loadsharing, this phenonmenon is
> likely to become more common.  The most accurate way to capture this
> information
> would be to use the Record Route IP option, but the size of the Internet has
> long since exceeded the capability of that mechanism (except in very short
> paths).
>...

Thanks for point out route jiggling.
That makes me feel less dumb for suggesting `ping -R`.


Vernon Schryver,  vjs@sgi.com

-----------[000114][next][prev][last][first]----------------------------------------------------
Date:      8 May 1993 18:44:57 -0500
From:      yau@cs.utexas.edu (David K.Y. Yau)
To:        comp.protocols.misc,comp.protocols.tcp-ip
Subject:   How to tell a SunRPC packet

Hi,

Is there any straightforward way to tell whether  a UDP or TCP packet is
a SunRPC request/reply? What is the best way to figure it out?

Thanks,
David

-----------[000115][next][prev][last][first]----------------------------------------------------
Date:      8 May 93 14:22:10 GMT
From:      mikeg@Ingres.COM (Mike Glendinning)
To:        comp.protocols.tcp-ip,comp.dcom.sys.cisco
Subject:   Re: Cisco IP filtering, the "established" criterion, and FTP

In article <1993May5.172508.17650@unipalm.co.uk> tim@unipalm.co.uk (Tim Goodwin) writes:
>Cisco routers can filter TCP packets according to whether they
>relate to an established connection (on the basis of the ACK and RST
>bits).
>
>When I put this in place, FTP suddenly stopped working.  A quick
>glance at RFC 959 suggest that FTP works in a somewhat bizarre way.
>etc...

The "proxy ftp" package referred to in an earlier reply to this message
is called "socks" and was written by David Koblas.  You can get it
from 's1.gov', file '/pub/socks.tar.Z' (well, it was there the last
time I looked).

The "socks" package implements a proxy TCP server on the firewall
host, and comes with a replacement BSD socket library (sort of)
with which you can link clients like 'ftp' and 'telnet'.  The
modified clients then perform all TCP connections via the proxy
server on the firewall host.

The only problem with "socks" is that it assumes you can resolve
all hostnames to IP addresses on the client side.  Depending on
your firewall setup, this may or may not be possible.  On my list of
"things to do" for our own firewall setup are some changes to this
package so that it can perform proxy DNS lookup as well.  Contact
me if you're interested (or want to volunteer some help!).

-Mike Glendinning, Ingres UK (mikeg@ingres.co.uk).

-----------[000116][next][prev][last][first]----------------------------------------------------
Date:      Sat, 8 May 93 15:41:05 GMT
From:      dsew@troi.cc.rochester.edu (David Sewell)
To:        comp.protocols.tcp-ip
Subject:   Re: FTP "hash" lies through its teeth

In <WCS.93May7175838@rainier.ATT.COM> wcs@anchor.ho.att.com (Bill Stewart +1-908-949-0705) writes:

>The important thing the hashmark tells you is
>	"I'm not dead yet!"
>which is nice to know if your firewall or the ftp server occasionally
>drops sessions.

Quite so.  Sometimes, though, I like to estimate whether I only have
time to brush my teeth during a transfer or whether I can go out and
do the week's grocery shopping.  :)  

Thanks to people who verified and explained the existences of bugs &
limitations.

-----------[000117][next][prev][last][first]----------------------------------------------------
Date:      8 May 93 20:01:32 GMT
From:      eb@felix.Sublink.Org (Enrico Badella)
To:        comp.protocols.snmp,comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject:   SNMP capable KA9Q, anyone done it?

I have picked up a copy of KA9Q and saw there are hooks for SNMP in the relevant
points but no agent.
I would like to try getting the CMU agent code running with KA9Q and was
wondering if anyone has already accomplished such a task and would share
some info on doing it.

Thanks.

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

-----------[000118][next][prev][last][first]----------------------------------------------------
Date:      Sun, 9 May 1993 02:37:28 GMT
From:      mikey@yoho.carleton.ca (Mike G McFaul)
To:        comp.protocols.ppp,comp.protocols.tcp
Subject:   Re: bad ppp telnet performance

In article <iand.736732795@labtam> iand@labtam.labtam.oz.au (Ian Donaldson) writes:
>yost@netcom.com (David Yost) writes:
>

[Compliant about poor telnet response when ftp active deleted...]

>>Anyone know how to fix this?  Is ther any ongoing work?
 
>>P.S.  The host software is SunOS 4.1.3.  Don't know
>>      what PPP we're running.
>
>This sort of problem is usually due to one or two things:  IP packet queue 
>ordering, and modem buffering.
>
>Many PPP's will queue telnet/rlogin and Type-Of-Service == LowDelay packets
>at the head of the queue, so that they get transmitted ahead of other packets.
>
>However there are many modems on the market with huge input buffers (eg: 15K)
>and this is usually the killer.  ie: you have to wait for 15K of data
>to travel throught the modems before your telnet echo comes back.
>This can take a few seconds even with V.32bis/V.42bis enabled.
>
>A solution here is to reduce the input buffer size of the modem, if you can.
>
>Ian Donaldson
>

There is another way to cure the problem. The deleted analysis was/is
correct, the telnet packets are queued behind the ftp. The real
culprit is the window size that is set in the TCP/IP software layer on
your machines. Its usually set to around 4096 bytes, this is fine for
a 10Mbit/sec ethernet, but way too high for a slow speed ppp link
(remember everything is relative!). Its not hard to re-set the window
size at the socket level when a connection (ftp data connection) is
established.  If the window size is too low, the data transfer is
burpy, if the window size is too large, the link gets plugged. On my
link with an MRU of 256 on USR Courier V.32bis modems, the best window
size is around 432 bytes for compressed data. Thats large enough to
keep things streaming.  Oh yeh for this to really work, you must have
that same link set with TCP_NODELAY, so the TCP/IP software layer
doesn't attempt to buffer up the ACK packets.

The neat thing about this is I only have to run a special ftp client
program (and a stock in.ftpd server program on my ppp host). If I run
the regular ftp client program, I'm back to a plugged link...

I call this 'slow ftp' and I use it all the time. I get excellent
telnet response while ftping stuff... its simple and it works!

-----------[000119][next][prev][last][first]----------------------------------------------------
Date:      Sun,  9 May 1993 13:00:19 -0400
From:      Abhijit_Khale@transarc.com
To:        comp.protocols.tcp-ip,comp.protocols.misc
Subject:   Re: How to tell a SunRPC packet

Excerpts from netnews.comp.protocols.tcp-ip: 8-May-93 How to tell a
SunRPC packet David K.Y. Yau@cs.utexas (156)


> Is there any straightforward way to tell whether  a UDP or TCP packet is
> a SunRPC request/reply? What is the best way to figure it out?

I'm assuming you're using some sort of network packet filter
to look at all packets on the net. 

In any case, the answer is No, there isnt any way to guarantee that a
particular packet is an RPC packet. However, you can make a pretty
good guess in the following manner :  

For an RPC request, the fields in the header are   like this
	
	32 bit xid; /* "transaction" id of call */
	32 bit direction field, 0 for CALL
	32 bit RPC version field, always 2
	<lots of other fields like progam number, procedure number,
	version number etc.>

Therefore to check if this is an RPC request, you check that the 2nd field
in the header is 0, and the 3rd field is 2. If so, theres a fairly high probab-
ility that this is an RPC request. 

For an RPC reply, the fields are like this :
	
	32 bit xid;
	32 bit direction field, 1 for REPLY
	32 bit reply status, either 0 (MSG_ACCEPTED) or
	 1 (MSG_DENIED)

Once, again, you have to check for the appropriate fields, and there's
a pretty good chance that this a reply packet. 

Incidentally, a reply doesnt contain the program number or the proced-
ure number of the call, so if you want to decode the entire reply, you
need to keep a small cache of the xid's around in the packet filter,
so you can match request with reply (requests and replies have the
 same xid). 

In practice, you would also increase the "hit rate" for RPC packets by
simply not checking packets from officially assigned ports (minus
those assigned to RPC services). 

Abhijit
File Systems Group, Transarc, Pittsburgh. 





-----------[000120][next][prev][last][first]----------------------------------------------------
Date:      9 May 1993 11:01:32 GMT
From:      jan@ravel.ifs.univie.ac.at (Jan M. Stankovsky)
To:        comp.protocols.tcp-ip,comp.os.ms-windows.apps,comp.windows.x,comp.sys.ibm.pc.hardware,comp.windows.open-look
Subject:   Loosing Mouse-Pointer


Hardware: 486DX 50Mhz
          Ms-Mouse
      !!  Pivot - A4 Monitor
         SVGA - card
         WD-Ethernet-card

Software: MSDos 6.0
          Win 3.1
          HclExceed for windows (V3 [?], very last version)
          PC/TCP from FTP

Problem: The Mouse pointer dissapears everytime it's moved to an X-Client window. t
It reappears when it is moved back to a WINDOW-window. What's going on? If anybody has a solution for this problem, this will be very fine, but any hint what the the problem could be is also appreciated.

Thanks

jan@ifs.univie.ac.at





-----------[000121][next][prev][last][first]----------------------------------------------------
Date:      9 May 1993 19:31 MST
From:      gavron@spades.aces.com (Ehud Gavron)
To:        comp.protocols.tcp-ip
Subject:   WIRELESS LAN Vendors, this is your golden opportunity of the day.

	If you sell wireless LAN systems (ETHERNET, Token-Ring, FDDI)
	that will work in a building environment (i.e. UHF RF or IR)
	this is your chance to display it for free at a trade show,
	have your sign displayed prominently, and be considered as
	the vendor of choice by this health-care VAR.

	If showing your stuff to several hundred health-care facility
	representatives, with the auspices of several major VARs who
	can resell your equipment appeals to you, please write me at
		
		gavron@sunquest.com

	Or call at
		+1 602 570 2546


	Thanks 

	Ehud

--
Ehud Gavron        (EG76)     
gavron@aces.com
Yow!  Are you the self-frying president?

-----------[000122][next][prev][last][first]----------------------------------------------------
Date:      Sun, 9 May 1993 16:19:20 GMT
From:      masami@mtu.edu (MOHAMMED A. SAMI)
To:        comp.protocols.misc,comp.protocols.ibm,comp.protocols.iso,comp.protocols.tcp-ip
Subject:   SONET Protocol

I am looking for info on SONET (DQDB) protocol, specifically on t
he two layers
Physical and Data Link.

Please post your responses to the e-mail address

     masami@cs.mtu.edu

Thanx in advance

Mohammed Sami

-----------[000123][next][prev][last][first]----------------------------------------------------
Date:      Sun, 9 May 1993 21:01:18 GMT
From:      geertj@ica.philips.nl (Geert Jan de Groot)
To:        comp.protocols.tcp-ip
Subject:   Re: Microsloth Mail SMTP Gateway

prs9k@brain.med.virginia.edu (Phil Scarr) writes:

>If anyone has any hints for configuring the Microsloth Mail SMTP Gateway
>to talk to the outside world, I'd love to hear from you.

Please don't do that. The product contains a buggy, non-conformant SMTP
server; It supports less than RFC822 specifies and often produces incorrect
result codes.

What is more important, it does not understand the mechanisms used by list 
maintainers to keep error messages from bouncing back on the list. The result?
If Joe User loses his mailbox (leaving the company?), the list is cluttered
instead of the error-reporting address. 

Microsoft even did not manage to get the greeting herald right. It is something
like:
	200 All set, fire away
while it should be:
	200 pcgate.ica.philips.nl All set, fire away.
Microsoft USA tech support found this error 'irrelevalt' after which I returned
this irrelevant product.

Also, make shure you will *not* be responsible to keep the gateway running.
Since its internal (binary) file format is undocumented, you are likely
to have to start from scratch on a crash. Nice.

While the recover-from-error problems are local, correct mailing list behaviour
is not. You are likely to make yourself very unpopular if you connect this
Thing to the internet. Believe me.

Geert Jan


-----------[000124][next][prev][last][first]----------------------------------------------------
Date:      9 May 93 22:08:24 GMT
From:      junzhang@pepper.rutgers.edu (junbiao zhang)
To:        comp.protocols.tcp-ip
Subject:   TCP,UDP tests need explanation

I made a few tests on the performance of TCP and UDP(end-to-end as well as 
broadcast) and plotted the results. Some of the test results were interesting
and not quite easy to interpret. e.g. the average TCP connection time v.s. 
background TCP connection numbers(how many TCP connections already exist)
gives a plot with spikes in regular intervals. UDP average transmission delay
is greater than the TCP average transmission delay(both with same packet size),
etc.

I've made some conclusions from these results concerning our local systems. I
don't know if all these results are common on every ethernet and want to make
some general conclusions to explain these results accurately. Does anybody know
about books on the internal features of TCP and UDP? If you have any interests
on these results(about 32 sas plots) and think you may be able to explain some
of the interesting plots, please let me know.

Thanks. 

-----------[000125][next][prev][last][first]----------------------------------------------------
Date:      Mon, 10 May 1993 01:05:49 GMT
From:      imp@boulder.parcplace.com (Warner Losh)
To:        comp.protocols.tcp-ip
Subject:   Re: NIS & DNS questions

>>Bash even makes csh look fast.

Heck, bash makes tcsh look small :-)

Just another happy Tenex csh user.

Warner
-- 
Warner Losh		imp@boulder.parcplace.COM	ParcPlace Boulder
I've almost finished my brute force solution to subtlety.

-----------[000126][next][prev][last][first]----------------------------------------------------
Date:      10 May 1993 11:32:46 -0400
From:      dsc@xray.hmc.psu.edu (David S. Channin)
To:        news.announce.newgroups,news.groups,sci.med,sci.med.physics,sci.med.telemedicine,sci.image.processing,comp.graphics,comp.protocols.iso,comp.protocols.tcp-ip,comp.protocols.misc
Subject:   RFD: comp.protocols.dicom

Request For Discussion    RFD

Name: comp.protocols.dicom

Charter:

  The purpose of this group will be to discuss issues surrounding the
  American College of Radiology - National Electrical Manufacturers
  (ACR-NEMA) standard for Digital Imaging and Communications in
  Medicine (DICOM). This standard represents the next step beyond the
  ACR-NEMA version 2 standard released in 1988.

  Postings will include information about progress of the development
  of the standard, and issues concerning implementation of the
  standard. Periodic postings will be made explaining how to obtain
  the latest versions of the available chapters, as well as
  information related to demonstrations of the standard at the RSNA meeting.

Moderated: No

Discussion Period: May 10, 1993 to June 6, 1993 (anticipated)

Call for Votes: Anticipated around June 6, 1993.

For off-line discussion concerning this RFD, please contact:

  dsc@xray.hmc.psu.edu

  David S. Channin
  Department of Radiology
  Section of Radiologic Computing and Imaging Science
  Penn State University
  The Milton S. Hershey Medical Center
  P.O. Box 850
  Hershey, PA 17033
  (717) 531 - 5728

-----------[000127][next][prev][last][first]----------------------------------------------------
Date:      Mon, 10 May 1993 07:54:46 GMT
From:      moller@diku.dk (Bo M|ller)
To:        comp.protocols.tcp-ip
Subject:   Re: FTP archive for RFCs

joho@kobe (Hans ter Horst) writes:


>I'm afraid that this is probably a FAQ, but can somebody inform me
>where I can find the RFCs.
 
>/Hans
>--
>  joho@pfbs.philips.se

You can look at ftp@denet.dk in /pbu/rfc.
-- 
	Bo Moeller, Student, DIKU		DIKU is the department of
						Computer Science at the
	InterNet: moller@diku.dk		University of Copenhagen

-----------[000128][next][prev][last][first]----------------------------------------------------
Date:      Mon, 10 May 1993 11:35:12 GMT
From:      janf@sci.kun.nl (Jan Frederik Nipshagen)
To:        comp.dcom.modems,comp.sys.sun.misc,comp.protocols.tcp-ip,comp.protocols.ppp
Subject:   Re: Fast modems and dialup SLIP/PPP

In <1sl8jjINNpdn@spatula.csv.warwick.ac.uk> cudep@csv.warwick.ac.uk (Ian Dickinson) writes:

>I have a Sun3/50 running SunOS4.1.1u1 and a V.32/V.42 Hayes compatible modem.
>Firstly, I've found that the SunOS tip doesn't understand hayes modems faster
>than 2400.  I've got the cslip-2.6 package which comes with a modified Berkeley
>tip with SLIP startup support, but I can't get it to run at any speed
>whatsoever.  Using 'trace', I find the SunOS tip is using a quite a few ioctl()
>calls, which the cslip tip doesn't.  Can anyone tell me what it's up to?
>Or does anyone have a libacu/hayes.c which is known to work under SunOS4.1.x?

Do you use softwareflowcontrol or hardwareflowcontrol?

At Nijmegen University I am working on establishing SLIP access via an Cisco
Terminal Server. One thing that I found out is that SLIP requires a fully
transparant channel, which makes it impossible to use softwareflowcontrol.

Regards,
Jan Frederik


-----------[000129][next][prev][last][first]----------------------------------------------------
Date:      10 May 1993 10:51:47 +0100
From:      cudep@csv.warwick.ac.uk (Ian Dickinson)
To:        comp.dcom.modems,comp.sys.sun.misc,comp.protocols.tcp-ip,comp.protocols.ppp
Subject:   Fast modems and dialup SLIP/PPP

I have a Sun3/50 running SunOS4.1.1u1 and a V.32/V.42 Hayes compatible modem.

Firstly, I've found that the SunOS tip doesn't understand hayes modems faster
than 2400.  I've got the cslip-2.6 package which comes with a modified Berkeley
tip with SLIP startup support, but I can't get it to run at any speed
whatsoever.  Using 'trace', I find the SunOS tip is using a quite a few ioctl()
calls, which the cslip tip doesn't.  Can anyone tell me what it's up to?
Or does anyone have a libacu/hayes.c which is known to work under SunOS4.1.x?

Secondly, I may need to run PPP as well as SLIP.  Can anyone recommend a
publicly available package which can do both, or a combination of two
packages which are known to work well together?

Cheers,
-- 
\/ato - Ian Dickinson - NIC handle: ID17          This article is dedicated to
vato@csv.warwick.ac.uk  ...!uknet!warwick!vato        those who disapprove but
/I=I/S=Dickinson/OU=CSV/O=Warwick/PRMD=UK.AC/ADMD= /C=GB/          continue to
@c=GB@o=University of Warwick@ou=Computing Services@cn=Ian Dickinson      read

-----------[000130][next][prev][last][first]----------------------------------------------------
Date:      Mon, 10 May 1993 15:40:48 GMT
From:      drubin@poly.edu (Dave Rubin)
To:        comp.protocols.tcp-ip,comp.dcom.sys.cisco,comp.sys.sun.admin
Subject:   NIS/NFS firewall?


We want to use access control lists on our Cisco AGS+ router to prevent
NIS and NFS traffic from getting in/out of our local network.  This should
be easy, provided I block the appropriate ports (NFS, NIS, portmapper,
etc.).

Has somebody implemented Cisco access lists to provide this type of
firewall?  If not, can anyone tell me all the ports which I need to block
in order to truly prevent all NFS and NIS traffic from leaving our network?

Thanks ... please respond via E-mail.

--
Dave Rubin
Network Manager
Polytechnic University
drubin@poly.edu

-----------[000131][next][prev][last][first]----------------------------------------------------
Date:      Mon, 10 May 1993 16:29:01 GMT
From:      robertt@n154.mentor.stortek.com (Robert Thompson (robertt))
To:        comp.protocols.tcp-ip
Subject:   NCSA v2.3 locks up



--
I am trying to figure out why NCSA Telnet Version 2.3 locks my PC up when a
connection is closed.  FTP dpes not do this.  After loging out of a host,
the screen goes black and I have to press the reset button to continue.
Any ideas anyone ?

-robert


------------------------------------------------------------------------------
Robert Thompson                       |  Storage Technology Corporation
Redwood Digital Hardware Design Team  |  2270 South 88th. Street
(303) 673-7747   FAX: (303) 673-2568  |  Louisville, Colorado 80028-0211
--------------------------------------+---------------------------------------
Please don't rely on the header for replies; use  robertt@n33.stortek.com
------------------------------------------------------------------------------

-----------[000132][next][prev][last][first]----------------------------------------------------
Date:      10 May 1993 15:24:25 +0100
From:      cudep@csv.warwick.ac.uk (Ian Dickinson)
To:        comp.dcom.modems,comp.sys.sun.misc,comp.protocols.tcp-ip,comp.protocols.ppp
Subject:   Re: Fast modems and dialup SLIP/PPP

In article <C6t6up.749@sci.kun.nl> janf@sci.kun.nl (Jan Frederik Nipshagen) writes:
>In <1sl8jjINNpdn@spatula.csv.warwick.ac.uk> cudep@csv.warwick.ac.uk (Ian Dickinson) writes:
>>I have a Sun3/50 running SunOS4.1.1u1 and a V.32/V.42 Hayes compatible modem.
>>Firstly, I've found that the SunOS tip doesn't understand hayes modems faster
>>than 2400.  I've got the cslip-2.6 package which comes with a modified Berkeley
>>tip with SLIP startup support, but I can't get it to run at any speed
>>whatsoever.  Using 'trace', I find the SunOS tip is using a quite a few ioctl()
>>calls, which the cslip tip doesn't.  Can anyone tell me what it's up to?
>>Or does anyone have a libacu/hayes.c which is known to work under SunOS4.1.x?
>Do you use softwareflowcontrol or hardwareflowcontrol?

I don't truly know.

I use hardware carrier detect. I haven't done anything specific yet with the
flow control.  This is because I hoping to have something working before
choosing XON/XOFF or DTR/DTS? or CTRCTS?  Is this something I need to worry
about, or is it an end-to-end thing?  I must admit serial lines are not my
strong point. :-(

Everything works fine with the SunOS supplied tip so long as I don't want to
run at greater than 2400 baud.  The cslip tip won't talk at all even at 2400.

The thing I'm really after is modem driver source that it known to work under
SunOS4.1.1 and instructions for use.

Cheers,
-- 
\/ato - Ian Dickinson - NIC handle: ID17          This article is dedicated to
vato@csv.warwick.ac.uk  ...!uknet!warwick!vato        those who disapprove but
/I=I/S=Dickinson/OU=CSV/O=Warwick/PRMD=UK.AC/ADMD= /C=GB/          continue to
@c=GB@o=University of Warwick@ou=Computing Services@cn=Ian Dickinson      read

-----------[000133][next][prev][last][first]----------------------------------------------------
Date:      Mon, 10 May 1993 18:48:22 GMT
From:      bob@MorningStar.Com (Bob Sutterfield)
To:        comp.dcom.modems,comp.sys.sun.misc,comp.protocols.tcp-ip,comp.protocols.ppp
Subject:   Re: Fast modems and dialup SLIP/PPP

In article <1sl8jjINNpdn@spatula.csv.warwick.ac.uk> cudep@csv.warwick.ac.uk (Ian Dickinson) writes:
   I have a Sun3/50 running SunOS4.1.1u1 and a V.32/V.42 Hayes
   compatible modem.  I've found that the SunOS tip doesn't understand
   hayes modems faster than 2400.

Don't worry about whether it's a Hayes or anything else.  Just try
putting a line like this into your /etc/remote:
	cua:dv=/dev/cua:br#38400:
Of course, you'll need to say the usual
	mknod /dev/cua c 12 128
	chown root.staff /dev/cua
	chmod 666 /dev/cua
Then, just say "tip cua" and you should be talking to the modem.

   Secondly, I may need to run PPP as well as SLIP.  Can anyone
   recommend a publicly available package which can do both, or a
   combination of two packages which are known to work well together?

I don't know of any freely-available implementations of both SLIP and
PPP in the same package for UNIX, though KA9Q and maybe NCSA could be
said to combine the two on DOS boxes.  It's really pretty simple,
though, so somebody might do it someday (I did it long ago for our
UNIX PPP/SLIP product).  Just start with a working PPP package,
hotwire the finite state machine to Opened, and lobotomize the framer
(FCS, etc).  Use the SLIP flag and escape characters, and hope the
administrator decides to use RTS/CTS flow control.
--
Bob Sutterfield, Morning Star Technologies            +1 614 451 1883
1760 Zollinger Rd, Columbus Ohio USA, 43221-2856      +1 800 558 7827
bob@MorningStar.Com                                   +1 614 459 5054 (FAX)

-----------[000134][next][prev][last][first]----------------------------------------------------
Date:      10 May 1993 18:57:07 GMT
From:      Jim.Rees@umich.edu
To:        comp.protocols.ppp,comp.protocols.tcp
Subject:   Re: bad ppp telnet performance

In article <C6qnAG.M77@cunews.carleton.ca>, mikey@yoho.carleton.ca (Mike G McFaul) writes:

  The real
  culprit is the window size that is set in the TCP/IP software layer on
  your machines. Its usually set to around 4096 bytes, this is fine for
  a 10Mbit/sec ethernet, but way too high for a slow speed ppp link
  (remember everything is relative!).

Window size is not a fixed number.  It changes to adapt to the link.  Some
implementations of tcp have an initial or maximum window size, or both, and
tuning these is sometimes required for low speed links.

I suppose there are probably still some old, obsolete implementations of tcp
with fixed windows out there, but you should replace them rather than try to
tune them.

-----------[000135][next][prev][last][first]----------------------------------------------------
Date:      Mon, 10 May 1993 20:28:23 GMT
From:      heberlei@cs.ucdavis.edu  (Louis Todd Heberlein)
To:        comp.protocols.tcp-ip
Subject:   Out Of Band data

Networld,

I was looking at some code for telnetd and rlogind, and
I noticed how much effort was given to handling out-of-band
data.  For the most part, I have never seen other server
software handle this data, and at least in the telnetd code
I was looking at, the solution looked ad hoc in nature.

Do many TCP/IP servers support out-of-band data?

Is there a rule of thumb used to determine if your server
should be prepared to handle out-of-band data?
    (For example, should only long-lived connections worry about it?)

In an environment like telnet/rlogin, what would be the cause/purpose
of out-of-band data?
    (Is it mainly used by the client to re-synch the connections?
    Are there any user actions which would cause out-of-band data?)

Is there a "generally" accepted method to handle out-of-band data?
    (From the quick glance that I took, it looked like the telnetd
    just kept the out-of-band data in-line with the normal data, and
    the server just ignored everything from the out-of-band signal
    until the actual out-of-band data.  Is it application-dependent?)

Any help would be appreciated.

Thanks,

Todd			heberlei@cs.ucdavis.edu

-----------[000136][next][prev][last][first]----------------------------------------------------
Date:      Mon, 10 May 1993 22:32:28 GMT
From:      vjs@rhyolite.wpd.sgi.com (Vernon Schryver)
To:        comp.protocols.ppp,comp.protocols.tcp
Subject:   Re: bad ppp telnet performance

In article <1sm8i3$ip3@terminator.rs.itd.umich.edu>, Jim.Rees@umich.edu writes:
> In article <C6qnAG.M77@cunews.carleton.ca>, mikey@yoho.carleton.ca (Mike G McFaul) writes:
> 
>   The real
>   culprit is the window size that is set in the TCP/IP software layer on
>   your machines. Its usually set to around 4096 bytes, this is fine for
>   a 10Mbit/sec ethernet, but way too high for a slow speed ppp link
>   (remember everything is relative!).
> 
> Window size is not a fixed number.  It changes to adapt to the link.  Some
> implementations of tcp have an initial or maximum window size, or both, and
> tuning these is sometimes required for low speed links.
> 
> I suppose there are probably still some old, obsolete implementations of tcp
> with fixed windows out there, but you should replace them rather than try to
> tune them.


Big windows can cause problems.

Consider a case, where IP gateways between fast media (e.g.  ethernet)
and slow (e.g. 56k leased line) have big queues, but not as big as the
TCP windows used by the end points.  Say the end points workstations
have a name that sounds like a flower and use default windows of 60K
and the gateways have cute little orange suspension bridges painted on
them and use queues of around 56KBytes.

Imagine starting a big file transfer over such a route.  At the same
time, start running a `ping` (the BSD or BRL variety that runs
continually).  TCP slow start starts the congestion window small, and
ping will report delays on the order of 1 or 2 seconds.  Slow start
gradually opens the congestion window, and ping will report steadily
increasing round trip delays.  When the delays reach between 10 and 12
seconds (!), they'll suddenly drop to zero, and after a few seconds
start building toward 10-12.  This sawtooth pattern continues
indefinitely.

The 10-12 second delays reported by ping seem much longer if you are
trying to use the link for interactive work.

What is happening is that as the queue in the nearest gateway fills,
the RTT increases.  Finally packets are dropped, but the sender does
not realize until a long time as has passed, and the gateway's queue is
empty.

The solution is one or more of:
    - reduce the default window size in the worstations from 60K to 2-4K.
	This is the best solution, although it does destroy TCP/FDDI
	performance, pushing it below 50Mbit/sec.  Unfortunately, this
	solution requires reconfiguring all workstations that might use
	the slow link.

    - put a little program in ~guest/.cshrc and similar accounts on
	machines to which that applies the setsockopt() to fd 0.  This
	works fine, except that you can never seem to find all of the
	servers that people `rcp` to or from, and does nothing for FTP.

    - reduce the queues in the gateways to ~8K.
	This keeps the congestion window from bloating up, and keeps
	the delays from getting out of hand.  It does mean that some
	bandwidth is wasted.


Vernon Schryver,  vjs@sgi.com

P.S. want to guess who set the default window size to 60K for FDDI and
   now spends hours/day using such a wide area link?

-----------[000137][next][prev][last][first]----------------------------------------------------
Date:      Tue, 11 May 1993 01:26:15 GMT
From:      copeland@sdf.lonestar.org (Charles Copeland)
To:        comp.protocols.tcp-ip
Subject:   TFTP missing some *.h files?

I got a copy of tftp from stanford and it is missing several .h files.
paradigmMon.h, pd_globram.h, pd_i82586.h, asmdef.h, paradigm.h, globram.h

Does anybody know where I can get a *full* copy of tftp and tftpd?

-- 
copeland@sdf.lonestar.org
*************************

-----------[000138][next][prev][last][first]----------------------------------------------------
Date:      Tue, 11 May 93 02:53:40 GMT
From:      nelson@crynwr.com (Russell Nelson)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc,comp.dcom.lans.ethernet,comp.sys.novell,bit.listserv.novell
Subject:   Packet Driver FAQ

1. What are they?

A packet driver is a terminate-and-stay-resident program for PCs
running MS-DOS.  Packet drivers hide the differences between network
adapter, and they permit multiple protocol stacks to access the same
network adapter at the same time.  They also make it easier to
install new networking software because the driver is already
installed and working.

On a more technical note, they allow programs to send packets,
receive packets, and determine the adapter's address.  Packet
drivers, by themselves, do not provide any application-level
services.  Some application is needed which will make use of the
low-level packet driver services.

2. What happens without a packet driver?

Without a packet driver, network software must access the adapter
directly. Every adapter is different, so the network software must be
programmed for each adapter.  And because each program is writing to
adapter memory, setting I/O ports, handling interrupts, etc.,
unfriendly programs do not work together.

When you use a packet driver, it handles the details, not the network
software. It doesn't matter if an adapter is I/O mapped, memory
mapped, or bus mastering. In addition, because only one program is
accessing the adapter, multiple protocol stacks can gain access
through the packet driver.

3. What don't they do?

They don't hide the difference between network technologies.  An
ARCNET driver needs ARCNET support, an Appletalk driver needs
Appletalk support, etc.  Having just said that, some packet drivers
emulate Ethernet, e.g. IBMTOKEN, ARCETHER, ETHERSLIP.

They also don't let you run multiple identical protocol stacks.  That
means that you can't run two TCP/IP stacks at the same time, e.g.
NCSA Telnet and PC-NFS.  Each program has its own TCP/IP stack, and
each expects to receive IP and ARP packets. Even if the packet driver
was modified to deliver the packets to both stacks, you still have
the problem of determining which stack should reply to which packets.

4. Where do they come from?

The Packet Driver Specification (PDS) was written by FTP Software.
Some companies have written their own packet drivers.  The majority
of packet drivers were written by individuals, and have been
collected by Russell Nelson while he was at Clarkson University. This
collection used to be called the Clarkson Packet Driver Collection.
Clarkson is now completely disassociated with any packet driver
collection, so the collection is now called the Crynwr Packet Driver
Collection.

5. What do they work with?

There are many applications that use the packet drivers, too many to
list here. Any such list would be incomplete because new applications
are constantly being written.  Therefore, we will name the most
popular and list the rest in the collection's SUPPORT.DOC file.

Freely copyable software:

NCSA Telnet -- NCSA's Telnet.  Provides VT-100 terminal emulation.
KA9Q aka NOS aka NET -- Phil Karn's complete TCP/IP package.  Free to
	some users.
Trumpet -- Usenet news reader using NNTP.
WNQVTNET -- Windows Telnet, FTP, news reader.  Shareware.
BYU and Intel have free packet driver clients for NetWare's IPX.

Commercial software:

TCP/IP -- FTP Software, The Wollongong Group, Beame & Whiteside,
	SunConnect, James River Group.  Only a very few TCP/IP stacks
	do not support packet drivers.
NetWare -- BYU and Intel have free packet driver clients for NetWare's IPX.
Monitors -- FTP Software, Intel, Klos Technologies, US Networx, General S'ware
Others -- Performance Technology, WEBos, Invisible LAN, LANsoft and Banyan.

6. Support?

The packet drivers in the Crynwr collection are freed software.  They
are available from many places for the cost of copying them.
However, they do not come with support unless purchased directly from
Crynwr Software.

We accept purchase orders and checks drawn in US funds via mail, FAX,
and telephone.  Terms of the support are available on request.

7. How do I get them?

Crynwr Software distributes supported drivers only.  You can get
unsupported drivers from the following locations.

Mail:

Columbia University distributes packet drivers on PC diskette by
postal mail.  Please call (212) 854-3703 for ordering information, or
write to: Kermit Distribution, Dept PD;  Columbia University Center
for Computing Activities;  612 West 115th Street;  New York, NY
10025 or send e-mail to kermit@watsun.cc.columbia.edu (Internet) or
KERMIT@CUVMA (BITNET/EARN).

FTP/email:

The packet driver collection has its own directory devoted to it,
pd1:<msdos.pktdrvr>.  The drivers are there, along with many free
programs that use the packet drivers.

SIMTEL20 files are also available from mirror sites OAK.Oakland.Edu,
wuarchive.wustl.edu, ftp.uu.net, nic.funet.fi, src.doc.ic.ac.uk or
archie.au, or by e-mail through the BITNET/EARN file servers.

Modem:

If you cannot access them via FTP or e-mail, the packet drivers are
also available for downloading from Detroit Download Central (313)
885-3956.  This is a subscription system with an average hourly cost
of 17 cents.  It is also accessible on Telenet via PC Pursuit and on
Tymnet via StarLink outdial.

8. What about the Novell/Unix connection?

There is no problem transporting both Novell (actually, NetWare) and
Unix (actually, TCP/IP) packets over the same network at the same
time.  NetWare packets have one magic number, TCP/IP another.  The
trick, for DOS users, is to run both at the same time on the same PC.

NetWare servers and clients can be configured for standard Ethernet
II packets, or left alone for nonstandard NetWare packets.  This
configuration process is done by a program called econfig.

NetWare's drivers access the adapter directly, which will cut off
packet driver access to the adapter. The way to convince NetWare to
avoid stomping on your packet driver is to use a version of IPX that
accesses the adapter through a packet driver.  There are two such
IPXes, both of them freely copyable. Brigham Young University (BYU)
wrote one back in April of 1989. Intel wrote one more recently, and
is continuing to modify it as needed.

With BYU PDIPX, you must either econfig or use the packet driver's -n
switch. In any case, BYU requires that you econfig the client. The
Intel PDIPX lets you choose to econfig your network or not.

9. Are there alternatives to packet drivers?

After the packet driver specification had been published, Microsoft
and Novell devised their own driver specifications, NDIS and ODI (aka
ODLI).  LAN Manager requires an NDIS driver, and newer versions of
NetWare require an ODI driver. The specifications for NDIS drivers
are freely copyable, but writing an ODI driver requires a
multi-thousand dollar toolkit from Novell.

There are several "shims" that convert one specification into the
other: dis_pkt, which emulates a packet driver using an NDIS driver,
odipkt, which is a packet driver over ODI, and pdether, which is an
ODI driver over packet driver.  Crynwr Software distributes these,
although we do not support them.

-russ <nelson@crynwr.com> What canst *thou* say?
Crynwr Software           Crynwr Software sells packet driver support.
11 Grant St.              315-268-1925 Voice  |  LPF member - ask me about
Potsdam, NY 13676         315-268-9201 FAX    |  the harm software patents do.

-----------[000139][next][prev][last][first]----------------------------------------------------
Date:      11 May 1993 11:14:28 -0400
From:      mkc@Graphics.Cornell.edu (Mitch Collinsworth)
To:        comp.protocols.tcp-ip,comp.mail.mime
Subject:   Re: Commercial Multimedia Software for teleconferencing

In <C6otqs.69w@ra.nrl.navy.mil> atkinson@itd.nrl.navy.mil (Ran Atkinson) writes:

>In article <1sei34INNbnb@rex.graphics.cornell.edu> mkc@Graphics.Cornell.edu (Mitch Collinsworth) writes:
 
>[ Re: DECspin, a commercial proprietary networking multimedia tool ]
>>The current version does work over ethernet, though I agree that you
>>have to keep the window size down and cut the frame rate back.
>>Depending on what you want to see it still might be good enough.  We've
>>tried it with FDDI and it's a little better, though not what we expected.
>>From what little I've been able to find out, the next version is supposed
>>to include video compression, which should help a lot.  Also the new FDDI
>>controller has about 2-3 times the throughput of the old one, so that
>>alone could help a lot.
 
>I's amusing to read the above.

It must be nice to be so easily amused.

>  The _free_ implementations being done by the folks working with the
>IETF on audio/video conferencing have had compression for some long
>while now.  Those versions only need about 40-64 Kbps of bandwidth if
>you go with 8-bit greyscale at 6-8 frames/second and high quality
>voice (a bit more when you move to color and more frames/second but
>still easy to fit on an Ethernet shared with normal traffic).

Like I said, DECSPIN's bandwidth goes down when you cut its frame rate
back and switch to b/w, too.  Big suprise there.  When the compressed
version is out the bandwidth will probably be in the same ballpark.
Equal amounts of data are equal amounts of data.

>  So the versions that use the audio/video protocols being developed
>by the IETF are not only cheaper (free) but also work better.  Makes
>one wonder how DEC is selling this product...

I don't know that they are, but I also don't know why you seem to be
so negative about it.  I would like to see the latest version of the
IETF software.  The last time I saw it (maybe a year ago) it was a long
way from the picture quality of DECSPIN.  You listed several programs
(sd, vat, wb, nevot, nv) and mentioned a rem-conf and a mbone mailing
list.  Where can these programs be obtained from?  Which ones run on the
DECstation 5000/240?  How does one subscribe to the mailing lists?

-Mitch Collinsworth
 mitch@graphics.cornell.edu

-----------[000140][next][prev][last][first]----------------------------------------------------
Date:      11 May 93 13:47:47
From:      amoss@shuldig.cs.huji.ac.il (Amos Shapira)
To:        comp.protocols.tcp-ip
Subject:   Re: Out Of Band data

heberlei@cs.ucdavis.edu  (Louis Todd Heberlein) writes:

   Is there a rule of thumb used to determine if your server
   should be prepared to handle out-of-band data?
       (For example, should only long-lived connections worry about it?)

Depends on the protocol you want to use over TCP/IP.

   In an environment like telnet/rlogin, what would be the cause/purpose
   of out-of-band data?
       (Is it mainly used by the client to re-synch the connections?
       Are there any user actions which would cause out-of-band data?)

OOB on telnet connections is used mainly to simulate interrupts.

   Is there a "generally" accepted method to handle out-of-band data?
       (From the quick glance that I took, it looked like the telnetd
       just kept the out-of-band data in-line with the normal data, and
       the server just ignored everything from the out-of-band signal
       until the actual out-of-band data.  Is it application-dependent?)

It is application dependent.  I don't know about any "generally accepted
method".

   Any help would be appreciated.

You might want to read the Telnet RFC's (dozens of them,  there was this
basic TELNET protocol and then lots of options added each with its own
RFC).

   Thanks,

   Todd			heberlei@cs.ucdavis.edu

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

-----------[000141][next][prev][last][first]----------------------------------------------------
Date:      11 May 1993 10:09:56 GMT
From:      Dieder Bylsma <bylsma@unixg.ubc.ca>
To:        comp.protocols.tcp-ip
Subject:   HELP TCP/IP tunneling Novell net

I need to find out ASAP about the possibilities of connecting various
clients
to a Novell server connected solely through the use of a TCP/IP
connection.
The setup is on a very large Japanese campus with a fiber-optic backbone, 
through which TCP/IP is used...a number of NEC 9801 PCs across the campus 
must connect to a central server....any help as to how this could be done 
would be greatly appreciated....I need an answer ASAP...please e-mail me 
directly...I don't read the groups as often as I would like...

Thanks,

Dieder B.
bylsma@unixg.ubc.ca

-----------[000142][next][prev][last][first]----------------------------------------------------
Date:      Tue, 11 May 1993 12:45:47 GMT
From:      djn@csc.liv.ac.uk (David Nixon)
To:        comp.sys.hp,comp.protocols.tcp-ip
Subject:   Re: Diskless Hp-Bootprotocol

In article <C6LpLn.9II@informatik.uni-rostock.de>, ddr@informatik.uni-rostock.de (Detlef Drewanz) writes:
> Hi,
> 
> i have a question to HP 9000/series300:
> 
> Does anybody know, which protocol the diskless HP 9000/3xx use for
> loading the kernel.

The boot ROM on a discless node communicates with an 'rbootd' server 
process on the cluster server to down-load HP-UX: The protocol employed
is called remote Maintenance Protocol (RMP). I am not sure if this protocol
is an in-house HP product.

>                   The motivation is to boot a HP from a SUN or DECstation.
> Our HP-Server is very slow (nfs,...) and we think that we can get more
> availability for our HP-workstations, if we could boot and serve they by
> faster machines.

Even if you could down-load HP-UX via RMP your file server then would have to 
talk HP's Discless (DUX) protocol to serve file I/O from the discless node.

So all you would need is to port the DUX device driver to run as part of your 
SUN's kernel.

... I believe an HP source licence is a bit expensive.
  
 

David Nixon -- University of Liverpool, Computer Science dept.

-----------[000143][next][prev][last][first]----------------------------------------------------
Date:      11 May 1993 14:19:53 GMT
From:      trier@slc6.ins.cwru.edu (Stephen C. Trier)
To:        comp.protocols.tcp-ip
Subject:   Re: Out Of Band data

In article <C6tvJB.IL6@ucdavis.edu> heberlei@cs.ucdavis.edu writes:
>Do many TCP/IP servers support out-of-band data?

Don't put too much reliance on Berkeley "out-of-band" semantics.  It's
a tweak of the TCP Urgent mechanism, and even Loeffler et al admits it
was a stretch to turn TCP Urgent into the socket out-of-band data
abstraction.  :-)

>Is there a rule of thumb used to determine if your server
>should be prepared to handle out-of-band data?

Yes.  It will be specified in the protocol spec.

Some protocols don't bother with urgent data.

What you will find in Unix is that the Berkeley protocols (like rlogin)
use urgent data with the Berkeley out-of-band semantics, but the IETF
protocols use it with standard "urgent" semantics.  That may be part of
the reason it seems confusing.

>    (For example, should only long-lived connections worry about it?)

No!  If the protocol spec says urgent data is permissible, you haven't
implemented the spec until you can handle urgent data.  Connection
length doesn't matter.

(For example, I don't think anyone worries about urgent data in their
finger clients, but it is of minor importance in FTP, greater
importance in telnet, and is essential for rlogin.)

>Is there a "generally" accepted method to handle out-of-band data?

It is protocol dependent, and the semantics of urgent data (such as
whether it is in-band or out-of-band) differs depending on who invented
the protocol.  :-)

Take a look at the Telnet and FTP RFCs and you'll get an idea of how
urgent data is used in standard protocols.

       Stephen

-- 
Stephen Trier (trier@ins.cwru.edu)   Star Trek dialog mistake of last week:
Network Software Engineer              "We've tried every decryption key
IRIS/INS/T                               on record, Captain."
Case Western Reserve University             - Geordi LaForge, ST:TNG, 5/1/93

-----------[000144][next][prev][last][first]----------------------------------------------------
Date:      11 May 1993 14:24:58 GMT
From:      trier@slc6.ins.cwru.edu (Stephen C. Trier)
To:        comp.protocols.tcp-ip
Subject:   Re: HELP TCP/IP tunneling Novell net

In article <1snu1kINNjnk@iskut.ucs.ubc.ca> Dieder Bylsma <bylsma@unixg.ubc.ca> writes:
[How to tunnel Novell through an IP-only backbone?]

Check the _Novell NetWare v3.11 TCP/IP Transport Supervisor's Guide_,
appendix A.  It came with your NetWare 3.11 server.

-- 
Stephen Trier (trier@ins.cwru.edu)   Star Trek dialog mistake of last week:
Network Software Engineer              "We've tried every decryption key
IRIS/INS/T                               on record, Captain."
Case Western Reserve University             - Geordi LaForge, ST:TNG, 5/1/93

-----------[000145][next][prev][last][first]----------------------------------------------------
Date:      Tue, 11 May 1993 15:51:34 GMT
From:      mahmood@lambda.msfc.nasa.gov (Rafique Mahmood)
To:        comp.protocols.tcp-ip
Subject:   WHERE TO FIND THE TCPVIEW FOR SUN SPARC2?

I LIKE TO GET THE SOURCE CODE OR EXECUTABLE FOR TCPVIEW. 


ONE OF OUR USER GOT IT FROM THE NET SOMEWHERE. BUT IT DOES NOT HAVE THE SOURCE 
CODE. I INSTALLED IT ACCORDING TO

THE INSTALL DOCUMENT BUT WHEN I RUN IT IT SAYS:

Warning: ... found while parsing 's <Key>osfLeft:key-select(left)'
Warning: translation table syntax error: Unknown keysym name: osfLeft
Warning: ... found while parsing '<Key>osfLeft:backward-character()'
Warning: translation table syntax error: Unknown keysym name: osfRight
Warning: ... found while parsing 's c <Key>osfRight:forward-word(extend)'
Warning: translation table syntax error: Unknown keysym name: osfRight
Warning: ... found while parsing 'c <Key>osfRight:forward-word()'
Warning: translation table syntax error: Unknown keysym name: osfRight
Warning: ... found while parsing 's <Key>osfRight:key-select(right)'
Warning: translation table syntax error: Unknown keysym name: osfRight
Warning: ... found while parsing '<Key>osfRight:forward-character()'
Warning: translation table syntax error: Unknown keysym name: osfUp
Warning: ... found while parsing 's c <Key>osfUp:backward-paragraph(extend)'
Warning: translation table syntax error: Unknown keysym name: osfUp
Warning: ... found while parsing 'c <Key>osfUp:backward-paragraph()'
Warning: translation table syntax error: Unknown keysym name: osfUp
Warning: ... found while parsing 's <Key>osfUp:process-shift-up()'
Warning: translation table syntax error: Unknown keysym name: osfUp
Warning: ... found while parsing '<Key>osfUp:process-up()'  


and much more warning.  

It brings out the window and I captured some packets but I don't know where did it
stored. 

If anyone is using TCPVIEW please email me the response. 

Thanks a lot

Rafique
email: mahmood@lambda.msfc.nasa.gov


-----------[000146][next][prev][last][first]----------------------------------------------------
Date:      Tue, 11 May 1993 15:53:02 GMT
From:      heka@ost.ericsson.se (hedie kamoun)
To:        comp.protocols.tcp-ip
Subject:   sockoptions in TLI

Dear net-wizards,
	I have a question (and a problem) that I wonder if somebody out there
could help me with.
	I have a system which is built around TLI (SunOS). Since the transport
provider I'm using (tcp) is configured with the Nagle-algoritm option disabled
(The TCP_NODELAY for sockets) and my system sends out a lot of small packets
I'd like to set the TCP_NODELAY option thus enabling the Nagle algoritm (which
I learned from this group, by the way). However I suspect that TLI internally
uses a different socket towards tcp, thus the socket I recieve from t_open is
not the one for which I should set the socket option. 

	Could somebody shine light on how to set a socketoption using TLI in
general and for the TCP_NODELAY in particular, or if not possible indicate so.

	Hoping for an answer,
		Best regards
			Hedie
			Email:heka@ppvku.ericsson.se


-----------[000147][next][prev][last][first]----------------------------------------------------
Date:      11 May 1993 16:15:27 GMT
From:      Jim.Rees@umich.edu
To:        comp.protocols.ppp,comp.protocols.tcp
Subject:   Re: bad ppp telnet performance

In article <hqpsv8k@rhyolite.wpd.sgi.com>, vjs@rhyolite.wpd.sgi.com (Vernon Schryver) writes:

  Big windows can cause problems...

  The solution is one or more of:
  [ reduce max window size or gateway queue size ]

I don't like either of those solutions.  What you really would like is for
tcp to set its window size to the number of bytes actually in flight, rather
than that number plus all the queue sizes on intermediate gateways.  I'm not
up on all the latest tcp research but I don't know of any implementation
that does this, and I can't even think how you would do it in the absence of
forward/reverse congestion bits.  Expecting the administrator of each end
system to guess the appropriate maximum window size is not just unrealistic,
it's impossible.

-----------[000148][next][prev][last][first]----------------------------------------------------
Date:      11 May 1993 16:53:16 GMT
From:      mjr@tis.com (Marcus J Ranum)
To:        comp.protocols.tcp-ip
Subject:   Re: Where I can find information about firewalls ?

>Any suggestions of where I can find infomration about network security 
>issues (related to Internet), especially about firewall-technique ? 

	Check out the firewalls mailing list (firewalls@greatcircle.com)
and its archive (ftp.greatcircle.com).  There are also several good
sources of articles on:
	ftp.greatcircle.com	pub/firewalls
	research.att.com	dist/internet_security
	decuac.dec.com		pub/doc/firewall
	moink.nmsu.edu		firewalls

	'Practical UNIX Security' by O'Rielly and associates describes a
basic simple screening firewall.

mjr.

-----------[000149][next][prev][last][first]----------------------------------------------------
Date:      Tue, 11 May 1993 16:58:19 GMT
From:      stewart@oin.cis.udel.edu (John Stewart)
To:        comp.protocols.tcp-ip
Subject:   Re: Where I can find information about firewalls ?

In article <9305111250.AA16961@kymmene.fi> gronja@kymmene.fi writes:
>
>Our site is going to connect to Eunet (probably with IBM 6611), which 
>provides us Internet access. What I need right now is information how 
>to prevent unauthorized persons accessing our network (somewhere I 
>have seen spoken about firewalls).
>
>Any suggestions of where I can find infomration about network security 
>issues (related to Internet), especially about firewall-technique ? 
>
>Thanks for any help and sorry if this is FAQ.

There is a mailing list "raptor@delmarva.com" (subscription
requests should go to "raptor-request@delmarva.com") which
discusses the Eagle Secure Gateway made by Raptor Systems,
as well as firewalls in general.

On the host "ftp.delmarva.com" in "/pub/security", there is
a collection of security-related documents.

Good luck.

/jws

-----------[000150][next][prev][last][first]----------------------------------------------------
Date:      11 May 1993 16:59:48 GMT
From:      adiwan@bbn.com (Arif Diwan)
To:        comp.protocols.tcp-ip
Subject:   Looking for OSPF packet trace programs


Does anyone have a program which would promiscuously listen for
and grab OSPF packets and then give a formatted output? Has anyone
modified tcpdump or tcpview to give a formatted OSPF packet output?

Please email to me and I will post the compendium.

-- 

				-- Arif Diwan (adiwan@bbn.com)
						617/873-6274

-----------[000151][next][prev][last][first]----------------------------------------------------
Date:      11 May 93 18:00:47 GMT
From:      adiwan@bbn.com (Arif Diwan)
To:        comp.protocols.tcp-ip
Subject:   Re: Looking for OSPF packet trace programs

In article <1993May11.125623@bbn.com>, adiwan@bbn.com (Arif Diwan) writes:

|> Does anyone have a program which would promiscuously listen for
|> and grab OSPF packets and then give a formatted output? Has anyone
|> modified tcpdump or tcpview to give a formatted OSPF packet output?
...

Ooops! FYI -- tcpdump2.2.1 has ospf packet parsing. 

-- 

				-- Arif Diwan (adiwan@bbn.com)
						617/873-6274

-----------[000152][next][prev][last][first]----------------------------------------------------
Date:      Tue, 11 May 1993 14:50:38 +0200 (WET)
From:      gronja@kymmene.fi
To:        comp.protocols.tcp-ip
Subject:   Where I can find information about firewalls ?


Our site is going to connect to Eunet (probably with IBM 6611), which 
provides us Internet access. What I need right now is information how 
to prevent unauthorized persons accessing our network (somewhere I 
have seen spoken about firewalls).

Any suggestions of where I can find infomration about network security 
issues (related to Internet), especially about firewall-technique ? 

Thanks for any help and sorry if this is FAQ.

----
Jan-Erik Gron				Email: gronja@kymmene.fi
Kymmene Corporation, Finland		Fax:   +358 51 402 2241

-----------[000153][next][prev][last][first]----------------------------------------------------
Date:      Wed, 12 May 93 05:20:00 PDT
From:      amc@cup.portal.com (Alan - Crawley)
To:        comp.protocols.tcp-ip
Subject:   Need wireless LAN bridge code

Looking for spanning tree bridge code for 802.11 wireless LAN applications.
Other wireless LAN roaming software?  Perpetual royalties possible.
E-mail please.

-----------[000154][next][prev][last][first]----------------------------------------------------
Date:      11 May 93 23:01:20 GMT
From:      carrato@mhinfo.UUCP (Tony Carrato)
To:        comp.protocols.tcp-ip
Subject:   SCO subnetting problem


In article <3@mhinfo.UUCP> I wrote:
>Here's the problem:
>
>	Segment 1				Segment 2
>  ================================   ==========================
>  "       "          "           "   "           "            "
> SCO    RS6000     PC 1 w/        Netware     PC 2 w/      PC  3 w/
>                   LAN WG         w/ Novell   LAN WG       LAN WG
>		   for DOS        TCP/IP      for DOS      for DOS
>
>In this configuration, PC 1 can ping/telnet to the SCO box.  If you
>move it to segment 2, it can't.  However, on either segment, PC 1
>(and the other PC's) can easily ping/telnet to the RS6000.

It turns out the problem was the subnetwork addressing on the SCO box.
as soon as we went to a subnet mask of 255.255.255.0 things started working
fine.  It could well be that on the SCO TCP/IP implementation that
partial byte subnetting simply doesn't work.  (The RS6000 worked just
fine in either configuration.)

Thanks very much to everyone who wrote with suggestions.

Tony


-----------[000155][next][prev][last][first]----------------------------------------------------
Date:      Wed, 12 May 1993 00:16:26 GMT
From:      Mark_Hebets@ccmail.radian.com  (Mark Hebets)
To:        comp.protocols.tcp-ip
Subject:   Scripted FTP for unattended transfers

I need a way to run an FTP transfer unattended, at a particular
time every day.  Is there a good example of how to do this?

I know I could run the ftp command with input re-directed, but this 
would require a little work to fake the keyboard input for the password, 
and it would not be too robust.  Is there a way to run it from a 
script, that would allow me to handle error messages and retry the 
transfer?

Thanks for any help you can give.  I'll summarize here if the answers 
look generally useful.

-----------[000156][next][prev][last][first]----------------------------------------------------
Date:      Wed, 12 May 1993 00:44:54 GMT
From:      pwb@newt.phys.unsw.edu.au (Paul W. Brooks esq.)
To:        comp.protocols.tcp-ip
Subject:   Re: unnecessary Retransmission Timeouts

In article <1993May5.223910.7681@acc.com>, art@acc.com (Art Berggreen) writes:
> In article <1s6lad$m5@urmel.informatik.rwth-aachen.de> marmary@kaa.informatik.rwth-aachen.de (Mahmoud-Reza Nazeman) writes:
> >I am running a simulation program, where two workstations on different
> >ethernet-segments are interconnected through a satellite link.
> >
> >There I am wondering, why so many unnecessary TCP-Retransmission-Timeouts
> >occur, even under the assumption of an error-free (!) connection.
> >
> >The RTO-value is always calculated as in the revised paper of V. Jacobsen ('88)
> >is suggested (for bandwidth-dominated paths):
> >
> >                RTO = SRTT + 4 * RTT_VAR        .
> 
> Hmmm, I wonder if Van ever considered that as RTT_VAR approeaches 0, that RTO
> approaches SRTT (creating a potential race condition).  Seems like this function
> should be bounded such that RTO is never less than, say, 1.25 SRTT.

If RTT_VAR approaches zero,if means your path is extremely consistent in
its transmission delay, so you expect the acknowledgement to arrive very
soon after SRTT time. Why would you want the extra delay caused by
putting a lower limit on RTT_VAR? 
	Note that in the paper, the algorithm when implemented in
integer arithmetic ensures RTT_VAR >= 1 through integer round-off
'errors'.

Paul Brooks        |Internet: pwb@newt.phys.unsw.edu.au
Uni. of N.S.W.     |          paul@abccomp.oz.au
Kensington NSW 2033| 
AUSTRALIA          | Microwave ovens: God's gift to bachelors

-----------[000157][next][prev][last][first]----------------------------------------------------
Date:      Wed, 12 May 1993 00:49:23 GMT
From:      pwb@newt.phys.unsw.edu.au (Paul W. Brooks esq.)
To:        comp.protocols.tcp-ip
Subject:   Re: RARP through a Router?

In article <1993May7.193913.5280@nstn.ns.ca>, daniel@nstn.ns.ca (Daniel MacKay) writes:
> In <C6I3Io.BoF@sci.kun.nl> petervc@sci.kun.nl (Peter van Campen) writes:
> 
> >- When we tried it out again on SunOS4.1.2 the SunOS rarpd refused to
> >  give a RARP reply, because the client was not on his subnet.
> 
> Hey, I just discovered this for myself a couple weeks ago!!  I have a whole
> slew of Ether bridges that need RARP, but I can't put a server on every
> segment.  Does anyone have any suggestions?

So how does the rarpd detect the client was not on its subnet? the RARP
query doesn't have any IP numbers in it, just the hardware address of
the client.

Paul Brooks        |Internet: pwb@newt.phys.unsw.edu.au
Uni. of N.S.W.     |          paul@abccomp.oz.au
Kensington NSW 2033| 
AUSTRALIA          | Microwave ovens: God's gift to bachelors

-----------[000158][next][prev][last][first]----------------------------------------------------
Date:      Wed, 12 May 1993 02:01:15 GMT
From:      tcooper@bnr.ca (Terry Cooper)
To:        comp.sys.hp,comp.protocols.tcp-ip
Subject:   Re: Diskless Hp-Bootprotocol

In article <C6v4sB.BA4@compsci.liverpool.ac.uk> djn@csc.liv.ac.uk (David Nixon) writes:
>In article <C6LpLn.9II@informatik.uni-rostock.de>, ddr@informatik.uni-rostock.de (Detlef Drewanz) writes:
>> Hi,
>> 
>> i have a question to HP 9000/series300:
>> 
>> Does anybody know, which protocol the diskless HP 9000/3xx use for
>> loading the kernel.
>
>The boot ROM on a discless node communicates with an 'rbootd' server 
>process on the cluster server to down-load HP-UX: The protocol employed
>is called remote Maintenance Protocol (RMP). I am not sure if this protocol
>is an in-house HP product.
>
>>                   The motivation is to boot a HP from a SUN or DECstation.
>> Our HP-Server is very slow (nfs,...) and we think that we can get more
>> availability for our HP-workstations, if we could boot and serve they by
>> faster machines.
>
>Even if you could down-load HP-UX via RMP your file server then would have to 
>talk HP's Discless (DUX) protocol to serve file I/O from the discless node.
>
>So all you would need is to port the DUX device driver to run as part of your 
>SUN's kernel.
>
>... I believe an HP source licence is a bit expensive.
>  
The DUX stuff is proprietary (as pointed out in another thread) so you can't
use it with non-HP systems.  If you have a bunch of HPs you will get much
better response by clustering the HPs and getting rid of NFS.  If this is
done properly (ie: no more than 20 workstations/server and each cluster
behind a filtering bridge) you will see a lot of performance increase on
both the HPs and the LAN.

HP gives stats that say that NFS is 300% slower than local disk and that DUX
is about 15% slower than local.  My experience tells me that this is probably
pretty close, although I haven't measured it.
measured it 


-- 
=========================================================================
Terry Cooper                        
Northern Telecom               "Opinions expressed are personal and"
Ottawa, Ontario                "are not those of Northern Telecom  "

-----------[000159][next][prev][last][first]----------------------------------------------------
Date:      Wed, 12 May 1993 03:07:21 GMT
From:      jwb@capek.rdt.monash.edu.au (Jim Breen)
To:        comp.protocols.misc,comp.protocols.ibm,comp.protocols.iso,comp.protocols.tcp-ip
Subject:   Re: SONET Protocol

masami@mtu.edu (MOHAMMED A. SAMI) writes:

>I am looking for info on SONET (DQDB) protocol, specifically on t
>he two layers
>Physical and Data Link.

Hmmm. SONET and DQDB are *very* different things. SONET is
the (new US) digital transmission hierarchy. DQDB is a MAN protocol
annointed as IEEE802.6, atc.  Which do you want?
-- 
Jim Breen          [ジム.ブリーン@モナシュ大学]
Department of Robotics & Digital Technology. Monash University. 
Wellington Rd, Clayton VIC 3168 Australia (ph) +61 3 565 3298 
(fax) +61 3 565 3574  AARNet/Internet:j.breen@rdt.monash.edu.au  

-----------[000160][next][prev][last][first]----------------------------------------------------
Date:      12 May 1993 11:48:09 -0500
From:      bryan@wuarchive.wustl.edu (Bryan O'Connor)
To:        comp.protocols.tcp-ip,comp.archives.admin,alt.sources.d,comp.unix.admin,comp.sys.sun.admin,comp.sys.sgi.admin,comp.unix.ultrix,comp.protocols.misc
Subject:   New wuarchive ftp server available

The Washington University Office of the Network Coordinator is pleased
to announce the release of a new version of the wuarchive FTP server.
This server includes many security enhancements and new features.

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

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


ADDITIONS AND CHANGES IN VERSION 2.1
====================================

-- upload: default was to not allow uploads ever.  This is backwards, if
           no upload keywords are given, it should act like a normal server.

-- double conversion: double conversion stuff works now.  Included is a 
           gzip2comp (in util) for converting from gzip format to compress.

-- cwd_beenhere(): now calls realpath(".", cwd) to figure out the path.
           This works for people in directories that are private.  That
           is that some component of their path is not readable by them.
           (cwdir() fails in such a case.)

-- upload: trying to set a file mode of 0000 would fail.  This is now
           possible.

-- makedir: Did not work properly for real users.

-- getgrent.c: removed the need for getgrent.c from the support library.
           This caused problems with systems running yellow pages (NIS).
           All gids in the private file are now parsed before the chroot().
           This gives us one less open file descriptor.

-- upload/truncate: STORE was not properly trunctating files when 
           overwriting them.

-- upload failing with directories in makedir/put commands: STORE and
           MAKEDIR were failing when giving full path names.

-- process ids: multiple process ids were written into the pid-files when
           a failed login attempt was made.  This caused problems with
           usage counts.

-- %E magic cookie: the %E cookie gets replaced with the "email" string
           from the ftpaccess file.

-- %F magic cookie: added trivial support for Solaris 2.1 (at least).
           If you fix this for your system, send me a patch.

-- %N magic cookie: did not work after the chroot().  The pid file has
           to remain open for the duration of the server's life now in
           order for this to work.

-- support/paths.h: removed the need for this file.  It caused more
           problems than it was worth.  The two #defines that were used
           were moved to src/pathnames.h

-- upload * no dirs: you can now specify a directory that does not allow
           uploads but does allow the creation of directories.

-- alias list: you can now get a listing of what aliases are available.
           at the ftp prompt type "quote site alias".

-- cdpath: you can now specify a cdpath (like the csh variable).  You
           can get a listing of the cdpath at the ftp prompt by typing
           "quote site cdpath".

-- email: you can specify an email address for the maintainer of the
           archive.  This string will be used for the %E magic cookie.

-- xferstats: updated version written by Dave Datta (datta@cs.uwp.edu).

-- host access: added ftphosts file that explicitly allows or denies 
           real user logins (on a per username basis) from certains hosts.
           (see ftphosts.5 for more info)

-- support for many more systems.


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

-----------[000161][next][prev][last][first]----------------------------------------------------
Date:      Wed, 12 May 1993 05:12:23 GMT
From:      fred_s@netcom.com (Frederick Scott)
To:        comp.protocols.tcp-ip
Subject:   Re: RARP through a Router?

pwb@newt.phys.unsw.edu.au (Paul W. Brooks esq.) writes: 

>In article <1993May7.193913.5280@nstn.ns.ca>, daniel@nstn.ns.ca (Daniel MacKay) writes:
>> In <C6I3Io.BoF@sci.kun.nl> petervc@sci.kun.nl (Peter van Campen) writes:
>> 
>> >- When we tried it out again on SunOS4.1.2 the SunOS rarpd refused to
>> >  give a RARP reply, because the client was not on his subnet.
>> 
>> Hey, I just discovered this for myself a couple weeks ago!!  I have a whole
>> slew of Ether bridges that need RARP, but I can't put a server on every
>> segment.  Does anyone have any suggestions?
>
>So how does the rarpd detect the client was not on its subnet? the RARP
>query doesn't have any IP numbers in it, just the hardware address of
>the client.

No, but one would expect the rarpd's database has the IP numbers, otherwise
with what was it going to fill in the reply?

Fred

-----------[000162][next][prev][last][first]----------------------------------------------------
Date:      11 May 93 15:13:31 +1000
From:      baylissb@topaz.ucq.edu.au
To:        comp.protocols.tcp-ip
Subject:   problem with TCP/IP packet size

Hi,


I have come across the following problem while using TCP/IP, and was wondering
if others have come across this also, and if so, what are the possible
solutions.

Situation
---------
- the backing up of PCs onto tape, using both DECnet and TCP/IP
- the packet size for both protocols was set at 512.
- when using TCP/IP, it was found that at a packet size of 512, DECnet ran
  approximately 10 times faster.

Solutions Tried
---------------
- in order to speed up the TCP/IP transfer, the following were tried
       - swapping the server and client ends.
       - changing from a connection and a connectionless set-up.
       - changing the receive and send call functions.
       - changing the packet size

Problem
-------
- when adjusting the packet size, the following was noticed.  on transferring
  the same information, with different packet sizes, the following was
  obtained.
   
            size of packet                     time taken
            --------------                     ----------
                 256                           approx.  2 sec
                 512                           approx. 24 sec
                1024                           approx. 14 sec


Note
----
- i have changed the programs to handle the situation of using a packet
  size of 256, while still creating a usable TAR file.


If anyone has come up with another possible solution, i'd be interested in 
hearing it.  I can be contacted on the below e-mail addresses (it may be 
best as i don't often use NEWS).


baylissb@topaz.ucq.edu.au
baylissb@jasper.ucq.edu.au       <- i check this one each working day.


thanks in advance.      



-----------[000163][next][prev][last][first]----------------------------------------------------
Date:      12 May 93 09:36:18 GMT
From:      Rainer.Blaes@erno.de (Rainer.Blaes)
To:        comp.protocols.tcp-ip
Subject:   3270 Terminal Emulation

Dear experts,

is there any 3270 emulator for VAX/VMS 5.x available which can be used with 
'TCP/IP services for VMS' ?

We would like to use this emulation on the VAX which is connected by Ethernet to
our TCP/IP IBM mainframes.

Many thanks in advance!

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
| Dr. Rainer Blaes                   | Rainer.Blaes@erno.de                |
| Senior System Manager              |                                     |
| ERNO Raumfahrttechnik GmbH         | "In any organization there          |
| Huenefeldstrasse 1-5               | will always be one person           |
| 2800 Bremen 1 Germany              | who knows what is going             |
| Voice: (0421) 539-4132             | on. This person must be             |
| Fax:   (0421) 539-4424             | fired."                             |
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

-----------[000164][next][prev][last][first]----------------------------------------------------
Date:      Wed, 12 May 1993 11:40:56 GMT
From:      leilabd@syma.sussex.ac.uk (Leila Burrell-Davis)
To:        comp.protocols.tcp-ip
Subject:   Re: Scripted FTP for unattended transfers

Mark Hebets (Mark_Hebets@ccmail.radian.com) wrote:
: I need a way to run an FTP transfer unattended, at a particular
: time every day.  Is there a good example of how to do this?
 
: I know I could run the ftp command with input re-directed, but this 
: would require a little work to fake the keyboard input for the password, 
: and it would not be too robust.  Is there a way to run it from a 
: script, that would allow me to handle error messages and retry the 
: transfer?
 
: Thanks for any help you can give.  I'll summarize here if the answers 
: look generally useful.

There's a package called autoftp that looks as if it might do the
job. I got it from src.doc.ic.ak in 
	packages/unix-c/networks/autoftp2.tar-z
but I expect you can find it at a site near you.

Leila

-- 
Leila Burrell-Davis, Computing Service, University of Sussex, Brighton, UK
Tel:   +44 273 678390              Fax:   +44 273 678470
Email: leilabd@syma.sussex.ac.uk  (JANET: leilabd@uk.ac.sussex.syma)

-----------[000165][next][prev][last][first]----------------------------------------------------
Date:      Wed, 12 May 1993 11:55:19 GMT
From:      Graham Barlow <gkb1@tower.york.ac.uk>
To:        comp.protocols.tcp-ip
Subject:   problem printing-lpr (QVTNET3.4) on VAX(CMUTEK)

Can anyone help? I am trying to print using lpr on a PC using WIN/QVTNET v3.4
with lpd running on a VaxStation 3100 using lpd from CMUTEK - OpenVMS/IP 6.6-5.

QVTNET seems to be sending junk for the forms type... can anyone tell
me how to fix this on either end, perhaps by getting CMUTEK to forget/
ignore the forms specifier or QVTNET to do the right thing.

I have set up hosts.lpd OK and have an entry in printcap.txt :

--------
sys$print "opus.york.ac.uk" "opus.york.ac.uk" opus:: default define-logicals
--------

The following is an extract from lpd-d-mmm-yy.log file

------------
 4-MAY-1993 11:49:22.76 Request 11:49:22.73 Created
 4-MAY-1993 11:49:22.99 Request 11:49:22.73 Open Requested
 4-MAY-1993 11:49:23.11 Request 11:49:22.73 Connection open Remote '', 144.32.128.191 (724)
 4-MAY-1993 11:49:23.22 Request 11:49:22.73 Connection open Local '................................................................................................................................', 144.32.128.147 (515)
 4-MAY-1993 11:49:23.42 Request 11:49:22.73 Please Add Entry, Printer 'SYS$Print'
 4-MAY-1993 11:49:23.52 Request 11:49:22.73, Sent ACK on Command
 4-MAY-1993 11:49:23.74 Request 11:49:22.73 Recv Control File Name 'LPD$SPOOL_DIR:cfA008chempc10_york_ac_uk;1', Size 146
 4-MAY-1993 11:49:23.90 Request 11:49:22.73 Sent Control File Size ACK
 4-MAY-1993 11:49:24.03 Request 11:49:22.73, Recv Control File
 4-MAY-1993 11:49:24.15 Request 11:49:22.73 Recv ACK for Control File
 4-MAY-1993 11:49:24.28 Request 11:49:22.73 Control File Host Name is 'chempc10.york.ac.uk'
 4-MAY-1993 11:49:24.40 Request 11:49:22.73 Control File User Name is 'SYSTEM'
 4-MAY-1993 11:49:24.54 Request 11:49:22.73 Control File Job Name is 'autoexec.bat'
 4-MAY-1993 11:49:24.65 Request 11:49:22.73 Control File Form Name is 'chempc10.york.ac.uk.york.ac.uk'
 4-MAY-1993 11:49:24.78 Request 11:49:22.73 $SNDJBCW Create_Job IOSB status = 0004814C
 4-MAY-1993 11:49:24.92 LPD Dying abnormally
 4-MAY-1993 11:49:25.05 Status = '%JBC-F-INVFORNAM, invalid form name'

-----------

Thanks in advance, Graham

.______________________________________________________________________.
|  Dr. Graham Barlow   |                                               |
|  NMR Service         |                                               |
|  Dept. of Chemistry  |    JANET mail:        gkb1@UK.AC.YORK         |
|  Univ. of York, UK   |    Internet mail:     gkb1@tower.york.ac.uk   |
 +----------------------+-----------------------------------------------+

-----------[000166][next][prev][last][first]----------------------------------------------------
Date:      Wed, 12 May 1993 13:47:43 GMT
From:      gandalf@Csli.Stanford.EDU (Juergen Wagner)
To:        comp.protocols.tcp-ip
Subject:   Re: RARP through a Router?

You have to bridge RARP in the router connecting the subnets. Some
routers have the capability to bridge Ethernet protocols based on
Ethertype of packets. 

--Juergen

J_Wagner@iao.fhg.de
gandalf@csli.stanford.edu

-----------[000167][next][prev][last][first]----------------------------------------------------
Date:      Wed, 12 May 1993 13:52:38 GMT
From:      pwb@newt.phys.unsw.edu.au (Paul W. Brooks esq.)
To:        comp.sys.sun.admin,comp.protocols.tcp-ip
Subject:   802.3 SNAP ethernet under SunOS ?

Could someone please tell me if it is possible to configure a Sun IPX
to use 802.3 SNAP ethernet framing instead of Ethernet_II for a TCP/IP
network? Is it possible to configure it with two logical networks
through the same interface, one for each ethernet frame format, so it
will route between them?

Thanks for any pointers - drew a blank with TFM.

Paul Brooks        |Internet: pwb@newt.phys.unsw.edu.au
Uni. of N.S.W.     |          paul@abccomp.oz.au
Kensington NSW 2033| 
AUSTRALIA          | Microwave ovens: God's gift to bachelors

-----------[000168][next][prev][last][first]----------------------------------------------------
Date:      Wed, 12 May 1993 14:15:47 GMT
From:      ignatios@theory.cs.uni-bonn.de (Ignatios Souvatzis)
To:        comp.dcom.modems,comp.sys.sun.misc,comp.protocols.tcp-ip,comp.protocols.ppp
Subject:   Re: Fast modems and dialup SLIP/PPP

In article <C6t6up.749@sci.kun.nl>, janf@sci.kun.nl (Jan Frederik Nipshagen) writes:

 > At Nijmegen University I am working on establishing SLIP access via an Cisco
 > Terminal Server. One thing that I found out is that SLIP requires a fully
 > transparant channel, which makes it impossible to use softwareflowcontrol.

Yeah, thats why you should be using PPP, as appropriate for discussions in this
newsgroup :-).

-- 
	Ignatios Souvatzis
	ignatios@cs.uni-bonn.de souva@astro.uni-bonn.de
Cute quote: "You should also consider that the ST comes fully equipped with a 
             text adventure. It's called ST Basic." Amylaar@meolyon.hanse.de

-----------[000169][next][prev][last][first]----------------------------------------------------
Date:      Wed, 12 May 1993 14:48:04 GMT
From:      dtalleri@maestro.mitre.org (David Tallerico)
To:        comp.protocols.tcp-ip
Subject:   Re: sockoptions in TLI

hedie kamoun writes:

>I have a system which is built around TLI (SunOS). Since the transport
>provider I'm using (tcp) is configured with the Nagle-algoritm option disabled
>(The TCP_NODELAY for sockets) and my system sends out a lot of small packets
>I'd like to set the TCP_NODELAY option thus enabling the Nagle algoritm

//this works on a SunOS 4.1.x
//see sys calls man entry for fcntl

#include <fcntl.h>

...

int flags = O_NDELAY;

int transportEndpoint = t_open("/dev/tcp", flags, NULL);

...


Hope this helps,

-David

-----------[000170][next][prev][last][first]----------------------------------------------------
Date:      12 May 1993 16:33:09 GMT
From:      ch981@cleveland.Freenet.Edu (Tony Alicea)
To:        comp.protocols.tcp-ip
Subject:   BISYNC/TCP Conversion, Looking for...



Does anyone know of a software and/or hardware product to convert
from Bisync/TCP both ways? Please "Reply-To:" address above.

Thanks,

Tony Alicea
talicea@arinc.com

-----------[000171][next][prev][last][first]----------------------------------------------------
Date:      12 May 93 16:37:03 GMT
From:      art@acc.com (Art Berggreen)
To:        comp.protocols.tcp-ip
Subject:   Re: unnecessary Retransmission Timeouts

In article <1993May12.004454.24655@usage.csd.unsw.OZ.AU> pwb@newt.phys.unsw.edu.au (Paul W. Brooks esq.) writes:
>
>If RTT_VAR approaches zero,if means your path is extremely consistent in
>its transmission delay, so you expect the acknowledgement to arrive very
>soon after SRTT time. Why would you want the extra delay caused by
>putting a lower limit on RTT_VAR? 

Because I'd like to operate a little further from the cliff edge.  With an RTO that
close to the SRTT you have little or no room to accomodate any change in local
processing delay, remote processing delay, or path delay without taking a spurious
timeout.  This results in unneccesary retransmission of data and a reduction in the
TCP window.  With a higher bound on RTO, we have some operating room to deal with
small fluctuations in SRTT and also to adapt to any small permanent changes in SRTT.
Also, the SRTT measurement is not perfect.  I've seen situations with low speed
links where an SRTT estimate is built from an exchange of small packets that give
a low variance figure.  But because of the low speed link, the SRTT is actually
dependent on the packet size and the SRTT is underestimated for the first few large
packets, until the SRTT estimate adapts.  Worse yet, the RTT samples are usually
discarded while retransmissions are occuring, delaying the acquisition of a proper
SRTT for the large packet traffic.  This is not uncommon for interactive traffic
(remote echo of keystrokes followed by a screen refresh).  And low speed links are
where you most want to avoid spurious retransmissions.

>	Note that in the paper, the algorithm when implemented in
>integer arithmetic ensures RTT_VAR >= 1 through integer round-off
>'errors'.

But if the ratio between SRTT and clock tick granularity is large, then an RTT_VAR
of 1 may be little different from 0.  Remember that the size of the RTO interval
is only a factor if a packet is lost or believed lost.  The trick is to balance
timely recovery from loss against spurious retransmissions.  The TCP world lived
it's first several years with a fixed beta of 2.

Art

-----------[000172][next][prev][last][first]----------------------------------------------------
Date:      Wed, 12 May 1993 18:24:20 GMT
From:      copeland@sdf.lonestar.org (Charles Copeland)
To:        comp.protocols.tcp-ip,comp.protocols.ibmpc,comp.sources.wanted
Subject:   repost: help with tftp code

I have been trying to find a *complete* copy of tftp with no luck.
Does anybody know where I can get a copy that includes the missing .h files:
paradigmMon.h,pd_globram.h,pd_i82586.h,asmdef.h paradigm.hglobram.h,

copeland@sdf.lonestar.org
-- 
copeland@sdf.lonestar.org
*************************

-----------[000173][next][prev][last][first]----------------------------------------------------
Date:      12 May 1993 18:47:20 GMT
From:      Jim.Rees@umich.edu
To:        comp.dcom.modems,comp.sys.sun.misc,comp.protocols.tcp-ip,comp.protocols.ppp
Subject:   Re: Fast modems and dialup SLIP/PPP

In article <1993May12.141547.9340@olymp.informatik.uni-bonn.de>, ignatios@theory.cs.uni-bonn.de (Ignatios Souvatzis) writes:

   > One thing that I found out is that SLIP requires a fully
   > transparant channel, which makes it impossible to use softwareflowcontrol.
  
  Yeah, thats why you should be using PPP, as appropriate for discussions in this
  newsgroup :-).

No, that's why you should be using out-of-band ("hardware") flow control.
The async map in ppp is a software workaround for buggy hardware.

-----------[000174][next][prev][last][first]----------------------------------------------------
Date:      Wed, 12 May 1993 23:35:47 GMT
From:      clarkm@slab.pr.erau.edu (Michael Clark)
To:        comp.protocols.tcp-ip
Subject:   Tracing the Origin of an FTP Download

  To All FTP gurus -

    Does anyone know how to keep track of the origin of an FTP download or
  to encode a header specifying where it came from.  Ultimately, I would
  like to be able to download multiple text files from various sites, then
  allow users who download my files to be able to know where the files
  originated.  Each individual file would need a header associated with it.
    Thanks for your help!

					- Mike Clark
					  clarkm@slab.pr.erau.edu

 
  

-----------[000175][next][prev][last][first]----------------------------------------------------
Date:      Thu, 13 May 1993 00:58:43 GMT
From:      mikey@yoho.carleton.ca (Mike G McFaul)
To:        comp.protocols.ppp,comp.protocols.tcp
Subject:   Re: bad ppp telnet performance

In article <1sm8i3$ip3@terminator.rs.itd.umich.edu> Jim.Rees@umich.edu writes:
>In article <C6qnAG.M77@cunews.carleton.ca>, mikey@yoho.carleton.ca (Mike G McFaul) writes:
>
>  The real
>  culprit is the window size that is set in the TCP/IP software layer on
>  your machines. Its usually set to around 4096 bytes, this is fine for
>  a 10Mbit/sec ethernet, but way too high for a slow speed ppp link
>  (remember everything is relative!).
>
>Window size is not a fixed number.  It changes to adapt to the link.  Some
>implementations of tcp have an initial or maximum window size, or both, and
>tuning these is sometimes required for low speed links.
>
>I suppose there are probably still some old, obsolete implementations of tcp
>with fixed windows out there, but you should replace them rather than try to
>tune them.

Well I should learn to read my old code *before* writing about it. Jim
is absolutely correct, its not the window size, its the send and
receive buffer sizes that you change. These are set to 4096 bytes (at
least on SunOS 4.x), what I've done is to reduce this size to a small
number a factor of 10 reduced...

The options I've used on my SET_SOCKOPT calls are: SO_SNDBUF and
SO_RCVBUF.  With the SET_SOCKOPT calls its possible to adjust a single
connection to whatever you want, a small number means that the device
input/output queue's are always small.  By device I mean the 'ppp0'
devices, this means that during my ftp transfer, the output queue of
packets is very small and my telnet packets get transmitted very
quickly. Try hacking a bit -- you'll see what I mean... but remember
when you reduce the buffer sizes, you must set the SO_NODELAY on that
socket, to get the ACK's back as quickly as possible.

-----------[000176][next][prev][last][first]----------------------------------------------------
Date:      13 May 93 01:31:54 GMT
From:      edhall@rand.org (Ed Hall)
To:        comp.dcom.modems,comp.sys.sun.misc,comp.protocols.tcp-ip,comp.protocols.ppp
Subject:   Re: Fast modems and dialup SLIP/PPP

In article <1srgnp$4md@terminator.rs.itd.umich.edu> Jim.Rees@umich.edu writes:
>In article <1993May12.141547.9340@olymp.informatik.uni-bonn.de>, ignatios@theory.cs.uni-bonn.de (Ignatios Souvatzis) writes:
>
>   > One thing that I found out is that SLIP requires a fully
>   > transparant channel, which makes it impossible to use softwareflowcontrol.
>  
>  Yeah, thats why you should be using PPP, as appropriate for discussions in this
>  newsgroup :-).
>
>No, that's why you should be using out-of-band ("hardware") flow control.
>The async map in ppp is a software workaround for buggy hardware.

Real helpful response, there.  Some of us either don't own every piece
of equipment involved in a connection, or don't want to spend the money
to replace equipment or wiring which is otherwise functional.

SLIP is a hack.  The RFC it was defined in says as much.  It's "good
enough" for a lot of people's purposes, but it falls short in many other
situations.  PPP widens the field of possible applications considerably.
In the past it has suffered somewhat from a certain lack of focus on the
part of its designers (most committee efforts seem to have this problem)
but the current design is robust, well-defined, and extensible.  SLIP is
none of these.

		-Ed Hall
		edhall@rand.org

-----------[000177][next][prev][last][first]----------------------------------------------------
Date:      13 May 1993 04:35:18 GMT
From:      wanning@skorpio.usask.ca (Mandy Zhu)
To:        comp.protocols.tcp-ip
Subject:   Just a test

aaaaaaaaaaaaaa

-----------[000178][next][prev][last][first]----------------------------------------------------
Date:      13 May 1993 05:10:33 GMT
From:      wanning@skorpio.usask.ca (Mandy Zhu)
To:        comp.protocols.tcp-ip
Subject:   information wanted

Hi,
I am working on characterizing wide-area conversations on an Internet.
Could anybody recommend some new papers about this topic. I will very
appreciate.

Mandy

-----------[000179][next][prev][last][first]----------------------------------------------------
Date:      Thu, 13 May 1993 05:35:31 GMT
From:      Monty Solomon <monty%roscom@think.com>
To:        comp.protocols.appletalk,comp.sys.mac.comm,comp.protocols.tcp-ip
Subject:   Looking for sockets for MacTCP

We are looking for sockets libraries for MacTCP.

Anyone have any info or pointers?

Thanks.

Monty

-- 
# Monty Solomon / PO Box 2486 / Framingham, MA  01701-0405
# monty%roscom@think.com

-----------[000180][next][prev][last][first]----------------------------------------------------
Date:      13 May 93 06:55:24 GMT
From:      J.Crowcroft@cs.ucl.ac.uk (Jon Crowcroft)
To:        comp.protocols.tcp-ip
Subject:   Re: Commercial Multimedia Software for teleconferencing



 >>  So the versions that use the audio/video protocols being developed
 >>by the IETF are not only cheaper (free) but also work better.  Makes
 >>one wonder how DEC is selling this product...

the DEC product is quite cute - the other big difference between it (and
most 'products') and the ietf
ones is that it started out on ether and fddi and tuned its bandwidth
down, whereas the ones in use on the Internet started out in the wide
areas so start with extreme caution...concerning bandwidth etc
 
 >(sd, vat, wb, nevot, nv) and mentioned a rem-conf and a mbone mailing
 >list.  Where can these programs be obtained from?  Which ones run on the
 >DECstation 5000/240?  How does one subscribe to the mailing lists?

rem-conf-request@es.net
mbone-request@isi.edu

most those work on decstations, 

i would add ivs, which interworks with known h.261 video codec
hardware using h.261 standard coding

all these take advantage of internet wide area (experiemtnalish) multicast 
in fairly smart ways, which makes their model of multi-party audio
and/or video (and whiteboarding) conferencing  non-contralised (i.e. network
partition tolerant), again crucially  unlike most products...

again suitable in extremis for the internet

 jon


-----------[000181][next][prev][last][first]----------------------------------------------------
Date:      Thu, 13 May 1993 08:09:37 GMT
From:      evansmp@uhura.aston.ac.uk (Mark Evans)
To:        comp.protocols.tcp-ip
Subject:   Re: RARP through a Router?

Paul W. Brooks esq. (pwb@newt.phys.unsw.edu.au) wrote:
: In article <1993May7.193913.5280@nstn.ns.ca>, daniel@nstn.ns.ca (Daniel MacKay) writes:
: > In <C6I3Io.BoF@sci.kun.nl> petervc@sci.kun.nl (Peter van Campen) writes:
: > 
: > >- When we tried it out again on SunOS4.1.2 the SunOS rarpd refused to
: > >  give a RARP reply, because the client was not on his subnet.
: > 
: > Hey, I just discovered this for myself a couple weeks ago!!  I have a whole
: > slew of Ether bridges that need RARP, but I can't put a server on every
: > segment.  Does anyone have any suggestions?
: 
: So how does the rarpd detect the client was not on its subnet? the RARP
: query doesn't have any IP numbers in it, just the hardware address of
: the client.

Becuase what is looked at is the source address from the ethernet header.

An IP router cannot forward RARP becuase it is not IP.

What is needed is to forward the whole packet with it's ethernet headers 
intact, in both directions. A bridge or a simple repeater will do this.

One answer would be to use bootp, which dosn't have this problem (also
any machine running a correct suite of IP can act as a bootp server).
Here the ethernet address of the sending machine is contained inside a UDP
packet, so it dosn't matter what is in the ethernet header which the server
gets.

: 
: Paul Brooks        |Internet: pwb@newt.phys.unsw.edu.au
: Uni. of N.S.W.     |          paul@abccomp.oz.au
: Kensington NSW 2033| 
: AUSTRALIA          | Microwave ovens: God's gift to bachelors

--
-------------------------------------------------------------------------
Mark Evans                                   |evansmp@uhura.aston.ac.uk
+(44) 21 429 9199  (Home)                    |evansmp@cs.aston.ac.uk
+(44) 21 359 6531 x4039 (Office)             |

-----------[000182][next][prev][last][first]----------------------------------------------------
Date:      13 May 1993 15:10:58 -0400
From:      clark@umbc.edu (Ms. Kathleen Clark)
To:        comp.protocols.tcp-ip
Subject:   source code on ftp sites?


  I have looked around on some ftp sites, but I was wondering
if anyone knows of where I can find some source code to help
me with writing a program that simulates a router?

Thanks!
Kathy 
clark@umbc.edu



-----------[000183][next][prev][last][first]----------------------------------------------------
Date:      13 May 93 11:37:09 GMT
From:      sp_ppm@space.alcbel.be (Paul Moore)
To:        comp.protocols.tcp-ip
Subject:   Info on high-speed transport protocols requested

Hello,

I don't know if this is the best place to put this request.

We are looking at an application that will involve distributing high-speed data
across a range of network types.

We have looked at using TCP, but its maximum transmission speed using a Sparc 
over Ethernet is not fast enough for us. Also TCP is stream-oriented. TP4 is message-
oriented, but for the same hardware configuration, it is slower than TCP. We 
cannot use XTP, because we need to have IP compatibility.

So we are looking for other transport protocols that might be available, and
preferably implemented on dedicated hardware, such as for the VME bus.

Are there any transport protocols that have been implemented to take advantage of
the much higher data rates achievable with FDDI? One that we know of is the
Versatile Message Transaction Protocol, or VMTP designed at Stanford University,
but are there any commercial implementations of this? 

Also, what is the current state-of-the-art of TCP implementations, either built 
into the operating system such as UNIX, or implemented on dedicated hardware?

Our proposed implementation looks like the following, with the transport protocol
X working over IP. In some cases, distribution is across a local LAN. In this case,
it may be possible to get by without using IP, although we would prefer a general solution which also works for the LAN/WAN case.


 Data ------+                                                 +-----> Data
            |                                                 |
            v                                                 |
        +-------+                                         +-------+
        |       |                                         |       |
        | Host  |                                         | Dest. |
        | ----  |                                         | ----  |
        |       |                                         |       
        |-------|                                         |-------|
        | Appl. |                                         | Appl. |
        |-------|                                         |-------|
        |   X   |                                         |   X   |
        |-------|     +-----+     +-----+     +-----+     |-------|
        |  IP   |     | IP  |     | IP  |     | IP  |     |  IP   |
        |-------|     |-----|     |-----|     |-----|     |-------|
        |  DL   |     | DL  |     | DL  |     | DL  |     |  DL   |
        +-------+     +-----+     +-----+     +-----+     +-------+
            |          ^   |       ^   |       ^   |          ^
            |          |   |       |   |       |   |          |
            +----------+   +-------+   +-------+   +----------+


Thanks in advance, 
Paul

---
Paul Moore,                      email: sp_ppm@space.alcbel.be
ALcatel Bell Telephone,
Berkenrodelei 33,                phone: (+32) 3/829.5024
2660 Hoboken,
Belgium.                         fax: (+32) 3/829.5579


-----------[000184][next][prev][last][first]----------------------------------------------------
Date:      Thu, 13 May 1993 13:18:16 GMT
From:      wmp@ornl.gov (W. Mac Post)
To:        comp.protocols.tcp-ip,comp.archives.admin,alt.sources.d,comp.unix.admin,comp.sys.sun.admin,comp.sys.sgi.admin,comp.unix.ultrix,comp.protocols.misc
Subject:   Re: New wuarchive ftp server available

If anyone runs a ftpmail server I would like to know about it.  Better yet,
if anyone has a list, or knows the location of a list of ftpmail servers
I would like to get a copy.  We have a service that maintains and distributes
data for global climate and carbon cycle research.  Some individuals interested
in getting this information do not have ftp capabilities so we would like
to be able to provide them with a list of ftpmail servers.  I'll post
the list I compile if there is not one somewhere already.

Thanks,

Mac Post
wmp@ornl.gov

-----------[000185][next][prev][last][first]----------------------------------------------------
Date:      13 May 1993 12:27:58 +0100
From:      cudep@csv.warwick.ac.uk (Ian Dickinson)
To:        comp.dcom.modems,comp.sys.sun.misc,comp.protocols.tcp-ip,comp.protocols.ppp
Subject:   Re: Fast modems and dialup SLIP/PPP

In article <1sl8jjINNpdn@spatula.csv.warwick.ac.uk> cudep@csv.warwick.ac.uk (Ian Dickinson) writes:
>I have a Sun3/50 running SunOS4.1.1u1 and a V.32/V.42 Hayes compatible modem.

And the slight lack of Hayes compatibility turned out to be the main problem.
A bit of hacking on CR versus LF and I've got it sorted.

However, I did find I needed RTS/CTS as suggested here, and I now have that
working.

>Secondly, I may need to run PPP as well as SLIP.  Can anyone recommend a
>publicly available package which can do both, or a combination of two
>packages which are known to work well together?

The net has come up trumps here - I now have a set of patches which make
cslip-2.6 a dynamically loadable module, and I'm told that ppp-1.2 can do
the same, and more importantly, that they happily co-exist.

I'm a happy dialer now.

Cheers,
-- 
\/ato - Ian Dickinson - NIC handle: ID17          This article is dedicated to
vato@csv.warwick.ac.uk  ...!uknet!warwick!vato        those who disapprove but
/I=I/S=Dickinson/OU=CSV/O=Warwick/PRMD=UK.AC/ADMD= /C=GB/          continue to
@c=GB@o=University of Warwick@ou=Computing Services@cn=Ian Dickinson      read

-----------[000186][next][prev][last][first]----------------------------------------------------
Date:      13 May 1993 16:07:54 GMT
From:      Jim.Rees@umich.edu
To:        comp.dcom.modems,comp.sys.sun.misc,comp.protocols.tcp-ip,comp.protocols.ppp
Subject:   Re: Fast modems and dialup SLIP/PPP

In article <16771@rand.org>, edhall@rand.org (Ed Hall) writes:

  Real helpful response, there.  Some of us either don't own every piece
  of equipment involved in a connection, or don't want to spend the money
  to replace equipment or wiring which is otherwise functional.

Sounds like you agree with me here.  If you have buggy hardware, and can't
fix it, then the async map in ppp can help.

  but the current design is robust, well-defined, and extensible.  SLIP is
  none of these.

I'll agree with you on two out of three, but I don't see how you can claim
that ppp is robust.  Certainly many of the implementations of ppp are not
robust, as a quick glance through comp.protocols.ppp will demonstrate.  It's
possible that the protocol itself could be considered robust now that it has
matured a bit.

-----------[000187][next][prev][last][first]----------------------------------------------------
Date:      13 May 93 18:19:28 GMT
From:      rryan@panix.com (Rob Ryan)
To:        comp.dcom.modems,comp.sys.sun.misc,comp.protocols.tcp-ip,comp.protocols.ppp
Subject:   Re: Fast modems and dialup SLIP/PPP

In <BOB.93May10144815@volitans.MorningStar.Com> bob@MorningStar.Com (Bob Sutterfield) writes:

>In article <1sl8jjINNpdn@spatula.csv.warwick.ac.uk> cudep@csv.warwick.ac.uk (Ian Dickinson) writes:
>   I have a Sun3/50 running SunOS4.1.1u1 and a V.32/V.42 Hayes
>   compatible modem.  I've found that the SunOS tip doesn't understand
>   hayes modems faster than 2400.
>
>Don't worry about whether it's a Hayes or anything else.  Just try
>putting a line like this into your /etc/remote:
>	cua:dv=/dev/cua:br#38400:
> ...

Personally, I found that I had to include a "nt" field in /etc/remote
file to have tip (even when I set hardwareflow) not send ^S's and ^Q's.
I'm running SunOS 4.1.3.  But, with that, I'm successfully using tip
at 38400, using a 14400 V.42bis modem.

-- Rob

-----------[000188][next][prev][last][first]----------------------------------------------------
Date:      Thu, 13 May 1993 19:03:27 GMT
From:      Tom Sheppard <toms@bnr.ca>
To:        comp.protocols.tcp-ip
Subject:   Ethernet Out-of-Band Reset?

Is there any known or standardized way of using OOB for Ethernet?
Specifically, if my Ethernet peripheral is presumed to be brain-dead,
can I do anything over Ethernet to force a H/W reset?  Since I'm
developing the logic board for the peripheral, I can be somewhat
creative.  However, I do have to use a standard protocol chip.

I can think up some screwball schemes but I would prefer to know if
there is a standard.  If not, I'd still be interested in how you may have
done the same thing.

Security is a concern (not sure how important yet).  I would also like
any scheme to be useable from any workstation vendor.  Does your method
prevent any old bozo from resetting the peripheral?

Please reply via e-mail.  Thanks.

Oh, did I mention I may also want to reset the peripheral over a WAN?  :-)

---------------------------------------------------------------------------
Tom Sheppard     Bell-Northern Research Ltd. "Got a minute..."
613-763-4053 [W] P.O. Box 3511, Station C    Translation: I'm about to dump
613-763-8312 [F] Ottawa, Ontario, Canada     a major headache in your lap.
toms@bnr.ca      K1Y 4H7                     ...Sally Forth comic strip

-----------[000189][next][prev][last][first]----------------------------------------------------
Date:      Thu, 13 May 1993 19:32:53 GMT
From:      bob@MorningStar.Com (Bob Sutterfield)
To:        comp.dcom.modems,comp.sys.sun.misc,comp.protocols.tcp-ip,comp.protocols.ppp
Subject:   Re: Fast modems and dialup SLIP/PPP

In article <1stroq$ocp@terminator.rs.itd.umich.edu> Jim.Rees@umich.edu writes:
   In article <16771@rand.org>, edhall@rand.org (Ed Hall) writes:
      ...but the current design is robust, well-defined, and extensible.

   I'll agree with you on two out of three, but I don't see how you
   can claim that ppp is robust.  Certainly many of the
   implementations of ppp are not robust, as a quick glance through
   comp.protocols.ppp will demonstrate.

How many of the comp.protocols.ppp questions are really about the PPP
protocol, and ways in which it needs to be changed or updated?  How
many more are about system-specific installation problems, or network
configuration questions like routing or ARP hacks?

Many of the questions in comp.protocols.ppp are from people using code
that is largely unchanged from Drew Perkins' original proof-of-concept
implementation, written four years ago while RFC 1134 was being ironed
out by Drew and the other programmers/protocol designers (notably Russ
Hobby), who were also working on their own independent
proof-of-concept implementations.

I haven't looked at dp-2.3, but I suspect the guts of its PPP protocol
engine haven't changed much since it was called "patchlevel 5", by
which time its guts hadn't changed much since Drew's original 4.2BSD
code.  Yes, more recent maintainers have done a lot of porting work
and bug fixes, and they've apparently added modern VJ negotiations,
but the guts are showing their age.  The IETF PPP Working Group
(defines the protocol) and the PPP Consortium (industry group that
conducts formal interoperability tests) have learned a *lot* since RFC
1134 was published, and RFC 1331 shows it.  Every finite-state-machine
change, no matter how subtle, reflects that increase in the collective
wisdom.

The remarkable thing is that, even considering the vintage of the guts
of the freely-available PPP implementations, we don't see more
questions on comp.protocols.ppp about how its PPP engine is broken, or
lacks modern features, or whatever.  From that, I infer that even that
ancient PPP implementation is pretty robust!

   It's possible that the protocol itself could be considered robust
   now that it has matured a bit.

Everything takes some shaking down.  Now, if only the popular free
implementations would also mature along with the protocol...
--
Bob Sutterfield, Morning Star Technologies            +1 614 451 1883
1760 Zollinger Rd, Columbus Ohio USA, 43221-2856      +1 800 558 7827
bob@MorningStar.Com                                   +1 614 459 5054 (FAX)

-----------[000190][next][prev][last][first]----------------------------------------------------
Date:      13 May 1993 21:23:15 GMT
From:      WEINTRAU@arizvm1.ccit.arizona.edu
To:        comp.protocols.tcp-ip
Subject:   TN3270 from qvtnet33

I just downloaded QVTNET33.zip from FTP.CICA.INDINIA.EDU.  Looking at
the documentation I find that it only supports ASCII terminals.  Is
there a way for it to support 3270 (tn3270) for access to our IBM
mainframe?
-----------------------------------------------------------------------------
DAVID B. WEINTRAUB           |   VOICE: 602-626-0876                        |
SYSTEMS PROGRAMMER - SENIOR  |   FAX:  602-626-4884                         |
OFFICE OF MEDICAL COMPUTING  |   EMAIL: WEINTRAU@ARIZVM1.CCIT.ARIZONA.EDU   |
1501 N. CAMPBELL AVE #2104   |                                              |
TUCSON, ARIZONA 85724        |                                              |
----------------------------------------------------------------------------
DISCLAIMER:
THE ABOVE STATEMENTS ARE THE AUTHORS AND DO NOT REPRESENT THE OPINIONS OF THE
UNIVERSITY OF ARIZONA.

-----------[000191][next][prev][last][first]----------------------------------------------------
Date:      Thu, 13 May 1993 23:43:40 GMT
From:      Mark_Hebets@ccmail.radian.com (Mark Hebets)
To:        comp.protocols.tcp-ip
Subject:   SUMMARY:  Scripted FTP

I asked:

> I need a way to run an FTP transfer unattended, at a particular
> time every day.  Is there a good example of how to do this?
 
> I know I could run the ftp command with input re-directed, but this
> would require a little work to fake the keyboard input for the password,
> and it would not be too robust.  Is there a way to run it from a
> script, that would allow me to handle error messages and retry the
> transfer?

Thanks!  I got answers from 10 of you, they broke down into three
categories:

1) RTFM.

   There is a .netrc file that ftp reads, I should have known about
   this :(. Ftp will read the login/password data (and possibly a file
   transfer script?) from $HOME/.netrc.  Then stdin redirection would
   work for the rest of the transfer.

   (Still not too robust, I'm looking at a noisy connection, with
   dropped connections and retries likely.)

2) Use a special ftp program

   - bftp (batch ftp) from gatekeeper.dec.com in /.3/net/ip/applic

   - autoftp from src.doc.ic.ak in packages/unix-c/networks/autoftp2.tar-z

   - "There was also a program called "xtp" posted to alt.sources a
     few years ago (like 1989 or 1990).  It is a command-line
     front-end for ftp."  Maybe on a big archive site?

3) Use a general-purpose scripting program.

   - perl

   - mirror.tar.Z from sunsite.unc.edu:pub/packages/ftp-archive

   - tcl and expect from ftp.uu.net in /languages/tcl

I don't have ftp access at this site, so I haven't had a chance to
track any of this down yet.  Tcl/expect got the most recommendations,
sounds like I should learn about it.

Thanks to:

   Stephen Trier        trier@ins.cwru.edu
   Scott Bradner        sob@hsdndev.harvard.edu
   John Sottile         jjs@cblph.att.com
   Arnt Gulbrandsen     agulbra@pvv.unit.no
   Bruce Barnett        barnett@alydar.crd.ge.com
   Philippe Oechslin    oechslin@ltisun.epfl.ch
   John R. Zavgren      gte.com!ganges!jrz0
   Mark D. Eggers       mdeggers@wdi.disney.com
   Brad Keifer          brad@cerberus.bhpese.oz.au
   Leila Burrell-Davis  leilabd@syma.sussex.ac.uk

----
Mark Hebets
Radian Corporation
Mark_Hebets@ccmail.radian.com
Phone: 512-454-4797


-----------[000192][next][prev][last][first]----------------------------------------------------
Date:      Fri, 14 May 1993 00:18:13 GMT
From:      ggm@brolga.cc.uq.oz.au (George Michaelson)
To:        comp.protocols.tcp-ip
Subject:   Re: Commercial Multimedia Software for teleconferencing


[rumor mode] when I installed the Internet mm suite on a dec 5000/25
and de-installed DECspin the users stated:

	oh wow. it works.

previously, nice glossy video was being shipped at the expense of audio
quality. since most people view (sorry) this stuff as a videoPHONE that
is voice with occaisionally useful images, rather than an audioMOVIE with
nice images and occaisionally useful sound, methinks DEC got the code wrong.

I am also less than impressed with being told to buy alpha to achieve useful
proprietary mm performance. everyone else is crowing about how SMALL a box
they can pack mm onto (pc/mac announcements being common) yet DEC sing about
how BIG a box you need to reaaly see thier code work...

-george
--
                         George Michaelson
G.Michaelson@cc.uq.oz.au The Prentice Centre      | There's no  market for
                         University of Queensland | hippos in Philadelphia
Phone: +61 7 365 4079    QLD Australia 4072       |          -Bertold Brecht

-----------[000193][next][prev][last][first]----------------------------------------------------
Date:      Fri, 14 May 1993 01:18:41 GMT
From:      cproto@cs.curtin.edu.au (Computer Protocol)
To:        comp.protocols.tcp-ip
Subject:   Telnet EOR option?

I wonder if any of you TCP-IP experts could help me with a Telnet
problem I've been having - or refer me to another source.  Let us
assume two Telnet NVTs are talking to each other across a network
(I hope I have this right I am no Telnet expert):

       Host side
        +-----+                                 +-----+
        | NVT |<------------------------------->| NVT |----[terminal]
        +-----+                                 +-----+

Anyway both Telnets have EOR option set.  How should a terminal connected
to the client NVT see the incoming data stream in character and in line
mode?  What sort of packets should be coming across the line.  I have
access to a LAN analyser so I can find out what is going across the line
but the problem is I don't know what is supposed to be going across the
line.

In character mode, should each character be sent with an EOR tacked onto
the end of each character sent?  In line mode, should the EOR be tacked
onto the end of each line?  Does EOR work in a different way, is my view
of the problem to simplistic?

Thanx in advance,
george.
-----------------
cproto@cs.curtin.edu.au

-----------[000194][next][prev][last][first]----------------------------------------------------
Date:      14 May 1993 01:53:16 GMT
From:      vern@horse.ee.lbl.gov (Vern Paxson)
To:        comp.protocols.tcp-ip
Subject:   Paper on wide-area TCP growth trends available for ftp

The following paper is now available via anonymous ftp to ftp.ee.lbl.gov.
Retrieve WAN-TCP-growth-trends.ps.Z (about 100KB):

	Growth Trends in Wide-Area TCP Connections
	Vern Paxson
	Lawrence Berkeley Laboratory and
	EECS Division, University of California, Berkeley
	vern@ee.lbl.gov

	We analyze the growth of a medium-sized research laboratory's
	wide-area TCP connections over a period of more than two years.
	Our data consisted of six month-long traces of all TCP connections
	made between the site and the rest of the world.  We find that
	{\em smtp\/}, {\em ftp\/}, and {\em X11} traffic all exhibited
	exponential growth in the number of connections and bytes
	transferred, at rates significantly greater than that at which the
	site's overall computing resources grew; that individual users
	increasingly affected the site's traffic profile by making
	wide-area connections from background scripts; that the proportion
	of local computers participating in wide-area traffic outpaces the
	site's overall growth; that use of the network by individual
	computers appears to be constant for some protocols ({\em telnet})
	and growing exponentially for others ({\em ftp\/}, {\em smtp\/});
	and that wide-area traffic geography is diverse and dynamic.

If you have trouble printing it let me know and I'll mail you hardcopy.

		Vern

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

-----------[000195][next][prev][last][first]----------------------------------------------------
Date:      Fri, 14 May 1993 06:08:59 GMT
From:      schlege@lips2.ecn.purdue.edu (Kevin L Schlegelmilch)
To:        comp.protocols.tcp-ip
Subject:   TCP calculation

Question:
  If a sender of TCP has a window size limit of 4096 bytes and the
receiver has a limit of 8196 bytes, the two are connected via a 
1544000bps (t-1) link, for what distances are the window sizes a
bottleneck, and for what distances is the link a bottleneck?
(Express the distance in microseconds.)  If the speed of light 
is 3 times 10 to the 8th meters/second, how long is the cable at
the threshold?

Instead of emailing me directly, please post answers.  Thanks!

Kevin

-----------[000196][next][prev][last][first]----------------------------------------------------
Date:      14 May 93 16:52:15 -0600
From:      system@condor.navsses.navy.mil (Mike Jacobi; NAVSSES 012C; VAX SYSTEM MANAGER)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP calculation

In article <C70xGr.IsF.1@cs.cmu.edu>, cmaeda+@cs.cmu.edu (Christopher Maeda) writes:
> In article <C706F0.31M@noose.ecn.purdue.edu> schlege@lips2.ecn.purdue.edu (Kevin L Schlegelmilch) writes:
>>Question:
>>  If a sender of TCP has a window size limit of 4096 bytes and the
>>receiver has a limit of 8196 bytes, the two are connected via a 
>>1544000bps (t-1) link, for what distances are the window sizes a
>>bottleneck, and for what distances is the link a bottleneck?
>>(Express the distance in microseconds.)  If the speed of light 
>>is 3 times 10 to the 8th meters/second, how long is the cable at
>>the threshold?
> 
> What is the airspeed velocity of an unladen swallow?
> 

African or European swallow?

> 
> 
> -- 
> 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."
-- 
Mike Jacobi
NAVSSES VAXCluster system manager
System@Eagle.Navsses.Navy.Mil
System@Condor.Navsses.Navy.Mil

Disclaimer - I speak for myself.  No-one else.

-----------[000197][next][prev][last][first]----------------------------------------------------
Date:      Fri, 14 May 1993 11:34:01 GMT
From:      debiso@westfield.win.net (Joe DeBiso)
To:        comp.protocols.tcp-ip
Subject:   Problem with remote printing

I am having a problem mounting a printer on my SCO box from a PC
using PC-NFS.  I have other systems in the NET and have no
problems printing from or to the SCO box.  Any suggestions would be
greatly appreciated. 


-----------[000198][next][prev][last][first]----------------------------------------------------
Date:      Fri, 14 May 1993 13:42:04 GMT
From:      carlson@steam.Xylogics.COM (James Carlson)
To:        comp.protocols.tcp-ip
Subject:   Re: Specs on rlogin? now where are dey?


In article <1svsdhINN1hq@flash.pax.tpa.com.au>,
hart@flash.pax.tpa.com.au (Leigh M Hart) writes:
|> Now, either I didn't look hard enough or I'm blind, but for the life of
|> me I can't find the specifications for the rlogin protocol.  The RFC's
|> don't seem to cover it (unless I missed it) - any ideas?

You did -- RFC 1282.

--
James Carlson <carlson@xylogics.com>            Tel:  +1 617 272 8140
Annex Software Support / Xylogics, Inc.               +1 800 225 3317
53 Third Avenue / Burlington MA  01803-4491     Fax:  +1 617 272 3159

-----------[000199][next][prev][last][first]----------------------------------------------------
Date:      Fri, 14 May 1993 13:58:51 GMT
From:      fred_s@netcom.com (Frederick Scott)
To:        comp.protocols.tcp-ip
Subject:   Re: RARP through a Router?

evansmp@uhura.aston.ac.uk (Mark Evans) writes: 

>Paul W. Brooks esq. (pwb@newt.phys.unsw.edu.au) wrote:
>: So how does the rarpd detect the client was not on its subnet? the RARP
>: query doesn't have any IP numbers in it, just the hardware address of
>: the client.
>
>Becuase what is looked at is the source address from the ethernet header.
>
>An IP router cannot forward RARP becuase it is not IP.

Perhaps I'm mistaken but I thought the original question stemmed from
a situation where multiple subnets were on the same wire.  Since the RARP
packet was addressed as an ethernet broadcast on the MAC level, no routing was
necessary but the rarpd server was ignoring the client not on his subnet
anyway.

Assuming I'm mistaken and the original poster meant that the subnets are
actually on different wires:

>What is needed is to forward the whole packet with it's ethernet headers 
>intact, in both directions. A bridge or a simple repeater will do this.

Of course, you have changing your entire IP addressing scheme or (if
applicable) subnet mask to bridge between ethernet segments rather than
route them...

>One answer would be to use bootp, which dosn't have this problem (also
>any machine running a correct suite of IP can act as a bootp server).
>Here the ethernet address of the sending machine is contained inside a UDP
>packet, so it dosn't matter what is in the ethernet header which the server
>gets.

Yes, but the destination address on a bootp request can not normally be 
present.  It's usually filled in with the IP broadcast address or all zeroes
(depending on the implementation - I think someone told me the RFD actually
recommends using 255.255.255.255).  Therefore, bootp requests cannot be
routed (by standard, run-of-the mill IP routers) either, unless you have
specific software and an administrative database to do it.  (In short, unless
you have a "bootp router".)

Fred

-----------[000200][next][prev][last][first]----------------------------------------------------
Date:      Fri, 14 May 1993 15:53:14 GMT
From:      cmaeda+@cs.cmu.edu (Christopher Maeda)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP calculation

In article <C706F0.31M@noose.ecn.purdue.edu> schlege@lips2.ecn.purdue.edu (Kevin L Schlegelmilch) writes:
>Question:
>  If a sender of TCP has a window size limit of 4096 bytes and the
>receiver has a limit of 8196 bytes, the two are connected via a 
>1544000bps (t-1) link, for what distances are the window sizes a
>bottleneck, and for what distances is the link a bottleneck?
>(Express the distance in microseconds.)  If the speed of light 
>is 3 times 10 to the 8th meters/second, how long is the cable at
>the threshold?

What is the airspeed velocity of an unladen swallow?



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

-----------[000201][next][prev][last][first]----------------------------------------------------
Date:      Fri, 14 May 1993 16:58:01 GMT
From:      vjs@rhyolite.wpd.sgi.com (Vernon Schryver)
To:        comp.protocols.tcp-ip
Subject:   Re: Specs on rlogin? now where are dey?

In article <1svsdhINN1hq@flash.pax.tpa.com.au>, hart@flash.pax.tpa.com.au (Leigh M Hart) writes:
> Now, either I didn't look hard enough or I'm blind, but for the life of
> me I can't find the specifications for the rlogin protocol.  The RFC's
> don't seem to cover it (unless I missed it) - any ideas?


Like RIP, the authoritative reference is not an RFC, but the source.

Look on uunet.


Vernon Schryver,  vjs@sgi.com

-----------[000202][next][prev][last][first]----------------------------------------------------
Date:      Fri, 14 May 1993 17:22:20 GMT
From:      davis@unidata.ucar.edu (Glenn P. Davis)
To:        comp.protocols.tcp-ip
Subject:   PIPE_BUF (or equivalent) for a socket file descriptor

Hi.

I have a tcp socket which is set for non-blocking I/O:

	int cfd ; /* client side file descriptor, a TCP socket */
    int flags = fcntl(cfd, F_GETFL, 0) ;

    if(flags == -1)
    {
        serror("fcntl(..., F_GETFL,)") ;
        return 0 ;
    }
    /* else */

    flags |= O_NONBLOCK ;
    if(fcntl(cfd, F_SETFL, flags) == -1)
    {
        serror("fcntl(..., F_SETFL, O_NONBLOCK)") ;
        return 0 ;
    }

What I need to determine is the maximum number of bytes that can
be written atomically to the descriptor. (If this were a POSIX system
and the descriptor was a pipe, this number would be referred to as
PIPE_BUF.) By "written atomically", I mean that all the bytes will
be transfered by a single call to write(), or none will be transfered
write() returns -1 and errno is set to EWOULDBLOCK (EAGAIN).

I guess the first question is whether I can count on the existance of
such semantics at all? The implementations of interest are all UNIX:
SunOS 4.1.x, SunOS 5.1, Ultrix 4.3, AIX 3.2, IRIX 4.0.5F, OSF-1 ...

The second question is, if the semantics exist, how do I determine the number?
If the POSIX function fpathconf(cfd, _PC_PIPE_BUF) returns an error, can
a make a guess from the return of getsockopt(..., ..., SO_SNDBUF, ...) ?
If both are available, what is or should be the relationship between them?

Here is a code fragment I ran on several systems:

	long mtu = 512 ; /* _POSIX_PIPE_BUF, default minimum value? */
	int optlen = sizeof(mtu) ;

	/* try fpathconf first */
	mtu = fpathconf(cfd, _PC_PIPE_BUF) ;
	if(mtu == -1L)
	{
		int errnum = errno ;
		fprintf(stderr, "fpathconf: %s\n", strerror(errnum));
	}
	else
	{
		fprintf(stdout, "MTU (_PC_PIPE_BUF) %ld\n",
			mtu) ;
	}
	/* compare with getsockopt */
	errno = 0 ;
	if(getsockopt(cfd, SOL_SOCKET, SO_SNDBUF,
			(char *)&mtu, &optlen ) < 0)
	{
		int errnum = errno ;
		fprintf(stderr, "getsockopt: %s\n", strerror(errnum));
	}
	else
	{
		fprintf(stdout, "MTU (getsockopt SOL_SOCKET) %ld\n",
			mtu) ;
	}

And here are the results:

	SunOS 4.1.3
		fpathconf: Invalid argument
		MTU (getsockopt SOL_SOCKET) 4096

	SunOS 5.1
		MTU (_PC_PIPE_BUF) 5120
		getsockopt: No such file or directory

	Ultrix 4.3, MIPSEL
		MTU (_PC_PIPE_BUF) 4096
		MTU (getsockopt SOL_SOCKET) 16384

	AIX 3.2
		MTU (_PC_PIPE_BUF) 32768
		MTU (getsockopt SOL_SOCKET) 16060

	IRIX 4.0.5F
		MTU (_PC_PIPE_BUF) 10240
		MTU (getsockopt SOL_SOCKET) 61320

This shows how far standardization efforts have to go to get
sockets rolled in.

Some hypotheses (Feel free to comment, confirm, or deny.)

	SunOS 4.1.3
		Doesn't support fpathconf for sockets => sockets and
		pipes have different semantics => all bets are off?
		Kinda small SO_SNDBUF?

	SunOS 5.1
		Sockets and pipes share kernel support, but they didn't
		get the getsockopt compatibilty call right. Use 5120.

	Ultrix 4.3, MIPSEL
		I guess use the smaller of the two numbers. Do the semantics
		apply?

	AIX 
		How can getsockopt(...SO_SNDBUF) be less than PIPE_BUF?
		Weird. Do the semantics apply? With which number?

	IRIX
		Sockets and pipes share kernel support, use 10240.
		(If all the systems had a number this big, I wouldn't
		need to do the nonblocking I/O at all!)

In the absence of a reasonable, portable way to determine this
at runtime, is there a number which will "always" work? 512? 1024?
4096?

Any discussion? Especially welcome are remarks by those familiar with
the internals of the various systems.
Please reply directly.

Glenn P. Davis				davis@unidata.ucar.edu
UCAR / Unidata
PO Box 3000                   3300 Mitchell Lane, Suite 170
Boulder, CO 80307-3000        Boulder, CO  80301

(303) 497 8643

-----------[000203][next][prev][last][first]----------------------------------------------------
Date:      14 May 1993 16:55:42 +0100
From:      cudep@csv.warwick.ac.uk (Ian Dickinson)
To:        comp.dcom.modems,comp.sys.sun.misc,comp.protocols.tcp-ip,comp.protocols.ppp
Subject:   Re: Fast modems and dialup SLIP/PPP

In article <1stbbuINNct@spatula.csv.warwick.ac.uk> cudep@csv.warwick.ac.uk (Ian Dickinson) writes:
>The net has come up trumps here - I now have a set of patches which make
>cslip-2.6 a dynamically loadable module, and I'm told that ppp-1.2 can do
>the same, and more importantly, that they happily co-exist.

Enough people have asked me where to get this from (and I don't know the
offical source for these patches) that I've put the stuff up for anon ftp
from ftp.warwick.ac.uk:/pub/inet

Another thing that cropped up via email was this:

Will a modloadable cslip-2.6 co-exist with dp-2.3 ?

Also, Bob Sutterfield mentioned it being quite easy to modify a PPP
implementation to do SLIP.  Has anyone done this to a PD implementation
and managed to keep the PPP support working?  It certainly looks like dp-2.3
with this capablity would be ideal for my situation.  But I'll stick with
what I have for now.

Cheers,
-- 
\/ato - Ian Dickinson - NIC handle: ID17          This article is dedicated to
vato@csv.warwick.ac.uk  ...!uknet!warwick!vato        those who disapprove but
/I=I/S=Dickinson/OU=CSV/O=Warwick/PRMD=UK.AC/ADMD= /C=GB/          continue to
@c=GB@o=University of Warwick@ou=Computing Services@cn=Ian Dickinson      read

-----------[000204][next][prev][last][first]----------------------------------------------------
Date:      Fri, 14 May 93 20:18:23 GMT
From:      ddml@visual1.jhuapl.edu (Dave Libershal)
To:        comp.protocols.tcp-ip
Subject:   Help! Need feedback on FTP's PC/LPD

Hello,

Does anybody have any experience they can share using FTP's PC/LPD
 software??  We want to print from both remote UNIX machines and a local
PC to the printer which is attached to that PC (Parallel connection). PC/LPD
runs in a DOS box under Windows, allowing the remote UNIX printing. Local
printing can be done from the Windows or DOS drivers. So, that should do
the trick. But, how well does it work. The FTP sales person says they run it
on standalone (dedicated print server) PCs for performance reasons.

I'm thinking about getting a copy to try it out with our applications, but I
don't want to use the PC as a dedicated print server; I want the user to be
able to run his normal PC applications while allowing the UNIX printing.

Has anybody done this????

Thanks,

Dave Libershal

-----------[000205][next][prev][last][first]----------------------------------------------------
Date:      Fri, 14 May 93 20:36:41 GMT
From:      ccg@tcdsp1.mmm.com ("Charles Ganzhorn")
To:        comp.protocols.tcp-ip
Subject:   Re: Specs on rlogin? now where are dey?

One thing that seems to be missing in the spec is the connection port
numbers and the starting range of the return port numbers.  Where are
they?

Charles.

--
Charles Ganzhorn			E/Mail:  ccganzhorn@mmm.com
3M IT Network Services			AT&T:	 +1 612 736 7122
St. Paul, MN				FAX:	 +1 612 736 7689

-----------[000206][next][prev][last][first]----------------------------------------------------
Date:      Fri, 14 May 1993 21:36:44 GMT
From:      ekc1@wucs1.wustl.edu (Eng K. Chong)
To:        comp.protocols.tcp-ip
Subject:   Can't obtain broadacast mask from UDP app.

We're using a version of the winsock API and can't obtain the broadcast mask
via the standard ioctl command (in winsock the command is actually ioctlsocket) as it is currently not supported.

My question:

Does anyone know of an alternative means of obtaining the broadcast mask under 
the winsock API?   -- OR --

I can obtain my local IP address and determine whether or not it is class
A, B or C, and then construct my broadcast mask.  But I'm concerned about
the implications of IP-subnetting.   Can anyone offer some experienced
advice?


Please send replies to:

	ekc1@wucs1.wustl.edu



-----------[000207][next][prev][last][first]----------------------------------------------------
Date:      Fri, 14 May 1993 21:53:55 GMT
From:      chris@uis.com (Chris Howard)
To:        comp.protocols.tcp-ip,comp.sys.hp,comp.sys.ibm
Subject:   IBM 3090 connections

We have a need for information on tcp/ip connections from
an IBM 3090 to an existing network (ethernet) of HP Unix
boxes (750s).

We need to move a _lot_ of data in file transfers.
(About 50 Gb in periodic uploads from HPs to IBM)

Any suggestions, or contacts to people doing it now would
be appreciated.

--
Chris Howard					          chris@uis.com
Unix Integration Services     	Urbandale, Iowa	          (515) 254-3074 
-- 
Chris Howard					          chris@uis.com
Unix Integration Services     	Urbandale, Iowa	          (515) 254-3074 

-----------[000208][next][prev][last][first]----------------------------------------------------
Date:      Fri, 14 May 1993 21:59:15 GMT
From:      vhalkka@klaava.Helsinki.FI (Vesa Halkka)
To:        comp.dcom.lans.ethernet,comp.protocols.tcp-ip
Subject:   Re: DECbridge90 filtering strategy ?

In <1993May7.112947.9474@serra.unipi.it> luigi@pical2.iet.unipi.it (Luigi Rizzo) writes:

>Of course I may be totally wrong, but after 10 days of tracing
>ethernet packets I'm pretty confident there's something non obvious
>with the learning strategy of the DECbridge90 (mainly because
>once it has been replaced with a PCBRIDGE, all the strange things
>have disappeared!).

It is a toy bridge: it has a very limited forwarding table,
and *it is bridging only to one direction.* Every packet
coming from the other direction goes through the bridge.

They were cheap, and we almost bought them. But we did read
the FM.

VesA



-----------[000209][next][prev][last][first]----------------------------------------------------
Date:      Sat, 15 May 1993 02:29:43 GMT
From:      raj@cup.hp.com (Rick Jones)
To:        comp.protocols.tcp-ip,comp.sys.hp,comp.sys.ibm
Subject:   Re: IBM 3090 connections

Well, since you are going to move a lot of data, I assume that you are
interested in performance. 

"Raw" TCP as measured by netperf on the 750 will proceed in excess of
1024 KBytes/s (K=1024). With reasonably zippy disks, you should be
able to see that with FTP.

If you would like to get a copy of netperf, try ftp-ing over to
iworks.ecn.uiowa.edu, or ftp.csc.liv.ac.uk.

Having said all that, I assume that you have figured-out that your
*best-case* transfer time is going to be on the order of 50*1024
seconds, or roughly 14 hours, 15 minutes. This assumes that the *only*
nodes generating traffic on the Ethernet are the 3090 and the 750. The
peak transfer rate that I have seen on "timeshare" lans has been
800KB/s, which would up the time to over 18 hours.

This seems like a rather long time. You might want to consider means
of improving your theoretical performance. If there are multiple
files, you could add a second Ethernet between the two hosts. My
stronger suggestions, however, would be to put a faster link between
the two boxes - perhaps FDDI.

If you opt for FDDI, you must choose an EISA FDDI card. "Raw" TCP on
the HP EISA FDDI is not going to exceed 4MB/s. If you are willing to
upgrade the 750 to a 755, you have another choice in FDDI interfaces -
an integrated one which has "raw" TCP of 80+Mb/s. I do not know what
sort of FTP performance you could expect. If you cannot upgrade the
750, there are a couple of third-parties who either have, or are
producing EISA FDDI cards for 700's - I would hope that they could
meet or exceed the performance levels of the HP EISA FDDI card.

Of course, this rambling completely ignores the capabilities and/or
limitations of the 3090...and remember, I have quoted a lot of TCP
performance figures, NOT FTP figures. FTP performance includes a lot
more than just TCP, it includes disk, filesystem, and all sorts of
other things that could bog stuff down. Think of the TCP number in the
same way you would (should?) MFLOPS - something you are guaranteed NOT
to exceed... ;-)

rick jones
I am in a maze of twisty little opinions, all my own...
I am but knowledgable north by northwest, when the bits are from the east...

-----------[000210][next][prev][last][first]----------------------------------------------------
Date:      15 May 93 04:29:45 GMT
From:      sun-jian@cc.sophia.ac.jp (Sun Jian)
To:        comp.protocols.tcp-ip
Subject:   about PWD_2 and simtel20

i send this message befor, but it may be did not delivered because my server
host spool was overflowed. i send it again.
i got a message on the PED_2 and simtel20, but  i do not know them detail.
i need some information on the protocol simulations, but i have not any materials on it, and so i need help now.

-----------[000211][next][prev][last][first]----------------------------------------------------
Date:      15 May 93 04:33:45 GMT
From:      sun-jian@cc.sophia.ac.jp (Sun Jian)
To:        comp.protocols.tcp-ip
Subject:   about PWD_2 and simtel20

i send this message befor, but it may be did not delivered because my server
host spool was overflowed. i send it again.
i got a message on the PED_2 and simtel20, but  i do not know them detail.
i need some information on the protocol simulations, but i have not any materia\
ls on it, and so i need help now.

-----------[000212][next][prev][last][first]----------------------------------------------------
Date:      Sat, 15 May 1993 08:11:42 GMT
From:      sakura@ics.kula.kyoto-u.ac.jp (Takashi SAKURAGAWA)
To:        comp.sys.mac.system,comp.sys.mac.comm,comp.protocols.tcp-ip
Subject:   Question: Broadcast address of MacTCP

Hi! Everybody.

When I open AdminTCP or MacTCP control panel on Macintosh, there is no
field for broadcast address.  As you know, UNIX machines allow users
to set an arbitrary broatcast address.  I think there is no protocol
to get the broadcast address of the LAN.

I think there are three possibilities.

(1)Macintosh sends no broadcast packet and it does not recognize them.

(2)Macintosh sends no broadcast packet and it recognize more than one
broadcast address.

(2)Macintosh use a fixed broadcast address which is decided according to
its IP address and netmask.

Which is the truth?
Please send me an E-mail.
Thanks in advance.

sakura@ics.kula.kyoto-u.ac.jp
Takashi SAKURAGAWA
Faculty of Integrated Human Studies
Kyoto University
Japan


-----------[000213][next][prev][last][first]----------------------------------------------------
Date:      14 May 1993 20:01:12 +0930
From:      hart@flash.pax.tpa.com.au (Leigh M Hart)
To:        comp.protocols.tcp-ip
Subject:   Specs on rlogin? now where are dey?

Now, either I didn't look hard enough or I'm blind, but for the life of
me I can't find the specifications for the rlogin protocol.  The RFC's
don't seem to cover it (unless I missed it) - any ideas?

Cheers

Leigh
-- 
Leigh M Hart (hart@pax.tpa.com.au) 

-----------[000214][next][prev][last][first]----------------------------------------------------
Date:      15 May 1993 14:11:55 GMT
From:      trier@odin.ins.cwru.edu (Stephen C. Trier)
To:        comp.sys.mac.system,comp.sys.mac.comm,comp.protocols.tcp-ip
Subject:   Re: Question: Broadcast address of MacTCP

In article <SAKURA.93May15171142@misen.ics.kula.kyoto-u.ac.jp> sakura@ics.kula.kyoto-u.ac.jp (Takashi SAKURAGAWA) writes:
>(2)Macintosh use a fixed broadcast address which is decided according to
>its IP address and netmask.

This option is correct.  I don't know if MacTCP can receive broadcasts to
the old (0's) 4.2BSD broadcast address.  It definitely transmits
broadcasts to the "new" (1's) address(es).

-- 
Stephen Trier (trier@ins.cwru.edu)   Star Trek dialog mistake of last week:
Network Software Engineer              "We've tried every decryption key
IRIS/INS/T                               on record, Captain."
Case Western Reserve University             - Geordi LaForge, ST:TNG, 5/1/93

-----------[000215][next][prev][last][first]----------------------------------------------------
Date:      Sat, 15 May 1993 16:07:33 GMT
From:      swslr@well.sf.ca.us (Larry Krone)
To:        comp.protocols.tcp-ip
Subject:   SCO TCP

Gentle People:

We are trying to use SCO TCP/IP under SCO 2.3.4...We are using the
progress database pacakge and FTP.  After a certain number of connections
via TCP has been reached, the system hangs....this number seems to be around 
30 or 40 but is not consistent....Is there some TCP/IP paramaters
for SCO that I can check, or does anyone have any ideas???

Thanx,


Larry Krone
swslr@well.sf.ca.us

-----------[000216][next][prev][last][first]----------------------------------------------------
Date:      16 May 1993 02:07:10 GMT
From:      shuford@cs.utk.edu (Richard Shuford)
To:        vmsnet.networks.misc,comp.protocols.tcp-ip
Subject:   Re: VMS-TCP/IP

In article <1993May13.182036.14889@picker.com>,
  visconti@picker.com (Leonard A. Visconti, +1 216/473-4801) writes:
>
> Does anyone know of any public domain software that would provide FTP 
> capablility for a vax? Thanks you.

Presumably you mean a VAX running VMS? (or OpenVMS, in fashionable terms)

And also presumably you are in need not just of an implementation of
the File-Transfer Protocol (FTP) but of the entire TCP/IP protocol
suite to run on this VAX?

If so, the microbudget way to set up TCP/IP on your VAX is to obtain
the package which is now called "CMU-OpenVMS-IP".  (The software once
had a connection to Tektronix, but the current name remembers only the
Carnegie-Mellon heritage.)  

Information on the most economical commercial TCP/IP stack for VMS may
be obtained by e-mailing a query about "TCPware" to "sales@process.com".
The other major vendors are TGV, with Multinet, and Wollongong, with
WIN/TCP.  Network Research is said to sell Fusion TCP for VMS.  DEC
sells an implementation called "UCX" or "TCP/IP Services for OpenVMS",
but only halfheartedly, since DEC's corporate sympathy is with OSI.

Most net discussion of CMU-OpenVMS-IP takes place in the newsgroup 
"vmsnet.networks.tcp-ip.cmu-tek". (If you can't access this group,
you can join the mailing list by e-mailing a request to
"CMU-OpenVMS-IP-Request@DRYCAS.CLUB.CC.CMU.EDU".)

Here is some recent instruction from Henry Miller, the current heroic
wielder of the BLISS compiler for the CMU-OpenVMS-IP community.

| To get the new version, use ANONYMOUS FTP to either SACUSR or
| SACWMS.MP.USBR.GOV.  In directory [.TEKIP] are the files TEKIP0665A.SAVE and
| TEKIP0665A.SAVE_Z.  The latter is an LZCOMP'ed version of the former.  This
| is not at installation kit, but just a BACKUP saveset and the structure of
| the saveset should make it obvious where the files go under CMUTEK_SYSROOT:.
| 
| Due to the new IP driver and PTY drivers, you will have to reboot the system.
| The IPACP and drivers are co-dependent on each other, so you have to load
| them all up and reboot.  Before you reboot, modify your INTERNET.CONFIG
| file to use the 'ETHER' driver instead of 'XEDRV'.  There are still some
| problems with the external driver, but the internal driver works OK.
| 
| ----------
| Henry W. Miller
| Assistant Systems and Network Manager
| U.S. Bureau of Reclamation
| Mid Pacific Region
| 2800 Cottage Way MP1100
| Sacramento, CA 95825
| (916) 978-5108
| Internet: "henrym@sacwms.mp.usbr.gov"
| BITNET:    hmiller@scu"                "I've fallen, and I can't get up!"
-- 
 ...Richard S. Shuford  | "A prudent man sees danger and takes refuge,
 ...shuford@cs.utk.edu  |  but the simple keep going and suffer for it."
 ...Info-Stratus contact|  Proverbs 22:3 NIV

-----------[000217][next][prev][last][first]----------------------------------------------------
Date:      16 May 93 18:27:35 GMT
From:      jonc@status.gen.nz (Jon Clarke)
To:        comp.protocols.tcp-ip
Subject:   ESIX tcp-ip

Hello netters,

Is there any sites out there that use tcp-ip with ESIX Sys V at all?
If so can you please drop me an email.

I want information on sub-addressing ESIX so it can find a PCR.

regards
       
       _         Jon Clarke (jonc@status.gen.nz)       * Public Access Unix * 
      ( )o       The home of Z*NET on the World Nets (Z*NET Free ASCII Zines)
      /\  \      HEXAGON: HSBC NZ EBD  GEM: Jon Clarke   PH : (+649) 358-5589


-----------[000218][next][prev][last][first]----------------------------------------------------
Date:      Mon, 17 May 1993 03:32:27 GMT
From:      mdella@dts.harris.com (Marcos Della)
To:        comp.protocols.tcp-ip
Subject:   Info on VistaPoint Wireless

Has anyone had any experiance with the Motorola VISTAPoint wireless
microwave LAN transmitter?  I'm looking at buying one, but would like
to know if anyone has had any experiance with them...

Marcos

-- 
_______________________________________________________________________________
Marcos R. Della                             | Did you ever wonder if there was
Harris Digital Telephone Systems            | more to the universe than this?
mdella@dts.harris.com                       |

-----------[000219][next][prev][last][first]----------------------------------------------------
Date:      Mon, 17 May 1993 05:40:15 GMT
From:      swslr@well.sf.ca.us (Larry Krone)
To:        comp.protocols.tcp-ip
Subject:   AIX TCP

To those who sent me replies about my SCO problem, thanx...Here we go again:

One of our sites is running a network of 2 AIX boxes on site (550 & 580) and
a 530 remotely over a 56KB line...We just upgraded the operating system
tonite and started to have a weird problem; we can rlogin and telnet to the
remote 530 okay for a while; then it just locks up on us...we cannot
rlogin,telnet or FTP to the 530, but ping returns okay.  ALso, if we 
reboot the 550 & 580 all becomes well again for a while...

Thoughts???

Please email to:

swslr@well.sf.ca.us




-----------[000220][next][prev][last][first]----------------------------------------------------
Date:      17 May 93 11:14:43
From:      art@now.midnight.com (Art Mellor)
To:        comp.protocols.tcp-ip
Subject:   Beta testers needed for IP net discovery tool


We have a simple net management tool for doing IP node discovery. We would
like to find some people to help us Beta test it. If you are interested,
please send mail to support@midnight.com and we'll send you details.

Requirements:
------------

o Sparc running SunOS 4.x.x

o Network Interface Tap (NIT) installed

o Access to /dev/nit and /dev/kmem

o An UP and RUNNING IP interface with a Class B (or smaller) net mask

o Working hostname resolution (NIS, DNS, and/or host file)

o ~ 2.0M of disk space

o X11R4 or R5 (OpenWindows 3 or 4 should be OK)

--


...............................................................................
  Art Mellor       : Midnight Networks Inc. 100 Fifth Avenue Waltham MA 02154 
  art@midnight.com : Phone 617/890-1001 Fax 890-0028  *The Best in Network SW


-----------[000221][next][prev][last][first]----------------------------------------------------
Date:      Mon, 17 May 1993 07:18:02 GMT
From:      cproto@cs.curtin.edu.au (Computer Protocol)
To:        comp.protocols.tcp-ip
Subject:   Public domain OSPF ?

Is there a public domain version of OSPF ?

Regards - Tibor Sashegyi (cproto@cs.curtin.edu.au)


-----------[000222][next][prev][last][first]----------------------------------------------------
Date:      Mon, 17 May 1993 08:59:37 GMT
From:      websterc@decuk.uvo.dec.com (Colin Webster)
To:        comp.dcom.lans.ethernet,comp.protocols.tcp-ip
Subject:   Re: DECbridge90 filtering strategy ?


In article <1993May14.215915.2460@klaava.Helsinki.FI>, vhalkka@klaava.Helsinki.FI (Vesa Halkka) writes:
|>Xref: uvo.dec.com comp.dcom.lans.ethernet:4419 comp.protocols.tcp-ip:25876
|>Newsgroups: comp.dcom.lans.ethernet,comp.protocols.tcp-ip
|>Path: uvo.dec.com!news.crl.dec.com!pa.dec.com!decwrl!elroy.jpl.nasa.gov!usc!cs.utexas.edu!utnut!torn!nott!bnrgate!bnr.co.uk!uknet!pipex!sunic!news.funet.fi!hydra!klaava!vhalkka
|>From: vhalkka@klaava.Helsinki.FI (Vesa Halkka)
|>Subject: Re: DECbridge90 filtering strategy ?
|>Message-ID: <1993May14.215915.2460@klaava.Helsinki.FI>
|>Organization: University of Helsinki
|>References: <1993May7.112947.9474@serra.unipi.it>
|>Date: Fri, 14 May 93 22:59:15 GMT-1:00
|>Lines: 18
|>
|>In <1993May7.112947.9474@serra.unipi.it> luigi@pical2.iet.unipi.it (Luigi Rizzo) writes:
|>
|>>Of course I may be totally wrong, but after 10 days of tracing
|>>ethernet packets I'm pretty confident there's something non obvious
|>>with the learning strategy of the DECbridge90 (mainly because
|>>once it has been replaced with a PCBRIDGE, all the strange things
|>>have disappeared!).
|>
|>It is a toy bridge: it has a very limited forwarding table,
|>and *it is bridging only to one direction.* Every packet
|>coming from the other direction goes through the bridge.
|>
The DECbridge 90 is a so called "workgroup" bridge. As such, it only
has one address table with a maximum of 200 nodes and this is for the nodes 
on the "workgroup" side. If a node is not in this table, then it is assumed
to be on the "backbone" side.  
If the 200 node table is exceeded, then the 201st node cannot talk to
the backbone (the only situation where you bridge in one direction is
where the 200 node limit is exceded with a  DB90FL, the bridge goes into 
to flood mode and allows all traffic to the backbone untill the "workgroup" 
node count is 200 or less).
The forwarding and filter rate is pretty much the same as a DEC lanbridge 200.
You can draw your own conclusions as to whether the "workgroup" concept
for a hub based bridge makes it a toy or not.

	/Colin 

-----------[000223][next][prev][last][first]----------------------------------------------------
Date:      Mon, 17 May 1993 11:16:26 GMT
From:      evansmp@uhura.aston.ac.uk (Mark Evans)
To:        comp.protocols.tcp-ip
Subject:   Re: Specs on rlogin? now where are dey?

Vernon Schryver (vjs@rhyolite.wpd.sgi.com) wrote:
: In article <1svsdhINN1hq@flash.pax.tpa.com.au>, hart@flash.pax.tpa.com.au (Leigh M Hart) writes:
: > Now, either I didn't look hard enough or I'm blind, but for the life of
: > me I can't find the specifications for the rlogin protocol.  The RFC's
: > don't seem to cover it (unless I missed it) - any ideas?
: 
: 
: Like RIP, the authoritative reference is not an RFC, but the source.

Odd I have a printout of an RFC claiming to be the BSD rlogin 
protocol....

--
-------------------------------------------------------------------------
Mark Evans                                   |evansmp@uhura.aston.ac.uk
+(44) 21 429 9199  (Home)                    |evansmp@cs.aston.ac.uk
+(44) 21 359 6531 x4039 (Office)             |

-----------[000224][next][prev][last][first]----------------------------------------------------
Date:      Mon, 17 May 1993 13:30:11 GMT
From:      edge@unislc.slc.unisys.com (Brian Edginton)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP calculation

cmaeda+@cs.cmu.edu (Christopher Maeda) writes:

>In article <C706F0.31M@noose.ecn.purdue.edu> schlege@lips2.ecn.purdue.edu (Kevin L Schlegelmilch) writes:
>>Question:
>>  If a sender of TCP has a window size limit of 4096 bytes and the
>>receiver has a limit of 8196 bytes, the two are connected via a 
>>1544000bps (t-1) link, for what distances are the window sizes a
>>bottleneck, and for what distances is the link a bottleneck?
>>(Express the distance in microseconds.)  If the speed of light 
>>is 3 times 10 to the 8th meters/second, how long is the cable at
>>the threshold?
 
>What is the airspeed velocity of an unladen swallow?

African or European?



>-- 
>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."
-- 
Brian Edginton                   | edge@unislc.slc.unisys.com
Unisys - Performance Engineering | unislc!edge@cs.utah.edu
320 North 2200 West  D1V01       | {hpda, sun, uplherc}!unislc!edge 
Salt Lake City, Utah 84116       | (801) 594-6009 Human (usually)

-----------[000225][next][prev][last][first]----------------------------------------------------
Date:      Mon, 17 May 1993 13:58:11 GMT
From:      vjs@rhyolite.wpd.sgi.com (Vernon Schryver)
To:        comp.protocols.tcp-ip
Subject:   Re: Specs on rlogin? now where are dey?

In article <1993May17.111626.24534@aston.ac.uk>, evansmp@uhura.aston.ac.uk (Mark Evans) writes:
> Vernon Schryver (vjs@rhyolite.wpd.sgi.com) wrote:
> : In article <1svsdhINN1hq@flash.pax.tpa.com.au>, hart@flash.pax.tpa.com.au (Leigh M Hart) writes:
> : > Now, either I didn't look hard enough or I'm blind, but for the life of
> : > me I can't find the specifications for the rlogin protocol.  The RFC's
> : > don't seem to cover it (unless I missed it) - any ideas?
> : 
> : Like RIP, the authoritative reference is not an RFC, but the source.
> 
> Odd I have a printout of an RFC claiming to be the BSD rlogin 
> protocol....


What is odd about it?

The rlogin and RIP RFC's were written a decade or more after the code
that implemented and defined the protocols, and not by the authors of
the implementations that defined the protocols.

A quick reading of the RIP RFC finds at least one modest error in how
RIP has worked for many years, and some more significant errors in how
the 4.3BSD code works.  (Sorry, it's been a year or two since I read
the RIP RFC after a bout hacking on the code and I've forgotten details.)

Consider the differences between RFC 1282 and RFC 1258.  You can check
old versions of the source to discover that the protocol did not change.

Did the MIL spec's re-define (and so break) TCP, despite carrying more
de jure weight than the RFCs?

A standard can be good for describing and documenting reality, but a
standard does not redefine reality.  Only reality defines reality.
Like any documentation, a standard is only as good as it is complete
and free of errors.  Like every work of man, every standard has errors
and almost all standards are incomplete.

It's a sympthom of a disease common among Standards Committee Goers to
believe that nothing exists except as written in a Genuine Standard
(tm) by an Accredited Committee (tm).

The RIP RFC and the second rlogin RFC should be viewed as very good
textbooks on their subjects.  Like any textbook about practical
matters, whether about mining, airplanes or computers, they do not
define their subjects.  Who would pick an airplane driven by someone
who had only read about flying?

Of course the RIP-2 RFC is definitive about its protocol, because it
defined the protocol before (or perhaps during, I don't know) the
implementations.


Vernon Schryver,  vjs@sgi.com

-----------[000226][next][prev][last][first]----------------------------------------------------
Date:      Mon, 17 May 1993 14:10:43 GMT
From:      larryp@sco.COM (Larry Philps)
To:        comp.protocols.tcp-ip
Subject:   Re: SCO subnetting problem

In <5@mhinfo.UUCP> carrato@mhinfo.UUCP (Tony Carrato) writes:

> In article <3@mhinfo.UUCP> I wrote:
> >Here's the problem:
> >
> >	Segment 1				Segment 2
> >  ================================   ==========================
> >  "       "          "           "   "           "            "
> > SCO    RS6000     PC 1 w/        Netware     PC 2 w/      PC  3 w/
> >                   LAN WG         w/ Novell   LAN WG       LAN WG
> >		   for DOS        TCP/IP      for DOS      for DOS
> >
> >In this configuration, PC 1 can ping/telnet to the SCO box.  If you
> >move it to segment 2, it can't.  However, on either segment, PC 1
> >(and the other PC's) can easily ping/telnet to the RS6000.
> 
> It turns out the problem was the subnetwork addressing on the SCO box.
> as soon as we went to a subnet mask of 255.255.255.0 things started working
> fine.  It could well be that on the SCO TCP/IP implementation that
> partial byte subnetting simply doesn't work.  (The RS6000 worked just
> fine in either configuration.)

I really have no idea what is/was causing your problem, but partial
byte subnetting works fine under SCO (at least with TCP/IP 1.2.0 and
1.2.1.  I have a working subnet (for testing) that uses a netwask of
255.255.225.224 off a Class C address.  There are 5 configured subnets
under this.  The test net is gatewayed to the rest of SCO's corporate
net via an ODT 2.0 machine acting as a 4 way router.  The results of
ifconfig'ing the interfaces on this machine are shown below.  (I have
changed the actual class C network numbers for reasons that can only be
attributed to paranoia to ClassC.Net.1, ClassC.Net.2, and ClassC.Net.3)

Script started on Mon May 17 10:03:16 1993
$ ifconig wdn0
wdn0: flags=23<UP,BROADCAST,NOTRAILERS>
        inet ClassC.Net.1.124 netmask ffffff00 broadcast ClassC.Net.1.255
$ ifconfig wdn1
wdn1: flags=23<UP,BROADCAST,NOTRAILERS>
        inet ClassC.Net.2.65 netmask ffffffc0 broadcast ClassC.Net.2.127
$ ifconfig wdn2
wdn2: flags=23<UP,BROADCAST,NOTRAILERS>
        inet ClassC.Net.2.1 netmask ffffffc0 broadcast ClassC.Net.2.63
$ ifconfig wdn3
wdn3: flags=23<UP,BROADCAST,NOTRAILERS>
        inet ClassC.Net.3.1 netmask ffffffe0 broadcast ClassC.Net.3.31
$ 
script done on Mon May 17 10:04:33 1993

The only time I have seen such a configuration fail to work, is when
all the systems involved are not configured with the same broadcast
addresses.  ie. they all must use all 1's for the broadcast part, and
those addresses must match the host part of the address _after_ the
netmask is applied.  See the above for examples - the .31, .63, and
.127 are important.

---
#include <std/disclaimer>

Larry Philps,	 SCO Canada, Inc.
Postman:  130 Bloor St. West, 10th floor, Toronto, Ontario.  M5S 1N5
InterNet: larryp@sco.COM
UUCP:	  uunet!sco!larryp
Phone:	  (416) 922-1937

-----------[000227][next][prev][last][first]----------------------------------------------------
Date:      17 May 93 17:47:13 GMT
From:      ajm@wilson.fibercom.com (AJ Madison)
To:        comp.protocols.tcp-ip,comp.protocols.ppp
Subject:   Re: Fast modems and dialup SLIP/PPP

In article <BOB.93May13153250@volitans.MorningStar.Com>, bob@MorningStar.Com (Bob Sutterfield) writes:
> 
> Many of the questions in comp.protocols.ppp are from people using code
> that is largely unchanged from Drew Perkins' original proof-of-concept
> implementation, written four years ago while RFC 1134 was being ironed
> out by Drew and the other programmers/protocol designers (notably Russ
> Hobby), who were also working on their own independent
> proof-of-concept implementations.
> 
> I haven't looked at dp-2.3, but I suspect the guts of its PPP protocol
> engine haven't changed much since it was called "patchlevel 5", by
> which time its guts hadn't changed much since Drew's original 4.2BSD
> code.  Yes, more recent maintainers have done a lot of porting work
> and bug fixes, and they've apparently added modern VJ negotiations,
> but the guts are showing their age.  The IETF PPP Working Group
> (defines the protocol) and the PPP Consortium (industry group that
> conducts formal interoperability tests) have learned a *lot* since RFC
> 1134 was published, and RFC 1331 shows it.  Every finite-state-machine
> change, no matter how subtle, reflects that increase in the collective
> wisdom.
> 

Bob had gotten me to think that dp-2.3 may not be as up to date as I
thought.  I dug in and gave the source and the RFCs a good once over.
Here is the list of (non-)compliances that I came up with.  I make no
claim that this list is exhaustive (nor a comment on the quality of the
maintainers).  I say dp-2.3, but I'm really talking about the CMU PPP
"core."

RFC1331 Compliance:

(As Bob points out above) VJ Negotiation terminology has been upgraded
in dp-2.3.  Best I can tell, the functionality remains the same, but the
names have been changed.

RFC1332 Compliance:

dp-2.3 has made the IPCP Ip-Addresses option backwardly compatible and
now includes the Ip-Address option.  The former was deprecated in
RFC1332 and the latter an addition.

RFC1331 NON Compliance:

dp-2.3 includes passive and active Open States in the FSM.  Fortunately,
they're implemented as sub-states, and consolidation to RFC 1331's Open
state is almost trivial, albeit tedious.  (Bob Sutterfield pointed out
this problem some months ago).

dp-2.3's LCP does not successfully negotiate the usage of the
Authentication protocols.  This is actually an implementation defect
rather that lack of compliance.  I may have suggested earlier there are
flaws in the RFCs when I really was trying to vent my frustration with
the share-ware implementations.  The RFCs are fine.

dp-2.3's LCP includes and expects a callback field in the Authenticate
Option when requesting CHAP.  This field is not present in
RFC1331/RFC1334.  Anyone desiring to "tolerate" older versions of PPP
should be prepared to ignore this field.  LCP code has been set-up to
allow for options to be longer than they should be, which is a plus, so
defect removal should be easy.

dp-2.3's PPP does not protocol reject unrecognized protocols/channel
id's (for example LQM).  If it did this, the remote node (eg. MST PPP)
could adjust, adapt, and overcome (to paraphrase Clint Eastwood).
(Again a nod to Bob).

RFC1334 NON Compliance:

dp-2.3's CHAP expects a value-length field in incoming Success and
Failure Packets.  This field is not in evidence in RFC1334.  Interestingly
enough, dp-2.3 does not format these packets with these fields, which
makes this feature not only non-compliant, but a defect as well.

dp-2.3's CHAP through no fault of its own, can be configured to be
unable to reach the Opened state upon reception of a good Response
Packet.  Not really a non-compliance issue; included for completeness.

dp-2.3 PPP makes no attempt to "prefer" CHAP over UPAP as has been
strongly recommended in RFC1334.  Further, dp-2.3 can be configured to
use both protocols simultaneously, which is also strongly discouraged in
the RFC.
-- 
A.J. Madison                       PHONE: (703) 342-6700 X383
FiberCom, Inc.                       FAX: (703) 342-5961
P.O. Box 11966                  INTERNET: ajm@fibercom.com
Roanoke, VA  24022-1966             UUCP: ...!uunet!fibercom!ajm

-----------[000228][next][prev][last][first]----------------------------------------------------
Date:      Mon, 17 May 1993 17:57:55 GMT
From:      wmasson@cbnewsj.cb.att.com (bill.masson)
To:        comp.protocols.tcp-ip
Subject:   shared sockets


The book "Internetworking with TCP/IP Volume III" by Douglas Comer &
David Stevens describes a concept of shared sockets, whereby a master
server creates a socket and then spawns several slave process's which
each inherit this socket and hang an accept off of it waiting for
connections. They go on to say that the UNIX implementation provides
mutual exclusion for multiple processs that all atempt to accept 
connections from the same socket. My question is, does this hold true
for multiprocessor systems. Are semafors needed to guarantee the mutal
exclusion? Does this paradigm make sense in a multiprocessor environment?


-----------[000229][next][prev][last][first]----------------------------------------------------
Date:      Mon, 17 May 1993 18:09:42 GMT
From:      wmasson@cbnewsj.cb.att.com (bill.masson)
To:        comp.protocols.tcp-ip
Subject:   max tcp connections


What is the maximum number of concurrent TCP connections on a Sparc 10
running Solaris 2.x and is there a kernel tunable that must be set to
realize this max? Ive found documentation for AT&T's SVR4/386 stating
that the kernel variable NDEV_TCP can be set to a minimum of 10
and a max of 1024, but can not find anything in the Solaris Documentation.
Also what kind of memory do I need to support the maximum configuration?

				Thanks.


-----------[000230][next][prev][last][first]----------------------------------------------------
Date:      Mon, 17 May 1993 19:23:00 GMT
From:      tim@spctrm.UUCP (Tim Fry)
To:        comp.protocols.tcp-ip,comp.unix.misc,comp.unix.programmer
Subject:   TLI/TCP data transfer question

Does anyone know how to determine if a *non-blocking* TCP based TLI 
connection between two processes is able to handle a known number 
of bytes *before* a t_snd() call is issued?

Unfortunately the t_snd() call does not return the number of bytes written
if the send was flow-controlled - it simply fails and returns -1, setting
t_errno to TFLOW. I assumed(wrongly) that if I tried to send 5000 bytes from 
A to B and B was in some wait state, then the above TLI generated 
flow-control condition implied that the t_snd() did not send *any* of
the 5000 bytes. It seems however, that partial data is sent even though
the call fails. This tends to screw-up my protocol somewhat as I am 
left with fragmented messages queued up for the receiving process.

This is on Interactive 3.2 2 and sending between two processes 
on the same machine. 

Thanks 

Tim


-----------[000231][next][prev][last][first]----------------------------------------------------
Date:      Tue, 18 May 1993 00:03:06 GMT
From:      royc@rbdc.wsnc.org (Roy Crabtree)
To:        comp.unix.questions,comp.protocols.tcpip
Subject:   WANTED: SVR4/SVR3 RFS on TCP/IP (NCR to ESIX)


ESIX 5.3.2D (Everex UNIX) to/from AT&T/NCR 4.0 3.0:

	What are the appropriate addreses to get RFS running?

	ESIX uses rss.serve/rss in its rfmaster files

	NCR uses \x00020aceTCPIPHEX for its.


	I can get remsh, rcp, and telnet to function, BUT

	rlogin fails ('rcmd failed') and RFS does not
	see each other.

	Do I need to reenable the listener at \00020401 on 4.0 side?

Email me solutions and I will post the result.

Thanx!

roy andrew crabtree

-----------[000232][next][prev][last][first]----------------------------------------------------
Date:      18 May 1993 14:29:41 -0400
From:      bb31351@bingsunb.cc.binghamton.edu (Rakesh Shetty)
To:        comp.protocols.tcp-ip
Subject:   PING source code !!!!!!!!


Hello,

I am looking for the source code of ping (packet internet groper - BSD).
Any info on where I could ftp it from would be a great help.

Thanx,
Rakesh 


-----------[000233][next][prev][last][first]----------------------------------------------------
Date:      18 May 93 12:01:03 GMT
From:      J.Crowcroft@cs.ucl.ac.uk (Jon Crowcroft)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP calculation



 >>receiver has a limit of 8196 bytes, the two are connected via a 
 >>1544000bps (t-1) link, for what distances are the window sizes a
 >>bottleneck, and for what distances is the link a bottleneck?

below threshold, link speed throttles, above it, window does.

 >>(Express the distance in microseconds.)  If the speed of light 
 >>is 3 times 10 to the 8th meters/second, how long is the cable at
 >>the threshold?

Threshold bps = limiting-W/threshold-rtt = 1544000 for T1

Assumptions
1. ignoring processing:
2. assume T1 is copper/coax therefore
2/3 c signal propogation speed)

rtt = cablelength/2*10**8 	(dimensionally trivial - 

i.e.
threshold-rtt = limiting-W/1544000 = cablelength/2*10**8

i.e. for rx window 8k bytes, you have
trtt=414 msecs
or 1 way 200 msecs approx

cablelength is around (200 * 10**-3 * 2 * 10**8) meters, or 
40000 kilometers (like near geostationary satellite)

i could be out by a factor of x, where x is left as an e?ercise for
the reader...

 >What is the airspeed velocity of an unladen swallow?
 
720 cleese's per nano-palin

but what's your name?  

 jon


-----------[000234][next][prev][last][first]----------------------------------------------------
Date:      18 May 93 15:18:36 GMT
From:      rturner@imagen.com (Randy Turner)
To:        comp.protocols.tcp-ip
Subject:   PD TCP/IP (~NCSA)


	Is there a public domain TCP/IP package that is relatively
	stable that was designed for a multitasking OS. I have looked
	at the NCSA code and found it to be too monolithic, since I
	plan on running the system in a multitasking environment.
	I have heard about the CMU package. Is it geared towards a
	multi-task model? Or is there some other TCP/IP stack implementation
	out there that is?

	Thanx in advance!
			Randy

-- 
-----------------------------------------------------------------------------
Randy Turner
QMS, Inc.
rturner@aqm.com

-----------[000235][next][prev][last][first]----------------------------------------------------
Date:      Tue, 18 May 1993 16:47:18 GMT
From:      Benoit Grange <Benoit_Grange@gateway.qm.apple.com>
To:        comp.unix.wizards,comp.protocols.tcp-ip
Subject:   HELP: Need to implement rarp on SysV.4

How can I implement a rarp daemon that would answer to rarp queries ?
Where can I read rarp paquets arriving to my machine ? And send responses
?

My system is a Consensys (or Unixware) SysV.4.
----
Benoit Grange

-----------[000236][next][prev][last][first]----------------------------------------------------
Date:      18 May 93 17:03:45 GMT
From:      garry@ceco.ceco.com (Garry J. Garrett)
To:        comp.protocols.tcp-ip
Subject:   Help me fix my EBCDIC-ASCII translate table for FTP

I have found that when I ftp something from our mainframe to my
sun and then ftp it back to the mainframe, I don't get the same
file (dataset) back on the mainframe.  What I have found is that
our translate for EBCDIC & ASCII tables don't have a 1:1 mapping.
Originally the ASCII-to-EBCDIC table was ignoring the parity bit
but the EBCDIC-to-ASCII table was translating some of it's characters
into 8 bit IBM PC ascii.  I have fixed most of the table by altering
the ASCII-to-EBCDIC chart so that if EBCDIC character Y is translated
into ASCII character Y, then character Y on the ASCII-to-EBCDIC chart
translates Y back into X.  Now I am down to a handful of EBCDIC control
characters that have no equivalent in ASCII.  Presently, they all map
to 1A in ASCII.  Only 3F EBCDIC should map to 1A ASCII.  Also EBCIDIC
15, 1C, and 1E all map to ASCII characters that don't map back into
that same character in the ASCII-to-EBCDIC chart.

My background is in Suns & PCs.  I am not familiar enough with these
control characters to make a maping that makes sense.  (I am down
to eenie-meenie-minie-moe.)  All I want is a 1:1 maping so that
if I send a file back & forth nothing gets lost in the translation.
I would like to have a little more confidence in my conversion charts
than I do with the eenie-meenie-minie-moe method.

What would I like from you?  Do you have a chart that you are willing
to share with me (that has a 1:1 corresponance, i.e. each character
on the chart maps to one and only one character on the other chart,
and that character maps back to the one you started with.)?  Or do
you have any suggestions as to how I should modify my chart to get
a 1:1 maping?  I would perfer e-mail as I don't frequent this newsgroup.

Garry Garrett
garry@ceco.ceco.com



My chart after I fixed the 8 bit ascii thing:
----------------------------------------------
;                                                                               
; ASCII-to-EBCDIC table                                                         
; x0 x1 x2 x3 x4 x5 x6 x7 x8 x9 xA xB xC xD xE xF                               
;                                                                               
  00 01 02 03 37 2D 2E 2F 16 05 25 0B 0C 0D 0E 0F    ; 0x ;                     
  10 11 12 13 3C 3D 32 26 18 19 3F 27 22 1D 35 1F    ; 1x ;                     
  40 5A 7F 7B 5B 6C 50 7D 4D 5D 5C 4E 6B 60 4B 61    ; 2x ;                     
  F0 F1 F2 F3 F4 F5 F6 F7 F8 F9 7A 5E 4C 7E 6E 6F    ; 3x ;                     
  7C C1 C2 C3 C4 C5 C6 C7 C8 C9 D1 D2 D3 D4 D5 D6    ; 4x ;                     
  D7 D8 D9 E2 E3 E4 E5 E6 E7 E8 E9 AD E0 BD 5F 6D    ; 5x ;                     
  79 81 82 83 84 85 86 87 88 89 91 92 93 94 95 96    ; 6x ;                     
  97 98 99 A2 A3 A4 A5 A6 A7 A8 A9 C0 4F D0 A1 07    ; 7x ;                     
  43 01 02 03 37 EB 2E 9B 71 05 25 49 90 BA EC DF    ; 8x ;                     
  45 11 12 9D 72 3D 8A 9A 67 56 64 4A 53 68 59 46    ; 9x ;                     
  EA DA 7F DE 8B 55 41 FE 58 51 52 48 69 DB 8E 8D    ; Ax ;                     
  73 74 75 FA F4 B0 B1 B3 B4 B5 6A B7 B8 B9 CC BC    ; Bx ;                     
  AB C1 C2 C3 BF 8F C6 C7 A0 C9 CB CA D3 D4 9C D6    ; Cx ;                     
  D7 EF D9 E2 E3 E4 77 70 BE BB AC 54 63 65 66 62    ; Dx ;                     
  79 42 47 57 EE 85 B6 E1 CD ED 91 44 CE CF 95 AA    ; Ex ;                     
  FC 9E AE 8C DD DC A5 FB 80 AF FD 78 76 B2 9F FF    ; Fx ;                     
;                                                                               
; EBCDIC-to-ASCII table                                                         
; x0 x1 x2 x3 x4 x5 x6 x7 x8 x9 xA xB xC xD xE xF                               
;                                                                               
  00 01 02 03 1A 09 1A 7F 1A 1A 1A 0B 0C 0D 0E 0F    ; 0x ;                     
  10 11 12 13 1A 0A 08 1A 18 19 1A 1A 1C 1D 1E 1F    ; 1x ;                     
  1A 1A 1C 1A 1A 0A 17 1B 1A 1A 1A 1A 1A 05 06 07    ; 2x ;                     
  1A 1A 16 1A 1A 1E 1A 04 1A 1A 1A 1A 14 15 1A 1A    ; 3x ;                     
  20 A6 E1 80 EB 90 9F E2 AB 8B 9B 2E 3C 28 2B 7C    ; 4x ;                     
  26 A9 AA 9C DB A5 99 E3 A8 9E 21 24 2A 29 3B 5E    ; 5x ;                     
  2D 2F DF DC 9A DD DE 98 9D AC BA 2C 25 5F 3E 3F    ; 6x ;                     
  D7 88 94 B0 B1 B2 FC D6 FB 60 3A 23 40 27 3D 22    ; 7x ;                     
  F8 61 62 63 64 65 66 67 68 69 96 A4 F3 AF AE C5    ; 8x ;                     
  8C 6A 6B 6C 6D 6E 6F 70 71 72 97 87 CE 93 F1 FE    ; 9x ;                     
  C8 7E 73 74 75 76 77 78 79 7A EF C0 DA 5B F2 F9    ; Ax ;                     
  B5 B6 FD B7 B8 B9 E6 BB BC BD 8D D9 BF 5D D8 C4    ; Bx ;                     
  7B 41 42 43 44 45 46 47 48 49 CB CA BE E8 EC ED    ; Cx ;                     
  7D 4A 4B 4C 4D 4E 4F 50 51 52 A1 AD F5 F4 A3 8F    ; Dx ;                     
  5C E7 53 54 55 56 57 58 59 5A A0 85 8E E9 E4 D1    ; Ex ;                     
  30 31 32 33 34 35 36 37 38 39 B3 F7 F0 FA A7 FF    ; Fx ;                     


My chart before I fixed the 8 bit ASCII thing:
(note how the 2nd 1/2 of the ascii chart looks
amazingly like the first 1/2)
-----------------------------------------------

;                                                                               
; ASCII-to-EBCDIC table                                                         
; x0 x1 x2 x3 x4 x5 x6 x7 x8 x9 xA xB xC xD xE xF                               
;                                                                               
  00 01 02 03 37 2D 2E 2F 16 05 25 0B 0C 0D 0E 0F    ; 0x ;                     
  10 11 12 13 3C 3D 32 26 18 19 3F 27 22 1D 35 1F    ; 1x ;                     
  40 5A 7F 7B 5B 6C 50 7D 4D 5D 5C 4E 6B 60 4B 61    ; 2x ;                     
  F0 F1 F2 F3 F4 F5 F6 F7 F8 F9 7A 5E 4C 7E 6E 6F    ; 3x ;                     
  7C C1 C2 C3 C4 C5 C6 C7 C8 C9 D1 D2 D3 D4 D5 D6    ; 4x ;                     
  D7 D8 D9 E2 E3 E4 E5 E6 E7 E8 E9 AD E0 BD 5F 6D    ; 5x ;                     
  79 81 82 83 84 85 86 87 88 89 91 92 93 94 95 96    ; 6x ;                     
  97 98 99 A2 A3 A4 A5 A6 A7 A8 A9 C0 4F D0 A1 07    ; 7x ;                     
  00 01 02 03 37 2D 2E 2F 16 05 25 0B 0C 0D 0E 0F    ; 8x ;                     
  10 11 12 13 3C 3D 32 26 18 19 3F 27 22 1D 35 1F    ; 9x ;                     
  40 5A 7F 7B 5B 6C 50 7D 4D 5D 5C 4E 6B 60 4B 61    ; Ax ;                     
  F0 F1 F2 F3 F4 F5 F6 F7 F8 F9 7A 5E 4C 7E 6E 6F    ; Bx ;                     
  7C C1 C2 C3 C4 C5 C6 C7 C8 C9 D1 D2 D3 D4 D5 D6    ; Cx ;                     
  D7 D8 D9 E2 E3 E4 E5 E6 E7 E8 E9 AD E0 BD 5F 6D    ; Dx ;                     
  79 81 82 83 84 85 86 87 88 89 91 92 93 94 95 96    ; Ex ;                     
  97 98 99 A2 A3 A4 A5 A6 A7 A8 A9 C0 4F D0 A1 07    ; Fx ;                     
;                                                                               
; EBCDIC-to-ASCII table                                                         
; x0 x1 x2 x3 x4 x5 x6 x7 x8 x9 xA xB xC xD xE xF                               
;                                                                               
  00 01 02 03 1A 09 1A 7F 1A 1A 1A 0B 0C 0D 0E 0F    ; 0x ;                     
  10 11 12 13 1A 0A 08 1A 18 19 1A 1A 1C 1D 1E 1F    ; 1x ;                     
  1A 1A 1C 1A 1A 0A 17 1B 1A 1A 1A 1A 1A 05 06 07    ; 2x ;                     
  1A 1A 16 1A 1A 1E 1A 04 1A 1A 1A 1A 14 15 1A 1A    ; 3x ;                     
  20 A6 E1 80 EB 90 9F E2 AB 8B 9B 2E 3C 28 2B 7C    ; 4x ;                     
  26 A9 AA 9C DB A5 99 E3 A8 9E 21 24 2A 29 3B 5E    ; 5x ;                     
  2D 2F DF DC 9A DD DE 98 9D AC BA 2C 25 5F 3E 3F    ; 6x ;                     
  D7 88 94 B0 B1 B2 FC D6 FB 60 3A 23 40 27 3D 22    ; 7x ;                     
  F8 61 62 63 64 65 66 67 68 69 96 A4 F3 AF AE C5    ; 8x ;                     
  8C 6A 6B 6C 6D 6E 6F 70 71 72 97 87 CE 93 F1 FE    ; 9x ;                     
  C8 7E 73 74 75 76 77 78 79 7A EF C0 DA 5B F2 F9    ; Ax ;                     
  B5 B6 FD B7 B8 B9 E6 BB BC BD 8D D9 BF 5D D8 C4    ; Bx ;                     
  7B 41 42 43 44 45 46 47 48 49 CB CA BE E8 EC ED    ; Cx ;                     
  7D 4A 4B 4C 4D 4E 4F 50 51 52 A1 AD F5 F4 A3 8F    ; Dx ;                     
  5C E7 53 54 55 56 57 58 59 5A A0 85 8E E9 E4 D1    ; Ex ;                     
  30 31 32 33 34 35 36 37 38 39 B3 F7 F0 FA A7 FF    ; Fx ;                     

-- 
# Garry Garrett, P&EIS		# (Me?  Speak for CECo?  I get into enough
# Commonwealth Edison Co.	#    trouble speaking for myself!) 
# P.O. Box 767, 1600 Edison	# UUCP: ...!uunet!ceco.ceco.com!garry
# Chicago, IL 60690-0767	# Internet: garry@ceco.ceco.com

-----------[000237][next][prev][last][first]----------------------------------------------------
Date:      18 May 93 18:07:13 GMT
From:      lars@spectrum.CMC.COM (Lars Poulsen)
To:        comp.protocols.tcp-ip
Subject:   Re: RFC's Etc (was Rlogin specs, now where are dey?)

In article <1tb2roINNgkk@flash.pax.tpa.com.au>
   hart@flash.pax.tpa.com.au (Leigh M Hart) writes:
>Some peole have posted saying the RFCs aren't necessarily a good guideline
>for implementing [rlogin etc], if they aren't then what is?  should we
>have to read original code to implement the protocol in our own applications?
> ...
>Now I simply ask - is the RFC for the rlogin protocol (RFC1282) correct?  or
>am I wasting my time implementing the protocol based on the RFC?  does the
>same go for the telnet protocol specification and telnet option specification
>RFCs?

The Internet perspective is that there is no point in implementing a
protocol if it does not work. Arguing about whether the paper
specification is more correct than the many currently running
implementations is pointless.

This applies in particular, when - as in the case of rlogin - the
protocol was not developed through the standards process, but was
a useful non-standard hack implemented by someone and then widely
distributed. RFC1282 reflects a reverse-engineering effort and it is
very nearly correct.

TELNET, on the other hand, is a standard protocol, and the specification
is authoritative.
-- 
/ 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

-----------[000238][next][prev][last][first]----------------------------------------------------
Date:      Tue, 18 May 1993 18:51:28 GMT
From:      imp@boulder.parcplace.com (Warner Losh)
To:        comp.protocols.tcp-ip
Subject:   Re: RFC's Etc (was Rlogin specs, now where are dey?)

In article <1tb2roINNgkk@flash.pax.tpa.com.au> hart@flash.pax.tpa.com.au (Leigh M Hart) writes:
>Some peole have posted saying the RFCs aren't necessarily a good guideline
>for implementing these protocols, if they aren't then what is?  should we
>have to read original code to implement the protocol in our own applications?

rlogin is a fairly new RFC, so it is bound to have some problems.  FTP
and SMTP RFC's aren't quite right either.  They have been updated over
time.  They are very old RFC's, while rlogin is much newer and the
stuff that isn't quite right in these Request For Comments hasn't been
commented on.

The RFCs are a good place to start, but there are implementations out
there that, for whatever reason, don't conform 100% to the RFCs.  Your
best bet is to do interop testing once you have your base
implementation done.  Anything less, even in a fully specified
protocol, would not be wise.

Warner
-- 
Warner Losh		imp@boulder.parcplace.COM	ParcPlace Boulder
I've almost finished my brute force solution to subtlety.

-----------[000239][next][prev][last][first]----------------------------------------------------
Date:      Tue, 18 May 1993 19:18:58 GMT
From:      tomiii@mtu.edu (Thomas Dwyer III)
To:        comp.protocols.tcp-ip
Subject:   Re: Specs on rlogin? now where are dey?

Vernon Schryver (vjs@rhyolite.wpd.sgi.com) wrote:
>The rlogin and RIP RFC's were written a decade or more after the code
>that implemented and defined the protocols, and not by the authors of
>the implementations that defined the protocols.

Could someone please point out the major differences between the rlogin
RFC and the reality of its implementation?


Thanks,
Tom.III

-----------[000240][next][prev][last][first]----------------------------------------------------
Date:      Tue, 18 May 93 23:01:34 GMT
From:      thsssxs@iitmax.iit.edu (Semir Sirazi)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject:   Wanted: TFTP Source for Windows



Hello there,

	I am looking for source code for the TFTP protocol (client side only).
	What I am intending on doing is to port the TFTP stack to Windows 3.1
	running over the Novell LAN WorkPlace TCP/IP Stack, (Berkley Sockets).
	If anyone knows of source code that might get me close to what I am
	trying to do, I would greatly appreciate hearing from you.

	Please E-mail me directly at keithz@usr.com.

		Thank you,

			Keith Zimmerman
			keithz@usr.com
			U.S. Robotics

-----------[000241][next][prev][last][first]----------------------------------------------------
Date:      Tue, 18 May 1993 23:48:14 GMT
From:      vjs@rhyolite.wpd.sgi.com (Vernon Schryver)
To:        comp.protocols.tcp-ip
Subject:   Re: RFC's Etc (was Rlogin specs, now where are dey?)

In article <1tb2roINNgkk@flash.pax.tpa.com.au>, hart@flash.pax.tpa.com.au (Leigh M Hart) writes:
> ...
> Some peole have posted saying the RFCs aren't necessarily a good guideline
> for implementing these protocols, if they aren't then what is?  should we
> have to read original code to implement the protocol in our own applications?

I don't know of an errors in the rlogin RFC, but I wouldn't consider
hiring anyone who wouldn't or couldn't check the rlogin source before
implementing it.

>Not only does that breach copyright (in terms of continuancy) in some countries
> but it's a pain.  

In what way does the BSD copyright restrict you?  You can do anything
you please with the BSD source, provided only you don't blame them, and
you include the copyright message somewhere.  In which countries have
any of the many vendors selling BSD derived products, including rlogin,
had any problems?  For pity's sake, notice who is my employer!  Silicon
Graphics has had problems with RIP, but only because of U.S. export
restrictions, and certainly not because of the BSD copyright.

Why unthinkingly invent something different, inevitably with differen
bugs and features, when the Real McCoy, Genuine Article is free for the
using?


> Now I simply ask - is the RFC for the rlogin protocol (RFC1282) correct?  or
> am I wasting my time implementing the protocol based on the RFC?  does the
> same go for the telnet protocol specification and telnet option specification
> RFCs?

The rlogin and RIP protocols existed for many years in freely available
code before people decided to write reasonably good but not authoritative
RFC's about them.  ... oh, whatever...  consider my previous diatribe
against egregiously slavish Standard Committee-ism repeated. 

If nothing else, read the first paragraph on both versions of the rlogin
RFC to see that the RFC "does not specifiy an Internet standard."


Telnet was and is different.  The RFC's defining Telnet did not come
long after the implementations.  There were many different early
implementations of telnet, while there has long been only a single
implementation of rlogin, albeit that rlogin implementation has
appeared in a myriad of guises.


> There must be *some* semblence of consistency in these documents!   If people
> implementing these protocols don't follow the RFCs that have been designated
> as the "standard" then where will we end up?  about 20 years behind thats 
> where - as far as I can see, the push towards "open systems" is really
> hotting up at the moment, and it can't succeed without people adhering to
> standards that are set up - regardless of which "Standards Organisation (tm)"
> defines them.

That's almost my rant, except you are being picky about the language of
the standard and the Royal Patent of the standards writers.  Code is a
perfectly fine language for standards.  After all, the best (well,
whatever) products of CCITT or ANSI are filled with "psuedo-code" and
"state machine descriptions."  The usual way to write from such
standards is to mentally compile from their language into your current
favorite.

The authoritative description of the rlogin standard is the BSD source.
If you don't want to compile, use and ship binaries from that standard
then don't.  That your C compiler won't accept the stuff in an OSI
document, or even any of the contents of most (but not all) RFC's does
not keep you from paying homage to them.

You're not going to be able respond to your `push towards "open systems"'
unless you're able to be rational about the standards and standards
organizations you accept.


Vernon Schryver,  vjs@sgi.com

-----------[000242][next][prev][last][first]----------------------------------------------------
Date:      Tue, 18 May 1993 23:49:28 GMT
From:      vjs@rhyolite.wpd.sgi.com (Vernon Schryver)
To:        comp.protocols.tcp-ip
Subject:   Re: PING source code !!!!!!!!

In article <1tb9ul$23m@bingsunb.cc.binghamton.edu>, bb31351@bingsunb.cc.binghamton.edu (Rakesh Shetty) writes:
> 
> I am looking for the source code of ping (packet internet groper - BSD).
> Any info on where I could ftp it from would be a great help.



Check uunet.  someplace like .../usr.etc/ping.c

Check brl.mil.



Vernon Schryver,  vjs@sgi.com

-----------[000243][next][prev][last][first]----------------------------------------------------
Date:      Tue, 18 May 1993 23:57:06 GMT
From:      vjs@rhyolite.wpd.sgi.com (Vernon Schryver)
To:        comp.protocols.tcp-ip
Subject:   Re: Specs on rlogin? now where are dey?

In article <1993May18.191858.14617@mtu.edu>, tomiii@mtu.edu (Thomas Dwyer III) writes:
> Vernon Schryver (vjs@rhyolite.wpd.sgi.com) wrote:
> >The rlogin and RIP RFC's were written a decade or more after the code
> >that implemented and defined the protocols, and not by the authors of
> >the implementations that defined the protocols.
> 
> Could someone please point out the major differences between the rlogin
> RFC and the reality of its implementation?


I've recently quickly skimmed the rlogin RFC.  I've seen no difference.

Still, would you hire someone who would not or could not or did not
check the real, authoritative standard, the source at the start and end
of such a project?
When there is no restriction on doing so?
When you can buy the source on CDROM for a few dollars?
When you can have the source delivered by email to you just about as easily
and for little more money than the RFC?  (uunet's email service)


Eventually I suppose the transformation of the Internet standards
and sub-culture into something identical to ANSI/CCITT/OSI/IEEE/whatever
is inevitable, where form matters and politics and content is at often
no more than an inconvenient detail.  I hope I'm gone by then.


Vernon Schryver,  vjs@sgi.com

-----------[000244][next][prev][last][first]----------------------------------------------------
Date:      Wed, 19 May 1993 02:22:17 GMT
From:      ray@exicom.OZ.AU (Ray Soo)
To:        comp.protocols.tcp-ip
Subject:   problem with dialup SLIP interfaces?

we are a leaf site with dialup SLIP access to a university campus network
(we use the slipware.tar.Z package from Toronto University on a Sparc 2 running
SunOS 4.1.2).

The university end of the connection
has more than one slip interface and each slip
interface there is associated with a particlular IP route. I don't
have the complete details but as I
understand the problem from our network contact at the university, the
problem for us is that if more than one slip interface is down
(off-line) at any one time, the slip interfaces have to come
up in a particular order (e.g. if our route were associated
with slip0, then we would have to come back up first, or else
we'll get allocated slip1 which is associated with the wrong route).

So occasionally when the university dials us back and 
the slip interface comes back up , we find the routing
to the outside world is incorrect.

I can't see anything in the slipware package that can 
hardwire a particular slip interface to a particular IP address.

How do we solve this problem? If you have answers, please EMAIL

	ray@exicom.OZ.AU

thanks in advance,

ray

-----------[000245][next][prev][last][first]----------------------------------------------------
Date:      Wed, 19 May 1993 06:24:27 GMT
From:      skl@wimsey.bc.ca (Samuel Lam)
To:        comp.protocols.tcp-ip
Subject:   Re: Help me fix my EBCDIC-ASCII translate table for FTP

In article <900@ceco.ceco.com>, garry@ceco.ceco.com (Garry J. Garrett) wrote:
>What would I like from you?  Do you have a chart that you are willing
>to share with me (that has a 1:1 corresponance, i.e. each character
>on the chart maps to one and only one character on the other chart,
>and that character maps back to the one you started with.)?

The following should do it.  It's the "MTS T-Day chart".  Much efforts
and sweat had gone into it.

+display ascebc@type=xl256
+ascebc@type=xl256  X'
+        00010203 372D2E2F 1605250B 0C0D0E0F 10111213 3C3D3226 18193F27 
+        1C1D1E1F 405A7F7B 5B6C507D 4D5D5C4E 6B604B61 F0F1F2F3 F4F5F6F7 
+        F8F97A5E 4C7E6E6F 7CC1C2C3 C4C5C6C7 C8C9D1D2 D3D4D5D6 D7D8D9E2 
+        E3E4E5E6 E7E8E9BA E0BBB06D 79818283 84858687 88899192 93949596 
+        979899A2 A3A4A5A6 A7A8A9C0 4FD0A107 20212223 24150617 28292A2B 
+        2C090A1B 30311A33 34353608 38393A3B 04143EFF 41AA4AB1 9FB26AB5 
+        BDB49A8A 5FCAAFBC 908FEAFA BEA0B6B3 9DDA9B8B B7B8B9AB 64656266 
+        63679E68 74717273 78757677 AC69EDEE EBEFECBF 80FDFEFB FCADAE59 
+        44454246 43479C48 54515253 58555657 8C49CDCE CBCFCCE1 70DDDEDB 
+        DC8D8EDF'
+display ebcasc@type=xl256
+ebcasc@type=xl256  X'
+        00010203 9C09867F 978D8E0B 0C0D0E0F 10111213 9D850887 1819928F 
+        1C1D1E1F 80818283 840A171B 88898A8B 8C050607 90911693 94959604 
+        98999A9B 14159E1A 20A0E2E4 E0E1E3E5 E7F1A22E 3C282B7C 26E9EAEB 
+        E8EDEEEF ECDF2124 2A293BAC 2D2FC2C4 C0C1C3C5 C7D1A62C 255F3E3F 
+        F8C9CACB C8CDCECF CC603A23 40273D22 D8616263 64656667 6869ABBB 
+        F0FDFEB1 B06A6B6C 6D6E6F70 7172AABA E6B8C6A4 B57E7374 75767778 
+        797AA1BF D0DDDEAE 5EA3A5B7 A9A7B6BC BDBE5B5D AFA8B4D7 7B414243 
+        44454647 4849ADF4 F6F2F3F5 7D4A4B4C 4D4E4F50 5152B9FB FCF9FAFF 
+        5CF75354 55565758 595AB2D4 D6D2D3D5 30313233 34353637 3839B3DB 
+        DCD9DA9F'

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

"NetNews on CD's" product information: <NewsCD@CDPublishing.COM>


-----------[000246][next][prev][last][first]----------------------------------------------------
Date:      Wed, 19 May 1993 09:47:43 +0000
From:      akcs@semagl.demon.co.uk (Alistair Scott)
To:        comp.protocols.tcp-ip,comp.unix.solaris,comp.unix.sys5.r4,comp.protocols.misc
Subject:   Reliable multi-cast comms - please help

We are interseted in any products which sit on-top of
SVR4 UNIX (e.g. SunOS 5.1) which can provide a reliable 
LAN based multi-cast messaging service, with flow-control. 

We would like to use this from within a multi-threaded
language (Ada in particular).

Does anyone have experience or know of any such products
or packages?

Please email any replies to:
      
      akcs@semagl.co.uk
and   mnb@baesema.demon.co.uk

Many thanks in advance for you help.
-- 
Alistair Scott, BAeSEMA Ltd.

-----------[000247][next][prev][last][first]----------------------------------------------------
Date:      Wed, 19 May 1993 10:04:26 GMT
From:      nirad@ceu.uq.oz.au (Nirad Sharma)
To:        comp.protocols.tcp-ip,comp.protocols.snmp
Subject:   Commercial PC-Route with SNMP support ?

We've been using the internet-available version of PC-Route for a while now
and are very happy with it.  What I'm after is a version of PC-Route that has
SNMP support - I suspect that there isn't a free version of such a beast but
does it's commercial incarnation offer such support ?  Who do I contact ?
--
Nirad Sharma  (nirad@ceu.uq.oz.au)			Phone : (+61 7) 365 7575
Continuing Education Unit				Fax :	(+61 7) 365 7099
The University of Queensland.  QLD  4072.  AUSTRALIA

-----------[000248][next][prev][last][first]----------------------------------------------------
Date:      Wed, 19 May 1993 12:51:49 GMT
From:      artman@vpnet.chi.il.us (Wilfred A Artman)
To:        comp.unix.admin,comp.sys.sun.admin,comp.protocols.tcp-ip
Subject:   WAN Vendor Info

We are planning the installation of a wide area network in the near
future (2-3 months) and have contacted various vendors concerning
there respective hardware.

I would like to have any input from admin's who have dealt with, or
have knowledge of the following equipment in a networking environment
that includes the implementation of NIS.

1) 3-Com Boundry Routing
2) Vitalink Bridges
3) ACC Remote Bridge/Router & Central Site Bridge/Router

We are running Solbournes at the remote sites and a mix of Solbournes
and Vaxen at the local (host) site. We would like to manage the admin
files using NIS but have heard through the trade journals that this
operation may not work well across a bridged environment.

Any information, including any "oh hecks..." will be greatly appreciated!

Please respnd via e-mail and I will consolidate and post any results.

Thanks!

===========================================================================
Wil Artman                            Email: artman@vpnet.chi.il.us
Senior System Administrator           Voice: (708) 505-0066
Millward Brown, Inc.                  Fax:   (709) 505-0077
Naperville, IL



-----------[000249][next][prev][last][first]----------------------------------------------------
Date:      Wed, 19 May 1993 16:30:07 GMT
From:      craig@sics.se (Craig Partridge)
To:        comp.protocols.tcp-ip
Subject:   re: Info on high-speed transport protocols requested

>We have looked at using TCP, but its maximum transmission speed using a Sparc
>over Ethernet is not fast enough for us. Also TCP is stream-oriented. TP4 is message-
>oriented, but for the same hardware configuration, it is slower than TCP. We
>cannot use XTP, because we need to have IP compatibility.
 
Please note that this is a limitation of the Sparc TCP/IP and TP4
implementations you have.
 
> Are there any transport protocols that have been implemented to take advantage of
> the much higher data rates achievable with FDDI? One that we know of is the
> Versatile Message Transaction Protocol, or VMTP designed at Stanford University,
> but are there any commercial implementations of this?
 
It is very important to distinguish between what the *protocol* can do and
what the *implementation* one has actually achieves.  There exist research
Sparc TCP/IP implementations that achieve a large fraction of the FDDI
bandwidth.  (I think the latest ones fill the FDDI).  In addition,
some vendors, like Silicon Graphics distribute TCP/IP with their products
that achieves 100 Mb/s.
 
I suspect the experimental VMTP implementations are slower than the best
TCP/IP implementations.

Craig Partridge
craig@bbn.com

-----------[000250][next][prev][last][first]----------------------------------------------------
Date:      Wed, 19 May 1993 16:48:44 GMT
From:      vjs@rhyolite.wpd.sgi.com (Vernon Schryver)
To:        comp.protocols.tcp-ip
Subject:   Re: Info on high-speed transport protocols requested

In article <2025@alcbel.be>, sp_ppm@space.alcbel.be (Paul Moore) writes:
> ...
> We have looked at using TCP, but its maximum transmission speed using a Sparc 
> over Ethernet is not fast enough for us. Also TCP is stream-oriented.
> TP4 is message-
> oriented, but for the same hardware configuration, it is slower than TCP. We 
> cannot use XTP, because we need to have IP compatibility.

That limits your choices to among TCP/IP, UDP/IP, and some kind of
raw or non-standard IP.

> So we are looking for other transport protocols that might be available, and
> preferably implemented on dedicated hardware, such as for the VME bus.
> 
> Are there any transport protocols that have been implemented to take
> advantage of
> the much higher data rates achievable with FDDI? One that we know of is the
> Versatile Message Transaction Protocol, or VMTP designed at Stanford
> University,
> but are there any commercial implementations of this? 
> ...


Hmmmph.

This common question is just another form of the ancient and equally
wrong "what kind of protocol should I use instead of TCP/IP because my
ethernet machines can do only 0.8Mbit/sec".
Remember when a VAX-750 was respectable?
Remember when Van Jacobson astounded the world by running TCP/IP
at Ethernet speed?

Some commercial TCP/IP/FDDI implementations do "take advantage of the
much higher data rates achievable with FDDI":

    - A pair of Silicon Graphics R4000 Indigos run at "light speed"
	over a single TCP/IP virtual circuit as measured by `ttcp`.
	Light speed for TCP over FDDI with 4K packets and tokens
	every 40-100KBytes is about 98Mbit/sec.  We showed that
	at Interop92.  "Light speed" means the token rotation time
	is as high as you want to push it.

    - at Interop92 I saw a pair of boxes in the DEC booth doing 95Mbit
	sec through TCP/IP.  I have reason to believe they were Alpha's.

    - HP has publically said they can do 80Mbit/sec with some model 
	of system and a new FDDI card.

This ignores the Gbit/sec rates reported by Cray over HIPPI links.
Just how fast do you want TCP/IP to go?

That some FDDI implementations are slower than others implies nothing
about the TCP/IP protocol itself.  That PC-AT clones do an awesome
300KByte/sec over Ethernet implies nothing of technical interest.  That
some commercial workstations are not impressive on FDDI says some
slightly interesting things about bus, cache and I/O architectures that
would good 10 years ago but wrong today.  Those slow workstations may
also say something about how not to organize your engineering people,
and that more people are not necessarily more productive than fewer.
(The "software team" for SGI FDDI development has fewer than 2
full-time-equivalents, and the "hardware team" is only slightly
larger.  "Team"--eeyuck.  Those who talk that way are often the problem.)


Vernon Schryver,  vjs@sgi.com

-----------[000251][next][prev][last][first]----------------------------------------------------
Date:      19 May 1993 01:58:40 +0930
From:      hart@flash.pax.tpa.com.au (Leigh M Hart)
To:        comp.protocols.tcp-ip
Subject:   RFC's Etc (was Rlogin specs, now where are dey?)


Apologies WRT not opening my eyes when looking for the RFC on the rlogin
protocol.  It was there all along!  amazing huh.

Some peole have posted saying the RFCs aren't necessarily a good guideline
for implementing these protocols, if they aren't then what is?  should we
have to read original code to implement the protocol in our own applications?

Not only does that breach copyright (in terms of continuancy) in some countries
but it's a pain.  

Now I simply ask - is the RFC for the rlogin protocol (RFC1282) correct?  or
am I wasting my time implementing the protocol based on the RFC?  does the
same go for the telnet protocol specification and telnet option specification
RFCs?

There must be *some* semblence of consistency in these documents!   If people
implementing these protocols don't follow the RFCs that have been designated
as the "standard" then where will we end up?  about 20 years behind thats 
where - as far as I can see, the push towards "open systems" is really
hotting up at the moment, and it can't succeed without people adhering to
standards that are set up - regardless of which "Standards Organisation (tm)"
defines them.

Leigh
-- 
Leigh M Hart (hart@pax.tpa.com.au) 

-----------[000252][next][prev][last][first]----------------------------------------------------
Date:      Wed, 19 May 1993 17:38:07 +0000
From:      proyse@peeras.demon.co.uk (Phil Royse)
To:        comp.protocols.tcp-ip
Subject:   Class C Addresses & subnet masks


A client I am working for is planning to install a large IP 
router network of about 60 routers, 40/60 premises and 1200 hosts.
We have only been allocated a Clump-o-Cs, and have planned on paper
an address structure which makes heavy use of subnetting:

subnet mask = 255.255.255.192  = two subnets of 62 hosts each
            = 255.255.255.224  = six subnets of 30 hosts
            = 255.255.255.240  = 14   "      "  14  "

etc. etc., we even have 30 subnets with 6 hosts (for the small 
offices)  -  tight, I know, but that's all we got :-)

We are planning to use OSPF within the autonomous system.

Are there any pitfalls related to all this heavy subnetting???

Can most modern routers (e.g. 3Com, Cisco, W'Fleet etc. cope OK?)

Any advice please.

-- 

Phil Royse     Comms Consultant  | member:  The Peer Association
TUDOR HOUSE                      | (networking & OSI specialists)
12 Woodside Road, Purley           
Surrey  CR8 4LN   (UK)        Tel: (+44) 81 645-9868 

-----------[000253][next][prev][last][first]----------------------------------------------------
Date:      Wed, 19 May 1993 19:07:45 GMT
From:      randolph@freighter.mitre.org (Randolph Mitchell)
To:        comp.protocols.tcp-ip
Subject:   Re: Info on high-speed transport protocols requested


Are you sure that even a *zero* processing-overhead transport protocol will give you the performance you desire?  A while back, we took some measurements (on a Sun) that showed that you could realize a 25% improvement in throughput by skipping the transport protocol altogether (i.e., go right to network-layer).  That's an improvement, to be sure, but not exactly breath-taking.  The problems (as the Wise Ones have pointed out over the past few years) often do not lie with the protocols themselves, but with 


memory management, the OS, interface mechanisms, etc.  These do not change with the choice of transport protocol.  Perhaps you have already done this, but I'd make doubly sure that the transport protocol is properly configured and that the bottleneck is indeed the transport protocol before hunting for a special-purpose transport protocol.

Regards,
Randy Mitchell

-----------[000254][next][prev][last][first]----------------------------------------------------
Date:      19 May 1993 20:17:06 GMT
From:      mogul@pa.dec.com (Jeffrey Mogul)
To:        comp.unix.questions,comp.protocols.tcp-ip
Subject:   Re: Internetworking book

In article <C7AGJA.79C@mcs.anl.gov> curtis@achilles.ctd.anl.gov (Jeffrey S. Curtis) writes:
>I've searched high and low for a copy of the book _Internetworking:
>Bridges and Routers_ to no avail.  None of the local bookstores have
>it, and I can't even find it in any of the well-known book lists (yabl,
>the book faq, et al.).  Can anyone give me a pointer to a list which
>contains this book, or tell me the ISBN, or at least the publisher, or
>anything else about this book?

AUTHOR:       Perlman
TITLE:        Interconnections: Bridges and Routers in Osi and Tcp / Ip
IMPRINT:      Addison Wesley Pub Co Inc., 1991. (Hardback. ISBN:0-201-56332-0)

You can phone-order books from Addison-Wesley, 1-800-447-2226.

The Stanford bookstore sells this for $45.95, but it might list for
more, and you have to pay shipping if you order by telephone.

-Jeff

-----------[000255][next][prev][last][first]----------------------------------------------------
Date:      19 May 93 20:18:01 GMT
From:      art@acc.com (Art Berggreen)
To:        comp.unix.questions,comp.protocols.tcp-ip
Subject:   Re: Internetworking book

In article <C7AGJA.79C@mcs.anl.gov> curtis@achilles.ctd.anl.gov (Jeffrey S. Curtis) writes:
>I've searched high and low for a copy of the book _Internetworking:
						    ^^^^^^^^^^^^^^^
						    Interconnections

>Bridges and Routers_ to no avail.  None of the local bookstores have
>it, and I can't even find it in any of the well-known book lists (yabl,
>the book faq, et al.).  Can anyone give me a pointer to a list which
>contains this book, or tell me the ISBN, or at least the publisher, or
>anything else about this book?

ISBN 0-201-56332-0
Addison-Wesley 
1992

-----------[000256][next][prev][last][first]----------------------------------------------------
Date:      Wed, 19 May 1993 20:21:17 GMT
From:      curtis@achilles.ctd.anl.gov (Jeffrey S. Curtis)
To:        comp.unix.questions,comp.protocols.tcp-ip
Subject:   Re: Internetworking book (solution)

curtis@achilles.ctd.anl.gov (Jeffrey S. Curtis) writes:
}I've searched high and low for a copy of the book _Internetworking:
}Bridges and Routers_ to no avail. [...]

I've been informed that the correct title is _Interconnections:
Bridges and Routers_ by Radia Perlman for Addison-Wesley, ISBN
0-201-56332-0.  Thanks to Greg Dobrich for this info.

Jeff
--
Jeffrey S. Curtis - curtis@anl.gov     / Argonne National Laboratory
Research Assistant, Network Section    / Electronics and Computing Technologies
Polk - Phase Linear - Sanyo - Proton   / 9700 South Cass Avenue
Jensen - Sony - StreetWires - Sennet   / Argonne, IL 60439      +1 708/252-4750 

-----------[000257][next][prev][last][first]----------------------------------------------------
Date:      Wed, 19 May 1993 20:30:56 GMT
From:      mskucher@math.uwaterloo.ca (Murray S. Kucherawy [MFCF])
To:        comp.protocols.tcp-ip
Subject:   Declaring a weird CNAME to named

We have a host called 1308.watstar, whose relevant nameserver data looks like
this:

1308.watstar		IN	A	129.97.20.3
			IN	MX	0	starhost.watstar
			IN	MX	10	steam
1308			IN	CNAME	1308.watstar

The meaning of this last line, the CNAME, has me puzzled.  nslookup(1) seems
to interpret it to mean "1308 is an alias for 1380.watstar", but
host(1) seems to interpret it to mean "1308.watstar is an alias for
1308.watstar with a time-to-live of 1308".

Unless I've missed some detail in RFC1035, it could go either way;
RFC1123 says having a name fragment which is all digits is legal.

So which is correct, and which will the nameserver use?

-- Murray S. Kucherawy ----------------------------------------+--------------
Software Systems Co-op, Math Faculty Computing Facility [MFCF] | This is a
University of Waterloo, Ontario, Canada                        | machine that
E-mail: mskucherawy@{math,watdragon}.UWaterloo.ca              | goes PING!
---------------------------------------------------------------+--------------

-----------[000258][next][prev][last][first]----------------------------------------------------
Date:      Wed, 19 May 1993 20:54:21 GMT
From:      lapp@waterloo.hp.com (David Lapp)
To:        comp.unix.questions,comp.protocols.tcp-ip
Subject:   Re: Internetworking book

Jeffrey S. Curtis (curtis@achilles.ctd.anl.gov) wrote:
: I've searched high and low for a copy of the book _Internetworking:
: Bridges and Routers_ to no avail.  None of the local bookstores have
: it, and I can't even find it in any of the well-known book lists (yabl,
: the book faq, et al.).  Can anyone give me a pointer to a list which
: contains this book, or tell me the ISBN, or at least the publisher, or
: anything else about this book?

Assuming that you mean "Interconnections: Bridges and Routers"
by Radia Perlman then try
ISBN 0-201-56332-0
Published by Addison-Wesley

: Thanks,
You're welcome.

Dave Lapp



-----------[000259][next][prev][last][first]----------------------------------------------------
Date:      Wed, 19 May 93 21:56:17 GMT
From:      jan@ois.com (Jan Morales)
To:        comp.dcom.lans.misc,comp.protocols.tcp-ip,comp.protocols.ppp,comp.unix.aux,comp.unix.questions,comp.sys.sun.misc,comp.sys.sun.admin
Subject:   cannot get SLIP to work

I am posting this for a friend so please e-mail
replies to him: sturt@filetek.com

Thanks.

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

	I recently got the sun slip mods for sunos 4.1 off of the uunet
archives. I want to set up my sun at work as a slip server that I can use
from my Apple AUX system at home. I got the driver genned into the sun 
kernel without a hitch but I'm having problems setting up the connection from
home. I dial into the sun logon and run slip-attach as follows:

	slip-attach /dev/ttypxxx 9600 sun-addr home-addr netmask

I then open up another window on my home system and run slattach and ifconfig
to configure the serial line as follows:

	slattach /dev/tty0 9600
	ifconfig sl0 home-addr sun-addr up

When I ping the sun host I see the transmit light on the modem working but
nothing comes back. I also get a console message on the sun side:

	vmunix: slipencode: overrun

This indicates a packet over the MTU for the connection. Can anybody give me
a play by play on how to set up the slip connection and what I might be 
doing wrong? Do I need special modem strappings? Thanks in advance for any help
				
					Dave S.
					sturt@filetek.com
					uunet!fltk!sturt

-- 
Jan Morales                           jan@ois.com
Objective Interface Systems, Inc.     uunet!ois!jan
Reston, Virginia, U.S.A.

-----------[000260][next][prev][last][first]----------------------------------------------------
Date:      Thu, 20 May 1993 04:41:29 GMT
From:      vjs@rhyolite.wpd.sgi.com (Vernon Schryver)
To:        comp.protocols.tcp-ip
Subject:   Re: RFC's Etc (was Rlogin specs, now where are dey?)

In article <1993May18.180713.6908@spectrum.CMC.COM>, lars@spectrum.CMC.COM (Lars Poulsen) writes:
> In article <1tb2roINNgkk@flash.pax.tpa.com.au>
>    hart@flash.pax.tpa.com.au (Leigh M Hart) writes:
> >Some peole have posted saying the RFCs aren't necessarily a good guideline
> >for implementing [rlogin etc], if they aren't then what is?  should we
> >have to read original code to implement the protocol in our own applications?
> > ...
> >Now I simply ask - is the RFC for the rlogin protocol (RFC1282) correct?  or
> >am I wasting my time implementing the protocol based on the RFC?  does the
> >same go for the telnet protocol specification and telnet option specification
> >RFCs?
> 
> The Internet perspective is that there is no point in implementing a
> protocol if it does not work. Arguing about whether the paper
> specification is more correct than the many currently running
> implementations is pointless.
> 
> This applies in particular, when - as in the case of rlogin - the
> protocol was not developed through the standards process, but was
> a useful non-standard hack implemented by someone and then widely
> distributed. RFC1282 reflects a reverse-engineering effort and it is
> very nearly correct.
> 
> TELNET, on the other hand, is a standard protocol, and the specification
> is authoritative.


Well put.


Last week someone wrote me suggesting that the diffference between the
RIP RFC and the routed implementation should and must be resolved by
changing routed implemenation, and never mind that the BSD code is 
many years older and in the particular technical differences, obviously
better.  The idea of treating an RFC as newly revealed devine law,
innocently proposed although it was, is what really started the smoke
pouring out of my ears.

The trouble with the final rlogin RFC is that it is too consise.  No
new implementation of rlogin from the RFC will be usable without years
of debugging, because the RFC documents only the trivial part of the
protocol that can be seen with your favorite ethernet snoop tool.  The
hard issues are such as implementing that out-of-band stuff mentioned
in passing by the RFC.  Consider the reasons for moving the
initialization of the SIGURG signal handler between 4.3BSD and more
recent versions.  Or the reasons for the strange helper signal handlers
in the parent of the two rlogin processes.


Vernon Schryver,  vjs@sgi.com

-----------[000261][next][prev][last][first]----------------------------------------------------
Date:      Thu, 20 May 1993 06:47:22 GMT
From:      isc20078@nusunix1.nus.sg (FOONG CHEE KHIONG)
To:        comp.protocols.tcp-ip
Subject:   PCTCP appilcation package


My project group is currently embarking on a project to incorporate 3D
sound into our existing system. The sound equipment is PC-based while
our system is running on the Silicon Graphics Reality Engine.

Hence, we are in the process of scouting for viable software to link both
our systems. We sincerely hope that somebody could give us some informations
about the source code and library routine documentation that we can  
made use of.

Currently  we are working on 'C' programming , therefore we do not need 
the executable files but rather the 'C' codes of the FTP package. 
We intend to use 'types.h, socket.h' which are available in Unix 'C' but
not to be found on Borland C++ on our PC.

ckfoong@iss.nus.sg

 




-----------[000262][next][prev][last][first]----------------------------------------------------
Date:      Thu, 20 May 93 07:05:41 GMT
From:      R.Thirlby@lut.ac.uk
To:        comp.protocols.tcp-ip
Subject:   Re: 3270 Terminal Emulation

We have a similar requirement for 3270 emulation over IP for an HP710
workstation.  Any information would be useful

rob thirlby, r.thirlby@lut.ac.uk



-----------[000263][next][prev][last][first]----------------------------------------------------
Date:      Thu, 20 May 1993 13:25:28 GMT
From:      stewart@oin.cis.udel.edu (John Stewart)
To:        comp.unix.questions,comp.protocols.tcp-ip
Subject:   Re: Internetworking book

In article <C7AGJA.79C@mcs.anl.gov> curtis@achilles.ctd.anl.gov (Jeffrey S. Curtis) writes:
>I've searched high and low for a copy of the book _Internetworking:
>Bridges and Routers_ to no avail.  None of the local bookstores have
>it, and I can't even find it in any of the well-known book lists (yabl,
>the book faq, et al.).  Can anyone give me a pointer to a list which
>contains this book, or tell me the ISBN, or at least the publisher, or
>anything else about this book?

I don't know of a book by that name.  Could you mean
_Interconnections: Bridges and Routers_ by Radia Perlman?  If
so, the ISBN is 0-201-56332-0.

(There's also the three volume _Internetwokring with TCP/IP_
series by Comer and Stevens, but the "Bridges and Routers"
you mention makes me think it's Perlman's book you want.)

Good luck.

/jws

-----------[000264][next][prev][last][first]----------------------------------------------------
Date:      Thu, 20 May 1993 16:38:46 GMT
From:      skaggs@nsslsun.nssl.uoknor.edu (Gary Skaggs)
To:        comp.dcom.lans.misc,comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpC
Subject:   Need Router software that runs on a PC...

I've looked in the FAQs for a few groups and haven't found this anywhere
and haven't needed it till now, but I need the PD softwared that runs
on a poor old dumb PC that uses two network cards to route (or bonus, and
bridge) between two networks.

Any help on finding this is appreciated.
______________________________________________________________________________
Gary Skaggs - WB5ULK				skaggs@nssl.nssl.uoknor.edu
	"Neither my employer, The University of Oklahoma,
	 nor The National Severe Storms Laboratory, where I work,
	 know that I even have any opinion, much less this one."

-----------[000265][next][prev][last][first]----------------------------------------------------
Date:      Thu, 20 May 1993 18:48:13 GMT
From:      pug@wixer.bga.com (Pug)
To:        comp.sys.mac.programmer,comp.sys.mac.apps,comp.sys.mac.comm,comp.protocols.tcp-ip,comp.protocols.tcp-ip.domains
Subject:   MacTCP 1.1.1 and DNS...

Good Morning,

   This is been posted over a wide variety of places just because I'm
not sure who to ask/discuss this with.

   We have an ethernet network with a lot of Mac's on it. We have MacTCP
1.1.1 running on them and generally use NCSA Telnet 2.5. This is
happening on all of our Macs so I don't think it's System dependant.
What the problem is is this - When using MacTCP and having more then one
server per domain, which is rather standard to have a primary and
secondary server incase the primary is down, if the primary *is* down,
it will not use the secondary for the domain. You have to change the
default setting and then reboot. Well this is not an acceptable
solution. It will go on to any server under another domain name though.
The reason that we need a solution is our primary server is moving and
we want people to still be able to access other computers when it does.
We can't synchronize the changing of every Mac in the building when we
do switch, and would prefer to have the time. As well, if the primary at
any point is down *and* they have another NS off-site listed, then if
our link to the world goes down as well, they can't even get to the UN*X
box that might be sitting on the next guys desk. I have tried talking to
1-800-SOS-APPL to no avail, they don't even seem to believe that the
problem exists, eventhough it can easily be duplicated.

   Does anyone know of a solution for this problem? In the domainname
field, does it have to be a true domain? For example can I put
arluta.utexas.edu, arlutb.utexas.edu, etc and still get back correct
addresses given the short name for a host?

Thanks to anyone who has any ideas on this.

Ciao,

-- 
Richard Bainter          Mundanely     |    System Analyst        - OMG/CSD
Pug                      Generally     |    Applied Research Labs - U.Texas
    bainter@csdsun1a.arlut.utexas.edu  |    pug@wixer.bga.com
Note: The views may not reflect my employers, or even my own for that matter.

-----------[000266][next][prev][last][first]----------------------------------------------------
Date:      Thu, 20 May 1993 20:15:37 GMT
From:      richb@jti.com (Rich Braun)
To:        comp.protocols.tcp-ip
Subject:   Re: Class C Addresses & subnet masks

proyse@peeras.demon.co.uk writes:
>A client I am working for is planning to install a large IP 
>router network of about 60 routers, 40/60 premises and 1200 hosts.
>We have only been allocated a Clump-o-Cs, and have planned on paper
>an address structure which makes heavy use of subnetting:

A little over a year ago I posted to this newsgroup with the same
problem:  a site about to buy a bunch of routers and link 20 field
offices onto the net, which had 10 Class C addresses.

The feedback I got here was unanimous:  you'll regret subnetting your
Class C networks like that.  Not all _client_ IP implementations support
this.  Unless you know for sure they do, then you might run into trouble
later.

Armed with this advice, I went for a Class B network number.  Made things
a heck of a lot easier to manage, especially as the field sites grew.

Have Class B's already gotten hard to come by?

-rich

-----------[000267][next][prev][last][first]----------------------------------------------------
Date:      Thu, 20 May 1993 21:26:47 GMT
From:      cricket@corp.hp.com (Cricket Liu)
To:        comp.protocols.tcp-ip
Subject:   Re: Declaring a weird CNAME to named

Murray S. Kucherawy [MFCF] (mskucher@math.uwaterloo.ca) wrote:
: We have a host called 1308.watstar, whose relevant nameserver data looks like
: this:
 
: 1308.watstar		IN	A	129.97.20.3
: 			IN	MX	0	starhost.watstar
: 			IN	MX	10	steam
: 1308			IN	CNAME	1308.watstar
 
: The meaning of this last line, the CNAME, has me puzzled.  nslookup(1) seems
: to interpret it to mean "1308 is an alias for 1380.watstar", but
: host(1) seems to interpret it to mean "1308.watstar is an alias for
: 1308.watstar with a time-to-live of 1308".

Hmm.  I've never heard of the field after the record type being interpreted
as a time-to-live (of course, I may have missed some subtle nuance of
RFC1035).  Certainly not with a dot separating it from the first field of
record-specific data.

BTW, my host command doesn't interpret the '1308' as a TTL.  I use the
NIKHEF version, ftp'able from ftp.nikhef.nl.

--
cricket

cricket@hp.com / Hewlett-Packard Professional Services Org. / Englewood, CO

-----------[000268][next][prev][last][first]----------------------------------------------------
Date:      Thu, 20 May 1993 23:01:11 GMT
From:      tannen@mack.geg.mot.com (David Tannen x2325)
To:        comp.protocols.tcp-ip
Subject:   Developing with Sockets and recv

Our application uses Sockets (recv and send) to transport data across TCP/IP.
My question has to do with recv. 

1)  I want to send up to 32k buffers across TCP/IP, but my documentation 
    (and socket.h) seem to indicate that sockets can only handle about 8k 
    at a time. Is this true?  If we do have to break up the 32k buffer into
    pieces, do we need to track the order of each piece? (i.e. Is the order
    that sends occur preserved across TCP/IP?)

2)  The buffer contains a header which indicates the size of the entire buffer.
    The header is the first 20 bytes of the buffer.  If I do a recv for the first     
    20 bytes, without the PEEK flag, will the rest of the buffer be lost?

Our prototype seems to indicate that we should break up our buffers into smaller 
pieces and then send them.  It also seems to indicate that recv is destructive,
unless the PEEK flag is used.



-----------[000269][next][prev][last][first]----------------------------------------------------
Date:      Thu, 20 May 1993 23:13:47 +0000
From:      chan@chan1.demon.co.uk (Daniel de Klerk)
To:        comp.sys.novell,comp.protocols.tcp-ip
Subject:   LAN WorkPlace, Ethernet and terminal emulator problems...

I believe that this question might be an FAQ, but I do not normally
follow these newsgroups (although I have subscribed now).  Please
give me some pointers if you can:

We are running Novell 3.11 (5 user) on Ethernet with 3 PC's and a
proprietary box running standard (I think) TCP/IP.  Two PC's are
running DOS 5, one on DOS 6, and all load the following drivers:

   LSL       although this also works    LSL
   NE2000                                NE2000
   TCPIP                                 IPXODI
   TELAPI                                NETX
   IPXODI                                TCPIP
   NETX                                  NETX
   TSU (2 sessions)                      TSU (ditto)

We have our own terminal emulator written in Turbo C which talks
to the proprietary system, and works quite happily from DOS.  

Yes, this whole lot eats memory, but hold on, there's more to come...

I now want to load 2 session of the emulator under Windows so that
we can have multiple sessions to the same host.  The emulator talks
to INT 14, which is intercepted by TSU and passed on to the Telnet
servers on the host.

I can get this whole setup running quite well provided I have enough
memory before I start Windows.  If I have all the above drivers loaded,
and Novell's CAPTURE as well, Windows complains that there is not
enough memory to start the application, sometimes the application (the
term em) is aborted due to illegal instructions, and whatever can get
worse.  Sometimes Windows complains that there is not enough memory for
the application's screen to be displayed, but if you ignore the message
it starts up OK.

The "funny" (not ha-ha) thing is that the term em uses less than 200K
of RAM (tested by doing MEM, then loading and shelling to DOS and doing
MEM again; find the difference).  I am starting the sessions up via
PIF files, and have fiddled with memory settings and windowed vs
full-screen, to no avail.

I have also tried QEMM 6.0 and DOS 6 to improve memory usage.  Both do
quite a good job of giving me lots of memory, but the emulator will
not work at all if TCPIP and TELAPI are loaded high.

So, the question:

If I start Windows with the drivers loaded as listed above, I start off
with approx 470K RAM (yes, horrible, isn't it!).  The terminal emulator
sessions crash with varying degrees of severity, or Windows just refuses
to load them.

Is there anything I am doing wrong?  Can I try something like the Clarkson
packet drivers with some PD/Shareware TCP/IP instead of LAN WorkPlace?

All help MUCH appreciated!
-- 
__________________________________________________________________
Neville Chamberlain                         chan@chan1.demon.co.uk

-----------[000270][next][prev][last][first]----------------------------------------------------
Date:      Thu, 20 May 1993 23:24:39 GMT
From:      kre@cs.mu.oz.au (Robert Elz)
To:        comp.protocols.tcp-ip
Subject:   Re: Declaring a weird CNAME to named

In <C7AJnK.7II@math.uwaterloo.ca>
mskucher@math.uwaterloo.ca (Murray S. Kucherawy [MFCF]) writes:

| We have a host called 1308.watstar, whose relevant nameserver data looks like
| this:
 
| 1308.watstar		IN	A	129.97.20.3
| 			IN	MX	0	starhost.watstar
| 			IN	MX	10	steam
| 1308			IN	CNAME	1308.watstar
 
| The meaning of this last line, the CNAME, has me puzzled.  nslookup(1) seems
| to interpret it to mean "1308 is an alias for 1380.watstar",

That's correct.

| but host(1) seems to interpret it to mean "1308.watstar is an alias for
| 1308.watstar with a time-to-live of 1308".

Weird.

| Unless I've missed some detail in RFC1035, it could go either way;
| RFC1123 says having a name fragment which is all digits is legal.
 
| So which is correct, and which will the nameserver use?

nslookup uses the nameserver, and in the binary packet formats, the
whole thing is unambiguous ("1308" as a string is in the name field,
and is clearly a name, 1308 as a binary integer is in the TTL field, and
so is a TTL).  I thought host did that too, but haven't used it, so I'm
not sure.   Dig agrees with nslookup.

In any case, in zone files, names always begin at the left margin,
and whatever is at the left margin is always a name (modulo absurd
BIND DNS file parsing implementations, and continuation lines using
'(' ')' in conforming zone files).  TTL's, if given, must be indented.

" 1308 IN CNAME ..." would make 1308.watstar be a cname for 1308.watstar
(which is both meaningless and illegal) with a ttl of 1308.  As you
have it, and without the space, all is fine.

What's more, it really does work...

dig 1308.uwaterloo.ca

; <<>> DiG 2.0 <<>> 1308.uwaterloo.ca 
;; ->>HEADER<<- opcode: QUERY , status: NOERROR, id: 6
;; flags: qr aa rd ra ; Ques: 1, Ans: 2, Auth: 0, Addit: 0
;; QUESTIONS: 
;;      1308.uwaterloo.ca, type = A, class = IN

;; ANSWERS:
1308.uwaterloo.ca.      86400   CNAME   1308.watstar.uwaterloo.ca.
1308.watstar.uwaterloo.ca.      86400   A       129.97.20.3

;; Sent 4 pkts, answer found in time: 3767 msec  sent 3 too many pkts
;; FROM: mulga.cs.mu.OZ.AU to SERVER: default -- 192.43.207.2
;; WHEN: Fri May 21 09:24:26 1993
;; MSG SIZE  sent: 35  rcvd: 90

kre

-----------[000271][next][prev][last][first]----------------------------------------------------
Date:      21 May 1993 11:11:23 -0400
From:      kent@tfd.com (Kent Hauser)
To:        comp.protocols.tcp-ip
Subject:   Can't flush a TCP connection


Environment: All under SunOS 4.1.1 and 4.1e

Is there a way a sender can abort and flush a TCP connection?

I have a system where a server process provides a stream of data to
multiple remote clients. When a client fails to read it's data (for
instance it rec'd a SIGSTOP, or is busted), TCP provides buffering on
both the local host & remote host. When the buffering capability is
exhausted, my server receives EWOULDBLOCK & closes the connection.

Unfortunately, all of the buffered data on both the local & remote hosts
sits around waiting for the client to one day read it (or exit).  This
is a problem when there are multiple connections stopped up, as it eats
up all of my buffer space.

Since the `FIN' bit is buffered right along with the data, I think I
need to send a `RESET' some how. I tried setting the `linger' option
on the socket to 2 seconds, but it had no effect.

Can someone advise me how I can kill the connection & flush the
buffers?

Thanks.

	Kent

-- 
Kent Hauser			UUCP: {uunet,sundc,uupsi}!tfd!kent
Twenty-First Designs		INET: kent@tfd.com
(301) 572-6370

-----------[000272][next][prev][last][first]----------------------------------------------------
Date:      21 May 1993 05:14:51 GMT
From:      munna@eng.umd.edu (Ajay Kumar Srivastava)
To:        comp.protocols.tcp-ip
Subject:   FAQ


Keywords: 

I recently joined this news group. Can someone please send me an FAQ for this news group.

Thanks,
ajay

-----------[000273][next][prev][last][first]----------------------------------------------------
Date:      21 May 1993 10:48:12 GMT
From:      neideck@nestvx.enet.dec.com (Burkhard Neidecker-Lutz)
To:        comp.protocols.tcp-ip
Subject:   Re: Info on high-speed transport protocols requested

In article <i0imr8g@rhyolite.wpd.sgi.com> vjs@rhyolite.wpd.sgi.com (Vernon Schryver) writes:
>    - at Interop92 I saw a pair of boxes in the DEC booth doing 95Mbit
>	sec through TCP/IP.  I have reason to believe they were Alpha's.

Yep, and some CPU cycles left doing that. Complain to SUN (and tell them
that both SGI and DEC can do this). Reminds me of the customers we had
here that didn't believe you could get 1 MByte/sec task-to-task via
Ethernet. Showed them that on 2 DECstations (not even Alpha's). Customers
comment:

	"The best we've ever seen on a SUN is 500 KByte/sec. What
	 kind of ethernet do you have ?"

My response:

	"We have thicker cables..."


		Burkhard Neidecker-Lutz

Distributed Multimedia Group, CEC Karlsruhe  
Software Motion Pictures & BERKOM II Project
Digital Equipment Corporation
neidecker@nestvx.enet.dec.com

-----------[000274][next][prev][last][first]----------------------------------------------------
Date:      Fri, 21 May 1993 11:42:38 GMT
From:      luca@dedalo.unipg.it (Luca Priorelli)
To:        comp.protocols.tcp-ip
Subject:   Help installing SLIP on Sun!

I want to install SLIP on a SPARCstation running SunOS 4.1.2.

I got cslip 2.6.

1 - I don't know if this is the best slip package
2 - I installed it and it runs badly. pinging from the client
    is very slow. Some ping packets are dropped. Any other
    tcp/ip command works partially (e.g. they give a 'connect'
    message but do not go ahead).

Can you help me?

Luca Priorelli

-----------[000275][next][prev][last][first]----------------------------------------------------
Date:      21 May 1993 12:55:28 GMT
From:      casper@fwi.uva.nl (Casper H.S. Dik)
To:        comp.protocols.tcp-ip
Subject:   Re: Info on high-speed transport protocols requested

neideck@nestvx.enet.dec.com (Burkhard Neidecker-Lutz) writes:

>Yep, and some CPU cycles left doing that. Complain to SUN (and tell them
>that both SGI and DEC can do this). Reminds me of the customers we had
>here that didn't believe you could get 1 MByte/sec task-to-task via
>Ethernet. Showed them that on 2 DECstations (not even Alpha's). Customers
>comment:
 
>	"The best we've ever seen on a SUN is 500 KByte/sec. What
>	 kind of ethernet do you have ?"

We never had any problem getting 1000KB/s on Suns. Of course,
if the customers had a pretty busy ethernet or pretty obsolete
Sun hardware, it would not have been possible.
Ans what tests did they use? The default TCP send/recv windows
are small compared to other vendors.

Also, some Sun hardware is limited to 600KB/s. Anything with
the Intel (ie) ethernet interfaces can't possibly get above
600KB/s because it's a broken chip.

I'll grant yuo, though, that Sun for a company that has in the past
claimed that ``the network is the computer'' has always been
running behind on ethernet performance and even more behind
in FDDI performance.

Casper

-----------[000276][next][prev][last][first]----------------------------------------------------
Date:      Fri, 21 May 1993 14:03:18 GMT
From:      mskucher@math.uwaterloo.ca (Murray S. Kucherawy [MFCF])
To:        comp.protocols.tcp-ip
Subject:   Semantics of RFC1035 $ORIGIN

I'm afraid the wording of RFC1035 isn't quite clear to me with respect
to how to handle $ORIGIN control lines... for example, if my current
origin is "uwaterloo.ca" and I specify "$ORIGIN math", is the new
origin for the next record(s) encountered just "math", or is it
prepended to become "math.uwaterloo.ca" since there is no terminating
"." character?

-- Murray S. Kucherawy ----------------------------------------+--------------
Software Systems Co-op, Math Faculty Computing Facility [MFCF] | All spelling
University of Waterloo, Ontario, Canada                        | errors caused
E-mail: mskucherawy@{math,watdragon}.UWaterloo.ca              | by Pnews.
---------------------------------------------------------------+--------------

-----------[000277][next][prev][last][first]----------------------------------------------------
Date:      Fri, 21 May 1993 15:44:11 GMT
From:      jpb@jpbpc1.uncc.edu (John Bennett)
To:        comp.protocols.tcp-ip
Subject:   Super-TCP

I have just finished Tested the following nine competing products:
	PC/TCP from FTP Software
	ChameleonNFS from NetManage
	Pathway Access from Wollongong
	Lan Workspace for DOS from Novell
	3Com TCP from 3Com
	Sun PC-NFS from SunSoft V5.0
	IBM TCP/IP V2.1 from IBM
	Beam & Whiteside NFS V3.0a from Beam & Whiteside
	Super-TCP From Frontier Technologies V3.0 R1

Our basic requirements for a TCP/IP package are NFS support for both DOS & Windows environments, an 
integrated mail product with the ability to support enclosures, ease of installation, minimal use of base 
memory, ability to support third party vendor applications such as X-Windows for the PC, a package that 
was stable in performance, and support for DNS name servers.. Other considerations were support for 
Winsock v1.1, standard Telnet, FTP, SMTP, POPmail, TN3270, and support for SMC/WD ethernet cards. 
Super-TCP from Frontier Technologies is the only software that meets all of our basic requirements.
Frontier Technologies Super-TCP Email supports (MIME) extensions through SMTP gateways, Thus 
allowing the transmission of data to persons on various platforms for their use.

	Package Requirements:

*	Windows Sockets API
*	Winsock V1.1 support
*	100% Windows DLL
*	VxD Virtual Driver
*	Dual Mode Operation (100% DLL or TSR for DOS)
*	VT220 VT320
*	TN3270
*	Telnet Redirector
*	Client-Server FTP, TFTP
*	Electronic Mail (SMTP, POP 2&3) (MIME)
*	NNTP News Reader
*	Talk
*	NFS Client
*	NFS Server
*	Remote Protocols
*	SNMP Agent
*	Extendible MIB
*	ONC RPC/XDR API
*	NetBIOS API
*	Binary API
*	Berkely Sockets API
*	LPR
*	LPD
*	NDIS & PACKET DRIVERS
*	ODI & ASI DRIVERS
*	SLIP
*	PPP
*	X.25
*	RFC 1006 OSI
*	Modem Server
*	BOOTP
*	Third Party Support
*	Global Login



-----------[000278][next][prev][last][first]----------------------------------------------------
Date:      21 May 1993 03:58:33 +0930
From:      hart@flash.pax.tpa.com.au (Leigh M Hart)
To:        comp.protocols.tcp-ip
Subject:   Re: RFC's Etc (was Rlogin specs, now where are dey?)

vjs@rhyolite.wpd.sgi.com (Vernon Schryver) writes:

>I don't know of an errors in the rlogin RFC, but I wouldn't consider
>hiring anyone who wouldn't or couldn't check the rlogin source before
>implementing it.

When it comes to implementing protocols for the TCP/IP suite I'm pretty
much a "newbie" (for want of a better word).  I'm writing an application
that I hope, eventually, will be a viable contender for existing network
hardware.  I basically know (through USENET and other net exposure) that
when implementing existing protocols, following the RFCs is the norm and
is generally accepted as the way to do these things.  

Obviously anyone implementing one of the protocols from an RFC that isn't 
the authoritive standard would cross reference their code with the freely 
available and hopefully authoritive source code (in this case BSD's code 
for rlogin) to make damn sure it conformed, as well as the obvious testing 
to make sure it worked in the first place. 

I wasn't suggesting implementations should be wholy-and-solely based
on the RFCs and never checked against existing source code, but that
implementors shouldn't base their code entirely on original code. 

>> There must be *some* semblence of consistency in these documents!   If people
>> implementing these protocols don't follow the RFCs that have been designated
>> as the "standard" then where will we end up?  about 20 years behind thats 
>> where - as far as I can see, the push towards "open systems" is really
>> hotting up at the moment, and it can't succeed without people adhering to
>> standards that are set up - regardless of which "Standards Organisation (tm)"
>> defines them.
 
>That's almost my rant, except you are being picky about the language of
>the standard and the Royal Patent of the standards writers.  Code is a
>perfectly fine language for standards.  After all, the best (well,
>whatever) products of CCITT or ANSI are filled with "psuedo-code" and
>"state machine descriptions."  The usual way to write from such
>standards is to mentally compile from their language into your current
>favorite.

I agree with you on this point - the easiest (and safest) way to implement
any standard is to include example code along with the waffle describing
how it all works.

>The authoritative description of the rlogin standard is the BSD source.
>If you don't want to compile, use and ship binaries from that standard
>then don't.  That your C compiler won't accept the stuff in an OSI
>document, or even any of the contents of most (but not all) RFC's does
>not keep you from paying homage to them.

That's the point!  I _do_ want to compile use and ship binaries from 
the _standard_ - what's the point otherwise? (as you pointed out in
your post, why reinvent the wheel, just to find your's is square?)
The task at hand is to decypher the waffle and find out what *is* the
standard (in this case, you have put me on the right track, thanks!)

One example where this unfortunately all falls down, is some companies
when they invent a protocol that becomes a "standard" when applied to their
own products, but do not release code to their protocol nor (as far as I
know) freely release documentation of their protocol for developers,
it makes it kind of hard to implement their protocols.  

Leigh
-- 
Leigh M Hart (hart@pax.tpa.com.au) 

-----------[000279][next][prev][last][first]----------------------------------------------------
Date:      Fri, 21 May 93 19:43:43 GMT
From:      news@nlm.nih.gov
To:        comp.protocols.tcp-ip
Subject:   PC-NFS SLIP and Windows 3.1 compatible?

Hi,

I am trying to connect a PC and a Sparc using PC-NFS 4.0 SLIP and Microcom
modems.  The problem is if I tried to enter Windows 3.1 after establishing
SLIP connection, the PC hangs and I have to reboot.  Also I cannot establish
SLIP by typing connect "profilename".  I have to use connect -i to setup the
link.  Did I miss something?  The documentation is not much help. 

The many questions are:

Have anyone ever tried to use PC-NFS SLIP and Windows 3.1?

Is SLIP and modems only work in DOS level?

Will upgrade to 5.0 help?

Is PPP support in PC-NFS's future plan?  


When I just use a null modem cable to establish a direct connect SLIP, 
everything works fine. I can enter Windows with no problem.

Thanks.

Tin Li

Nationale Library of Medicine, NIH

li@nlm.nih.gov



-----------[000280][next][prev][last][first]----------------------------------------------------
Date:      Fri, 21 May 1993 20:03:36 GMT
From:      vjs@rhyolite.wpd.sgi.com (Vernon Schryver)
To:        comp.protocols.tcp-ip
Subject:   Re: Info on high-speed transport protocols requested

In article <1tijg0$dgo@mail.fwi.uva.nl>, casper@fwi.uva.nl (Casper H.S. Dik) writes:
> 
> We never had any problem getting 1000KB/s on Suns. Of course,
> if the customers had a pretty busy ethernet or pretty obsolete
> Sun hardware, it would not have been possible.
> Ans what tests did they use? The default TCP send/recv windows
> are small compared to other vendors.
> 
> Also, some Sun hardware is limited to 600KB/s. Anything with
> the Intel (ie) ethernet interfaces can't possibly get above
> 600KB/s because it's a broken chip.
> ...


I don't know about Sun ethernet TCP speed in the last few years, but it
turns out that a fast pair of machines using by-the-book Ethernet and
medium sized (> 20K) TCP windows are limited to about 800KByte/sec,
because the Ethernet backoff algorithm gets unfair to losers during
saturation.

On the other hand, 1100KByte/sec is easy if you either play games with
TCP or use "broken", "polite", "slow", "non-standard" or "enhanced" AMD
7990 LANCE's.  (Pick the right adjective when talking to AMD, depending
on whether you're playing angry customer or happy customer.)  This is
because the LANCE defers longer than the required 9.6 microseconds,
reducing the collision rate, and so the rate at which the TCP receiver
gets exponentially backed off into the weeds.


Vernon Schryver,  vjs@sgi.com

-----------[000281][next][prev][last][first]----------------------------------------------------
Date:      Fri, 21 May 1993 22:59:49 GMT
From:      joey@tessi.com (Joey Pruett)
To:        comp.protocols.tcp-ip,comp.dcom.lans.ethernet
Subject:   xyplex xp-cc8-e on tcp?

i've unconvered one of these beasts and have talked with
xyplex to learn that they talk some proprietary protocol
with a vax.  i was wondering if anyone out there had maybe
figured out how to use them in a standard tcp/ip environment.
i realize this is not a simple task, but maybe someone has
done it.  any info would be appreciated

-----------[000282][next][prev][last][first]----------------------------------------------------
Date:      Sat, 22 May 1993 00:23:17 GMT
From:      rstevens@noao.edu (W. Richard Stevens)
To:        comp.protocols.tcp-ip
Subject:   Re: Can't flush a TCP connection

>Since the `FIN' bit is buffered right along with the data, I think I
>need to send a `RESET' some how. I tried setting the `linger' option
>on the socket to 2 seconds, but it had no effect.
>
>Can someone advise me how I can kill the connection & flush the
>buffers?

You can force a reset by setting the SO_LINGER option with l_onoff
set to 1, and l_linger set to 0.  The next close() sends the RST.

	Rich Stevens  (rstevens@noao.edu)

-----------[000283][next][prev][last][first]----------------------------------------------------
Date:      22 May 93 02:50:55 GMT
From:      herlock@lclark.edu (Jon Herlocker)
To:        comp.protocols.tcp-ip
Subject:   FAQ?


Could someone send me or direct me to a FAQ for this group?

Thanks!
Jon
-- 
Jon Herlocker		email:  herlock@lclark.edu
Lewis & Clark College
Portland, OR 97219

-----------[000284][next][prev][last][first]----------------------------------------------------
Date:      22 May 93 10:06:14 GMT
From:      eb@felix.Sublink.Org (Enrico Badella)
To:        comp.protocols.tcp-ip.ibmpc,comp.protocols.tcp-ip
Subject:   Packet driver for AT&T LANPACER T7231

Hello

I was wondering if anyone has already written a packet driver for
the AT&T LANPACER T7231 and related chips and is willing to
share it.

Thank you.

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

-----------[000285][next][prev][last][first]----------------------------------------------------
Date:      22 May 1993 16:57:01 GMT
From:      sinisa@thphys.irb.hr (Sinisa Novosel)
To:        comp.protocols.tcp-ip
Subject:   gethostbyaddr_after_gethostbyname

I have a problem (Interactive(SunSoft) 3.0 Unix):

gethostbyaddr() doesnt work if previous call was 'gethostbyname()' ?!
h_errno == 1.
Named is not running, but nameserver is defined in 'resolv.conf'.
RTFM procedure doesnt help, i.e. I cant make my little program to work.
Same program work OK under Ultrix.

Any advise ?

Sinisa

-- 
-----------------------------------------------------------------------------
!  Sinisa Novosel, Institut Rugjer Boskovic, dep. FIZIKA; Croatia,Zagreb    !
!                     sinisa@thphys.irb.hr                                  !
-----------------------------------------------------------------------------

-----------[000286][next][prev][last][first]----------------------------------------------------
Date:      Sat, 22 May 1993 23:16:56 CDT
From:      <U37127@uicvm.uic.edu>
To:        comp.protocols.tcp-ip
Subject:   Info on programming SOCK_RAW type sockets

Sorry if this is not the appropriate group, but here goes.
I am looking for information or examples on programming SOCK_RAW
type sockets.
I have checked the Comer books, but they dont seem to have any concrete
details, just vague references.

I would appreciate any pointers to books or samples that you can give me.

Thank you,
Satish Movva
Samll Systems Group,
Univ. Of Illinois at Chicago

-----------[000287][next][prev][last][first]----------------------------------------------------
Date:      Sun, 23 May 1993 00:31:21 GMT
From:      Ronald M. Hoering <rhoering@uchicago.edu>
To:        comp.protocols.tcp-ip
Subject:   TN3270 and HyperCard

Hello,

I have what maybe a strange question. 

Does anyone know of a set of X-commands that would allow HyperCard to 
access Mainframes via the INBM 3270 terminal protocol? 

I really only need to read a line at a time and send back an appropriate 
response. My application is to login and parse out certain bits of data 
from the text screens.

Thanks,

Ron

-----------------------------------------------------------------
Physics Student:   "What the hell is all this math stuff anyway?"
   Math Student:   "How the hell do I know what it is!"
    Art Student:   "Math!?! Why ask why, Bud Dry!"

-----------[000288][next][prev][last][first]----------------------------------------------------
Date:      23 May 93 10:34:55 -0600
From:      lynn@vax1.mankato.msus.edu
To:        comp.protocols.tcp-ip
Subject:   NOVELL SHARING MODEM?



This posting is for my brother.  He does not have access to NEWS.  If
your mail bounces back, please E-mail your comments to me and I will
forward them to him.   Thank you.

My Address is:  lynn@vax1.mankato.msus.edu.






Subj:  Modem Sharing with NWlite v1.1



I have two computers that I want to share a modem between the two.
I currently have Netware LITE v1.1 installed on both machines.
The communication package that I am using is QMPRO.

QMPRO is made to work with a LAN system but unfortunatly the
instructions doesn't say a whole lot about it.  Does anyone know if
this is possible and what I will need.  Responses can be sent to:

m9aa@sdstate.sdsumus.edu

Thank you.

Sam
 

-----------[000289][next][prev][last][first]----------------------------------------------------
Date:      23 May 93 00:39:32 GMT
From:      trt@duke.cs.duke.edu (Tom Truscott)
To:        comp.protocols.tcp-ip
Subject:   Re: Developing with Sockets and recv

You omitted an important detail: are you using SOCK_STREAM or SOCK_DGRAM?

For SOCK_STREAM you can send arbitrary lengths, and it generally behaves
just like a pipe().
Since it is a stream, if you send(100) and then send(100)
and then recv(150), the recv may return any number of bytes
between 1 and 150 inclusive.  (This is a source of lots of bugs.)
A read of a SOCK_STREAM only removes the bytes you requested,
subsequent bytes wait patiently for a a later read.

For SOCK_DGRAM you can send only up to sender's SO_SNDBUF
(a larger send will be rejected) and up to the receiver's
SO_RCVBUF (a larger send will be quietly dropped). 
You can set those with setsockopt(), and you should make SO_RCVBUF
at least 16 bytes larger than the sent message (aka. record) because ...
of an implementation botch.
(Make RCVBUF size larger than that if you need to hold
multiple incoming messages, otherwise some will be quietly dropped.)
SOCK_DGRAM messages must be read "atomically":
if you got a 1000 byte message and read 600 bytes of it,
you get the first 600 bytes and the last 400 are quietly dropped.
You can indeed do a MSG_PEEK, or you can just allocate a huge
buffer and do a huge read to be safe.
Since SOCK_DGRAM is record oriented,
you will get at most 1 datagram message per read.

Using SOCK_DGRAM can get quite complex.  It does not guarantee delivery,
nor ordering if you send several messages.
Most typically people use SOCK_DGRAM either for non-critical stuff
such as that used by rwho and ruptime,
or in an RPC mode in which each message is numbered
and only one message is "in flight" at a time.
That way lost messages can be retransmitted and there
is no danger of things getting out of order.

Hope that helps,
	Tom Truscott

-----------[000290][next][prev][last][first]----------------------------------------------------
Date:      Sun, 23 May 1993 01:07:51 GMT
From:      rene@einstein.et.tudelft.nl (Rene Bodenstaff)
To:        comp.protocols.tcp-ip
Subject:   ATM

Hi to all you network gurus,

I wanted to know something about ATM. Any info or pointers
are welcomed.

Tnx, Rene.

-- 


       ---< Sonic says: "more haste is more speed" >---

-----------[000291][next][prev][last][first]----------------------------------------------------
Date:      Sun, 23 May 1993 03:40:12 GMT
From:      gc@isag1.isa.com (George Colt)
To:        comp.unix.wizards,comp.protocols.tcp-ip
Subject:   Re: HELP: Need to implement rarp on SysV.4

Benoit_Grange@gateway.qm.apple.com (Benoit Grange) writes:
: How can I implement a rarp daemon that would answer to rarp queries ?
: Where can I read rarp paquets arriving to my machine ? And send responses
: ?
: 
: My system is a Consensys (or Unixware) SysV.4.
: ----
: Benoit Grange

Unixware comes with a rarp server. Check out the man page for rarpd.
The server code is in /usr/sbin/in.rarpd


-- 
|      George Colt                                  ISA, Inc.      |
| Email     : colt@isag1.isa.com                  Chesapeake, VA.  |

-----------[000292][next][prev][last][first]----------------------------------------------------
Date:      Sun, 23 May 1993 12:03:13 GMT
From:      rstevens@noao.edu (W. Richard Stevens)
To:        comp.protocols.tcp-ip
Subject:   Re: Info on programming SOCK_RAW type sockets

>I am looking for information or examples on programming SOCK_RAW
>type sockets.

How about a hint as to what you'd like to do with them?  If you want
to read ICMP data, take a look at the ping sources (widely available).
If you want to write your own IP datagrams, take a look at the
traceroute sources.

	Rich Stevens

-----------[000293][next][prev][last][first]----------------------------------------------------
Date:      Sun, 23 May 1993 17:28:12 GMT
From:      fschotte@risc4.physik.fu-berlin.de (Friedrich-Schotte-6119-1.4.42)
To:        comp.protocols.tcp-ip
Subject:   TCP/IP programming library for MacOS ? - Please help me

Is there a network programming library for Think C or MPW C
which is source code compatible with the UNIX socket and TCP/IP
programming Interface?
I don't really need the basic system calls, I would be happy
if there exists a library for Remote Procedure Calls
which is compatible with the SUN RPC Library.

Thank you in advance.

Friedrich Schotte
Free University of Berlin
fschotte@dec1.physik.fu-berlin.de

-----------[000294][next][prev][last][first]----------------------------------------------------
Date:      Mon, 24 May 1993 03:39:24 GMT
From:      seifert@netcom.com (Rich Seifert)
To:        comp.protocols.tcp-ip,comp.unix.solaris,comp.unix.sys5.r4,comp.protocols.misc
Subject:   Re: Reliable multi-cast comms - please help

Alistair Scott (akcs@semagl.demon.co.uk) wrote:
: We are interseted in any products which sit on-top of
: SVR4 UNIX (e.g. SunOS 5.1) which can provide a reliable 
: LAN based multi-cast messaging service, with flow-control. 
 
: We would like to use this from within a multi-threaded
: language (Ada in particular).
 
: Does anyone have experience or know of any such products
: or packages?

It is not directly targeted at running over SunOS, but the IEEE 802.1(e)
System Load Protocol is a reliable multicast (data link) protocol with 
full error and flow control. It was originally designed to allow embedded
diskless systems (e.g., bridges or intelligent NICs) to be download from
a boot server, but it can be used for any variety of multicast image
load problems. It is available from IEEE in NY (like all IEEE standards).


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

-----------[000295][next][prev][last][first]----------------------------------------------------
Date:      Mon, 24 May 1993 08:49:15 CDT
From:      <U37127@uicvm.uic.edu>
To:        comp.protocols.tcp-ip
Subject:   Re: Info on programming SOCK_RAW type sockets

In article <1993May23.120313.3330@noao.edu>, rstevens@noao.edu (W. Richard
Stevens) says:
>
>>I am looking for information or examples on programming SOCK_RAW
>>type sockets.
>
>How about a hint as to what you'd like to do with them?  If you want
>to read ICMP data, take a look at the ping sources (widely available).
>If you want to write your own IP datagrams, take a look at the
>traceroute sources.

Thank you!  Yep, I wanted to see how to write my own IP datagrams.
The traceroute sources were great, but is there a more definitive
treatment of raw sockets available in a book form perhaps?  Thanks again,
Satish Movva
Univ. Of Illinois at Chicago

>
> Rich Stevens

-----------[000296][next][prev][last][first]----------------------------------------------------
Date:      Mon, 24 May 1993 06:19:12 GMT
From:      wselig@teal.csn.org (William John Selig)
To:        comp.protocols.tcp-ip
Subject:   looking for reference for installing SLIP

Can anyone point me to a reference for installing SLIP (preferably on a sun,
but at this point I'ld take any info). I'm having trouble installing this on
a Sun4m and don't even know enough about how it's supposed to work to check
for how close I'm getting.

Thanks in advance,
--bill	wselig@csn.org


-----------[000297][next][prev][last][first]----------------------------------------------------
Date:      Mon, 24 May 1993 09:26:48 +0000
From:      proyse@peeras.demon.co.uk (Phil Royse)
To:        comp.protocols.tcp-ip
Subject:   Re: Class C Addresses & subnet masks

In article <C7CDM2.In3@jti.com> richb@jti.com writes:

>>We have only been allocated a Clump-o-Cs, and have planned on paper
>>an address structure which makes heavy use of subnetting:
>
>A little over a year ago I posted to this newsgroup with the same
>problem:  a site about to buy a bunch of routers and link 20 field
>offices onto the net, which had 10 Class C addresses.
>
>The feedback I got here was unanimous:  you'll regret subnetting your
>Class C networks like that.  Not all _client_ IP implementations support
>this. 
>
>Have Class B's already gotten hard to come by?
>
>-rich

Yes, very much so.  This solution of subnetting Class Cs has been
forced upon us by the Internet.  PIPEX, the UK Registration
Authority has rejected the client's application for a Class B.

The routers we have chosen are Cisco MGS (at the 7 main offices) and 
many 3000's at the smaller offices.

When you mentioned "client IP implementations" above, did you mean
the routers?  or the UNIX hosts & PCs etc which will be the main
user machines?

The formal tender documents I wrote and the supplier responded
to includes categorical statements that the routers will all
subnet down to the last two bits of the fourth octet.  Ie. the
allowable subnet masks are:

255.255.255.192    ...224     ...240    ...248   and  ... 252

Is this sensible?   Are there anyt other issues which might
give us some problems??  (eg. problems on the host IP capability?)

TIA  Phil

-- 

Phil Royse     Comms Consultant  | member:  The Peer Association
TUDOR HOUSE                      | (networking & OSI specialists)
12 Woodside Road, Purley           
Surrey  CR8 4LN   (UK)        Tel: (+44) 81 645-9868 

-----------[000298][next][prev][last][first]----------------------------------------------------
Date:      Mon, 24 May 93 10:46:44 GMT
From:      chris@comtech.ct.oz.au (Chris Martin )
To:        comp.protocols.tcp-ip
Subject:   Reserved IP addresses (128.0.X.X) etc


I have just discovered that the address range 128.0.X.X is reserved.
I have no idea why this address range is reserved.
Can any one enlighten us.

Some others that we have come up with are 191.255.X.X and 192.0.0.X

Cheers

Chris Martin                 chris@comtech.ct.oz.au


-----------[000299][next][prev][last][first]----------------------------------------------------
Date:      Mon, 24 May 93 12:08:13 GMT
From:      smiles@NMC.ED.RAY.COM (Kevin Ruddy)
To:        comp.protocols.tcp-ip,comp.dcom.lans.ethernet
Subject:   Re: xyplex xp-cc8-e on tcp?

In article <1993May21.225949.19760@tessi.com> joey@tessi.com (Joey Pruett) writes:
>i've unconvered one of these beasts and have talked with
>xyplex to learn that they talk some proprietary protocol
>with a vax.  i was wondering if anyone out there had maybe
>figured out how to use them in a standard tcp/ip environment.
>i realize this is not a simple task, but maybe someone has
>done it.  any info would be appreciated

Xyplex CC8Es support IP.  However, the CC8Es themselves are no longer
supported by Xyplex.  The VMS-based code is no supported beyond VMS 5.4 I
believe, but I can't recall.  You have to load them from a VMS-based
host, unless you are intending to reverse engineer the Xyplex proprietary
protocol and reimplement it on some other box.

Talk to Xyplex for official answers -- (800) HELP-XYP.
-- 
Kevin.Ruddy@NMC.ED.RAY.COM

-----------[000300][next][prev][last][first]----------------------------------------------------
Date:      Mon, 24 May 1993 12:21:10 GMT
From:      joe@cm.nctu.edu.tw ()
To:        comp.protocols.tcp-ip
Subject:   about pcip

Hi...
I have some problems about pcip:
   
   1):: I want to trace the source code,but I find that I have no document
files.Where can I get these document files??

    
   2):: As I use MSC to compile it,I find that it can't succeed.I doubt the
makefile or my compiler has problem .(I use MSC 6.0 to compile but use MSC4.0
make program)
 
   Thanks !!!!!!!!


-----------[000301][next][prev][last][first]----------------------------------------------------
Date:      24 May 93 19:09:43 MDT
From:      jrd@cc.usu.edu (Joe Doupnik)
To:        comp.protocols.tcp-ip
Subject:   Re: about pcip

In article <C7J6BA.6LM@csie.nctu.edu.tw>, joe@cm.nctu.edu.tw () writes:
> Hi...
> I have some problems about pcip:
>    
>    1):: I want to trace the source code,but I find that I have no document
> files.Where can I get these document files??
> 
>     
>    2):: As I use MSC to compile it,I find that it can't succeed.I doubt the
> makefile or my compiler has problem .(I use MSC 6.0 to compile but use MSC4.0
> make program)
>  
>    Thanks !!!!!!!!
--------
	"The whole thing", docs and all, are on netlab1.usu.edu cd pub/netwatch
and netlab.usu.edu cd [.netwatch]. Read the read.me file for navigation
information.
	Joe D. 

-----------[000302][next][prev][last][first]----------------------------------------------------
Date:      Mon, 24 May 93 13:32:10 GMT
From:      philippe@gull.world (Philippe Waroquiers)
To:        comp.protocols.tcp-ip
Subject:   non-blocking mode! and then?


Dear netters,

If you know TCP-IP and the socket interface, then perhaps you know the
answers to the following 2 questions :


I am using the socket BSD interface in non blocking mode. This works ok but
in some cases, I do not see how I can determine the state of the socket.

Question 1 (after a select for "connect"):
------------------------------------------
  a socket is created
  then set it in non blocking mode using  fcntl(2) and the flag O_NONBLOCK.
  I then use the connect(2) system call.
     The manual of connect(2) indicates then that select(2) can be used to 
     determine if the connect is succesful by selecting for writing.

If no process is listening, the select call also terminates and does not 
indicate an error.

Question is : in such a case, how do I see if the socket is connected?


Question 2 (after a select for "read"):
---------------------------------------
when a socket is selected for read, the select returns when the socket is
ready for reading. Then some data can be read.

When the remote process closes the socket or dies, the socket is always 
selectable for read but no data can be received (read returns 0 bytes but 
does not return an error).

Question is : in such a case, how do I determine that the connection is
not valid anymore ? (note : I do not want to write on the socket to see
it the socket is still valid).


Thank you for your help.



--
Philippe WAROQUIERS             Eurocontrol - Central Flow Management Unit
philippe@cfmu.eurocontrol.be    Avenue des Arts 19H
Tel: +32 2 729 33 67            B-1040 BRUSSELS
Fax: +32 2 729 32 16            Belgium

-----------[000303][next][prev][last][first]----------------------------------------------------
Date:      Mon, 24 May 1993 17:06:39 +0000
From:      steve@svlpw.demon.co.uk (Steven Pearce)
To:        comp.protocols.tcp-ip
Subject:   Software production


-- 
Steven Pearce

-----------[000304][next][prev][last][first]----------------------------------------------------
Date:      24 May 1993 17:48:48 GMT
From:      whalenm@tsg.com (Matthew Whalen)
To:        comp.protocols.tcp-ip
Subject:   TCP/IP tunnel over AppleTalk

I realize that this thought may make some cringe, but I am looking for  
some software (preferable PD) that will let me tunnel TCP/IP traffic over  
an AppleTalk WAN.  Anyone have some suggestions?

thanks

-matthew           ____      
whalenm@tsg.com    \  /    equal rights, not special rights      
(NeXTMail OK)       \/      

(My actions/words in no way reflect those of my employer.)

-----------[000305][next][prev][last][first]----------------------------------------------------
Date:      Mon, 24 May 1993 18:13:12 GMT
From:      grmensz@grmensz.erenj.com (Gary R. Menszyk)
To:        comp.protocols.tcp-ip
Subject:   Re: TN3270 and HyperCard

In article <1993May23.003121.28201@midway.uchicago.edu>, Ronald M. Hoering
<rhoering@uchicago.edu> wrote:
> 
> Hello,
> 
> I have what maybe a strange question. 
> 
> Does anyone know of a set of X-commands that would allow HyperCard to 
> access Mainframes via the INBM 3270 terminal protocol? 
> 
> I really only need to read a line at a time and send back an appropriate 
> response. My application is to login and parse out certain bits of data 
> from the text screens.
> 
> Thanks,
> 
> Ron
> 
> -----------------------------------------------------------------
> Physics Student:   "What the hell is all this math stuff anyway?"
>    Math Student:   "How the hell do I know what it is!"
>     Art Student:   "Math!?! Why ask why, Bud Dry!"

I assume you are aware of the fact that the 2.3d26+ release of tn3270
from Brown University has an API which lets other applications use it
to communicate with a mainframe via PPC or their own inter-program
communications.  Don't know if these are in the form of X-cmds, but
this should be fairly easy to do using PPC support in the current
release of HyperCard (easy for me to say since I have never built
an X-cmd or used the PPC toolbox).


Gary R. Menszyk
Exxon Research & Engineering Co.
grmensz@erenj.com

-----------[000306][next][prev][last][first]----------------------------------------------------
Date:      Mon, 24 May 1993 18:27:52 GMT
From:      "David Herron" <david@twg.com>
To:        comp.sys.sun.admin,comp.protocols.tcp-ip
Subject:   Weirdo IP routing problem

Have I got a weird problem!

Summary: Have a local ethernet at home with a couple machines.  Am
setting up SLIP to The Internet.  When the SLIP line is up, and a
default route is installed, none of the local machines are reachable.


My system:  (davids.mmdf.com)

SPARC II, SunOS 4.1.2 (no kernel level patches), using either
CSLIP v2.6 or MorningStar PPP (in SLIP mode) v1.4beta.

Remote:	     (crl.com)

Sun 4/4xx, SunOS 4.1.2, probably using CSLIP v2.6.

The network looks like:

 
                samson.mmdf.com      termy.mmdf.com
      steves.mmdf.com   |   davids.mmdf.com   |
    ----+---------------+----+---+------------+--  House network (224.42.25.0)
                             |
                             | 192.215.1.18:192.215.1.13
                             |
                      -------+-------------- CRL 192.215.1.0
 
Looks real simple, right?

When the system boots I configure a network route (224.42.25.0)
and default route (pointing to 224.42.25.1 with metric 0).  Then
when SLIP comes up, a point-point route is set up for the above
addresses, and a different default route to 192.215.1.13 with
metric 1.



In other words:

Then after shutting down the SLIP (which undoes the default route):
 
| 36 - davids.mmdf.com:david -->  netstat -in
Name  Mtu  Net/Dest      Address        Ipkts  Ierrs Opkts  Oerrs Collis Queue 
le0   1500 224.42.25.0   224.42.25.1    7673    0    6476    0    0      0     
lo0   1536 127.0.0.0     127.0.0.1      1163    0    1163    0    0      0     
| 37 - davids.mmdf.com:david --> ifconfig le0
le0: flags=63<UP,BROADCAST,NOTRAILERS,RUNNING>
        inet 224.42.25.1 netmask ffffff00 broadcast 224.42.25.255
| 38 - davids.mmdf.com:david --> ifconfig lo0
lo0: flags=49<UP,LOOPBACK,RUNNING>
        inet 127.0.0.1 netmask ff000000 
| 39 - davids.mmdf.com:david --> ifconfig sl0
sl0: flags=2010<POINTOPOINT,LINK1>
        inet 192.215.1.18 --> 192.215.1.13 netmask ffffff00 
| 40 - davids.mmdf.com:david --> arp -a
steves.mmdf.com (224.42.25.2) at 0:0:c0:7a:87:29 permanent published
termy.mmdf.com (224.42.25.3) at 0:80:96:0:7:2e
| 41 - davids.mmdf.com:david --> 
davids.mmdf.com# ping -s termy
PING termy.mmdf.com: 56 data bytes
64 bytes from termy.mmdf.com (224.42.25.3): icmp_seq=0. time=8. ms
64 bytes from termy.mmdf.com (224.42.25.3): icmp_seq=1. time=2. ms
64 bytes from termy.mmdf.com (224.42.25.3): icmp_seq=2. time=2. ms
^C
----termy.mmdf.com PING Statistics----
3 packets transmitted, 3 packets received, 0% packet loss
round-trip (ms)  min/avg/max = 2/4/8
 


The routing configuration while CSLIP'd to CRL:
 
| 29 - davids.mmdf.com:david --> netstat -rn
Routing tables
Destination          Gateway              Flags    Refcnt Use        Interface
127.0.0.1            127.0.0.1            UH       2      798        lo0
192.215.1.13         192.215.1.18         UH       0      5          sl0
default              192.215.1.13         UG       1      171        sl0
224.42.25.0          224.42.25.1          U        6      4732       le0
| 30 - davids.mmdf.com:david --> netstat -in
Name  Mtu  Net/Dest      Address        Ipkts  Ierrs Opkts  Oerrs Collis Queue 
le0   1500 224.42.25.0   224.42.25.1    5743    0    4542    0    0      0     
sl0   552  192.215.1.13  192.215.1.18   50      0    176     0    0      0     
lo0   1536 127.0.0.0     127.0.0.1      970     0    970     0    0      0     
| 31 - davids.mmdf.com:david --> ifconfig le0
le0: flags=63<UP,BROADCAST,NOTRAILERS,RUNNING>
        inet 224.42.25.1 netmask ffffff00 broadcast 224.42.25.255
| 32 - davids.mmdf.com:david --> ifconfig lo0
lo0: flags=49<UP,LOOPBACK,RUNNING>
        inet 127.0.0.1 netmask ff000000 
| 33 - davids.mmdf.com:david --> ifconfig sl0
sl0: flags=2051<UP,POINTOPOINT,RUNNING,LINK1>
        inet 192.215.1.18 --> 192.215.1.13 netmask ffffff00 
| 34 - davids.mmdf.com:david --> arp -a
steves.mmdf.com (224.42.25.2) at 0:0:c0:7a:87:29 permanent published
termy.mmdf.com (224.42.25.3) at 0:80:96:0:7:2e
 
And attempts to reach a local host then:
 
PING steves.mmdf.com: 56 data bytes
^C
----steves.mmdf.com PING Statistics----
71 packets transmitted, 0 packets received, 100% packet loss
davids.mmdf.com# !!
ping -s steves
PING steves.mmdf.com: 56 data bytes
^C
----steves.mmdf.com PING Statistics----
476 packets transmitted, 0 packets received, 100% packet loss



I've had a couple different people, all experienced with configuring
IP routing, double check me here.  We all agree it looks right.


So ... any ideas?

The netmasks are right, and there is a route (metric 0) for the local
network.  The two machines even have arp entries ... Yet during that
ping just above, I could see the send/receive lights flickering at the
same rate as a ping.  Further, since MorningStar put in such excellent
logging, you can see from there that the packets for the local net are
going out the SLIP line.

Do I need to provide more information?  I tried to be complete ...

Is there anything I should try?  I tried to try everything ...

Please... if you respond by mail, send to david@twg.com or
david@davids.mmdf.com.


	Thank you,

		David Herron


-----------[000307][next][prev][last][first]----------------------------------------------------
Date:      Mon, 24 May 1993 19:06:24 +0000
From:      steve@svlpw.demon.co.uk (Steven Pearce)
To:        comp.protocols.tcp-ip
Subject:   Software production

**********************Analyst/Programmers*********************************
*************************for hire*****************************************

Do you have any requirements in the following areas?

C
C++
Unix
Motif
OSI
X400
TCP-IP

If not then read no further. If you do then consider the following.

We have a SCO Unix based development system, a link to the Internet
for E-mail and expertise in all of the above.

We can supply quality software at very competitive prices. All software
will be supplied on a trial basis and we will provide free quotations.

Anything tackled, from bespoke packages to maintenance, from large
applications to small programs and scripts.

Interested?

Contact Steve Pearce or Vivienne Walker in one of the following ways.
E-mail steve@svlpw.demon.co.uk
Phone UK 0602 463106


-----------[000308][next][prev][last][first]----------------------------------------------------
Date:      Mon, 24 May 1993 20:55:40 +0000
From:      mark@kram.org (Mark Turner)
To:        comp.protocols.tcp-ip
Subject:   Ever increasing RTT!

One of our connected sites is experiencing a wierd problem. He
dials into our gateway using Morningstar PPP on a SCO ODT machine.
Our gateway runs MST PPP on SCO. Every time he logs in and either
of us pings the other we see an ever increasing RTT! I do not
believe that MST is causing the problem as I remember seeing a
similar problem between 2 machines on our ethernet a while ago. We
have dozens of sites dialing into the same machine in the same way
with no problems and I can't find any obvious difference with the
affected site.

Can anyone give me any clues where I should look?

Regards,

Mark.
-- 
/\/\ark Turner                       Demon Systems / Demon Internet
Home: mt@kram.org (PGP key available)        42 Hendon Lane, London
Office: mark@demon.co.uk (+44 81 3490063)           N3 1TT, England
*** IP level dialup Internet connectivity for a tenner a month! ***

-----------[000309][next][prev][last][first]----------------------------------------------------
Date:      24 May 93 21:03:30 GMT
From:      wew@nuxi.ucc.nau.edu (Bill Wilson)
To:        comp.protocols.tcp-ip
Subject:   Public NFS for Mac?

Is there a public nfs for the Mac that runs with Mactcp?  We would
also like rmt and tar is there is.

--
Let sleeping dragons lie........                    | The RoleMancer 
--------------------------------------------------------------------
William Wilson (wew@naucse.cse.nau.edu | wilson@nauvax)
Northern AZ Univ  Flagstaff, AZ 86011
-- 
Let sleeping dragons lie........                    | The RoleMancer 
--------------------------------------------------------------------
William Wilson (wew@naucse.cse.nau.edu | wilson@nauvax)
Northern AZ Univ  Flagstaff, AZ 86011

-----------[000310][next][prev][last][first]----------------------------------------------------
Date:      24 May 1993 23:13:47 GMT
From:      tli@cisco.com (Tony Li)
To:        comp.protocols.tcp-ip
Subject:   Re: Reserved IP addresses (128.0.X.X) etc

In article <1993May24.104644.21289@comtech.ct.oz.au> chris@comtech.ct.oz.au
(Chris Martin ) writes: 
    
    I have just discovered that the address range 128.0.X.X is reserved.
    I have no idea why this address range is reserved.
    Can any one enlighten us.
    
    Some others that we have come up with are 191.255.X.X and 192.0.0.X
    
These were reserved because they are the corner cases in the Class system,
and would likely lead to confusion.  For example, is 191.255.255.255 a
broadcast to all Class B networks?  ;-)

Tony

-----------[000311][next][prev][last][first]----------------------------------------------------
Date:      Tue, 25 May 93 01:07:22 GMT
From:      jbell@pdev.ga.oz.au (John Bell)
To:        comp.protocols.tcp-ip
Subject:   Newbie TCP/IP Programming Problem


Hi all,
	I'm fairly new to TCP/IP programming (I've only read about 1/3 of the
Stevens book) and need some help with a project that has landed on my desk.

A customer of mine has a Unisys host running Burroughs Poll/Select which is
connected to a Sun.  The Sun has a Hardware/Software package that allows
anyone with a vt220 terminal to engage in an interactive session with Unisys
apps.  They want to purchase a 486 server running Advanced Pick (a database
product) under SCO Unix.  This will be connected to the Sun via E-net.  The
AP application needs to call a C subroutine which will log into the Unisys
host, make a query, massage the return screen output and return it to the AP
application as a formatted string.

It seems to me that I have to open a pty pair on the SCO host, bind it to
the Sun IP address and perhaps talk to its' telnet port.  Am I going in the
right direction or barking up the wrong tree?  Can anybody give me some idea
of how to code this?

*NOTE* My MX record is not yet in place, so if you want to reply by Mail rather
than using the newsgroup please send to ronny@mhs.oz.au who will forward your
response to me.

Thanks in advance

John Bell
jbell@pdev.ga.oz.au
+61-3-522-2211

-----------[000312][next][prev][last][first]----------------------------------------------------
Date:      25 May 93 02:24:25 GMT
From:      trt@duke.cs.duke.edu (Tom Truscott)
To:        comp.protocols.tcp-ip
Subject:   Re: non-blocking mode! and then?

>Question is : in such a case, how do I see if the socket is connected?

If getpeername() succeeds, the socket is connected.


>When the remote process closes the socket or dies, ...
>Question is : in such a case, how do I determine that the connection is
>not valid anymore ? (note : I do not want to write on the socket to see
>it the socket is still valid).

Hmm, "not valid" is a bit fuzzy.  A read (of non-zero amount) that returns 0
indicates you will never get any more data from the socket.
But you can still write to the socket if getpeername() succeeds
and your program has not called shutdown(WRITE)
and there is room left in the socket send buffer. 
Fuzzy enough?  (Alas, the socket API is a bit odd.)

Tom Truscott

-----------[000313][next][prev][last][first]----------------------------------------------------
Date:      Tue, 25 May 1993 03:58:29 GMT
From:      a866700@hp9000.csc.cuhk.hk (Wong Siu To)
To:        comp.protocols.tcp-ip
Subject:   FTP: Use PD version or write one ?

Hi there,

I apologize if this's a FAQ, and if this group is not the right place to
ask...

I'd like to know if there's 'configurable' ftp software available on the
net.  We're going to set up an anonymous ftp server soon and want to
have some features to keep track of the usage, e.g. 

- number of active ftp connections
- file size limit in file upload/download
- user information (hostname/IP address, session duration, files
  accessed, etc.)
- customized messages to be displayed
- etc.

We're also considering to write one to fit our requirement if we've
sufficient time ... :-(

Would anyone please advise ?  Thanks in advance.

Regards,
-- 
S.T. Wong             	            | BITNET: A866700@CUCSC.BITNET      
Computer Services Centre            | Internet: st-wong@cuhk.hk 
The Chinese University of Hong Kong | Tel. No: (852) 609 8825      
Shatin, N.T., Hong Kong	            | FAX  No: (852) 603 5001

-----------[000314][next][prev][last][first]----------------------------------------------------
Date:      24 May 1993 16:54:04 +0800
From:      dinesh@mail-server.bass.my (Dinesh Arnold Nair)
To:        comp.protocols.tcp-ip
Subject:   Re: looking for reference for installing SLIP

In article <wselig.738224352@teal> wselig@teal.csn.org (William John Selig) writes:
>Can anyone point me to a reference for installing SLIP (preferably on a sun,
>but at this point I'ld take any info). I'm having trouble installing this on
>a Sun4m and don't even know enough about how it's supposed to work to check
>for how close I'm getting.
>
>Thanks in advance,
>--bill	wselig@csn.org
>

                                   /\_/\   "All dogs go to heaven."
                                   (0 0)
+==========================----oOO--(_)--OOo----============================+
| Dinesh Nair (dinesh@bass.my)     /    Surface Address :                   |
| Software Engineer                \    8th Floor, Menara SMI,              |
| Technical Services Group         /    6 Lrg P Ramlee, 50250 Kuala Lumpur  | 
| Bass Consulting                  \    Malaysia.   Tel : 03-2305588        |
+===========================================================================+

-----------[000315][next][prev][last][first]----------------------------------------------------
Date:      Tue, 25 May 1993 13:26:34 GMT
From:      ramon@cantabria.cber.nih.gov (Ramon J. Hontanon)
To:        comp.protocols.tcp-ip.ibmpc,comp.protocols.tcp-ip
Subject:   DECnet & TCP/IP. Can they co-exist???

Hello all,

We have the need to do FTP file transfer from/to a PC that is currently
 running a  DECnet client in an all-DECnet ethernet.  My question is:

- Will we need to reboot the machine to load the TCP/IP drivers after
    having run DECnet for awhile?

- Will we need to edit any config files before starting the FTP transfer?

- How well do TCP/IP and DECnet packets coexist on the same ethernet?
   (the network admin was hesitant about allowing us to do this)

We'd appreciate any comments/experiences, as well as advice as to 
what TCP/IP package to install. (All we need is FTP, no Telnet, SMTP, etc.)

Best regards,

Ramon

-- 
___________________________________________________________________
                     Ramon J. Hontanon,  KE8SF                    
                        ramon@helix.nih.gov
          CBER FDA, 8800 Rockville Pk. Bethesda, MD 20892           
                          (301) 496 0718 


-----------[000316][next][prev][last][first]----------------------------------------------------
Date:      Tue, 25 May 93 15:07:15 GMT
From:      horn@schaefer.math.wisc.edu (Jeffrey Horn)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.pc
Subject:   SLIP Recommendations

I was wondering if anyone could tell me about some good SLIP
implementations.  I am trying to connect remote PC's to a central
Sun 690.  The connections will not be up 24 hours/day, but rather
about 4-6 hours/day.  

Could anyone help me as to reasonable modem and phone line specs
as well?  Is there any software or hardware that can manage several
slip connection through a single serial line?

Thanks for your help!!!

Jeffrey Horn

-----------[000317][next][prev][last][first]----------------------------------------------------
Date:      Tue, 25 May 1993 15:49:32 GMT
From:      drubin@poly.edu (Dave Rubin)
To:        comp.sys.sun.admin,comp.protocols.tcp-ip
Subject:   Synchronous serial line IP on a SUN?


Is there a way to use a synchronous serial connection as an IP link
(e.g., PPP) between two SUN SPARCstation 2 machines (i.e., without the
need for a sync to async converter)?
 
Thanks... please respond via E-mail.

--
Dave Rubin
Polytechnic University
drubin@poly.edu

-----------[000318][next][prev][last][first]----------------------------------------------------
Date:      Tue, 25 May 93 16:16:02 GMT
From:      oberman@ptavv.llnl.gov
To:        comp.protocols.tcp-ip
Subject:   RE: MacTCP 1.1.1 and DNS...

In Article <1993May20.184813.2879@wixer.bga.com>
pug@wixer.bga.com (Pug) writes:

>   We have an ethernet network with a lot of Mac's on it. We have MacTCP
>1.1.1 running on them and generally use NCSA Telnet 2.5. This is
>happening on all of our Macs so I don't think it's System dependant.
>What the problem is is this - When using MacTCP and having more then one
>server per domain, which is rather standard to have a primary and
>secondary server incase the primary is down, if the primary *is* down,
>it will not use the secondary for the domain. You have to change the
>default setting and then reboot. Well this is not an acceptable
>solution. It will go on to any server under another domain name though.
>The reason that we need a solution is our primary server is moving and
>we want people to still be able to access other computers when it does.

No one else has answered, so I'll throw in my un-informed 2 bits.

The way to configure DNS is weird and totally undocumented (by Apple). The
first entry (or, at least the one marked DEFAULT should be the local domain
name and the address of the primary:
bga.com	198.3.116.3 *

Then configure your secondaries as:
	198.3.116.3
	137.39.1.3
and so on.

Yes, this is weird, but so is MacTCP. (Please note that the primary is listed
twice, once for the local domain and once for root. This does not really mean
that either the primary or the secondary is a root server. It means that
requests for address in any domain under the root should go there.

If you really want to keep all of your requests going to on system, list it
first after the local domain. If you want to split the load , list them in
reverse order.

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

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

-----------[000319][next][prev][last][first]----------------------------------------------------
Date:      Tue, 25 May 93 16:22:25 GMT
From:      oberman@ptavv.llnl.gov
To:        comp.protocols.tcp-ip
Subject:   RE: DECnet & TCP/IP. Can they co-exist???

In Article <1993May25.092634@cantabria.cber.nih.gov>
ramon@cantabria.cber.nih.gov (Ramon J. Hontanon) writes:
>Hello all,
>
>We have the need to do FTP file transfer from/to a PC that is currently
> running a  DECnet client in an all-DECnet ethernet.  My question is:
>
>- Will we need to reboot the machine to load the TCP/IP drivers after
>    having run DECnet for awhile?

Shouldn't need to. (I can't speak for all packages, but those using NDIS
drivers (or any properly written ones) should have no trouble talking both.

CAVEAT!!! Because DECnet will rewrite the physical address of the Ethernet, it
MUST start before IP.

>- Will we need to edit any config files before starting the FTP transfer?

Shouldn't need to. The protocols are totally indepentdent and have no reason to
know that the other exists.

>- How well do TCP/IP and DECnet packets coexist on the same ethernet?
>   (the network admin was hesitant about allowing us to do this)

Just fine. I have about 1000 DECnet and 5000 IP nodes on my Ethernet (routed)
and about 50 DECnet and 300 IP on the local net. All of it works just fine.
Ethernet was designed to support this operation.

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

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

-----------[000320][next][prev][last][first]----------------------------------------------------
Date:      25 May 93 16:35:51 GMT
From:      jordan@IMSI.COM (Jordan Hayes)
To:        comp.protocols.tcp-ip
Subject:   Re: non-blocking mode! and then?

Philippe Waroquiers <philippe@gull.world> writes:

	[ non-blocking connect(), select for write ... ]

	in such a case, how do I see if the socket is connected?

(this is under UNIX)

If connect() returns EINPROGRESS, you can select() for write.  When it
returns, you need to check out what happened.  I just call connect()
again.  If it worked, connect() will return -1 and set errno to
EISCONN; if the connect() failed, the socket will be trashed by now (so
connect() will set errno to EINVAL, since the socket is no longer
valid), but there's a socket option to retrieve the reason it failed in
the first place, so you can retrieve it and slam that reason into errno
for reporting to the user ...

Here's some code:

	int			fd, i, len;
	struct sockaddr_in	local;
	extern int		errno;

	/* try to connect again */
	bzero((char *)&local, sizeof(local));
	len = sizeof(local);
	if (connect(fd, (struct sockaddr *)&local, len) < 0)
		switch (errno) {
		case EISCONN:
			/* worked! */
			break;
		case EINVAL:
			len = sizeof(i);
			if (getsockopt(fd, SOL_SOCKET, SO_ERROR,
			    (char *)&i, &len) < 0)
				Warn("%t getsockopt(%d, SO_ERROR): %m", fd);
			else
				errno = i;
			/*FALLTHROUGH*/
		default:
			Warn("%t connect(%d): %m", fd);
			(void)close(fd);
			/* other cleanup */
			return;
		}

/jordan

-----------[000321][next][prev][last][first]----------------------------------------------------
Date:      25 May 1993 17:51:46 GMT
From:      raghu@ecst.csuchico.edu (Raghu Madhok)
To:        comp.protocols.tcp-ip
Subject:   MTU for ethernet

	I would like to send UDP datagrams between two machines as quick as
	possible.  To avoid segmentation at any of the protocol layers, I
	need to know the Maximum Transmission Unit (MTU) for ethernet, and
	the size of the UDP, IP, and ethernet headers appended to each packet.
	This will give me the maximum number of bytes of data I can squeeze
	into each (datagram) packet.

	If it makes a difference, I am doing this between two Sun
	SparcStations currently running 4.1.2.

	Any help on this subject would be appreciated.  Please send replies
	to my e-mail address.



	...Raghu

	raghu@ecst.csuchico.edu

-----------[000322][next][prev][last][first]----------------------------------------------------
Date:      25 May 1993 18:05:20 GMT
From:      trier@odin.ins.cwru.edu (Stephen C. Trier)
To:        comp.sys.mac.programmer,comp.sys.mac.apps,comp.sys.mac.comm,comp.protocols.tcp-ip,comp.protocols.tcp-ip.domains
Subject:   Re: MacTCP 1.1.1 and DNS...

MacTCP's domain name server setup is braindead.  The "domain"
asssociated with each server restricts the queries that will be sent to
that server.  To make things worse, the domain associated with the
first server in the list is used as the Mac's domain.  It seems whoever
designed this was rather unfamiliar with how DNS usually works.

The workaround is to list the first server twice.  Set up your
configuration like this:

     <server 1>      .macs.domain.name
     <server 2>      .
     <server 1>      .

The "." means "this server can handle queries for all domains".  You
have to list a real domain the first time in order to let the Mac know
its domain, then you need to list both servers with the "." wildcard so
that you have fallback from one to another.

I've redirected followups to only comp.protocols.tcp-ip.  Please don't
cross-post as widely as you did.  ONE group is sufficient.  Pick the
best and use it.

-- 
Stephen Trier (trier@ins.cwru.edu - MIME OK)   
Network Software Engineer              
IRIS/INS/T                               
Case Western Reserve University             

-----------[000323][next][prev][last][first]----------------------------------------------------
Date:      Tue, 25 May 1993 18:18:05 GMT
From:      vjs@rhyolite.wpd.sgi.com (Vernon Schryver)
To:        comp.protocols.tcp-ip
Subject:   Re: DECnet & TCP/IP. Can they co-exist???

In article <1tth3o$iak@lll-winken.llnl.gov>, oberman@ptavv.llnl.gov writes:
> >- Will we need to reboot the machine to load the TCP/IP drivers after
> >    having run DECnet for awhile?
> 
> Shouldn't need to. (I can't speak for all packages, but those using NDIS
> drivers (or any properly written ones) should have no trouble talking both.
> 
> CAVEAT!!! Because DECnet will rewrite the physical address of the Ethernet, it
> MUST start before IP.
> ...

That depends on the system.  A system can (and some do) repeat the ARP
announcement of the IP-Ethernet mapping when DECnet is started and
changes the mapping.  On some such systems it is practically impossible
and fortunately unnecessary to start DECnet before IP.


Vernon Schryver,  vjs@sgi.com

-----------[000324][next][prev][last][first]----------------------------------------------------
Date:      25 May 93 18:47:09 GMT
From:      henry@ice03.uts.amdahl.com (Henry Cho)
To:        comp.protocols.tcp-ip
Subject:   Re: SLIP Recommendations

In article <1993May25.150715.16807@schaefer.math.wisc.edu>, horn@schaefer.math.wisc.edu (Jeffrey Horn) writes:
|> I was wondering if anyone could tell me about some good SLIP
|> implementations.  I am trying to connect remote PC's to a central
|> Sun 690.  The connections will not be up 24 hours/day, but rather
|> about 4-6 hours/day.  
|> 
|> Could anyone help me as to reasonable modem and phone line specs
|> as well?  Is there any software or hardware that can manage several
|> slip connection through a single serial line?
|> 
|> Thanks for your help!!!
|> 
|> Jeffrey Horn

I suggest you invest in a Xyplex TCP/IP terminal server.  It is capable of
routing incoming SLIP packet to TCP/IP packet.  So what you need is to
connect a few 9600 baud modems to the terminal connector and connect the 
etherport to you Sun 690 and up you running.  By the way SLIP are 
point-to-point connection, it run on a single serial and cannot be share by 
multiple SLIPs, unlike PPP which allow other application to share the serial
port.  What you need is a few rotary phone line connect the those modem which
in turn connect to the terminal server on the terminal side so that who ever
dial in can be automatically connect to a free terminal port using the same
phone number.

-----------[000325][next][prev][last][first]----------------------------------------------------
Date:      25 May 93 18:48:11 GMT
From:      arshad@dcs.ed.ac.uk (Arshad Mahmood)
To:        comp.protocols.tcp-ip,comp.protocols.ppp
Subject:   PPP Patch Level 6 problem

Hi,

	I am having a small problem trying to run the public domain PPP by
Karl Fox. Whenever a remote machine call's my machine and I start up PPP
it says "/dev/cua0: Locked". I am running PPP patch level 6 on a
Sun Sparc IPC (SunOS 4.1.3), my modem is a Miracom V.32 bis Fax (handles
up 14,400 baud). I have no problem calling the remote site (using a 
variation on Karl's chat script), so I think my PPP is built and configured
into the kernel O.k. I could not find any lock files anywhere in /var/spool
or /tmp, so I am wondering whether my getty when it answers the phone is
locking the modem device.

	Does anybody have any idea what I'm doing wrong ? Any help much
appreciated.

Regards,
A. Mahmood
Edinburgh
e-mail: arshad@dcs.ed.ac.uk

-----------[000326][next][prev][last][first]----------------------------------------------------
Date:      25 May 93 18:54:53 GMT
From:      don@lclark.edu (Don Weston)
To:        comp.dcom.sys.cisco,comp.protocols.tcp-ip
Subject:   IP Routing Questions on Subnet Masks and Multicasting


Hello,

I have a series of relatively straight forward IP routing questions which
are primarily focused on creative IP mask construction and multicasting
addresses.

The scenario is this:  we have a class B Internet address, but the component
class C addresses are spread randomly (by department) across the campus.  In
our Library for example we have 16.0, 20.0, 28.0, and 51.0.  These four
share one logical ethernet segment.  This segment is connected via Cisco
IGS+ to the "backbone" ethernet.

In the case of the Library the four subnets do not show up on the backbone,
but any of the 250 others could.  The backbone has the mask of 255.255.0.0.
This makes it difficult to route between the library and the campus since
the router sees on one port the whole class B address and on the other four
component class C nets which because of the masking appear to live on both
sides of the router.

As a short term fix I told the router that both sides were class C
addresses, and then used Cisco's multicast feature to add more class C
subnets.  This strikes me as inefficient, since it appears the router is in
effect rebroadcasting multiple class C packets when what I want is one
packet which gets to the appropriate places.

After doing some reading it looks like routing would be more efficient if I
reassigned the IP net numbers to be adjacent and created an appropriate net
mask.  This way the netmask would do the work and I would not have to rely
on multicasting.  I assume this is how the Internet folks band together Class C
addresses for institutions who joined the game too late to get a Class B.

Two to four class C addresses together seem to be the appropriate size for a
subnet.  (especially if we get a collapsed backbone router with under ten
ports and end up running large portions of campus on one logical ethernet.)

Our new configuration could look something like this:  
(This is off the cuff so I may have botched the mask, 
but hopefully the idea comes across.)


Subnet A: Mask 255.255.252.0
149.175.1.0 
149.175.2.0
149.175.3.0
149.175.4.0

Subnet B: Mask 255.255.252.0
149.175.5.0 
149.175.6.0
149.175.7.0
149.175.8.0

Subnet C: etc...
	Further subnetting would be simple under this model.

I understand that most people out there stick with class C addresses, but
these are not quite big enough for what we need to do.  Has anyone
experienced pitfalls with going to a nonstandard netmask?  Does this
particular scheme look right?  Is multicasting really better?
Do the nonstandard netmasks confuse some implementations of IP software such 
as MacIP, NCSA Telnet, SunOS, etc? 


	All comments gratefully accepted. 

... ... ... ... ....		Don Weston, Jr.		  .... ... ... ... ...
				Network Manager
				Lewis & Clark College
... ... ... ... ....		don@lclark.edu		  .... ... ... ... ...

-----------[000327][next][prev][last][first]----------------------------------------------------
Date:      25 May 1993 20:08:03 GMT
From:      tli@cisco.com (Tony Li)
To:        comp.protocols.tcp-ip
Subject:   Re: MTU for ethernet

In article <1ttmbiINNfg8@charnel.ecst.csuchico.edu> raghu@ecst.csuchico.edu
(Raghu Madhok) writes: 
    	I would like to send UDP datagrams between two machines as quick as
    	possible.  To avoid segmentation at any of the protocol layers, I
    	need to know the Maximum Transmission Unit (MTU) for ethernet, and
    	the size of the UDP, IP, and ethernet headers appended to each packet.
    	This will give me the maximum number of bytes of data I can squeeze
    	into each (datagram) packet.
    
Ethernet can support up to 1500 bytes, including the IP and UDP header, but
excluding the MAC layer.

But a better solution is to use ICMP Path MTU Discovery.

Tony

-----------[000328][next][prev][last][first]----------------------------------------------------
Date:      Tue, 25 May 1993 22:33:26 GMT
From:      alun@huey.wst.com (Alun Jones)
To:        comp.protocols.tcp-ip
Subject:   Re: MacTCP 1.1.1 and DNS...

In article <1ttn50$rje@usenet.INS.CWRU.Edu> trier@odin.ins.cwru.edu (Stephen C. Trier) writes:
>MacTCP's domain name server setup is braindead.  The "domain"

As a PC user who has been branded our company's Internet expert, I've been
asked by several Mac users how we can connect them to the Internet.  Is
Mac TCP the only/best way to do this?

All our Macs have ethernet boards, and are talking across the same ethernet
branches as our PCs that run packet driver software to get to the internet.
I would appreciate guidance as to what software I can get that will allow
me to give the people on the Macs the same access to Internet as those of
us on PCs.

Thanks,

Alun.
~~~~

-----------[000329][next][prev][last][first]----------------------------------------------------
Date:      Wed, 26 May 1993 06:53:18 GMT
From:      rob@sybase.com (Rob Cook)
To:        comp.protocols.tcp-ip
Subject:   Help with 'discovering' a client end connection died...

I've run into a problem in a few customer environments where a client 
(PC under DOS/Windows in this case), connected to a server via sockets
dies, but the server is never (apparently) notified. The server, if 
it attempts a write on the socket, will of course be notified that
the socket is dead on the client side. My problem is that if the client
and server are idle, and *then* the client dies, the server is not aware
of the condition, and it keeps the context and associated memory&socket 
descriptor resources, eventually running out of free ones. I've fiddled w/
linger, keepalive, etc., to no avail. I'd like to provide a 'heartbeat'
type of functionality between the client and server so that the 'heartbeat'
can detect the client is gone, then notify the server (once I can discover
a dead/gone client, I can easily notify my server). Ideally, I'd like to
be able to do the equivalent of a 'ping' to the specific client-side port
to see if it's still there, without interfering with any of the client/server
interaction. It is important that this be transparent to the existing client
and server processes (other than the fact that this 'heartbeat' process
can notify the server when a dead/gone connection is detected).
I've though of trying to open the client address&port after
a period of inactivity on the connection, though I'm not sure that would
work. I'm sure there is a relatively easy way of doing this, yes?
*Any* pointers/hints/help/etc. will be *most* appreciated.
Premptive apologies if this is a FAQ item, I'm fresh to this group, and 
just as fresh to low-level tcp/socket programming.
Please reply directly to e-mail below, or call if desired.

Regards,
Rob

rob@sybase.com
(510)596-3443



-----------[000330][next][prev][last][first]----------------------------------------------------
Date:      Wed, 26 May 1993 11:54:16 +0000
From:      proyse@peeras.demon.co.uk (Phil Royse)
To:        comp.protocols.tcp-ip
Subject:   Re: Super-TCP

In article <C7Dvpn.AyH@unccsun.uncc.edu> jpb@jpbpc1.uncc.edu writes:

>I have just finished Tested the following nine competing products:
>        PC/TCP from FTP Software
>        ChameleonNFS from NetManage
>        Pathway Access from Wollongong
>        Lan Workspace for DOS from Novell
>        3Com TCP from 3Com
>        Sun PC-NFS from SunSoft V5.0
>        IBM TCP/IP V2.1 from IBM
>        Beam & Whiteside NFS V3.0a from Beam & Whiteside
>        Super-TCP From Frontier Technologies V3.0 R1
 
>Super-TCP from Frontier Technologies is the only software that meets all of our
> basic requirements.

This is very interesting.  Please could you give more information and
feedback from your tests?

How can I contact Frontier Technologies?  What is their Internet
address?

TIA

Phil R.

-- 

Phil Royse     Comms Consultant  | member:  The Peer Association
TUDOR HOUSE                      | (networking & OSI specialists)
12 Woodside Road, Purley           
Surrey  CR8 4LN   (UK)        Tel: (+44) 81 645-9868 

-----------[000331][next][prev][last][first]----------------------------------------------------
Date:      26 May 93 13:49:59 GMT
From:      frankc@teleng.eng.telxon.com (Frank Ciotti)
To:        comp.protocols.tcp-ip
Subject:   RFC for keepalives


Is there an RFC for TCP keepalive polls?  I could not find any reference
to them in the RFC index, RFC 793, RFC 896, or the Comer/Stevens books.

Thanks for any help.

Frank Ciotti
frankc@telxon.com
Telxon Corp.
Akron, OH

-----------[000332][next][prev][last][first]----------------------------------------------------
Date:      Wed, 26 May 1993 15:25:22 GMT
From:      rob@icarus.inmos.co.uk (Robin Pickering)
To:        comp.sys.sun.admin,comp.protocols.tcp-ip
Subject:   Re: Weirdo IP routing problem

In article <1993May24.182738.511@twg.com> "David Herron" <david@twg.com> writes:
>Have I got a weird problem!
 ...
>
>When the system boots I configure a network route (224.42.25.0)
>and default route (pointing to 224.42.25.1 with metric 0). 

This is the problem!. You should not set up a route for the locally
connected network as this will have a hard-wired route entry by default.
By definition a default route should not have a 0 metric as this is only
for routes where the *target* host is on the local net (not the gateway)

Your configuration then should be:

Gateway (davids.mmdf.com):

SLIP down: No routes

SLIP up:  default route 192.215.1.13 metric >= 1
          (i.e. route add default 192.215.1.13 1)


Other Nodes:
 default route 224.42.25.1 metric >= 1


In practice however you may as well set up the default route on the gateway
at start-up and leave it irrespective of the status of the SLIP line. When
the SLIP interface is down the gateway will toss the packet and send an ICMP
unreachable net just the same as if it had no route.

The metric 0 case in the route table is only for use in the specific case
where a host address which isn't on the local net actually has another
interface which is directly connected to the local net.

--
    Rob Pickering.

-----------[000333][next][prev][last][first]----------------------------------------------------
Date:      26 May 1993 16:06:10 GMT
From:      pkrishna@cs.tamu.edu (P. Krishna)
To:        comp.protocols.tcp-ip
Subject:   FAQ


Could someone send me or direct me to a FAQ for this group?

Thanks!
Krishna.

P. Krishna
FTCL, Computer Science Dept.
Texas A&M University.


-----------[000334][next][prev][last][first]----------------------------------------------------
Date:      26 May 93 16:17:15 GMT
From:      wew@nuxi.ucc.nau.edu (Bill Wilson)
To:        comp.protocols.tcp-ip
Subject:   Macs on Ethernet & backup.

Is anyone out there backing up Macs to vhs or dat tape drives
on Unix servers?  Anyone doing it to a file on a Unix system?
If so, are you using TCP/IP or some form of localtalk?
If localtalk, is it public domain?

--
Let sleeping dragons lie........                    | The RoleMancer 
--------------------------------------------------------------------
William Wilson (wew@naucse.cse.nau.edu | wilson@nauvax)
Northern AZ Univ  Flagstaff, AZ 86011
-- 
Let sleeping dragons lie........                    | The RoleMancer 
--------------------------------------------------------------------
William Wilson (wew@naucse.cse.nau.edu | wilson@nauvax)
Northern AZ Univ  Flagstaff, AZ 86011

-----------[000335][next][prev][last][first]----------------------------------------------------
Date:      Wed, 26 May 1993 16:27:36 GMT
From:      lapp@waterloo.hp.com (David Lapp)
To:        comp.protocols.tcp-ip
Subject:   Re: RFC for keepalives

Frank Ciotti (frankc@teleng.eng.telxon.com) wrote:

: Is there an RFC for TCP keepalive polls?  I could not find any reference
: to them in the RFC index, RFC 793, RFC 896, or the Comer/Stevens books.

One of the Host Requirements RFCs (RFC 1122) does discuss
tcp keepalives. I'm not sure of any other RFCs which might.

Dave Lapp

Standard Disclaimer etc...

-----------[000336][next][prev][last][first]----------------------------------------------------
Date:      26 May 93 17:31:47 GMT
From:      nellied@dingo.ca.boeing.com (Nellie Diaz)
To:        comp.protocols.tcp-ip,comp.unix.questions
Subject:   tftp transfer time out

I had a user complain about a 30MB file size transfer limitation with tftp.
Since they have installation files that exceed that size and don't want to
have a login for every person that needs the software, this presents a problem.
The person that complained to me was transferring between IBM RS6k's, so I
did some testing in my lab with tftp transfers between 2 IBM RS6k's (models
520 & 530), between 2 Sun Sparcstations and between 2 HP 9000 (model 7xx).
The IBM got a transfer timeout error at 33+ MB (out of a 52MB file).  I
increased the max timeout to 60 seconds and it still timed out in the exact
same spot.  Both the Sun's and HP's timed out at 16.6 MB (out of a 63MB and
72MB file respectively).  I increased the max timeout to 60 & 120 seconds and
they still timed out at 16.6MB transferred.  Anyone out there have any ideas
as to what is going on?  Is this a tftp limitation or a platform dependant
limitation?

I would appreciate direct email as I don't always have time to read netnews
and when I do, I usually only get through comp.unix.aix.  Thank you in advance
for all responses.

-- 
Nellie Diaz        nellied%rstech3@atc.boeing.com    ___ ___ ___ ___     ___
UNIX Server Technical Services                      /__//  //__  /  /\ //  _
+1 206 957-5352              =-=-=-=-=-=-=-=-=-=   /__//__//__ _/_ /  //__/
All statements are my own, not Boeings.               Computer Services

-----------[000337][next][prev][last][first]----------------------------------------------------
Date:      26 May 1993 17:50:09 GMT
From:      emv@garnet.msen.com (Edward Vielmetti)
To:        comp.protocols.tcp-ip
Subject:   Re: RFC for keepalives

Frank Ciotti (frankc@teleng.eng.telxon.com) wrote:

: Is there an RFC for TCP keepalive polls?  I could not find any reference
: to them in the RFC index, RFC 793, RFC 896, or the Comer/Stevens books.

A quick WAIS search of "internet-rfcs" for "keepalive" or "keepalives"
threw up references to these RFCs - I don't know how much they say about
them tho (someoen who could condense these referecnes into something
useful would be welcomed).

rfc1267.txt rfc1163.txt rfc1105.txt rfc969.txt rfc998.txt rfc1323.txt
rfc1265.txt rfc1164.txt


: Thanks for any help.
 
: Frank Ciotti
: frankc@telxon.com
: Telxon Corp.
: Akron, OH

-----------[000338][next][prev][last][first]----------------------------------------------------
Date:      Wed, 26 May 1993 19:41:08 GMT
From:      richb@tps.COM (Richard Bourassa)
To:        comp.protocols.tcp-ip
Subject:   NNTP News Reader for Macintosh

Hello!

Does anyone know of a PD NNTP News Reader for the Macintosh?  If so, can I 
get it from an anonymous FTP site?  I am trying to find something along the 
lines of Trumpet, but for a Macintosh.  I would be thrilled to death to find 
out that there is a version of Trumpet for the Mac!

any help is greatly appreciated!
Thanks,
Rich
richb@tps.com
(PS please respond via eMail if possible.)

-----------[000339][next][prev][last][first]----------------------------------------------------
Date:      Wed, 26 May 1993 19:53:00 GMT
From:      vjs@rhyolite.wpd.sgi.com (Vernon Schryver)
To:        comp.protocols.tcp-ip
Subject:   Re: SLIP Recommendations

In article <1bCs03fAd3YP00@amdahl.uts.amdahl.com>, henry@ice03.uts.amdahl.com (Henry Cho) writes:
> 
> I suggest you invest in a Xyplex TCP/IP terminal server.  It is capable of
> routing incoming SLIP packet to TCP/IP packet.  So what you need is to
> connect a few 9600 baud modems to the terminal connector and connect the 
> etherport to you Sun 690 and up you running.  By the way SLIP are 
> point-to-point connection, it run on a single serial and cannot be share by 
> multiple SLIPs, unlike PPP which allow other application to share the serial
> port.  What you need is a few rotary phone line connect the those modem which
> in turn connect to the terminal server on the terminal side so that who ever
> dial in can be automatically connect to a free terminal port using the same
> phone number.



What's this about not being able to have several SLIP links share the
same modem?  Maybe that's true of Xyplex's product, although I have no
idea.

In fact, the PPP and SLIP protocols are exactly the same as far as how
many links can share the same modems or telephone lines.  Both are
point-to-point links.

Some implementations keep a SLIP or PPP link alive when the the modem
and phone line is dead or in use by another SLIP, PPP, or other use.
This is sometimes called something like "demand-dialing."


Vernon Schryver,  vjs@sgi.com

-----------[000340][next][prev][last][first]----------------------------------------------------
Date:      Wed, 26 May 1993 20:11:55 GMT
From:      motoole@relay.nswc.navy.mil (Edwina O'Toole - K31)
To:        comp.protocols.tcp-ip
Subject:   Strange address

What would this address be -
     1.1.1.1

It showed up in the IP accounting table
for several days on one of the routers here.

Thank you,
------------------------------------------------------------------------
Edwina O'Toole
Naval Surface Warfare Center    Phone:  (703) 663-7529
Code K31                                (DSN) 249-7529
Dahlgren, VA  22448             MILNET: motoole@relay.nswc.navy.mil
========================================================================

-----------[000341][next][prev][last][first]----------------------------------------------------
Date:      26 May 93 20:30:05 GMT
From:      jordan@IMSI.COM (Jordan Hayes)
To:        comp.protocols.tcp-ip
Subject:   Re: Help with 'discovering' a client end connection died...

Rob Cook <rob@sybase.com> writes:

	I've run into a problem in a few customer environments where a
	client (PC under DOS/Windows in this case), connected to a
	server via sockets dies, but the server is never (apparently)
	notified.

[ is this for Sybase DataServer? ]

Anyway, I think the best way to deal with this is to first set
keepalives on the socket, and then put a timer on each connection
that's as long as half the amount of time you're willing to wait to
timeout a connection.  Then, in the timer callback, do a FIONREAD on
the socket.  If the keepalives have marked the socket as dead, this
FIONREAD will generate the error necessary to close down the socket.

If this *is* for the Sybase dataserver, please include an
sp_clearclients or something that wil explicitly run through all
clients and do a FINOREAD *now* to reap any dead clients.

/jordan

-----------[000342][next][prev][last][first]----------------------------------------------------
Date:      Wed, 26 May 1993 21:01:50 GMT
From:      michael.ward@nt.com (Michael Ward)
To:        comp.protocols.tcp-ip
Subject:   NFS Alternative for Wide Area Networks

Hi,

	  Does anyone know about an alternative to NFS mounts for unix servers.  I
am looking at several unix machines that use NFS to mount drives across the
network and since NFS uses UDP to transmit information is proves to be very
un-reliable across mutiple Wide Area serial links.  This proves especially
so with low speed links like 56K.
   
   What I am looking for is the functionality that looks like NFS but uses
a more reliable protocol for transport like TCP. I do not want to tune NFS
on over 300 unix machines thoughout the network and some of the NFS mounts
cross 4 to 5 hops in the network. It is a very large network.


Thanks in advance,

- Michael 


-----------------------------------------------------------------------------
Michael Ward                       ||     My views are my own and do not   
                  
Northern Telecom                   ||     reflect the opinions of NT/BNR
2221 Lakeside Blvd                 ||
Richardson, Tx. 75082              ||                              
e-mail : nvjmw01@nt.com            ||      #include <std/disclaimer>       
                   
------------------------------------------------------------------------------

-----------[000343][next][prev][last][first]----------------------------------------------------
Date:      26 May 1993 21:43:06 GMT
From:      kevin@kevins.frontiertech.com
To:        comp.protocols.tcp-ip
Subject:   Re: Super-TCP

Frontier Technologies Corp.
10201 N. Port Washington Rd.
Mequon, WI 53092
Telephone: 414-241-4555
Fax: 414-241-7084
email: TCP@FrontierTech.COM

-----------[000344][next][prev][last][first]----------------------------------------------------
Date:      26 May 1993 20:14:10 +0200
From:      hz907sc@unidui.uni-duisburg.de (Lutz Schneider)
To:        comp.protocols.tcp-ip
Subject:   SOS, who can help me and my network ?


I'm working with a pc-network and want to analyze an Ethernet system. 
Exactly I want to get statistics about Ethernet errors. I'm using
standard Ethernet cards like NE2000, WD, Long shine, etc and packet 
drivers. Now I want to know how to get error-informations with packet 
drivers. Furthermore I want to know whether it is possible to get 
statistics with software which based on TCP/IP.
What is the meaning of the netmask (for example in a configuration-file
for Telnet or FTP) ?

I would be grateful to someone who can help me.

Lutz Schneider

-----------[000345][next][prev][last][first]----------------------------------------------------
Date:      Thu, 27 May 1993 01:52:24 GMT
From:      scott@nova.tcs.tufts.edu (Scott R. Corzine)
To:        comp.protocols.tcp-ip
Subject:   Re: DECnet & TCP/IP. Can they co-exist???

In article <i4iink6@rhyolite.wpd.sgi.com> vjs@rhyolite.wpd.sgi.com (Vernon Schryver) writes:
>In article <1tth3o$iak@lll-winken.llnl.gov>, oberman@ptavv.llnl.gov writes:
>> CAVEAT!!! Because DECnet will rewrite the physical address of the Ethernet, it
>> MUST start before IP.
>> ...
>
> That depends on the system.  A system can (and some do) repeat the ARP
> announcement of the IP-Ethernet mapping when DECnet is started and
> changes the mapping.  On some such systems it is practically impossible
> and fortunately unnecessary to start DECnet before IP.

    However I know of one major router vendor whose software has real
    difficulties with its ARP cache.  We've had some difficulties
    consistently convincing the router that the IP-Ethernet mapping
    has changed without rebooting the router.  I don't know if any
    other implementations have similar problems.

    I would recommend caution if attempting to start DECnet after IP.

			  -Scott R. Corzine-

-----------[000346][next][prev][last][first]----------------------------------------------------
Date:      Thu, 27 May 1993 02:04:03 GMT
From:      scott@nova.tcs.tufts.edu (Scott R. Corzine)
To:        comp.protocols.tcp-ip
Subject:   Re: SLIP Recommendations

In article <i5927bi@rhyolite.wpd.sgi.com> vjs@rhyolite.wpd.sgi.com (Vernon Schryver) writes:
>
> What's this about not being able to have several SLIP links share the
> same modem?  Maybe that's true of Xyplex's product, although I have no
> idea.

    If multiple SLIP links sharing the same modem means supporting
    different SLIP connections at different times, the Xyplex Doc's
    definitely seem to support this through a couple different methods
    (although possibly not in the most desirable fashion).

    If multiple SLIP links share the same modem means supporting the
    connections simultaneously (ie a multi-drop line), then I am
    unaware of any SLIP implementation which supports this (is it even
    possible)... :-)

    Disclaimer: This is from my reading the docs in preparation for
    implementing this, I'm still awaiting approval for the phone line
    for testing.  I have used Xyplex's SLIP implementation over direct
    links.

			  -Scott R. Corzine-

-----------[000347][next][prev][last][first]----------------------------------------------------
Date:      27 May 1993 03:05:28 GMT
From:      herrera@athena.mit.edu (Ramon F Herrera)
To:        comp.protocols.tcp-ip
Subject:   Are proxy ARP and ICMP redirects compatible??


I have a SLIP link between my home Mac and an Annex at work, but
one day it stopped working for no apparent reason.  Trying to find
the cause of the problem, I captured some packets that tell me that
the Annex is doing both proxy ARP and ICMP redirects.  Is that normal?
Note that on the Annex, the Ethernet port and the serial port have
the same IP address.

It seems strange to me that the Annex is sending ICMP redirects.
If the remote Mac is on the same subnet as the Annex, shouldn't
proxy ARP suffice?  Isn't that the case that from the point of
view of all the hosts in the LAN (except for the Annex) there
is NO routing going on?  They should just ARP, the Annex answers
with its own Ethernet address and that should be all.  The only
routing table that needs to know about my Mac is the Annex's.
If I am right those redirects are just bringing confusion, which
should be the reason for the link's failure to work.

My LAN is completelyt flat: one subnet with only one way out to
the Internet.  I don't have 'routed' running on any host.  The
routing tables only contain the minimun number of routes: looopback,
local net, and a default route.  I have not tried to put the Mac
on a different subnet because I don't want to add a new route to
every host's routing table.  Only one of the Annex' ports is
configured for SLIP.

Thanks for any insights,

-Ramon Herrera


-----------[000348][next][prev][last][first]----------------------------------------------------
Date:      Thu, 27 May 93 14:39:48 -0400
From:      "Andrew Luck" <p00078@psilink.com>
To:        comp.protocols.tcp-ip
Subject:   PC-eudora

Also posted to qualcomm.com

I am running PC-NFS v5.0 , MS-DOS 6.0, on a Dell 486-66 ME.

I like PC-Eudora.

Currently using pce11a7.exe

WHen I setup the PC-NFS network.bat file to use direct services:

NET NISDOMAIN gando
NET START RDR gran *
NET PCNFSD gru5
NET LOGIN  *

everything works fine.

But when I use NIS like so:

NET NISDOMAIN gando
NET START RDR gran *
NET NISSET *
NET PCNFSD *
NET LOGIN  *

Then it don't work:

All other PC-NFS services work fine under both scenarios.

The error is:

Unable to get services pop3 due to unspecified error.
(This may not be exactly what it says)

I have configured and rebuilt my services files in C:\NFS, C:\ETC,
on the NIS Server master file, etc.

They all look like this:
	
ftp             21/tcp
telnet          23/tcp
smtp            25/tcp          mail            # Simple Mail Transfer Protocol
time            37/udp          timeserver
time            37/tcp          timeserver
name            42/udp          nameserver
finger          79/tcp
ns              105/tcp         ns              # NameServer
pop             110/tcp                         # Post Office Protocol Default
pop2            109/tcp                         # Post Office Protocol V2
pop3            110/tcp                         # Post Office Protocol V3
sunrpc          111/udp
sunrpc          111/tcp
snmp            161/udp                         # Simple Network Mgmt Prot.
snmp-trap       162/udp         snmptrap        # SNMP trap (event) messages
shell           514/tcp         cmd             # no paawords used
printer         515/tcp         spooler         # line printer spooler

etc, etc, etc.

I have installed the new WSHELPER.EXE which was provided by Sun Microsytstems.

Do you have any intuition about where I might be going wrong?



-----------[000349][next][prev][last][first]----------------------------------------------------
Date:      26 May 1993 20:24:19 +0800
From:      newsuser@mail-server.bass.my (News Reader)
To:        comp.sys.mac.programmer,comp.sys.mac.apps,comp.sys.mac.comm,comp.protocols.tcp-ip,comp.protocols.tcp-ip.domains
Subject:   Re: MacTCP 1.1.1 and DNS...

We've got about 30 PCs, 3 Mac Ifxs and 25 Sun SS1s. The Suns are on a
thick ethernet backbone and so is our Sun SparcServer 690MP. The PC's go
thru a Xyplex Termserver and can login to the Suns. The Macs are
standalones. Any comments and software on how I can introduce the Macs to
our net ? I'm a bit new at this so please excuse my ignorance. Thanking
you in advance.

                                   /\_/\   "All dogs go to heaven."
                                   (0 0)
+==========================----oOO--(_)--OOo----============================+
| Dinesh Nair (dinesh@bass.my)     /    Surface Address :                   |
| Software Engineer                \    8th Floor, Menara SMI,              |
| Technical Services Group         /    6 Lrg P Ramlee, 50250 Kuala Lumpur  | 
| Bass Consulting                  \    Malaysia.   Tel : 03-2305588        |
+===========================================================================+


-----------[000350][next][prev][last][first]----------------------------------------------------
Date:      Thu, 27 May 1993 17:53:14 -0400
From:      "Eugene F. Hastings" <hastings+@andrew.cmu.edu>
To:        comp.protocols.tcp-ip
Subject:   Re: NNTP News Reader for Macintosh

Check out Nuntius and NewsWatcher, both available in the Info-Mac archives
on sumex-aim.stanford.edu. Nuntius is a little fancier, but requires System
7. NewsWatcher will work with System 6.x

Gene


-----------[000351][next][prev][last][first]----------------------------------------------------
Date:      27 May 93 13:10:32 GMT
From:      mvbr@se.alcbel.be (Marc Verbruggen)
To:        comp.protocols.tcp-ip
Subject:   DECnet vs. TCPIP


--
1) Where do I find a description on the differences between DECnet and TCP/IP.

2) We consider to use TCP/IP as main protocol on the Ethernet to connect VAXes,
PCs, IBMs, Unix systems. Are there (dis)advantages to allow systems of the
same architecure to communicate using their proprietary protocol ? E.g. VAX-VAX
= decnet, IBM-IBM = sna.
-----------------------------------------------------------
Marc Verbruggen                 tel : 03.240.94.19
Alcatel Bell Telephone          fax : 03.240.99.50
F. Wellesplein 1                email : mvbr@se.alcbel.be
B-2018 Antwerp
Belgium
 
"System Manager's Headaches Are Not Cured With Aspirin,
 There Is A Better Way ..."

-----------[000352][next][prev][last][first]----------------------------------------------------
Date:      Thu, 27 May 1993 13:27:06 GMT
From:      keith@comp.lancs.ac.uk (Mr K C Craig)
To:        comp.protocols.tcp-ip
Subject:   Re: MacTCP 1.1.1 and DNS...


In article <1993May25.223326.3132@nntpxfer.psi.com> alun@huey.wst.com (Alun Jones) writes:
>In article <1ttn50$rje@usenet.INS.CWRU.Edu> trier@odin.ins.cwru.edu (Stephen C. Trier) writes:
>
>As a PC user who has been branded our company's Internet expert, I've been
>asked by several Mac users how we can connect them to the Internet.  Is
>Mac TCP the only/best way to do this?

Just as word of a warning (and maybe a question to) when you run MAC TCP/IP, it
doesn't seem to bother to check if the IP address that you supply to it is already in use.
This makes for great "entertainment" if a user places the IP address of your X-Term server
in their configuration by mistake.  In PC TCP/IP work I have done the system checks to 
see if the IP address has already been used.

Is there anyway of avoiding this problem? (with the exception of dynamically assigning
IP addresses, which I can't do in these cases.) 

Keith Craig
MicroComputer Consultant
Lancaster University


-----------[000353][next][prev][last][first]----------------------------------------------------
Date:      Thu, 27 May 1993 13:57:00 GMT
From:      keith@comp.lancs.ac.uk (Mr K C Craig)
To:        comp.protocols.tcp-ip
Subject:   MAC TCP/IP DNS


There was a recent posting detailing how to set up secondary DNS servers
in MAC TCP/IP written by Steve Trier, I think.  I've deleted my copy by
accident.  Could someone repost it or mail it to me at keith.cent1.lancs.ac.uk.

Keith Craig
MicroComputer Consultant
Lancaster University.




-----------[000354][next][prev][last][first]----------------------------------------------------
Date:      27 May 1993 15:14:22 GMT
From:      kbw@helios.ath.epa.gov (Kevin B. Weinrich)
To:        comp.protocols.tcp-ip
Subject:   How to convert ethernet hard. addr. to IP addr.? ARP?

I know how (via kludge) to get an ethernet hardware address from an IP
address:
  ping host.domain
  arp -a
will first add host.domain to arp's table, then list all the machines
currently in the table, including both numeric IP addr and ether hardware
addr.  There's probably a slicker way to do this; I'd be thankful for hearing
of it.

But how can I do the reverse: start with an ethernet hardware address, and
wind up with the IP address it goes with?
-- 
Kevin Weinrich     Computer Sciences Corp.
kbw@helios.ath.epa.gov

-----------[000355][next][prev][last][first]----------------------------------------------------
Date:      27 May 1993 15:16:12 GMT
From:      roy@mchip00.med.nyu.edu (Roy Smith)
To:        comp.protocols.tcp-ip
Subject:   Re: MacTCP 1.1.1 and DNS...

keith@comp.lancs.ac.uk (Mr K C Craig)  writes:
> Just as word of a warning (and maybe a question to) when you run MAC
> TCP/IP, it doesn't seem to bother to check if the IP address that you
> supply to it is already in use.  This makes for great "entertainment" if a
> user places the IP address of your X-Term server in their configuration by
> mistake.  In PC TCP/IP work I have done the system checks to see if the IP
> address has already been used.

	I believe the latest version of MacTCP (2.0, which may or may not be
available to the public yet) does complain about duplicate IP addresses.
Duplicate IP addresses is not a problem specific to MacTCP.  Anytime the
user (or the system administrator, for that matter!) can set the IP address,
the possibility of duplication occurs.  I remember one memorable day when
somebody running Sun's PC/NFS set their IP address to the same as one of our
major file servers.  What fun.
-- 
Roy Smith <roy@nyu.edu>
Hippocrates Project, Department of Microbiology, Coles 202
NYU School of Medicine, 550 First Avenue, New York, NY 10016
"This never happened to Bart Simpson."

-----------[000356][next][prev][last][first]----------------------------------------------------
Date:      Thu, 27 May 1993 15:40:19 +0000
From:      proyse@peeras.demon.co.uk (Phil Royse)
To:        comp.protocols.tcp-ip
Subject:   Re: Super-TCP

In article <C7Dvpn.AyH@unccsun.uncc.edu> jpb@jpbpc1.uncc.edu writes:

>I have just finished Tested the following nine competing products:

John,

Have you got more info on TN3270?  What does it not have that
proper 3270 in a host have?

Put another way...  if IBM are recommending PC3270 to run
a software package over an SNA link, but we want to use TCP/IP
over our Ethernet, can we still use TN3270 (in the IBM 9370) and
a TN3270 emulator/over telnet/over TCP/IP without losing fuctionality?

TIA,  Phil R.

-- 

Phil Royse     Comms Consultant  | member:  The Peer Association
TUDOR HOUSE                      | (networking & OSI specialists)
12 Woodside Road, Purley           
Surrey  CR8 4LN   (UK)        Tel: (+44) 81 645-9868 

-----------[000357][next][prev][last][first]----------------------------------------------------
Date:      27 May 93 15:41:31 GMT
From:      nellied@dingo.ca.boeing.com (Nellie Diaz)
To:        comp.unix.questions,comp.protocols.tcp-ip
Subject:   tftp limitation problem

Big thank you to Tony Li for the following reply to the file size transfer
problem I was having with tftp:

>Yes, that's a limitation of the protocol.  TFTP can only handle up to
>16 bits of blocks, each block is 512 bytes, thus 65535x512=33553920.
>As the RFC never specified how to wrap block numbers (it _could_ be
>done), the protocol itself is limited to this size.
 
>The Sun implementation (and probably the HP) is broken because they
>use _signed_ numbers, and thus get confused when they've done 15 bits
>worth of blocks.
 
>Anonymous ftp would be a much better solution to this problem anyhow...
 
-- 
Nellie Diaz        nellied%rstech3@atc.boeing.com    ___ ___ ___ ___     ___
UNIX Server Technical Services                      /__//  //__  /  /\ //  _
+1 206 957-5352              =-=-=-=-=-=-=-=-=-=   /__//__//__ _/_ /  //__/
All statements are my own, not Boeings.               Computer Services

-----------[000358][next][prev][last][first]----------------------------------------------------
Date:      27 May 93 15:49:04 GMT
From:      art@acc.com (Art Berggreen)
To:        comp.protocols.tcp-ip
Subject:   Re: Strange address

In article <1993May26.201155.4245@relay.nswc.navy.mil> motoole@relay.nswc.navy.mil (Edwina O'Toole - K31) writes:
>What would this address be -
>     1.1.1.1
>
>It showed up in the IP accounting table
>for several days on one of the routers here.

My first guess would be that it leaked out of a test configuration.
Either the packet originated inside your enviroment and had a destination
address of 1.1.1.1 and happened to follow a default path, or someone
outside sent a packet to one of your addresses with a source address
of 1.1.1.1.

Art

-----------[000359][next][prev][last][first]----------------------------------------------------
Date:      Thu, 27 May 1993 12:37:42 +0200
From:      Andre' Pirard <pirard@vm1.ulg.ac.be>
To:        comp.protocols.tcp-ip
Subject:   Re: Help me fix my EBCDIC-ASCII translate table for FTP

In article <C79GGu.6qA@wimsey.bc.ca> Samuel Lam, skl@wimsey.bc.ca writes:
> In article <900@ceco.ceco.com>, garry@ceco.ceco.com (Garry J. Garrett)
 wrote:
> >What would I like from you?  Do you have a chart that you are willing
> >to share with me (that has a 1:1 corresponance, i.e. each character
> >on the chart maps to one and only one character on the other chart,
> >and that character maps back to the one you started with.)?
>
> The following should do it.  It's the "MTS T-Day chart".  Much efforts
> and sweat had gone into it.
>
> [table removed]

I have no doubt about the sweat :-)
As a specialist of the question, I have checked the table and found it to
match the IBM official translation between ISO 8859-1 and CECP 037 (it is
reversible and one to one indeed). Apparently good, but there's a hitch,
read on...

ISO 8859-1 is the de-facto-recognized(*) standard for 8-bit communication
of Latin-1 languages over networks formerly called ASCII (other language
groups would use another -x version of the same standard, while waiting
that a multi-byte code allow any language to use the same code. But that
would need that the TCP/IP protocols suite define an XDR (external data
representation), sort of OSI level 6, on a global scale to be used by any
protocol of the suite, a need I won't extend here).
(*) 8859 _is_ a standard, even the only real one, but its use is only
indicated for some TCP/IP application RFCs (Xwindows, Gopher, ...); the
other protocols use it in a de facto way, by similarity and compatibility
with the others.
No one seems to question 8859. Subject closed one side.

CECP 037 is the official IBM EBCDIC code (the 'hex values') to be used in
US for exactly that same character set (shapes) as ISO. And here's the
hitch: "in US". IBM defined different codes with exactly the same Latin-1
character set to be used in different countries, much like as if same
ASCII characters had different values in different states of the US.
Moreover, CECP 037 (and none of the others) is _not_ compatible with
traditional US EBCDIC for the values of brackets recognized by a host of
programs, including IBM's, among which one pinpoints the compilers (C,
Pascal) and _all_ the programs that produce EBCDIC to be translated to
ASCII (Postscript, HP ...).
This is ever so true that 3270 terminal emulators from IBM (e.g. X3270)
have a toggle to 'put the brackets correct', as they say.

A working group of SHARE (IBM users group) urged IBM to define a
USEBCDIC-compatible Latin-1 CECP and recommended that this single one be
used world-wide. From this emerged the definition of CECP 1047.

In summary, one may run into big troubles if the ISO 8859-1 to CECP 1047
is not used, especially because data is transmitted over EBCDIC networks
in US EBCDIC and it would convert to wrong ASCII. It's the eperience of
many people. Try requesting a uuencoded or binhex over BITNET and see
which translation works to get it back to ASCII. And everything clutches
together. Try Kermit etc...

The formerly posted table differs at ASCII 5B 5D 5E A8 AC DD (brackets,
circumflex and swaps). I would highly recommend the following table
instead (in IBM TCP/IP format). IBM TCP/IP default US EBCDIC translation
table is indeed just another one only this one is compatible with (and no
other will work, eg for SMTP that will no longer recognize brackets).

* Translation between ISO8859/1 and EBCDIC CECP 1047
* ASCII-to-EBCDIC table
* 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F
*
  00 01 02 03 37 2D 2E 2F 16 05 25 0B 0C 0D 0E 0F    * 00 *
  10 11 12 13 3C 3D 32 26 18 19 3F 27 1C 1D 1E 1F    * 10 *
  40 5A 7F 7B 5B 6C 50 7D 4D 5D 5C 4E 6B 60 4B 61    * 20 *
  F0 F1 F2 F3 F4 F5 F6 F7 F8 F9 7A 5E 4C 7E 6E 6F    * 30 *
  7C C1 C2 C3 C4 C5 C6 C7 C8 C9 D1 D2 D3 D4 D5 D6    * 40 *
  D7 D8 D9 E2 E3 E4 E5 E6 E7 E8 E9 AD E0 BD 5F 6D    * 50 *
  79 81 82 83 84 85 86 87 88 89 91 92 93 94 95 96    * 60 *
  97 98 99 A2 A3 A4 A5 A6 A7 A8 A9 C0 4F D0 A1 07    * 70 *
  20 21 22 23 24 15 06 17 28 29 2A 2B 2C 09 0A 1B    * 80 *
  30 31 1A 33 34 35 36 08 38 39 3A 3B 04 14 3E FF    * 90 *
  41 AA 4A B1 9F B2 6A B5 BB B4 9A 8A B0 CA AF BC    * A0 *
  90 8F EA FA BE A0 B6 B3 9D DA 9B 8B B7 B8 B9 AB    * B0 *
  64 65 62 66 63 67 9E 68 74 71 72 73 78 75 76 77    * C0 *
  AC 69 ED EE EB EF EC BF 80 FD FE FB FC BA AE 59    * D0 *
  44 45 42 46 43 47 9C 48 54 51 52 53 58 55 56 57    * E0 *
  8C 49 CD CE CB CF CC E1 70 DD DE DB DC 8D 8E DF    * F0 *
*
* EBCDIC-to-ASCII table
* 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F
*
  00 01 02 03 9C 09 86 7F 97 8D 8E 0B 0C 0D 0E 0F    * 00 *
  10 11 12 13 9D 85 08 87 18 19 92 8F 1C 1D 1E 1F    * 10 *
  80 81 82 83 84 0A 17 1B 88 89 8A 8B 8C 05 06 07    * 20 *
  90 91 16 93 94 95 96 04 98 99 9A 9B 14 15 9E 1A    * 30 *
  20 A0 E2 E4 E0 E1 E3 E5 E7 F1 A2 2E 3C 28 2B 7C    * 40 *
  26 E9 EA EB E8 ED EE EF EC DF 21 24 2A 29 3B 5E    * 50 *
  2D 2F C2 C4 C0 C1 C3 C5 C7 D1 A6 2C 25 5F 3E 3F    * 60 *
  F8 C9 CA CB C8 CD CE CF CC 60 3A 23 40 27 3D 22    * 70 *
  D8 61 62 63 64 65 66 67 68 69 AB BB F0 FD FE B1    * 80 *
  B0 6A 6B 6C 6D 6E 6F 70 71 72 AA BA E6 B8 C6 A4    * 90 *
  B5 7E 73 74 75 76 77 78 79 7A A1 BF D0 5B DE AE    * A0 *
  AC A3 A5 B7 A9 A7 B6 BC BD BE DD A8 AF 5D B4 D7    * B0 *
  7B 41 42 43 44 45 46 47 48 49 AD F4 F6 F2 F3 F5    * C0 *
  7D 4A 4B 4C 4D 4E 4F 50 51 52 B9 FB FC F9 FA FF    * D0 *
  5C F7 53 54 55 56 57 58 59 5A B2 D4 D6 D2 D3 D5    * E0 *
  30 31 32 33 34 35 36 37 38 39 B3 DB DC D9 DA 9F    * F0 *


------
Andre' Pirard         SEGI, Universite' de Lie`ge  139.165 IP coordinator
B26 - Sart Tilman     B-4000 Lie`ge 1 (Belgium)           +32 (41) 564932
pirard@vm1.ulg.ac.be  alias PIRARD@BLIULG11.BITNET

-----------[000360][next][prev][last][first]----------------------------------------------------
Date:      27 May 93 16:10:13 GMT
From:      veizades@apple.com (John Veizades)
To:        comp.protocols.tcp-ip
Subject:   Re: MacTCP 1.1.1 and DNS...

In article <1993May27.132706.12720@comp.lancs.ac.uk>,
keith@comp.lancs.ac.uk (Mr K C Craig) wrote:
> Just as word of a warning (and maybe a question to) when you run MAC TCP/IP, it
> doesn't seem to bother to check if the IP address that you supply to it is already in use.

MacTCP in all its incarnations uses ARP to check if its IP address is in
use by anyother system on the cable.

John Veizades...
MacTCP Lead Engineer
Apple Computer, Inc.

-----------[000361][next][prev][last][first]----------------------------------------------------
Date:      Thu, 27 May 1993 16:56:02 GMT
From:      craig@sics.se (Craig Partridge)
To:        comp.protocols.tcp-ip
Subject:   Advance Program for ACM SIGCOMM '93


	      ADVANCE PROGRAM FOR ACM SIGCOMM '93
        September 13-17th, San Francisco, California, USA


**************************************************************************
**************************************************************************

		CONFERENCE LOCATION

The SIGCOMM '93 Conference will be held at the Westin St. Francis Hotel
in downtown San Francisco, California.  The hotel is within walking
distance  of San Francisco's Chinatown and an easy cable car ride
away from Ghiradelli Square and Fisherman's Wharf.  Napa and Sonoma
Valleys, the heart of California wine country, are an hour's drive
away.

Weather: San Francisco in September is typically very pleasant.  Sunny
    and warm (about 70F) during the day, and cool (about 50F) in the
    evenings.  Note that the evening fog often makes it feel a bit
    colder and we recommend you bring a jacket.

Transportation: The hotel is about 20 minutes away from San Francisco
    International Airport.  A taxi ride from the airport typically costs
    about $25.  Also, the SFO Airporter has direct service to the
    hotel at 20-minute intervals.  The fare is $8 one-way and $14
    round-trip.

Rental Cars: HERTZ has been appointed as the car rental supplier for
    SIGCOMM '93.  Special rates with unlimited mileage have been negotiated
    for SIGCOMM attendees and are also available the week prior and the
    week after the symposium.  To make reservations call HERTZ Meeting Services
    at 1-800-654-2240 (In Canada 1-800-263-0600) and identify yourself as
    SIGCOMM attendee (Meeting # 2499).  Cars can be rented at most Bay-area
    airports and also at the Westin St. Francis Hotel.

Social Event: An evening dinner-cruise on the San Francisco Bay is planned
    for Wednesday, September 15.  The cost of the cruise is included in
    the registration fee.  Additional tickets may be purchased at a price
    of $53 each.  The cruise will be held on the Hornblower Dining Yachts's
    Empress.  Beverages will include premium wine and beer, soft drinks,
    fruit juices and mineral water.  Dinner will be a Greek Salad, Rice
    Pilaf, a choice of carved turkey or pasta, and dessert.

**************************************************************************
**************************************************************************

		     ADVANCE PROGRAM

Monday, September 13th

1:00-5:00  TUTORIALS
	Tutorial T1A: High-Speed Transport Protocols
	    Krishan Sabnani, AT&T Bell Labs

	Tutorial T1B: Interconnecting MANs and LANs to ATM
	    Mario Gerla, UCLA

------------------------------------------------------------------------------
Tuesday, September 14th

8:00-12:00 TUTORIALS
	Tutorial T2A: Wireless Communication Worldwide for Cellular and PCS
	   Donald L. Schilling, InterDigital Communications Corporation

	Tutorial T2B: Trends and Challenges in Broadband Networking
	   Richard D. Gitlin, AT&T Bell Labs

1:30-5:30 TUTORIALS
	Tutorial T3A: All-Optical Networking
	   Paul E. Green Jr., IBM T.J. Watson Research Center

	Tutorial T3B: Metropolitan Area Networks 
	   James F. Mollenauer, Technical Strategy Associates

6:00-8:00 Reception at Westin St. Francis Hotel.

------------------------------------------------------------------------------
Wednesday, September 15th

9:00 - 10:30
	Keynote Address: SIGCOMM Award Winner

11:00 - 12:30 REAL TIME COMMUNICATIONS

On Per-Session End-to-End Delay Distribution and the Call Admission
    Problem for Real Time Applications with QOS Requirements
	David Yates, Jim Kurose, Don Towsley (Univ. of Mass) and
	Mike Hluchyj (Motorola/Codex Corp)

Analysis of Burstiness and Jitter in Real Time Communications
	Zheng Wang and Jon Crowcroft (University College London)

An Adaptive Congestion Control Scheme for Real Time Packet Video Transport
	Hemant Kanakia, Amy Reibman (AT&T Bell Lab) and
	Partho P Misra (Univ. of Maryland - CP)

2:00 - 3:30 ROUTING

The Synchronization of Periodic Routing Messages
	Sally Floyd and Van Jacobson (Lawrence Berkeley Lab.)

Dynamics of Internet Routing Information
	Bilal Chinoy (San Diego Supercomputer Center)

Open Shortest Path First (OSPF) Routing Protocol Simulation
	Deepinder Sidhu, Tayang Fu, Shukri Abdallah, Raj Nair
	(Univ. of Maryland - BC) and Rob Coltun (Consultant)

4:00 - 5:00 PROTOCOL IMPLEMENTATION ISSUES

Implementation of Network Protocols at the User Level
	Chandramohan Thekkath, Edward D. Lazowska, Thu. D. Nguyen
	and Evelyn Moy (University of Washington)

Locking Effects in Multiprocessor Implementation of Protocols
	Mats Bjorkman (Uppsala University) and 
	Per Gunningberg (Swedish Institute of Computer Science)

5:30   Busses Leave for Cruise.

6:30 - 9:00 SOCIAL EVENT
	Cruise in San Francisco Bay.

------------------------------------------------------------------------------
Thursday, September 16th

9:00 - 10:30 MULTICAST

Core Based Trees
	Tony Ballardie (University College London), Paul Francis (Bellcore)
	and Jon Crowcroft (University College London)

Routing Reserved Bandwidth Multi-Point Connections
	Dinesh C. Verma, P. M. Gopal (IBM T.J. Watson Research Center)

The Design of a Reliable Multicast Algorithm
	R. Ajello, E. Pagani, G.P. Rossi (Universita' di Milano)

11:00 - 12:30 CONGESTION AND ADMISSION CONTROL, SCHEDULING

Optimizing File Transfer Response Time Using the Loss Load Curve Congestion
	Control Mechanism.  Carey Williamson (Univ. of Saskatchewan)

An Adaptive Framework for Dynamic Access to Bandwidth at High Speed.
	Kerry W. Fendick and Manoel A. Rodrigues (AT&T Bell Laboratories)

Warp Control: A Dynamically Stable Congestion Protocol and its Analysis.
	Kihong Park (Boston University)

2:00 - 3:30 PROTOCOL DESCRIPTION

Control Handling in Real-Time Communication Protocols.
	Atsushi Shionozaki and Mario Tokoro (Keio University)

Structural Complexity and Execution Efficiency of Distributed Application
	Protocols.  K. Ravindran and X. T. Lin (Kansas State University)

A Data Labelling Technique for High-Performance Protocol Processing 
	and its Consequences.  David C. Feldmeier (Bellcore)

4:00 - 5:00 TRAFFIC CHARACTERISTICS

On the Self-Similar Nature of Ethernet Traffic
	Will E. Leland (Bellcore), Murad S. Taqqu (Boston University), 
	Walter Willinger and Daniel V. Wilson (Bellcore)

Application of Sampling Methodologies to Network Traffic Characterization
	George Polyzos, K. C. Claffy and H. W. Braun
	(UC, San Diego)

------------------------------------------------------------------------------
Friday, September 17th

9:00 - 10:30 SCHEDULING AND MANAGEMENT

ATM Scheduling with Queueing Delay Predictions
	Daniel B. Schwartz (GTE Laboratories)

HAP: A New Model for Packet Arrivals with Implications for Broadband
	Network Control.  Ying Dar Lin, Tzu Chieh Tsai and Mario Gerla (UCLA)

Management of Virtual Private Networks for Integrated Broadband Communication
	Juergen M. Schneider (IBM European Networking Center), 
	Thomas Preuss (Technische Universitaet Cottbus) and
	Peter S. Nielsen (L. M. Ericsson A/S)

11:00 - 12:30 NETWORKING ISSUES

A Case for Caching File Objects Inside Internetworks
	Peter B. Danzig (University of Southern California), Richard S. Hall
	and Michael F. Schwartz (University of Colorado, Boulder)

Linear Recursive Networks and Their Applications in Topological Design and
	Data Routing. Wea Jing Hsu (Nanyang Technological Univ.)

The Importance of Non-Data Touching Processing Overheads in TCP/IP.
	Jonathon Kay and Joseph Pasquale (UC, San Diego)

2:00 - 3:30 PRACTICAL PROTOCOLS

A Distributed Queueing Random Access Protocol for a Broadcast Channel.
	Graham Campbell and Wenxin Xu (Illinois Institute of Technology)

Fault Detection in an Ethernet Network Using Anomaly Signature Matching
	Frank Feather (Hewlett-Packard Company), Dan Siewiorek and
	Roy Maxion (Carnegie Mellon University)

End-to-End Packet Delay and Loss Behavior in the Internet
	Jean - Chrysostome Bolot (INRIA)

**************************************************************************
**************************************************************************

		    TUTORIAL DESCRIPTIONS


Tutorial T1A: High-Speed Transport Protocols.  Instructor: Krishan Sabnani,
    AT&T Bell Laboratories (Monday, Sept. 13th, 1:00-5:00)

    Advances in data transmission and switching over the last
    decade promise deployment of communication systems with raw
    bandwidth and switching speeds that are orders of magnitude
    higher than the current systems.  Optical fibers, for
    example, allow transmission of tens of gigabits/sec over
    several kilometers without repeaters and switch fabrics that
    can switch bit-streams of more than hundreds of megabits/sec
    have already been prototyped.  To realize the fruits of
    these advances, transport protocols capable of delivering
    high end-to-end bandwidth to their users are needed.
    Various approaches for doing this have been proposed:
    (1) design of lightweight transport protocols such as NETBLT,
    SNR, and VMTP; (2) VLSI implementations of transport
    protocols such as PROVE and the Protocol Engine.  Some
    high-speed versions of standard protocols such as TCP have
    also been developed.  Many important advances in this area
    will be discussed.  A special effort will be made to
    describe the underlying principles behind these approaches.
    In addition, the adaptation layer protocols being proposed
    for the ATM/BISDN networks will also be presented.

    Biography: Krishan Sabnani is a researcher in the Distributed Systems
    Research Department of AT&T Bell Laboratories.  His major area of interest
    is communication protocols.  Krishan received the Leonard G. Abraham
    Award from the IEEE Communications Society in 1991.  He was awarded
    the Bell Laboratories Distinguished Technical Staff Award in 1990.
    He is also a fellow of the IEEE, and an editor for the IEEE/ACM
    Transactions on Networking.  He has been an editor of the IEEE
    Transactions on Communications and of the IEEE Transactions on
    Computers.  He has served as a guest editor for the IEEE Journal
    on Selected Areas in Communications (JSAC) and the Computer
    Networks Journal.  He also serves on the editorial boards
    of Journal of Systems Integration and Journal of High
    Speed Networks.

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

Tutorial T1B: Interconnecting MANs and LANs to ATM. Instructor: Mario Gerla,
    Computer Science Department, UCLA.  (Monday, Sept. 13, 1:00-5:00).

    The need for higher data rates in local and metropolitan areas has
    recently led to the development of several network products in the 
    100 MBPS speed range ( eg FDDI, DQDB etc). Following the introduction
    of a nationwide ATM network, it will be natural to interconnect
    these LANs and MANs to ATM, thus extending their services to 
    large geographical areas. One of the main challenges of the
    LAN/MAN/ATM interconnect is the connectionless traffic support in
    ATM. In fact, LANs and MANs are virtually all connectionless, 
    while ATM is connection oriented and requires bandwidth allocation
    prior to connection setup. In this seminar, we will examine and
    compare various alternatives for ATM connectionless service support,
    including: dedicated VPs (Virtual Paths); on-the-fly burst
    transmissions; fast reservations; and connectionless servers.
    We will also discuss the problem of extending LAN and MAN multicast
    services within ATM. Finally, we will consider the ATM LAN
    solution for local and campus area coverage, and examine the
    problem of interconnecting the ATM LAN to the ATM WAN.

    Biography: Dr. Gerla was born in Milan, Italy.  He received a
    graduate degree in engineering from the Politecnico di Milano, in
    1966, and the M.S. and Ph.D. degrees in engineering from UCLA in 1970
    and 1973, respectively.  He joined the faculty of the UCLA Computer
    Science Department in 1977.  His research interests cover the
    performance evaluation, design and control of distributed computer
    communication systems and high speed computer networks (ATM and
    Optical Networks). 

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

Tutorial T2A: Wireless Communication Worldwide for Cellular and PCS.
    Instructor: Donald L. Schilling, InterDigital Communication Corporation
    (Tuesday, Sept. 14th, 8:00-12:00)

    This is the decade of wireless telecommunications. During the 1990s people
    will demand, in increasing numbers, the ability to communicate 
    with a high degree of mobility, high quality voice, data at ISDN rates 
    and multimedia information such as video. Indeed, consumers demand
    wired line quality with wireless convenience.  The user of a cellular
    or PCS system wants to use one phone for all of these intended needs.
    Thus, a single portable phone should be able to operate in a residence
    as a cordless phone, in a vehicle using a cellular system and in an
    office using a WPBX.  This tutorial discusses the two primary
    technologies for wireless communications: TDMA and CDMA. Topics include:
    principles of operation of TDMA and CDMA; channel
    characterization-multipath fading, theory and experimental results;
    as well as applications and comparison of TDMA and CDMA for cellular
    and PCS.

    Biography: Donald L. Schilling is Executive President of InterDigital
    Communications Corporation where he directs programs leading to
    the production and sale of Wireless TDMA and B-CDMA Communication's
    products.  Dr. Schilling retired in May 1992 as the Herbert
    G. Kayser, Distinguished Professor of Electrical Engineering at
    the City College of the City University of New York where he
    had been a Professor since 1969.  Dr. Schilling is an
    internationally-known expert in the field of Communications Systems.
    He has made many notable contributions in Meteor-Burst Communications
    Systems, Spread Spectrum Communication Systems, FM and Phase Locked
    Systems and HF systems.  His design of a voice digitizer, called
    an adaptive delta modulator, is used on the Space Shuttle.  Dr.
    Schilling was President of IEEE Communications Society from
    1980-1981, and a member of the Board of Directors of the IEEE
    from 1982-1983.  He was Editor of the IEEE Transactions on
    Communications for 1968-1978.  He is a Fellow of the IEEE and a
    member of Sigma Xi.  He has co-authored eight textbooks and more than
    140 papers in Telecommunications and Electronics.

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

Tutorial T2B: Trends and Challenges in Broadband Networking.
    Instructor: Richard Gitlin, AT&T Bell Labs (Tuesday, Sept. 14th,
    8:00-12:00)

    This tutorial will present an overview of research in Broadband Networking
    (B-ISDN) based on the Asynchronous Transfer Mode (ATM). ATM is the leading
    candidate to provide a technological discontinuity that enables integrated
    broadband telecommunication services (e.g., multimedia), high-speed
    computer networking and scalable local, metropolitan, and wide area
    networks.  Specific topics that will be addressed are:

    o The technological discontinuities between narrowband and broadband
	networking;
    o Challenges and barriers to a broadband network;
    o Selected research topics (including the LuckyNet broadband testbed).

    Biography: Richard D. Gitlin received the B.E.E. degree (cum laude) from
    the City College of New York, N.Y., in 1964 and the M.S. and D.Eng.Sc.
    degrees from Columbia University, New York, N.Y., in 1965 and 1969,
    respectively.  Since 1969, he has been with AT&T Bell Laboratories,
    Holmdel, N.J.  In November, 1992 he was appointed Director of the
    Communications Systems Research Laboratory. He is now responsible for
    research in broadband networking, wireless networks, and access
    technologies.  Dr. Gitlin is the author of more than 50 technical
    papers, numerous conference papers, and he holds 25 patents in the
    areas of data communications, digital signal processing, and broadband
    networking.  He is a co-author of the text, Data Communication Principles
    (Plenum Press, 1992).  He is a member of Sigma Xi, and in 1985 he was
    elected a Fellow of the IEEE for his contributions to data communications
    technology.  In 1987 he was named an AT&T Bell Laboratories Fellow.

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

Tutorial T3A: All-Optical Networking. Instructor: P. E. Green, Jr.,
    IBM TJ Watson Research Center.  (Tuesday, Sept. 14th, 1:30-5:30).

    This short course will focus on recent developments in
    networks that exploit the multiprotocol and high bandwidth
    possibilities of clear end-to-end optical fiber paths by sending
    different sessions or connections at different wavelengths of light.
    In the first hour, the motivation and overall principles of such
    networks are reviewed.  In the next, the appropriate fiber optic
    technology is covered, focussing on those components that are special
    to networking.  In the third hour, various architectural topics are
    covered, (including link budgets, topologies and protocols), and in
    the final hour the status and prospects for real operational
    all-optical networks of various types are presented.

    Biography: Paul E. Green, Jr. is Manager of Advanced Optical
    Networking Member at IBM Research in Hawthorne, NY.  After some years
    at M.I.T.  Lincoln Laboratory, where he made pioneering contributions
    to spread spectrum, adaptive receivers, radar astronomy and seismic
    data processing, he joined IBM, where he has held a variety of
    research and Corporate Technical Staff positions.  His technical
    interests have centered on computer network architecture, and he has
    received several IBM Outstanding Innovation Awards for his role in
    formulating and promoting Advanced Peer-to-Peer Networking, now the
    basis for further evolution of IBM's System Network Architecture.  He
    is a member of the National Academy of Engineering, in 1983 was named
    Distinguished Engineering Alumnus by North Carolina State University,
    and received the IEEE's Simon Ramo Medal in 1991.  He is the author of
    many technical papers, has edited several books on computer
    communications, and is the author of the textbook: Fiber Optic
    Networks, (Prentice Hall, 1993), on which this course is based.
    Currently he is President of the IEEE Communication Society.

---------------------------------------------------------------
Tutorial T3B: Metropolitan Area Networks. Instructor: James F. Mollenauer,
    Technical Strategy Associates.  (Tuesday, Sept. 14th, 1:30-5:30).
 
    This tutorial will cover the applications, standards aspects, and
    technology of metropolitan area networks and their relationship
    to ATM technology.  The need for segmented transmission to
    support data, voice, and video services led early on to the
    adoption of an ATM or cell-based transmission strategy.  This
    provides a close relationship to ATM as it has emerged as a
    technology of choice for premises networks, replacing the shared
    medium LAN.  The tutorial will cover private multiservice networks
    and public facilities and their support of voice and video in addition
    to data.  Implementation issues will be addressed, both for the
    IEEE 802.6 MAN standard and for the public SMDS service based on it.
     
    Biography: James F. Mollenauer is currently President, Technical
    Strategy Associates, of Newton, Massachusetts, providing consultation
    in metropolitan and other high-speed networks from both a technical
    and product strategy point of view.  Since 1982 he has chaired
    the standardization group for metropolitan area networks, IEEE
    Project 802.6.  Prior to his present position Dr. Mollenauer was
    Vice President, Advanced Technology at Artel Communications
    Corporation, architecting a new line of very-high-performance LAN
    bridging and routing products.  Previously he spent 17 years at
    Bell Laboratories, starting out in nuclear physics research and
    moving on to work in real-time computing, time sharing, and
    computer-aided design.  He has also served at Prime Computer and
    its Computervision division in data communication architectures
    and planning, and at Codex Corporation, where he undertook
    strategic studies in LAN's and metropolitan area networks, and
    developed a wireless radio-based LAN.  Dr. Mollenauer is the
    author of many articles and conference papers on metropolitan and
    high speed networks and is currently Chair of the IEEE Local
    Computer Networks Conference.  He received his bachelor's degree
    at Amherst College and his PhD from the University of California
    at Berkeley. 


**************************************************************************
**************************************************************************

		    REGISTRATION INFORMATION

    Advance registration is available using the form below through September
7th.  (E-mail registration available only through August 10th, and must
use a credit card number).  On site registration at the Westin St. Francis
Hotel will be available starting Sunday, September 12th from 1PM-5PM, and
every day of the conference starting at 7:30 AM.

    Student Registration includes conference proceedings and presentations
but does not include the conference social event.

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

                      SIGCOMM '93
		     Registration Form

Please send this form and a check, credit card information, 
or money order (no purchase orders) to SIGCOMM '93.  
Registrations accepted via postal mail, FAX, or email only.

                SIGCOMM '93 Registrar
        Hewlett-Packard Laboratories, MS 1U-17
                    P.O. Box 10490
               Palo Alto, CA 94303-0969
				   
                FAX:  +1 415 813-3706
      EMAIL: sigcomm93-registration@hp.com (**note)

        Inquiries only: +1 415 857-3295  (voice)  

-----------------------------------------------------------
If you are not an ACM or a SIGCOMM member at this time, 
you may join now to take full advantage of ACM/SIG Member
or Student(*) rates for SIGCOMM '93:

ACM Associate Member Dues                       __ $79 US
Add SIGCOMM to ACM Membership                   __ $22 US

ACM Student Dues                                __ $24 US
Add SIGCOMM to ACM Student Membership           __ $15 US

SIGCOMM Membership only (non-ACM)               __ $50 US

Total New Membership Fees                       $_____ US
-----------------------------------------------------------
Tutorials (check the box for each tutorial attending)

Note: You may select at most one tutorial from each
session time (MAX 3).

                                                      ___
High-Speed Transport Protocols ....................../__/ T1A
(Monday, 1-5)
                                                      ___
Interconnecting MANs and LANS to ATM . ............../__/ T1B
(Monday, 1-5)
                                                      ___
Wireless Communication Worldwide ..................../__/ T2A
for Cellular and PCS (Tuesday, 8-12AM)
                                                      ___
Trends and Challenges in ............................/__/ T2B
Broadband Networking (Tuesday, 8-12AM)
                                                      ___
All-Optical Networking ............................../__/ T3A
(Tuesday, 1:30-5:30)
                                                      ___
Metropolitan Area Networks ........................../__/ T3B
(Tuesday, 1:30-5:30)


Enter total number of tutorials at the appropriate rate:

             For registrations received (postmarked)
                      by              after
               August 10 1993     August 10 1993

                 #    $'s Each     #    $'s Each
               ---------------    ---------------
ACM/SIG Member  ___ @ $ 99 US     ___ @ $125 US
Non-Member      ___ @ $119 US     ___ @ $145 US
Student*        ___ @ $ 50 US     ___ @ $ 50 US

Total Tutorial Fee:                             $_____ US
-----------------------------------------------------------
Conference (select one):

             For registrations received (postmarked)
                      by             after
               August 10 1993   August 10 1993

ACM/SIG Member  ___ $290 US       ___ $340 US
Non-Member      ___ $355 US       ___ $395 US
Student*        ___ $100 US       ___ $100 US

Conference Fee:                                 $_____ US
-----------------------------------------------------------
Extra Dinner/Cruise Tickets      ___ @ $53 US
(September 15) 
Total for extra tickets:                        $_____ US
-----------------------------------------------------------
Total Amount enclosed:                          $_____ US
-----------------------------------------------------------
Vegetarian Meals:   ___ YES  /  ___ NO
-----------------------------------------------------------

Name: ____________________________________

Affiliation: _____________________________

Address: _________________________________

Phone: ___________________________________

FAX: _____________________________________

Email Address: ___________________________

ACM Member #: ____________________________
(write "new" if joining at this time)

SIGCOMM Member?  ____ YES   /   ___ NO

Credit Card Payment

__ Visa    __ Mastercard

Card Holder Name: ________________________

Card Number: _____________________________

Expiration Date: _________________________

Signature: _______________________________


*  See the Advance Program section on student fees.
** Email registration is only available through August 10th and must
    use credit card payment.

**************************************************************************
**************************************************************************

		    HOTEL REGISTRATION

The Westin St. Francis
Union Square
335 Powell Street
San Francisco, CA 94102  USA

A special conference rate has been arranged for attendees of 
SIGCOMM '93.  These rates are applicable from September 10-17, 1993.  
When making reservations by telephone, identify yourself as an 
attendee of SIGCOMM '93.  Hotel reservation deadline: August 10, 
1993. Reservations received after August 10, 1993 are subject to
availability and prevailing rates.

The Westin San Francisco will not hold your reservation after 6:00 PM
on the day of arrival without guaranteeing the reservation with a
check or money order in U.S. dollars covering the first night's stay
(including 11% occupancy tax) or a major credit card with expiration
date and authorized signature.

Deposits will be refunded only if cancellation notification is
received at least 24 hours prior to arrival.  Check in time is 3:00 PM.

Type of Room       Main Building       Towers
                  Single Double      Single Double
Standard           $120   $120         -      -
Medium             $135   $135        $155  $155
Deluxe             $150   $150        $170  $170

Arrival Date: __________________________________

Departure Date: ________________________________

Name: __________________________________________

Share With: ____________________________________

Address: _______________________________________

         _______________________________________

Daytime Telephone: ___________________

Check or Money Order Enclosed in amount:

_ Mastercard   _ American Express  _ Carte Blanche
_ Visa         _ Discover          _ Diners Club

Credit Card Holder's Name: _________________

Credit Card No: ____________________________

Expiration Date: ___________________________

Signature: _________________________________

Reservation by fax, dial: +1 774-0292/774-0124

Reservation by phone, dial: +1 415 397-7000

Identify SIGCOMM '93 for conference rates.


**************************************************************************
**************************************************************************

		    CONFERENCE COMMITTEE

General Chair: Imrich Chlamtac, Univ. Massachusetts
Program Chair: Deepinder Sidhu, Univ. Maryland - BC
Tutorial Chair: Ian F. Akyildiz, Georgia Tech
Local Arrangements Chair: Anujan Varma, Univ. California - Santa Cruz
Treasurer: Lixia Zhang, XEROX PARC
Publicity Chair: Craig Partridge, BBN
Fund Raising Chair: Biswanath Mukherjee, Univ. California - Davis
Registration Chair: Mark Laubach, Hewlett-Packard

		
		INDUSTRIAL SUPPORTERS OF SIGCOMM '93

SIGCOMM '93 would like to thank Digital Equipment Corporation, Hewlett
Packard, International Business Machines Corporation, and XEROX Palo
Alto Research Center for their support of SIGCOMM '93.

-----------[000362][next][prev][last][first]----------------------------------------------------
Date:      Thu, 27 May 1993 13:44:45 +0200
From:      Andre' Pirard <pirard@vm1.ulg.ac.be>
To:        comp.protocols.tcp-ip
Subject:   Re: Class C Addresses & subnet masks

In article <738235608snz@peeras.demon.co.uk> Phil Royse,
proyse@peeras.demon.co.uk writes:
> In article <C7CDM2.In3@jti.com> richb@jti.com writes:
>
> >A little over a year ago I posted to this newsgroup with the same
> >problem:  a site about to buy a bunch of routers and link 20 field
> >offices onto the net, which had 10 Class C addresses.
> >
> >The feedback I got here was unanimous:  you'll regret subnetting your
> >Class C networks like that.  Not all _client_ IP implementations
 support
> >this.
> >
> The formal tender documents I wrote and the supplier responded
> to includes categorical statements that the routers will all
> subnet down to the last two bits of the fourth octet.  Ie. the
> allowable subnet masks are:
>
> 255.255.255.192    ...224     ...240    ...248   and  ... 252
>
> Is this sensible?   Are there anyt other issues which might
> give us some problems??  (eg. problems on the host IP capability?)

No, this is not sensible. Given the new referred to Internet philosophy,
any router or host must also be able to subnet _up_ to some bits too,
which means consolidating a "power-of-two" range of class C networks into
a single view.
Software writers beware, the RFC has no restriction about the mask and
what has been good intention check one day may become bad service
to-morrow.
As a one off example, I would choose MacTCP whose subnetting slidebar
bangs on the left side.

Related considerations.
A multiple-class-C network can alternatively be setup so that the home
router relays data onto the same network. Ugly, but works as long as the
router can be configured with multiple interface addresses, like cisco
(hey, Tony, I guess you (and others) don't send ICMP redirect in _that_
"same interface" case).
But what if one would wish to save some traffic by configuring part of
the hosts with the "consolidated mask"?
ARPs sent by the latter ones could be with all ones, but will or how will
the former reply? Any other problem? I guess! Seems like opening a can of
worms!
However, the problem is not quite new with those hosts unable to subnet.

------
Andre' Pirard         SEGI, Universite' de Lie`ge  139.165 IP coordinator
B26 - Sart Tilman     B-4000 Lie`ge 1 (Belgium)           +32 (41) 564932
pirard@vm1.ulg.ac.be  alias PIRARD@BLIULG11.BITNET

-----------[000363][next][prev][last][first]----------------------------------------------------
Date:      27 May 93 17:06:04 GMT
From:      daveb@jaws (David Breneman)
To:        comp.sys.att,u3b.tech,comp.unix.admin,comp.protocols.tcp-ip
Subject:   SLIP for 3B2

Greg's 3B2 FAQ contains a cryptic message :-) about SLIP for the 3B2:

---CUT---
------------------------------------------------------------------------
Subject: 14 Is there an implementation of SLIP for the 3B2?
------------------------------------------------------------------------

Rumor has it that there was one written by Wollongong, but AT&T
purchased exclusive marketing rights to WIN TCP/IP for the 3B2, but
chose NOT to include SLIP.  There is the NOS (KA9Q) package that
supposedly provides SLIP capabilities, but I have not tried it and
don't know if it'll run on a 3B2.

---CUT---

What is the NOS package?  *Has* anybody ported SLIP to the 3B2?
"Enquiring minds which can't afford an ethernet card want to know."
Thanks to any and all respondants.


--
David Breneman                          Email: daveb@jaws.engineering.dgtl.com
System Administrator,
Software Engineering Services
Digital Systems International, Inc.     Voice: 206 881-7544  Fax: 206 556-8033

-----------[000364][next][prev][last][first]----------------------------------------------------
Date:      Thu, 27 May 1993 14:14:56 +0200
From:      Andre' Pirard <pirard@vm1.ulg.ac.be>
To:        comp.protocols.tcp-ip
Subject:   Re: Subnetting question...

In article <1993May26.222718.2142@tolten.puc.cl> Jorge Cisternas M.,
jcistern@lascar.puc.cl writes:
> Hi:
> 	We have a class B network, but I need smallest's subnetworks (much
> less than 253 hosts per net), so I think on change some subnetmasks.
>
> 	What I think on is:
>
> Net		Subnetmask
> 146.155.1.0	255.255.255.0	(the backbone)
> 146.155.31.0	255.255.255.224	(one subnet of 30 hosts)
> and so on.
>
> And between the backbone and the subnets, a public domain pcroute
> (V. Morrison's), with one interface 146.155.1.57, subnetmask
> 255.255.255.0, and the other interface 146.155.31.1, subnetmask
> 255.255.255.224.
>
> 	My question: SHUOLD THIS WORK, OR I NEED TO CHANGE ALL MY
> NETWORK'S SUBNETMASK TO DO THIS?

Vance states explicitly that interfaces of PCROUTE can have different
subnetting.
From what I know of PCROUTE (much, but not tried this), I think it should
work if all the networks beyond one PCROUTE are deeper-subnetted the same
way in a single cluster and rely on RIP default route (and none appears
elsewhere than in this cluster, of course). What I would try first is how
RIP behaves on the normal subnet side (if it consolidates the subnets).

------
Andre' Pirard         SEGI, Universite' de Lie`ge  139.165 IP coordinator
B26 - Sart Tilman     B-4000 Lie`ge 1 (Belgium)           +32 (41) 564932
pirard@vm1.ulg.ac.be  alias PIRARD@BLIULG11.BITNET

-----------[000365][next][prev][last][first]----------------------------------------------------
Date:      Thu, 27 May 1993 18:29:33 +0000
From:      proyse@peeras.demon.co.uk (Phil Royse)
To:        comp.protocols.tcp-ip
Subject:   Re: IP Routing Questions on Subnet Masks and Multicasting

In article <1993May25.185453.19457@lclark.edu> don@lclark.edu writes:
>
>Hello,
>
>I have a series of relatively straight forward IP routing questions which
>are primarily focused on creative IP mask construction and multicasting
>
>Subnet A: Mask 255.255.252.0
>149.175.1.0 
>149.175.2.0
>149.175.3.0
>149.175.4.0
 
>  Does this particular scheme look right? 
>
>        All comments gratefully accepted. 
>
>.... ... ... ... ....           Don Weston, Jr.           .... ... ... ... ...

Don,

The plan you suggest does seem to be a good idea.   
If I have understood your plan correctly, you will get ONE subnet
with 510 hosts, for each Clump o' Cs, so long as the clumps are
contiguous.

I have just drawn up an IP address plan for a large UK org.
which was given a clump o' 16 Cs for 60 or so offices, despite
our application for a Class B.  It was quite a headache jumbling 
the number range and the masks.

None of our subnets needed more than 255 hosts, so we
subnetted "down" not "up" as you are doing.

One problem with subnetting down is that one cannot have a subnet
mask of 255.255.255.128  as that forces the network number
to be an illegal one or zero, thereby losing address space.  We
would have liked to have had two subnets of 126 hosts from
out of one Class C, but can't, the nearest is two subnets
of 62 hosts with a subnet mask of 255.255.255.192

Regards,

Phil R.

-- 

Phil Royse     Comms Consultant  | member:  The Peer Association
TUDOR HOUSE                      | (networking & OSI specialists)
12 Woodside Road, Purley           
Surrey  CR8 4LN   (UK)        Tel: (+44) 81 645-9868 

-----------[000366][next][prev][last][first]----------------------------------------------------
Date:      27 May 1993 19:28:56 GMT
From:      mengel@dcdmwm.fnal.gov (Marc Mengel)
To:        comp.protocols.tcp-ip
Subject:   Re: SLIP Recommendations

In article <SCOTT.93May26210403@nova.tcs.tufts.edu>, scott@nova.tcs.tufts.edu 
|>     If multiple SLIP links share the same modem means supporting the
|>     connections simultaneously (ie a multi-drop line), then I am
|>     unaware of any SLIP implementation which supports this (is it even
|>     possible)... :-)

I guess I'm having trouble seeing why this would be so difficult, if you
had some sort of box to hand around ClearToSend leads to each connection
on the multi-drop (which multi-drop lines usually do...)  Of course you
would "hear" lots of frames that weren't yours, which would be bad if you
tried to route them...

-------
Marc Mengel
mengel@fnal.fnal.gov

-----------[000367][next][prev][last][first]----------------------------------------------------
Date:      Thu, 27 May 1993 21:46:13 GMT
From:      add@is.rice.edu (Arthur Darren Dunham)
To:        comp.protocols.tcp-ip
Subject:   Re: MacTCP 1.1.1 and DNS...

In article <1993May27.132706.12720@comp.lancs.ac.uk> keith@comp.lancs.ac.uk (Mr K C Craig)  writes:
>
>
>Just as word of a warning (and maybe a question to) when you run MAC TCP/IP, it
>doesn't seem to bother to check if the IP address that you supply to it is already in use.
>This makes for great "entertainment" if a user places the IP address of your X-Term server
>in their configuration by mistake.  In PC TCP/IP work I have done the system checks to 
>see if the IP address has already been used.
>
>Is there anyway of avoiding this problem? (with the exception of dynamically assigning
>IP addresses, which I can't do in these cases.) 

Actually, MacTCP will not let you do this.

If MacTCP has not yet been initialized and a program calls TCPOpen() (or
whatever the call really is), it will arp for its address and fail to
open if present.  

It will not report any problems if its address appears between runs of a
program that uses MacTCP (then it's the other machine's fault). 

>Keith Craig
-- 
Darren Dunham                 		          add@is.rice.edu
MicroConsultant                       		  Rice University
(What is that? A small consultant?)	              Houston, TX
Any resemblance between real opinions and my post is coincidental

-----------[000368][next][prev][last][first]----------------------------------------------------
Date:      Thu, 27 May 1993 20:29:12 +0200
From:      Andre' Pirard <pirard@vm1.ulg.ac.be>
To:        comp.protocols.tcp-ip
Subject:   Time synchronization

I have had discussions with people about computer time synchronization
and I finally decided to take some time for a text in hope it reaches the
persons in a position to solve an irritating problem.
So, please forward if you know where to someone interested.

Computers normally get UTC time from their clock.
A local algorithm converts UTC to local for user display.
The algorithm adds a fixed value (time zone) and often a varying one
(daylight savings). (And doing it the other way round makes the following
problem even worse). Daylight savings is a rule RFCs cannot counteract.
UTC is the only time machines can exchange in the _general case_, because
they may be in different time zones.

PC, Mac and other small station's users do not know much about this.
Bigger systems' administrators know more of it, to varying degrees, but
especially that daylight savings rules are far from set in stone
(sometimes depending more on farmers' complaints that on computer
sanity). People's bored care is generally a rough setting of their local
clock so that the various _local_ dates in their system do not look
completely idiot in the _middle_ of summer.

Being on a network both strengthens the need for correct clock
synchronisation and offers means to achieve it.
The NTP protocol is the most refined way to distribute UTC to larger
machines with precision by far better than one second.
SNTP can be used to redistribute it to smaller ones, as a successor to
the TIME protocol (used by the setclock command).

A network administrator regrets that it is not possible, in the
_particular case_ of his machines with same time zone and daylight
savings rule, to concentrate a subject to change time offset information
on his few time servers and redistribute it automatically in addition to
UTC without a per TCP/IP implementation hack, because no time protocol
conveys the local offset (and DAYTIME is unspecified format and still a
hack to use).

Had the TIME protocol conveyed a few more bytes with this information, a
setclock writer for the PC would probably have used what he found in it
to be able to set the PC's (local time) clock without requiring a TZ
maintained by the user or set the TZ itself altogether so that the PC can
finally use UTC.
More generally speaking, an option of the setclock command could then
indicate if the server is known to use the same time offset as the client
and the time offset set in addition to UTC (the particular case).

The question are: could the TIME protocol be augmented with time offset?
If not, should the SNTP tackle the problem?
Else, is yet another time protocol needed so that the operation will be
possible in a few years?
Or is a world-wide strike to stop daylight savings the only solution?

------
Andre' Pirard         SEGI, Universite' de Lie`ge  139.165 IP coordinator
B26 - Sart Tilman     B-4000 Lie`ge 1 (Belgium)           +32 (41) 564932
pirard@vm1.ulg.ac.be  alias PIRARD@BLIULG11.BITNET

-----------[000369][next][prev][last][first]----------------------------------------------------
Date:      28 May 1993 00:15:23 GMT
From:      trier@odin.ins.cwru.edu (Stephen C. Trier)
To:        comp.protocols.tcp-ip
Subject:   Re: Time synchronization

BOOTP can convey time-zone information in the RFC 1084 vendor extension
field.

Some operating systems support automatic daylight savings time adaptation.
For those, being in the right time zone is not a major problem.

-- 
Stephen Trier (trier@ins.cwru.edu - MIME OK)   
Network Software Engineer              
IRIS/INS/T                               
Case Western Reserve University             

-----------[000370][next][prev][last][first]----------------------------------------------------
Date:      Fri, 28 May 1993 09:59:14 GMT
From:      masmm@gdr.bath.ac.uk (M McGettrick)
To:        comp.protocols.tcp-ip
Subject:   RPC problems with clnt_create() and pmap_getmaps()


I have a problem with making an rpc call to certain hosts (as far as I can 
figure out, only to RS6000s (AIX)). Basically the clnt_create() routine fails
with the message "port mapper failure" followed by RPC: Timed Out. This 
happens after say (roughly) 20 seconds. The thing is if I don't get a client
handle from clnt_create(), I can go no further.

Does anyone know how to set the TIMEOUT for the clnt_create() call itself, or
is this possible (I understand there's a default timeout of 25 seconds on RPC
stuff - I want clnt_create() to keep trying for longer than that!)?

(
To be more specific here, and example of a call I try which fails is
cl = clnt_create("130.233.224.22", 100000, 2, "tcp");
)

Another (perhaps related) problem is this: the pmap_getmaps() routine also
fails for certain hosts. This is puzzling, as the rpcinfo command succeeds
for these same hosts, and as I understand it rpcinfo uses pmap_getmaps().
Any hints here (or is it possible to get a look at the source code for 
rpcinfo)?

Thanks!

Michael Mc Gettrick,
University of Bath.
(masmm%gdr.bath.ac.uk@cunyvm.cuny.edu)


-----------[000371][next][prev][last][first]----------------------------------------------------
Date:      28 May 93 10:23:24 GMT
From:      bqt@Minsk.docs.uu.se (Johnny Billquist)
To:        comp.protocols.tcp-ip
Subject:   Re: How to convert ethernet hard. addr. to IP addr.? ARP?

In <1u2lse$dle@hermes.ath.epa.gov> kbw@helios.ath.epa.gov (Kevin B. Weinrich) writes:

>I know how (via kludge) to get an ethernet hardware address from an IP
>address:
>  ping host.domain
>  arp -a
>will first add host.domain to arp's table, then list all the machines
>currently in the table, including both numeric IP addr and ether hardware
>addr.  There's probably a slicker way to do this; I'd be thankful for hearing
>of it.
 
>But how can I do the reverse: start with an ethernet hardware address, and
>wind up with the IP address it goes with?

Was some time since I looked through this, but i think that's what RARP
are for. However, if I understand correctly, you are interested in finding
out for yourself, and not if the system can solve this for its own uses.
I don't know if and how you can talk directly to ARP and RARP, but it should
be possible in some way. I have only implemented ARP under another OS,
haven't played with it that much under unix.
--
Johnny Billquist                  || "I'm on a bus
CS student at Uppsala University  ||  on a psychedelic trip
email: bqt@minsk.docs.uu.se       ||  Reading murder books
pdp is alive!                     ||  tryin' to stay hip" - B. Idol

-----------[000372][next][prev][last][first]----------------------------------------------------
Date:      28 May 1993 10:25:37 GMT
From:      ruspc40@rus.uni-stuttgart.de (Peter Kolb)
To:        comp.protocols.tcp-ip
Subject:   Paket Driver for SMC 8013EPU wanted

Hello

I am not sure if this is the right groupe to post, but I try first here.

I am looking for a paket driver for the SMC Ether Card PLUS.
The full name is 8013EPC, and I know that SMC did WD stuff.

I have already looked in ARCHIE , and didn`t find one.
I need it for runnig telnet on a MS-DOS PC.

May someone of you know where I can find one , or where I can get an telnet 
that supports  this ethernetcard.


Pleas send E-Mail: torfnase@berapc.rus.uni-stuttgart.de

or just post in here


Thanx
Peter Kolb


-----------[000373][next][prev][last][first]----------------------------------------------------
Date:      Fri, 28 May 1993 10:27:50 GMT
From:      hmchen@fcom.ee.ntu.edu.tw (Hung-ming Chen)
To:        comp.protocols.tcp-ip
Subject:   Select function call question?

Dear Netter,
  I wrote a program using select function under Socket. When I
tested the program, sometimes the select function acted
something wrong. Its return value was greater than zero. But
when I tried to check the readmask(declare as fd_set), there
was nothing setting on. And my program did a endless loop that
caused all system CPU time were eaten by it. What's happenned?
Can I avoid this condition, or when it occured how to detect
it and recover?

P.S. It almost occured when something did a wrong action.

Fred Chen

-----------[000374][next][prev][last][first]----------------------------------------------------
Date:      Fri, 28 May 1993 10:56:49 GMT
From:      norbert@dfv.rwth-aachen.de (Norbert Vohn)
To:        comp.protocols.tcp-ip
Subject:   sliding window protocols

Hello there!

I'm a student of electrical engineering and just doing my masterthesis. 

In the scope of this I need to implement a sliding window protocol 
(with selective repeat) for usage in an simulation tool.
(see Andrew S. Tanenbaum, Computer Networks)

Maybe there exist some implementations in C++ or C?

Is there anyone who knows something about it, or even knows how to implement
the protocol quickly by myself?

So, I would wonder if someone of you could help me!

_______________________________________________________________________________
Norbert Vohn                  			 	 |     C   O   M
Communication Networks, Technical University of Aachen   | --v-^-v-^-v-^-v--
  Phone: +49-241-807925       Fax: +49-241-84964         |   N   E   T   S
  Email: norbert@dfv.rwth-aachen.de                      | RWTH Aachen, Germany

-- 
Norbert Vohn                  			 	 |     C   O   M
Communication Networks, Technical University of Aachen   | --v-^-v-^-v-^-v--
  Phone: +49-241-807925       Fax: +49-241-84964         |   N   E   T   S
  Email: norbert@dfv.rwth-aachen.de                      | RWTH Aachen, Germany

-----------[000375][next][prev][last][first]----------------------------------------------------
Date:      28 May 93 11:10:09 GMT
From:      gerry@spider.co.uk (Gerry Meyer)
To:        comp.protocols.tcp-ip
Subject:   Re: RFC for keepalives

emv@garnet.msen.com (Edward Vielmetti) wrote:
>Frank Ciotti (frankc@teleng.eng.telxon.com) wrote:
 
>: Is there an RFC for TCP keepalive polls?  I could not find any reference
>: to them in the RFC index, RFC 793, RFC 896, or the Comer/Stevens books.
 
>A quick WAIS search of "internet-rfcs" for "keepalive" or "keepalives"
>threw up references to these RFCs - I don't know how much they say about
>them tho (someoen who could condense these referecnes into something
>useful would be welcomed).
 
>rfc1267.txt rfc1163.txt rfc1105.txt rfc969.txt rfc998.txt rfc1323.txt
>rfc1265.txt rfc1164.txt

I hope all references to TCP keepalives in these will be unfavourable.

They are a practice to be severly frowned upon.

As an example if you make a telnet connection via a wide area network
dialup/demand connection and leave yourself logged in over the week end YOU
will foot the telephone bill because these useless keepalives have
forced your router to keep the call open UNNECESSARILY.

-----------[000376][next][prev][last][first]----------------------------------------------------
Date:      28 May 93 16:36:24
From:      drw@zermelo.mit.edu (Dale R. Worley)
To:        comp.protocols.tcp-ip
Subject:   Return-receipt-to and Errors-to headers

There are a small number of headers that sendmail implements but are
not described in RFC 822.  Most useful among these are
Return-receipt-to: and Errors-to:.  Has there been a more recent RFC
that has standardized these, or are they still strictly non-standard?
Would it be a useful thing to produce an RFC that standardized them?

Thanks,

Dale

-----------[000377][next][prev][last][first]----------------------------------------------------
Date:      Fri, 28 May 1993 09:54:03 +0200
From:      Andre' Pirard <pirard@vm1.ulg.ac.be>
To:        comp.protocols.tcp-ip
Subject:   Re: SLIP Recommendations

In article <1u34pp$n7u@fnnews.fnal.gov> Marc Mengel,
mengel@dcdmwm.fnal.gov writes:
> In article <SCOTT.93May26210403@nova.tcs.tufts.edu>,
 scott@nova.tcs.tufts.edu
> |>     If multiple SLIP links share the same modem means supporting the
> |>     connections simultaneously (ie a multi-drop line), then I am
> |>     unaware of any SLIP implementation which supports this (is it
 even
> |>     possible)... :-)
>
> I guess I'm having trouble seeing why this would be so difficult, if you
> had some sort of box to hand around ClearToSend leads to each connection
> on the multi-drop (which multi-drop lines usually do...)  Of course you
> would "hear" lots of frames that weren't yours, which would be bad if
 you
> tried to route them...

The first aspect is that the SLIP encapsulation just doesn't provide the
information to sort out multiplexed level 2 connections on a single line.
One could use  another protocol to tunnel SLIP indeed, but that wouldn't
be SLIP we would be talking of any longer.

The second aspect is that PPP is able to multiplex different protocols,
because its encapsulation contains a protocol type (while SLIP implies
IP).

Did I understand correctly so far?

The third aspect I am raising is that, when properly configured, a Cisco
Terminal Server is able to "multiplex SLIP at level 3" or, in simpler
parlance, to connect a remote IP network (not a single IP address) over a
dialup or fixed asynchronous line (and in fact do everything the full
blown routers do on synchronous line, but limited to IP, for example load
balancinng on parallel lines, X.25 over IP, ..., isn't that lovely). SLIP
or CSLIP on demand.
For that matter, they have been quite appropriately renamed
"Communication Server", specifically models CS 508 and CS 516 (8/16
ports).
Does any other make do similar things?

------
Andre' Pirard         SEGI, Universite' de Lie`ge  139.165 IP coordinator
B26 - Sart Tilman     B-4000 Lie`ge 1 (Belgium)           +32 (41) 564932
pirard@vm1.ulg.ac.be  alias PIRARD@BLIULG11.BITNET

-----------[000378][next][prev][last][first]----------------------------------------------------
Date:      Fri, 28 May 1993 10:47:24 +0200
From:      Andre' Pirard <pirard@vm1.ulg.ac.be>
To:        comp.protocols.tcp-ip
Subject:   Re: Time synchronization

In article <1u3lir$g90@usenet.INS.CWRU.Edu> Stephen C. Trier,
trier@odin.ins.cwru.edu writes:
> BOOTP can convey time-zone information in the RFC 1084 vendor extension
> field.

I am not sure that a bootp server would (presently) be the best means to
answer such requests coming from all over the campus. A fact is that the
idea did not materialize in PC setclock implementation. Something more
obvious would be needed.
You're sure right in migrating the idea that the info could come from
sort of a 'campus info' protocol, together with other data. An extendable
protocol. This would further simplify TCP/IP installation indeed.
In fact, there are too many protocols providing what a single one could
give (TIME, DAYTIME, BOOTP, ICMP router discovery, RARP ...).
Some info being LAN specific and the other general, are two protocols
needed or can a single one be designed so that a local server fills in
general info from a global one. Is it the role of the local router
(replaced by a local host if there is no router) to answer the
(broadcast) request (instead of requiring a full blown server on each and
every tiny network). Or are request to be forwarded to the global one
that would recognize the originating network?
Maybe an extended BOOTP after all? Dunno.
Of course, it wouldn't simplify setup until the protocol became a
requirement...

------
Andre' Pirard         SEGI, Universite' de Lie`ge  139.165 IP coordinator
B26 - Sart Tilman     B-4000 Lie`ge 1 (Belgium)           +32 (41) 564932
pirard@vm1.ulg.ac.be  alias PIRARD@BLIULG11.BITNET

-----------[000379][next][prev][last][first]----------------------------------------------------
Date:      Fri, 28 May 1993 14:20:50 GMT
From:      cam@mbunix.mitre.org (McLaughlin)
To:        comp.protocols.tcp-ip
Subject:   Routing Protocol Overhead - Class C vs. Class B

Has anyone got information on differences in routing protocol overhead
expected when a set of Class C networks  ( > 256 nets) is
implemented vs. several Class B networks?  The Class Cs will be set up
to take advantage of supernetting, when supernetting becomes available. Until
then, what should we expect?  We're looking at using BGP3, currently are
using EGP, OSPF.

Colleen McLaughlin	cam@mbunix.mitre.org
C2 Communications
The MITRE Corp.

-----------[000380][next][prev][last][first]----------------------------------------------------
Date:      Fri, 28 May 1993 14:31:33 GMT
From:      vjs@rhyolite.wpd.sgi.com (Vernon Schryver)
To:        comp.protocols.tcp-ip
Subject:   Re: RFC for keepalives

In article <1993May28.111009.15926@spider.co.uk>, gerry@spider.co.uk (Gerry Meyer) writes:
> 
> I hope all references to TCP keepalives in these will be unfavourable.
> They are a practice to be severly frowned upon.
> 
> As an example if you make a telnet connection via a wide area network
> dialup/demand connection and leave yourself logged in over the week end YOU
> will foot the telephone bill because these useless keepalives have
> forced your router to keep the call open UNNECESSARILY.


That's such an overstatement that it is simply wrong.

First, if the router keeps the call alive continually, then the router
is broken.  A packet every few hours should not require the router to
keep the line open continually.  It should simply than restore the line
for a few minutes every few hours to pass the keepalive.  (Assuming the
now typical hours between keepalives.)

Second, people really need keepalives in many circumstances.  If they
didn't they wouldn't continually ask about them in this newsgroup.
That they usually don't use the right jargon, and instead ask about
determining if a link has died is not their fault.

That keepalives are not always useful or that they are not free does
not imply that they should be outlawed.


Vernon Schryver,  vjs@sgi.com

-----------[000381][next][prev][last][first]----------------------------------------------------
Date:      28 May 93 15:48:25 GMT
From:      lvandyke@balboa.eng.uci.edu (Lee Van Dyke)
To:        comp.protocols.tcp-ip
Subject:   When does recv exit if its buffer is not full?

Hi, in general, does anyone know when recv exits if its buffer is
not full?

I am losing data when sent from a sun to a pc running dvx, using
the dvx recv.


TIA

Lee

--
Lee Van Dyke
      lvandyke@balboa.eng.uci.edu,
UUCP: infotec!Infotec.COM!lee@sunkist.West.Sun.COM

-----------[000382][next][prev][last][first]----------------------------------------------------
Date:      28 May 93 16:42:11 GMT
From:      ercm20@festival (Sam Wilson)
To:        comp.protocols.tcp-ip
Subject:   Re: MacTCP 1.1.1 and DNS...

Mr K C Craig (keith@comp.lancs.ac.uk) wrote:

: Just as word of a warning (and maybe a question to) when you run MAC TCP/IP, it
: doesn't seem to bother to check if the IP address that you supply to it is already in use.
: This makes for great "entertainment" if a user places the IP address of your X-Term server
: in their configuration by mistake.  In PC TCP/IP work I have done the system checks to 
: see if the IP address has already been used.

Err... I had a user phone me the other day to say that she couldn't get
Telnet started on her Mac because MacTCP was complaining that someone
else was using its IP number (indeed it was!).  There may be a version
difference here, but whatever we are using (could be 1.1.1) obviously
does check, presumably by doing an ARP for its own address.


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


-----------[000383][next][prev][last][first]----------------------------------------------------
Date:      Fri, 28 May 1993 17:00:52 GMT
From:      richb@jti.com (Rich Braun)
To:        comp.mail.sendmail,comp.unix.admin,comp.protocols.tcp-ip
Subject:   SysVr4 + IDA sendmail:  FQDN anomaly

Sending mail from my site to users on the following sites doesn't work:

    Generic name          FQDN of primary MX forwarder

    u.washington.edu      bashful.u.washington.edu
    apollo.hp.com         daphne.ch.apollo.hp.com
    attmail.com           att.att.com

What these sites have in common is this:  sending mail to "user@FQDN"
will bounce or fail to get through a gateway sitting behind a firewall;
this is how those sites are configured.  For most sites, sending mail
to "user@generic" works fine; from here, it doesn't.

I'm running IDA sendmail v5.65c, and Microport SysVr4.1 (also Unix 3.2
as shipped by Intel about 3 years ago).  What I'm looking for is other
people who are running the same combination of software to test mail
directed toward these sites.  Any SysV implementation may or may not
exhibit this behavior, and I'm curious as to just how many people might
run into this problem.  To test this, run 'sendmail -bt' and enter the
command '3,0 foo@generic.site.domain' and see if it translates the name
to a FQDN or leaves it well enough alone.

What's happening is the DNS resolver is substituting the MX gateway's
FQDN for the generic name in rule set 8 within IDA's Sendmail.mc rule.
According to Neil Rickert, this should not be happening, and it
signifies a bug in the vendor's resolver library.

This problem has caused some embarrasing moments for me as I've reported
"bugs" to the postmasters at these sites, and although they've got their
sites configured in somewhat unusual ways, there's nothing about them
which violates any of the SMTP standards.

-rich

-----------[000384][next][prev][last][first]----------------------------------------------------
Date:      28 May 1993 17:55:29 GMT
From:      carl@busop.cit.wayne.edu (carl@busop.cit.wayne.edu)
To:        comp.protocols.tcp-ip
Subject:   working COOKIE servers ... need IP addresses ?


I doubt this is the best place to post such a request, but I couldn't find 
anywhere else that seemed appropriate.

Does anyone have any COOKIE server addresses, perferably in the U.S., as 
many as you can list?  Thank you.


-----------[000385][next][prev][last][first]----------------------------------------------------
Date:      28 May 93 18:55:21 GMT
From:      guy@Auspex.COM (Guy Harris)
To:        comp.protocols.tcp-ip
Subject:   Re: sockoptions in TLI

>>I have a system which is built around TLI (SunOS). Since the transport
>>provider I'm using (tcp) is configured with the Nagle-algoritm option disabled
>>(The TCP_NODELAY for sockets) and my system sends out a lot of small packets
>>I'd like to set the TCP_NODELAY option thus enabling the Nagle algoritm
>
>//[turning O_NDELAY on] works on a SunOS 4.1.x

Sorry, wrong answer.  TCP_NODELAY has nothing to do with O_NDELAY;
TCP_NODELAY disables the Nagle algorithm, while O_NDELAY puts the file
descriptor into "no delay" mode.

From a look at the SunOS 4.1[.x] code, it appears that the "/dev/tcp"
code will turn the Nagle algorithm off whenever it accepts a connection,
or whenever, when making a connection, the other side accepts the
connection.

-----------[000386][next][prev][last][first]----------------------------------------------------
Date:      Fri, 28 May 1993 19:03:18 GMT
From:      yefim@magna.com (Yefim V. Natis)
To:        comp.protocols.tcp-ip,comp.protocols.misc,comp.protocols.ibm
Subject:   CPI-C over TCP/IP

I am looking for communications software with CPI-C (or near) API to use on 
a TCP/IP-connected network.  The hardware involved is the major flavors of
UNIX servers, the IBM mainframes, and Bull (Honeywell) mainframes.

Please help, if you can.  Find me at ynatis@magna.com on uunet.

Thanks

Yefim Natis
Software Architect
Magna Software Corporation



-----------[000387][next][prev][last][first]----------------------------------------------------
Date:      Fri, 28 May 93 19:13:00 GMT
From:      hgv@herring.network.com (Harry G. Varnis)
To:        comp.protocols.tcp-ip
Subject:   Rare (but nasty) BSD TCP problem

I recently stumbled across an admittedly weird case of socket misuse
that locks up SunOS 4.1 tighter than a drum.  It happens when an application
connects through a local interface to the same port to which it is bound.
From experimentation on another platform it appears that the TCP is mangling
the tcb state in such a way as to induce a hard loop doing tcp_output-s.

If someone knows of a fix to this problem I would appreciate hearing
of it.

Here is the program.  Execute at your own risk.

#include <sys/types.h>
#include <sys/socket.h>
#include <netinet/in.h>

main()
{
    struct sockaddr_in server;
    int     s, length;

    s = socket(AF_INET, SOCK_STREAM, 0);
    if (s < 0) {
        perror("socket");
        exit(1);
    }
    bzero(&server, sizeof(server));
    server.sin_family = AF_INET;
    server.sin_addr.s_addr = INADDR_ANY;
    server.sin_port = htons(0);

    if (bind(s, &server, sizeof(server)) < 0) {
        perror("bind");
        exit(1);
    }
    length = sizeof(server);
    if (getsockname(s, &server, &length) < 0) {
        perror("getsockname");
        exit(1);
    }
    printf("local: addr %s port %d\n", inet_ntoa(server.sin_addr),
      ntohs(server.sin_port));

    server.sin_addr.s_addr = inet_addr("127.0.0.1");
    printf("connecting: addr %s port %d\n", inet_ntoa(&server.sin_addr),
      ntohs(server.sin_port));

    if (connect(s, &server, sizeof(server)) < 0) {
        perror("connect");
    }
 exit(0);
}
-- 
Harry Varnis         <hgv@anubis.network.com>          +1 612 493 1042

-----------[000388][next][prev][last][first]----------------------------------------------------
Date:      Fri, 28 May 1993 19:17:06 +0000
From:      pbs@lmrln.demon.co.uk (Philip Shearer)
To:        comp.protocols.tcp-ip
Subject:   SLIP Recommendations

|> I was wondering if anyone could tell me about some good SLIP
|> implementations.  I am trying to connect remote PC's to a central
|> Sun 690.  The connections will not be up 24 hours/day, but rather
|> about 4-6 hours/day.
|>
|> Could anyone help me as to reasonable modem and phone line specs
|> as well?  Is there any software or hardware that can manage several
|> slip connection through a single serial line?
|>
|> Thanks for your help!!!
|>
|> Jeffrey Horn

I have a setup somthing like the set up you wish to have.
I have a couple of sites where I run Sun machines with a PD version of
slip:
slip-4.1-beta
from  Mark.Andrews@syd.dms.csiro.au
I picked it up with ftp from src.doc.ic.ac.uk

This version works with SunOS 4.1.x

The suns are connected via tcp/ip to terminal servers manufactured by
Chase Resurch here in the UK. I have seen adverts for them in US mags
but if you want info mail hda@chaser.co.uk

{Terminal servers alow you to place the serial connectons near the phone lines
and only have one eiternet cable to the place where the modems and phone lines 
are.}

Attached to the terminal servers are a number of modems.
We use telibits 2500s but they are expensive and not neccerily what you need.
Any good V42 bis modem will do.

Here in the UK I connect to Internet via a dialup connection using slip
to a company called DEMON LTD. 

Since they started last year they built up their client list to 1000+,
most  clients are using dialup slip/ppp connections to their machines. 
I connect using UNIX, but many of their clients use PD PC slip/ppp software.

I am not to hot on PD PC software but I believe that they recomend ka9q
but I might be wrong.

I would suggest that you contact them at email address:
internet@demon.co.uk. 

I am shure that any consultancy fees that they charged you would be
well worth while. 



-----------[000389][next][prev][last][first]----------------------------------------------------
Date:      28 May 93 19:27:48 GMT
From:      paul@alantec.com (G. Paul Ziemba)
To:        comp.protocols.tcp-ip,comp.sys.sun.admin,comp.security.misc,comp.unix.admin
Subject:   Announcing tcpr: proxy ftp/telnet through firewall


Tcpr was announced on the firewalls mailing list at the beginning of
the year; after a few tweaks, it seems as if it's ready for a wider
distribution. The currrent release is 1.1.5.

[From the README file]

    Tcpr is a set of perl scripts that enable you to run ftp and telnet
commands across a firewall. Forwarding takes place at the application
level, so it's easy to control.

    Tcpr consists of an inetd-type server that interprets commands, 
a relay program, and a client that talks to the server.

    The client asks the server for a relay connection to some specified
remote host at a specified TCP port number; the server invokes the relay
program and returns a proxy port number to the client. The client then
invokes telnet or ftp, telling them to connect to the relay host at the
proxy port number. The relay program then transfers data between the
client host and the remote host.

    Special handling is implemented for the FTP data connection, so
everything works properly.



Where to get it

    Tcpr is available from the following servers via anonymous ftp:

	ftp.alantec.com		pub/tcpr
	ftp.cs.umb.edu		pub/security
	ftp.psg.com		pub/unix/netware
	grasp1.univ-lyon1.fr	pub/unix/network/tcpip/security
	ftp.denet.dk		pub/misc/tcpr


Platforms

    Tcpr is known to work on SunOS 4.1. I haven't tested it on other
platforms, so I can't say if it'll work right out of the box for them.
It's all perl, but the output format of the netstat and ifconfig commands
might vary, and there isn't much flexibility in the parser for that yet.



Acknowledgements

    The tcpr package is based on a relay program written by
Kazumasa Utashiro, <utashiro@sra.co.jp>. The relay program originally
was to be invoked manually on the relay host, giving a port number which
the user then used as an argument to the ftp or telnet program.

    I modified the relay program to select an outgoing interface
based on some simple routing computations, and wrote a client and server
to automate the process.

    Many thanks to the maintainers of the ftp sites mentioned above,
listed in reverse alphabetical order (-:

	Christophe.Wolfhugel
	John P. Rouillard
	Kim H|glund
	Randy Bush

-- 
Paul Ziemba, software archaeologist: paul@alantec.com	alantec!paul
    "The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore, all progress
depends on the unreasonable man." - George Bernard Shaw

-----------[000390][next][prev][last][first]----------------------------------------------------
Date:      Fri, 28 May 1993 21:30:37 GMT
From:      mahmood@lambda.msfc.nasa.gov (Rafique Mahmood)
To:        comp.protocols.tcp-ip,comp.sys.sun.admin
Subject:   Need help on running 'tcpview'

Problem/question 1:

I have installed the tcpview in sun sparcstation 2. I have problem to
link with the option '-Bstatic' which is in the makefile. It tells:

	Undefined
		-dlsym
		-dlopen
		-dlclose

Then I took '-Bstatic' out and it compiled fine.

What is this Bstatic does? Is is ok to link without it?

Problem/question 2:

When I try to run tcpview it says:

	tcpdump: open: /dev/nit: permision denied.

I looked at /dev/nit. it had only root read write permision:
	crw-r--r-- 1 root      37,  40 Jan 10  1991 nit 
I then changed the permision to:
crw-rw-rw-  1 root      37,  40 Jan 10  1991 nit

That solved the permision problem but after window comes up everything get
hung.

What is the problem? I was running as a user. Is is that only root can run it?

I could not run as a root because it gave lots of warning:

	Warning: translation table syntax error: Unknown keysym name: osfDown
Warning: ... found while parsing 's c <Key>osfDown:forward-paragraph(extend)'
Warning: translation table syntax error: Unknown keysym name: osfDown
Warning: ... found while parsing 'c <Key>osfDown:forward-paragraph()'
Warning: translation table syntax error: Unknown keysym name: osfDown
Warning: ... found while parsing 's <Key>osfDown:process-shift-down()'
Warning: translation table syntax error: Unknown keysym name: osfDown
Warning: ... found while parsing '<Key>osfDown:process-down()'
Warning: translation table syntax error: Unknown keysym name: osfHelp
Warning: ... found while parsing '<Key>osfHelp:ManagerGadgetHelp()'
Warning: translation table syntax error: Unknown keysym name: osfActivate



Please let me know what are these error ( seems motif error)?
what can I do for this?  It seems still it runs ok (I don't know
what to expect).


My last question is how can I save the captured packets in a file?

Thanks and I appreciate verymuch any help.
please email me the response.

Rafique
email: mahmood@lambda.msfc.nasa.gov


-----------[000391][next][prev][last][first]----------------------------------------------------
Date:      29 May 1993 00:43:52 GMT
From:      barr@pop.psu.edu (Dave Barr)
To:        comp.protocols.tcp-ip
Subject:   Re: Rare (but nasty) BSD TCP problem

In article <1993May28.191300.21994@ns.network.com> hgv@herring.network.com (Harry G. Varnis) writes:
>I recently stumbled across an admittedly weird case of socket misuse
>that locks up SunOS 4.1 tighter than a drum.

Sure does.  I ran it on a 4.1.1B (plus lots of patches) machine and it
locked up real tight.  But, I ran it on a 4.1.3 machine and it was fine.

--Dave
-- 
System Administrator, Penn State Population Research Institute
End of article 2565 (of 2565)--what next? [npq]

-----------[000392][next][prev][last][first]----------------------------------------------------
Date:      29 May 1993 02:32:10 GMT
From:      barmar@think.com (Barry Margolin)
To:        comp.protocols.tcp-ip
Subject:   Re: How to convert ethernet hard. addr. to IP addr.? ARP?

In article <1u2lse$dle@hermes.ath.epa.gov> kbw@helios.ath.epa.gov (Kevin B. Weinrich) writes:
>But how can I do the reverse: start with an ethernet hardware address, and
>wind up with the IP address it goes with?

I don't think all hosts support it (or whether they're even *supposed* to),
but many systems (Suns, cisco routers, and Tektronix X terminals, but not
NCD X terminals) will respond to a ping to the broadcast address.  So if
you ping the broadcast address, your ARP cache will soon be filled with the
ethernet address of many of the systems on the subnet.

telecaster-24% arp -a | wc -l
      11
telecaster-25% ping 131.239.53.255
131.239.53.255 is alive
telecaster-26% arp -a | wc -l
      14
-- 
Barry Margolin
System Manager, Thinking Machines Corp.

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

-----------[000393][next][prev][last][first]----------------------------------------------------
Date:      Sat, 29 May 1993 02:33:38 GMT
From:      tjohnson@cobber.cord.edu (Protius)
To:        comp.sys.att,u3b.tech,comp.unix.admin,comp.protocols.tcp-ip
Subject:   Re: SLIP for 3B2

In article <2120@dsinet> daveb@jaws (David Breneman) writes:
>Greg's 3B2 FAQ contains a cryptic message :-) about SLIP for the 3B2:
>
>---CUT---
>------------------------------------------------------------------------
>Subject: 14 Is there an implementation of SLIP for the 3B2?
>------------------------------------------------------------------------
>
>Rumor has it that there was one written by Wollongong, but AT&T
>purchased exclusive marketing rights to WIN TCP/IP for the 3B2, but
>chose NOT to include SLIP.  There is the NOS (KA9Q) package that

The rumors are true, there is a real implementation of SLIP for 3B2s.
It calls itself NTI, networking TTY interface, or something like that.
It apparently works only with WIN/3b version 3.2.  I told Greg about 
it a while ago, but we both got distracted.  It is a commercial product
so all the legalise applies.

>
>What is the NOS package?  *Has* anybody ported SLIP to the 3B2?
>"Enquiring minds which can't afford an ethernet card want to know."
>Thanks to any and all respondants.

About a year ago, I tried a system V port of KA9Q that I found on
wuarchive on a 3b2/300.  It worked... sort of.  I could telnet to
another machine, and login, but if I got lots of characters at once,
like a longish ls, the 3b2 couldn't keep up and KA0Q would lock up.

>
>
>--
>David Breneman                          Email: daveb@jaws.engineering.dgtl.com
>System Administrator,
>Software Engineering Services
>Digital Systems International, Inc.     Voice: 206 881-7544  Fax: 206 556-8033

-Tommy Johnson                        #include<std.disclaimer.h>
tjohnson@cobber.cord.edu
I probably don't know what I'm talking about.

-----------[000394][next][prev][last][first]----------------------------------------------------
Date:      29 May 93 06:57:34 GMT
From:      vmendoza@Auspex.COM (Vince Mendoza)
To:        comp.protocols.tcp-ip
Subject:   Re: non-blocking mode! and then?

In article <PHILIPPE.93May24153245@gull.world> philippe@gull.world (Philippe Waroquiers) writes:
>
>Dear netters,
>
>If you know TCP-IP and the socket interface, then perhaps you know the
>answers to the following 2 questions :
>
>
>I am using the socket BSD interface in non blocking mode. This works ok but
>in some cases, I do not see how I can determine the state of the socket.
>
>Question 1 (after a select for "connect"):
>------------------------------------------
>  a socket is created
>  then set it in non blocking mode using  fcntl(2) and the flag O_NONBLOCK.
>  I then use the connect(2) system call.
>     The manual of connect(2) indicates then that select(2) can be used to
>     determine if the connect is succesful by selecting for writing.
>
>If no process is listening, the select call also terminates and does not
>indicate an error.
>
>Question is : in such a case, how do I see if the socket is
connected?

I am assuming that you are talking TCP.  If so, the "netstat -a"
command shows TCP states of the socket.  If the socket is
connected, the state field for that particular connection will be
CONNECTED.
>
 
>
>Question 2 (after a select for "read"):
>---------------------------------------
>when a socket is selected for read, the select returns when the socket is
>ready for reading. Then some data can be read.
>
>When the remote process closes the socket or dies, the socket is always
>selectable for read but no data can be received (read returns 0 bytes but
>does not return an error).
>
>Question is : in such a case, how do I determine that the connection is
>not valid anymore ? (note : I do not want to write on the socket to see
>it the socket is still valid).

In the a shell, the netstat -a command will serve the same
purpose.  In some cases, you may see the state of a connection
like this hang in something like a FIN-WAIT or CLOSE-WAIT state
(not exactly positive).  But in summary, the netstat command can
help you out.

---

Vince Mendoza 	{Technical Marketing Engineer}	
Auspex Systems
Address:	5200 Great America Parkway
		Santa Clara, CA. 95054
Internet:	vmendoza@auspex.com
Phone:		(408) 986-2397
Fax:		(408) 986-2020










--

Vince Mendoza 	{Technical Marketing Engineer}	
Auspex Systems
Address:	5200 Great America Parkway

-----------[000395][next][prev][last][first]----------------------------------------------------
Date:      Sat, 29 May 1993 16:27:27 GMT
From:      dls@mentor.cc.purdue.edu (David L Stevens)
To:        comp.protocols.tcp-ip
Subject:   Re: Rare (but nasty) BSD TCP problem

	The problem is that there is only one copy of the TCB, so both
sides of the connection are trying to change its state in incompatible
ways. Here's my version of a fix done by another department here at Purdue.
This is code for our version of Sequent's DYNIX, but with the 4.3 Tahoe
code in it. I think all of this section is straight Tahoe code, but line
numbers will certainly be different; the relevant function is in_pcbsetaddr()
in our code. I think this was in in_pcbconnect() directly in 4.2-based code.
	You could do this in TCP's connect() code, too, but the problem
will apply generally to connection-oriented protocols. So we did it here.


*** OLD in_pcb.c
--- NEW in_pcb.c	Mon Oct 26 14:32:06 1992
***************
*** 190,195 ****
--- 190,196 ----
  {
  	struct in_ifaddr *ia;
  	struct sockaddr_in *ifaddr;
+ 	struct protosw *pr;
  
  	if (sin->sin_family != AF_INET)
  		return (EAFNOSUPPORT);
***************
*** 274,289 ****
  		return (EADDRINUSE);
  #endif	notdef
  
+ 	pr = inp->inp_socket->so_proto;
+ 	/* try and prevent kernel from looping when a TCP socket is
+ 		connected to itself */
+ 	if ((pr->pr_flags & PR_CONNREQUIRED) && sin->sin_port == inp->inp_lport
+ 			&& ((inp->inp_laddr.s_addr == INADDR_ANY)?
+ 			ifaddr->sin_addr.s_addr: inp->inp_laddr.s_addr)
+ 			== sin->sin_addr.s_addr) {
+ 		return(ECONNREFUSED);
+ 	}
  
  	if (inp->inp_laddr.s_addr == INADDR_ANY) {
  		if (inp->inp_lport == 0) {


-- 
					+-DLS  (dls@mentor.cc.purdue.edu)

-----------[000396][next][prev][last][first]----------------------------------------------------
Date:      Sat, 29 May 1993 19:21:45 GMT
From:      donp@novell.com (don provan)
To:        comp.protocols.tcp-ip
Subject:   Re: RFC for keepalives

In article <i6ehhmu@rhyolite.wpd.sgi.com> vjs@rhyolite.wpd.sgi.com (Vernon Schryver) writes:
>First, if the router keeps the call alive continually, then the router
>is broken.  A packet every few hours should not require the router to
>keep the line open continually.  It should simply than restore the line
>for a few minutes every few hours to pass the keepalive.  (Assuming the
>now typical hours between keepalives.)

I'd love to hear more about "hours between keepalives" being "typical".
I'm hearing that BSD is brisk enough with its keepalives to detect a
failed node within minutes.  And i assume BSD behavior is still
generally considered typical.
						don provan
						donp@novell.com

-----------[000397][next][prev][last][first]----------------------------------------------------
Date:      Sat, 29 May 1993 19:30:18 GMT
From:      donp@novell.com (don provan)
To:        comp.protocols.tcp-ip
Subject:   Re: Rare (but nasty) BSD TCP problem

In article <1993May28.191300.21994@ns.network.com> hgv@herring.network.com (Harry G. Varnis) writes:
>I recently stumbled across an admittedly weird case of socket misuse
>that locks up SunOS 4.1 tighter than a drum.  It happens when an application
>connects through a local interface to the same port to which it is bound.

Just for the record, although i concur that this is a rare and
probably useless operation, it is not a "misuse".  There's nothing
about this operation that violates any TCP principle, and the
resulting TCP connection should be entirely legal and usable.

On the other hand, this result is entirely unexpected, which explains why
it's so often botched.  In fact, now that i think of it, i'm not sure
i've ever seen a TCP implementation that got this right the first time.

						don provan
						donp@novell.com

-----------[000398][next][prev][last][first]----------------------------------------------------
Date:      29 May 1993 20:51:09 +0200
From:      hn277pk@unidui.uni-duisburg.de (Peter Koch)
To:        comp.protocols.tcp-ip
Subject:   MacTCP and DNS and Bootp

Dear Readers,

I have asked this question some time ago but got no answer.
The recent discussion in this newsgroup about MacTCP and DNS
especially the following three lines 

> John Veizades...
> MacTCP Lead Engineer
> Apple Computer, Inc.

in one of the postings made me ask it again.

Our department has its own subnet. We must have more than one
gateway and more the one nameserver. We must move the namewervers
between machines once in a while and in the past it happened
twice that I spend a whole day changing the nameserver-IP-address
on all our macs. At the moment our computing center is even thinking
about changing the subnet mask.

Now all this would be no problem if I only could configure MacTCP
to behave in the following way:

On startup it broadcasts a bootp-request. Then the bootp-server
supplies the following information:
 
complete host name (ie foo.bar.sub.top), ip number of host, subnetmask
list of gateways and list of nameservers.

MacTCP should now use the supplied information and set its default
domain to the domain of its name (ie .bar.sub.top)

With MacTCP 1.1.1 part of this works but it is my impression
that in order to make MacTCP use the nameservers from the
bootp-reply one must not specify any nameservers in the control
panell. But then MacTCP only uses the first nameserver from the supplied
list and no default domain.

At the moment I am running a programm on our bootp server that
permanently checks if the first nameserver in the list of nameservers
is still running. If not the programms changes the bootptab file
and replaces the nameserver by one that is running. And all our users
have to fully specify all hostnames in TCP-application due to the
lack of a default domain.

There should be a better way to do this!

Much thanks in advance

Peter Koch   koch@math.uni-duisburg.de

-----------[000399][next][prev][last][first]----------------------------------------------------
Date:      Sun, 30 May 1993 01:21:14 GMT
From:      vjs@rhyolite.wpd.sgi.com (Vernon Schryver)
To:        comp.protocols.tcp-ip
Subject:   Re: RFC for keepalives

In article <1993May29.192145.2576@novell.com>, donp@novell.com (don provan) writes:
> In article <i6ehhmu@rhyolite.wpd.sgi.com> vjs@rhyolite.wpd.sgi.com (Vernon Schryver) writes:
> >First, if the router keeps the call alive continually, then the router
> >is broken.  A packet every few hours should not require the router to
> >keep the line open continually.  It should simply than restore the line
> >for a few minutes every few hours to pass the keepalive.  (Assuming the
> >now typical hours between keepalives.)
> 
> I'd love to hear more about "hours between keepalives" being "typical".
> I'm hearing that BSD is brisk enough with its keepalives to detect a
> failed node within minutes.  And i assume BSD behavior is still
> generally considered typical.
> 						don provan
> 						donp@novell.com


Instead of just loving to hear nonsense and then repeating it, why
don't you check the source?  It's been more than half a dozen years
since 4.3BSD came out with slow keep alives.  Consider the implications
of this line:

#define  TCPTV_KEEP_IDLE (120*60*PR_SLOWHZ)   /* dflt time before probing */


Fetch and read netinet/tcp_timer.c and netinet/tcp_input.c from uunet.
For extra credit, look at netinet/tcp_usrreq.c and netinet/tcp_output.c.

You won't go far wrong simply by looking at the SVR3 or SVR4 source
from your new, east coast colleagues.


You should also pay attention the reams of complaints in this newsgroup
(and maybe still a mailing list) from people who find that 4.3BSD TCP
is <<not>> "brisk enough with its keepalives to detect a failed node
within minutes".  Whatever "failed node" might be.

A dead connection that is active is generally detected within minutes,
but only because of reasonable transmission timers, which have absolutely
nothing to do with keepalives.


Vernon Schryver,  vjs@sgi.com

-----------[000400][next][prev][last][first]----------------------------------------------------
Date:      Sun, 30 May 1993 07:18:40 GMT
From:      donp@novell.com (don provan)
To:        comp.protocols.tcp-ip
Subject:   Re: RFC for keepalives

In article <i7d52o8@rhyolite.wpd.sgi.com> vjs@rhyolite.wpd.sgi.com (Vernon Schryver) writes:
>Instead of just loving to hear nonsense and then repeating it, why
>don't you check the source?  It's been more than half a dozen years
>since 4.3BSD came out with slow keep alives.  Consider the implications
>of this line:

I'm not sure what i ever did to you to illicit this tone, but you
know, in that half a dozen years, i've never had the slightest
interest in finding or retrieving the BSD sources, let alone studying
them well enough to find the one line you tell me i'd be looking for:

>#define  TCPTV_KEEP_IDLE (120*60*PR_SLOWHZ)   /* dflt time before probing */

I take it this makes the default time two hours?  How is the default
time overridden, and how many installations or applications override it?

>You should also pay attention the reams of complaints in this newsgroup
>(and maybe still a mailing list) from people who find that 4.3BSD TCP
>is <<not>> "brisk enough with its keepalives to detect a failed node
>within minutes".  Whatever "failed node" might be.

The typical "failed node" is an idle FTP client (i.e., in a state
where the server isn't transmitting anything, so there's nothing in
any retransmission queue) which crashes and reboots without
remembering the previous FTP session.  How long will it take a typical
4.3BSD FTP server to notice that this client has forgotten about the
connection, and are keepalives the mechanism used to make that
discovery?  Is this the case people complain about?  (Funny i don't
recall any of these discussions.  I must have dozed off.)

>A dead connection that is active is generally detected within minutes,
>but only because of reasonable transmission timers, which have absolutely
>nothing to do with keepalives.

Duh.
						don provan
						donp@novell.com

-----------[000401][next][prev][last][first]----------------------------------------------------
Date:      Sun, 30 May 93 15:17:53 EDT
From:      MACE@HDQCMS2H.UTSD.ATT.COM
To:        comp.protocols.tcp-ip,comp.protocols.misc,comp.protocols.ibm
Subject:   Re: CPI-C over TCP/IP

In article <C7r3LJ.E9M@magna.com>
yefim@magna.com (Yefim V. Natis) writes:
 
>I am looking for communications software with CPI-C (or near) API to use on
>a TCP/IP-connected network.  The hardware involved is the major flavors of
>UNIX servers, the IBM mainframes, and Bull (Honeywell) mainframes.
>
>Please help, if you can.  Find me at ynatis@magna.com on uunet.
>
>Thanks
>
>Yefim Natis
>Software Architect
>Magna Software Corporation
>
>
 
I would also be interested in the response to this question.  Please post
the information!  Thanks!
------------------------------------------------------------------------------
Mace Moneta, AT&T VM Product Engineering, Piscataway, NJ - mmoneta@attmail.com
------------------------------------------------------------------------------

-----------[000402][next][prev][last][first]----------------------------------------------------
Date:      30 May 93 11:18:30 GMT
From:      jonc@status.gen.nz (Jon Clarke)
To:        comp.protocols.tcp-ip
Subject:   Esix tcp-ip SVR3

Does anyone out there in netland have a Esix svr3 box working 100%
on internet using pc-routers or the likes? If so please drop me mail
as I wish to configure up my box for this purpose next week.

From all accounts it is not possible to find the routers sub address
when using tcp/ip.  I have Svr4 but have not installed yet, if svr3
does not do it does svr4 of Esix work 100%.

I wish to run nntp (have elm working over tcp ip now) server here and
also connect to several other boxes via leased lines.

If you can help me please email me today.

       
       _         Jon Clarke (jonc@status.gen.nz)       * Public Access Unix * 
      ( )o       The home of Z*NET on the World Nets (Z*NET Free ASCII Zines)
      /\  \      HEXAGON: HSBC NZ EBD  GEM: Jon Clarke   PH : (+649) 358-5589


-----------[000403][next][prev][last][first]----------------------------------------------------
Date:      Sun, 30 May 1993 13:55:51 GMT
From:      dedgar@mta.ca
To:        comp.protocols.tcp-ip
Subject:   Slip and Xon/Xoff

Hi

Since the RFC (1055) makes no mention it, can I assume that NO slip 
implementation ever uses XON\XOFF flow control?

Alternately if there is a standard for this, but not yet RFC'ed could
someone please tell me the ESC codes one would substitute for xon\xoff
chars occuring in the data being transmitted.

Thanks 

Dale Edgar
Cybernetic Control Inc.
DEDGAR@MTA.CA

-----------[000404][next][prev][last][first]----------------------------------------------------
Date:      Sun, 30 May 1993 16:25:47 GMT
From:      vjs@rhyolite.wpd.sgi.com (Vernon Schryver)
To:        comp.protocols.tcp-ip
Subject:   Re: RFC for keepalives

In article <1993May30.071840.14806@novell.com>, donp@novell.com (don provan) writes:
> In article <i7d52o8@rhyolite.wpd.sgi.com> vjs@rhyolite.wpd.sgi.com (Vernon Schryver) writes:
> >Instead of just loving to hear nonsense and then repeating it, why
> >don't you check the source?  It's been more than half a dozen years
> >since 4.3BSD came out with slow keep alives.  Consider the implications
> >of this line:
> 
> I'm not sure what i ever did to you to illicit this tone

What did you do? You played the same old game that regularly and
justifiably makes you Novell guys so hot.  That is to make
authoritative, prejorative, and wrong statements about protocols or
implementations you evidently know little about.  I would have not
snarled so if this lapse had been your only first, second or even tenth.


>       in that half a dozen years, i've never had the slightest
> interest in finding or retrieving the BSD sources, let alone studying
> them well enough to find the one line you tell me i'd be looking for:

Then how do you presume to make statments about how 4.3BSD TCP works or
what it does?  I try not to talk about how IPX works, because my
knowledge of Novell's code is probably little better than your
knowledge of 4.3BSD TCP.

The "studying well enough" consists of starting with
`grep -i 'keep.*alive' *.[ch]`, skimming the code and comments
that unearths, and repeating the process about 4 times.
Given on-line source, this effort requires less than 10 minutes.
How do I know it takes less than 10 minutes?  Guess how.

If you can't be bothered with an online copy of the free BSD source,
and still can make such pronouncements as you did, then then how can
you Novell guys presume to criticise people for making dumb statements
about your code?  Esp. when it is a lot harder and vastly more
expensive to get into a position where validation of intuition or
prejudice is possible?

Don't you have a copy of SVR4 around?  Where exactly the same line
appears in tcp_timer.h?


> >#define  TCPTV_KEEP_IDLE (120*60*PR_SLOWHZ)   /* dflt time before probing */
> 
> I take it this makes the default time two hours?  How is the default
> time overridden, and how many installations or applications override it?

That depends on details of the 4.3BSD port.  Generally, you must change
that line and recompile parts of the UNIX kernel and relink the whole
thing.  Depending on the system, you might be able to use `adb`, `sdb`
or even `dbx` to patch either the running system kernel or the image
that will be load when the system is next rebooted.

In other words, in answer to your implicit charge, practially no
one changes or overrides the default, 2 hour 4.3BSD keepalive.

It would be good to have per-connection control on the keepalive
parameters.  (There are more than just this main one.)  I seem to
recall that the HR RFC's urge such control.  It may be that one of the
major UNIX TCP vendors has provided such knobs.


> >You should also pay attention the reams of complaints in this newsgroup
> >(and maybe still a mailing list) from people who find that 4.3BSD TCP
> >is <<not>> "brisk enough with its keepalives to detect a failed node
> >within minutes".  Whatever "failed node" might be.
> 
> The typical "failed node" is an idle FTP client (i.e., in a state
> where the server isn't transmitting anything, so there's nothing in
> any retransmission queue) which crashes and reboots without
> remembering the previous FTP session.  How long will it take a typical
> 4.3BSD FTP server to notice that this client has forgotten about the
> connection, and are keepalives the mechanism used to make that
> discovery?  Is this the case people complain about?  (Funny i don't
> recall any of these discussions.  I must have dozed off.)


I don't recall any discussion of failed FTP clients, but people
frequently ask here how their applications of TCP/IP can be
automatically notified when the wires break or the other end of the
connection crashes.  It seems someone asks that question once a week,
but I suppose it's no more than a couple of times per month.  Such
applications and questions have nothing to do with FTP and are obvious
applications of keepalives.

Typical (e.g. 4.3BSD-NET2) FTP implementations have site specific
idle timers that throw off sleepers.  These have nothing to do with
keepalives, but are implemented in the applications.  They do not
detect crashed servers or clients, but only apparently idle servers or
clients.  (Look for "idle" in the 4.3BSD-NET2 client source, then the
server source, then look for "timeout" and "alarm" in the server source.)

Keepalives must be turned on explictly in 4.*BSD.  Consider
`grep -i keep *` applied to the 4.3BSD source.

The usual argument for keepalives is not FTP, if only because of those
idle timers.  Instead it is telnet, rsh, or rlogin, which generally do not
have idle timers.  The 4.3BSD practice is to:
    1. detect crashed telnet, rsh or rlogin clients after a matter of
	hours using keepalives, in order to recover server resources.
    2. not even try to detect crashed servers, until the client
	tries to talk to the server, and ...

> >A dead connection that is active is generally detected within minutes,
> >but only because of reasonable transmission timers, which have absolutely
> >nothing to do with keepalives.
> 
> Duh.
> 						don provan
> 						donp@novell.com

I do not understand your "duh".  It could be because you understand the
point, but I am honestly not sure.


The original complainer about keepalives should consider the utility of
the "-n" switch on rlogind or telnetd.  (That may not be a universal
feature.)


Vernon Schryver,  vjs@sgi.com

-----------[000405][next][prev][last][first]----------------------------------------------------
Date:      30 May 1993 16:26:25 GMT
From:      trier@odin.ins.cwru.edu (Stephen C. Trier)
To:        comp.protocols.tcp-ip
Subject:   Re: Slip and Xon/Xoff

In article <1993May30.135551.6453@jupiter.sun.csd.unb.ca> dedgar@mta.ca writes:
>Since the RFC (1055) makes no mention it, can I assume that NO slip 
>implementation ever uses XON\XOFF flow control?

No, you can't use XON/XOFF in SLIP.

If you must use XON/XOFF, you can use PPP.  However, even with PPP, the
consensus seems to be to use hardware flow-control if at all possible.

-- 
Stephen Trier (trier@ins.cwru.edu - MIME OK)   
Network Software Engineer              
IRIS/INS/T                               
Case Western Reserve University             

-----------[000406][next][prev][last][first]----------------------------------------------------
Date:      Sun, 30 May 1993 20:59:42 GMT
From:      dberry@csa.cs.technion.ac.il (Dan Berry)
To:        comp.protocols.tcp-ip,comp.protocols.snmp
Subject:   Seeking advise on EPILOGUE's software

(Orna Berry-Keren using Dan Berry's account).
I would like to ask whether people have experience in integrating
Epilogue's software (UDP/IP/TCP/telnet/SNMP...).
Can any one compare it (in quality and ease of integration) with other
available packages?

Thanks, Orna

-- 
Prof. Daniel M. Berry, Computer Science Department, Technion, Haifa 32000 ISRAEL
Tel:+972-4-294325, Bitnet:DBERRY@TECHSEL
Csnet & Internet:dberry@sel.technion.ac.il

-----------[000407][next][prev][last][first]----------------------------------------------------
Date:      30 May 1993 22:27:31 GMT
From:      tomv@cssc-syd.tansu.com.au (Tom Vasak)
To:        comp.protocols.tcp-ip
Subject:   Expedited data over TCP through TLI

Has anyone tried to send expedited data over a TLI connection through a
TCP transport provider on SunOS 4.1.2?

I have been having problems. Any tips?

---
Tom Vasak
Telecom Australia
tomv@cssc-syd.tansu.com.au





-----------[000408][next][prev][last][first]----------------------------------------------------
Date:      Mon, 31 May 93 03:57:26 GMT
From:      sob@generali.harvard.edu (Scott Bradner)
To:        comp.protocols.tcp-ip
Subject:   Harvard Router/Bridge tests - time again

	Well its that time of year again, I'm starting up the next round of
router & bridge performance tests.  The window is from now until early
August.  The results will be announced during the "fall" Interop at the
end of August & put up for anonymous ftp soon after.

	The tests include the Packet Loss Rate, Throughput and Latency
tests as defined in RFC 1242.

	This is an open invitation for any vendors of routers or bridges to 
take part.  There is no fee for these tests. (Since I expect that a
representative of the vendor will be present during the tests to configure
& observe, it ain't free to the vendor - but the hotels & airlines get
the money not Harvard or me)

	If you produce such a device and want to take part please give
me a call for more details and to schedule a testing time.

Scott Bradner 
Harvard University
10 Ware St
Cambridge MA 02138
617-495-3864
---------------------------------------------

	There are two basic test setups:

setup 1
                           ---------------
                           |             |
               ------------|   tester    |-----------
               |           |             |          |
               |           ---------------          |
               |                                    |
      net A    |                                    |   net B
               |                                    |
               |           ---------------          |
               |           |   device    |          |
               ------------|    under    |-----------
                           |     test    |
                           ---------------

setup 2
                              ---------------
                              |             |
               ---------------|   tester    |--------------
               |              |             |             |
               |              ---------------             |
               |                                          |
      net A    |                                          |   net B
               |                                          |
               |   ------------            ------------   |
               |   |  device  |            |  device  |   |
               ----|   under  |------------|   under  |----
                   |    test  |   net C    |    test  |
                   ------------            ------------


	In the simple case for setup 1 traffic flows from the tester through 
net A, through the device under test to net B and then back to the tester.

	In the simple case for setup 2 traffic flows from the tester through 
net A, through the device under test to net C, through a second identical
device under test to net B and then back to the tester.

Bi-directional traffic is also tested.

	Net A & net B are of the same type and can be Ethernets, token
ring, or FDDI. Testing will include devices with up to 48 Ethernet ports,
and 2 ( & I hope 4) token ring or FDDI ports.

	Net C is a 9600 baud, 56Kb, T1 & T3 WAN, a 56Kb & T1 frame relay,
an Ethernet, and an FDDI ring

	Protocols include TCP/IP, DECnet Phase IV, AppleTalk Phase II,
Novell IPX, OSI CLNP, Banyon Vines IP, bridge mode & mixtures of the same.


-----------[000409][next][prev][last][first]----------------------------------------------------
Date:      31 May 93 22:13:38 -0400
From:      mchenry@guvax.acc.georgetown.edu
To:        comp.protocols.iso.x400,comp.protocols.tcp-ip
Subject:   telecom conference in russia

Announcement:

3rd International Russian Forum on
ELECTRONIC COMMUNICATION TECHNOLOGY - ECT'93

ECT'93 is a conference that examines the state of the art in
Russian and CIS telecommunications through 1) a conference with speakers 
who represent major Russian/CIS communications initiatives, 2) an exhibit 
by service providers in this field, and 3) tutorial sessions about specific 
topics. The organizers of the conference provide conference proceedings and 
also publish a large series of tutorial materials on all aspects of Russian 
telecommunications. One of the organizers is the International Center for 
Scientific Technical Information. ICSTI used to spend most of its time on 
databases of scientific and industrial abstracts, and worked closely with 
sister institutes throughout the former Eastern bloc. Now it spends most of 
its time on conferences, tutorial materials, and incubating joint ventures 
or other ventures on its premises. This is a short provisional program for 
the conference. Please contact Yuri Gornostayev (e-mail address at end) if 
you are interested in attending.

PROVISIONAL PROGRAMME
of 3rd International Russian Forum on
ELECTRONIC COMMUNICATION TECHNOLOGY - ECT'93
June 28 to July 3, 1993
Academy of National Economy, Moscow, Russia

Sponsored by:                           Organizers:
Russian Ministry of Communication    Academy of National Economy
Concern Telecom of Russia            Russian-American JV "Eco-Trends"
                                     International Centre for Scientific and
                                     Technical Information
June 28,        10:00   Opening Ceremony
June 28-29              Conference on Future Electronic Communications
June 28 to July 3       Exhibition "Telecommunication Systems and Services"
June 29,        18:00   Press-conference
        19:30   Welcome reception and cocktail party

June 30 to July 1       Tutorials and Professional Learning Courses
        Tut_A   International computer networks: Internet, NASA science
                network, and others
        Tut_B   Personal computers, modems and communication technology
        Tut_C   NetWare local area networks and internetwork technology
        Tut_D   Security and data protection in computer networks
        Tut_E   Oracle-based information networks
        Tut_F   Banking networking and S.W.I.F.T. network
        Tut_G   Telecommunication applications in business, trade and finance

July 1          Business-visits and talks with Russian communication VIPs
        BV_1    Russian Ministry of Communication
        BV_2    INFOTEL network communication control center
        BV_3    Russian satellite communication control center
        BV_4    Institute of Automated Systems, IASNET computer network
July 2          Commercial product reviews and company presentation
        PR_1    Russian Telecommunication Market
        PR_2    Mobile communication networks
        PR_3    Open for proposals till May 25, 1993
        PR_4    ...
July 3          Business seminar "Privatization and investments in Russian
                communication industry"
July 3, 16:00   Closing Ceremony
Lune 29 - July 3  Intensive cultural programme for foreigners and
                  accompanying persons (Bus tours, theatre, museums, balett etc.)
For more information on the Exhibition, Conference, Tutorials and Workshop,
and preliminary programmee, please contact:
    Juri Gornostaev/Juri Andrianov
        ECT'93 Program Committee
   125252, Moscow, Russia, Kuusinen Str., 21-B, ICSTI
fax: 7(095)943-0089   Tel: 7(095)198-7041   e-mail: enir@ccic.icsti.msk.su
--- 
ICSTI Computer Department      E-Mail : enir@ccic.icsti.msk.su
21b Kuusinena st., Moscow      Voice  : (7-095) 198-76-91
125252, RUSSIA                 Fax    : (7-095) 943-00-89

-----------[000410][next][prev][last][first]----------------------------------------------------
Date:      31 May 1993 16:33:36 GMT
From:      ming@engin.umich.edu (horng ming tai)
To:        comp.dcom.sys.cisco,comp.protocols.tcp-ip
Subject:   Re: IP Routing Questions on Subnet Masks and Multicasting

hi! I have a question of interrupt calls on IBM machine for TCP/IP.
I would like to program for my two computers which are connected with RG-58
cable with TCP/IP drivers. But I do not have any document for that. I only have
experiences for ipx on Novell netware. Are there any one have experiences
of programming TCP/IP on IBM machine. Please tell me where I can get the
document and some examples source code.
TKS.


-----------[000411][next][prev][last][first]----------------------------------------------------
Date:      Mon, 31 May 1993 16:54:50 GMT
From:      bacon@mtu.edu (Jeff Bacon)
To:        comp.protocols.tcp-ip
Subject:   multiple ether interfaces on the same subnet, revisited

Let's suppose the following setup:
a sun with two ethernet interfaces, le0 and le1, numbered 128.100.100.1
and 128.100.100.2. we'll assume a subnet mask of 0xffffff00, so both
interfaces are on the same subnet. both interfaces are hooked to
separate ports of a multiport packet switch, which is bridging between
all of its ports. The rest of the ports are connected to various other
ethernets, all on the same subnet (obviously). Of course, the two sun
interfaces will have different MAC addrs (no spanning-tree).

As you might guess, the idea is to get maximum thruput into that
packet switch. Please don't mention FDDI, we can't afford that. (Yes
the sbus cards are kinda cheap, but the card for the packet switch
isn't. either way, I don't have the money.) Nor do I want ten zillion
servers all serving the same thing if I don't have to.

I'm aware of that numbering trick you can do, it's not an option - we
cannot split the clients up in any way such that one half talk to one
interface and the other half talk to the other. (Or at least I don't want
to do it that way - seems kludgy.)

It occured to me that:
a. This machine will be primarily an NFS read-only file server. But, while
there will be more packets going out than in, there will still be a
significant number of inbound packets, in the form of requests and acks.
b. The main reason ethernet doesn't ever go at full wire speed is because
of collisions - Jacobsen showed that a sun could drive an le interface
at near wire speed, if the traffic was unidirectional and there were only
two stations on the wire.
c. I can make it such that there are only two devices on the wire for
both interfaces, the packet switch and the sun, thereby removing any
external source of collisions.
d. If I were to do things such that some clients talked to one interface and
the others to the other, there would still be collisions on both wires
because of the bidirectional traffic, resulting in lower thruput.

So...it seems to me that the thing to do here is this: tell all the clients
that the sun is at 128.100.100.2 (le1). Let the sun go ahead and set
its default route for net 128.100.100.0 to le0. By doing this, what I've
done is essentially make both interfaces single-directional; e.g. all
inbound traffic comes in le1, all outbound traffic goes out le0.

By doing so, we are saying that the sun can't send data out any
faster than le0 can send it. But...since there's no one EVER telling
le0 it CAN'T send, I would think it should be able to send at near-wire
speed, which I would believe to be faster than it could ever send out
both interfaces in the face of collisions. By the same token, the sun
should also be able to receive at near-wire speed on le1.

Of course this would cause some interesting problems with things like
.rhosts, netgroups, etc. But for an NFS fileserver, who cares? Besides, I
can just define both interfaces as trusted anyway.

Am I correct? What am I missing here? Are there any gotchas inside the
kernel code that would keep things from working like I propose? Is my
networking knowledge awry? Your comments would be appreciated.

I'd just try this myself and save the discussion, but I don't happen
to have either the second interface or the packet switch yet.

-bacon
--
= Jeffery Bacon       General Systems Hack, Michigan Technological University =
= bacon@mtu.edu       ph-(906)487-2197 fax-(906)487-2822    Printing is Evil. =

-----------[000412][next][prev][last][first]----------------------------------------------------
Date:      Mon, 31 May 1993 17:18:08 GMT
From:      erick@sunee.uwaterloo.ca (Erick Engelke)
To:        comp.protocols.tcp-ip
Subject:   Re: RFC for keepalives


 vjs@rhyolite.wpd.sgi.com (Vernon Schryver) writes:
> donp@novell.com (don provan) writes:
>> vjs@rhyolite.wpd.sgi.com (Vernon Schryver) writes:
>>
>> I'm not sure what i ever did to you to illicit this tone
>
>What did you do? You played the same old game that regularly and
>justifiably makes you Novell guys so hot.  That is to make
>authoritative, prejorative, and wrong statements about protocols or
>implementations you evidently know little about.  I would have not
>snarled so if this lapse had been your only first, second or even tenth.


Ignoring all that, Don may have inadvertently reminded us that many 
people such as he and I and many other TCP implementors may have never 
inspected BSD code for inspiration, just the RFCs, relevant papers and
packet dumps.  So sometimes it's not as political as one may think, just
a different reference point.  In those cases non-BSDers are not prejudiced
by the same references as you.  In some cases, like the discussion on 
'Urgent' vs. OOB, the Noveller's alternative viewpoint turned out to be
inline with the original definition of the protocol.

But thanks for the authoritative answer.  

Erick
-- 
----------------------------------------------------------------------------
Erick Engelke				 	            WATTCP Architect
erick@development.uwaterloo.ca     TCP/IP was easy but i still can't work VI

-----------[000413][next][prev][last][first]----------------------------------------------------
Date:      Mon, 31 May 1993 19:37:49 +0000
From:      proyse@peeras.demon.co.uk (Phil Royse)
To:        comp.protocols.tcp-ip
Subject:   Re: How to convert ethernet hard. addr. to IP addr.? ARP?

In article <bqt.738584604@Minsk> bqt@Minsk.docs.uu.se writes:
>
>>But how can I do the reverse: start with an ethernet hardware address, and
>>wind up with the IP address it goes with?
>
>Was some time since I looked through this, but i think that's what RARP
>are for. 

My understanding is that RARP is for an ethernet device, which doesn't
know its OWN IP address (i.e. one hasn't been configured in it), 
but it assumes that an IP address has been somehow "reserved" for it.

The device, in effect says "Hey, somebody on this ethernet, as you
can see from this frame, my MAC address is AA BB CC DD EE FF, who can
tell me what my IP address is supposed to be?  answer my by an
ethernet frame addressed to me, please"

I don't think this RARP mechanism can be used for a general
IP address enquiry from some device with an ethernet address
OTHER than the one which is the subject of the query...
(I think the RARP request will only put {my-address} in the
MAC address field, also, I think, the RARP server will only
put the enquirer's IP address in the IP address field.)

Hope this helps,

Phil R
-- 

Phil Royse     Comms Consultant  | member:  The Peer Association
TUDOR HOUSE                      | (networking & OSI specialists)
12 Woodside Road, Purley           
Surrey  CR8 4LN   (UK)        Tel: (+44) 81 645-9868 

-----------[000414][next][prev][last][first]----------------------------------------------------
Date:      Mon, 31 May 1993 19:42:27 +0000
From:      proyse@peeras.demon.co.uk (Phil Royse)
To:        comp.protocols.tcp-ip
Subject:   Tunnelling or encapsulation?


Can anybody give a simple mind a simple explanantion of the 
difference between tunnelling and encapsulation?

This is with regard to sending IP packets over an X.25 subnet?

Don't normal routers (Cisco et al.) wrap the fragments of an 
IP packet in standard X.25 packets, once a virtual circuit
has been set up?  Is this encapsulation or tunelling?

TIA

-- 

Phil Royse     Comms Consultant  | member:  The Peer Association
TUDOR HOUSE                      | (networking & OSI specialists)
12 Woodside Road, Purley           
Surrey  CR8 4LN   (UK)        Tel: (+44) 81 645-9868 

-----------[000415][next][prev][last][first]----------------------------------------------------
Date:      Mon, 31 May 1993 19:49:58 +0000
From:      proyse@peeras.demon.co.uk (Phil Royse)
To:        comp.protocols.tcp-ip
Subject:   TN3270 HLLAPI or TelAPI?


We are looking into Windows based 3270 emulation packages to run over
TCP/IP, into an IBM 9370.  The application needs a HLLAPI interface.

Browns University TN3270 supports TelAPI?  Does any body know
the difference between HLLAPI & TelAPI?  Is it significant?

Will the IBM 9370 support a HLLAPI interface over its TN3270 server?


TIA

-- 

Phil Royse     Comms Consultant  | member:  The Peer Association
TUDOR HOUSE                      | (networking & OSI specialists)
12 Woodside Road, Purley           
Surrey  CR8 4LN   (UK)        Tel: (+44) 81 645-9868 

END OF DOCUMENT