The 'Security Digest' Archives (TM)

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

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

START OF DOCUMENT

-----------[000000][next][prev][last][first]----------------------------------------------------
Date:      1 Jun 1994 00:51:51 GMT
From:      rwoodard@pafosu2 (Robert Woodard)
To:        comp.protocols.tcp-ip
Subject:   Re: Wierd netork behaviour

Mathias Koerber (mathias@solomon.technet.sg) wrote:
: Hi there.
: I am at my wit's end.
 
: I have a local network (Thin Ethernet) with
: 	2 ICL DRS/6000
: 	2 IBM RS/6000
: 	1 Linux PC
: 	~50 DOS/Windows PCS
: 	1 Netblazer PN1 (V2.3)
 
: Thw whole net in on one line, no subntting etc sone.
 
: since yesterday, I experience a wierd bahaviour.
: It seems that the two ICL systems have grave difficulty talking
: to the netblazer, while the IBM and the PCs can talk. Then
: once in a while I have total outages, and things come
: back very slowly. First only the IBMS talk to each other,
: then they can alk to one of the ICLs, but none can talk to
: the blazer. Later, things change around ...
 
: I see very long return times (4000ms) from one machine to the
: blazer, while other have 0. One machine sees ICMP port unreachables
: from the other machine while talking to the blazer.
 
: etc, etc, etc.
 
: Sadly, I have no sniffer nor any other analyzer. I have changed a few 
: cables and checked  them with a multimeter. that's about all I have.

  Hi Mathais,

  The only time I've seen this happen, a tech had used
 75 ohm cable instead of RG-58. The closer the nodes were
to each other, the better they could communicate. The further
apart, the worse things became.

Hope this helps,

Woody


-----------[000001][next][prev][last][first]----------------------------------------------------
Date:      Wed, 1 Jun 1994 01:19:13 GMT
From:      rstevens@noao.edu (W. Richard Stevens)
To:        comp.protocols.tcp-ip
Subject:   Re: How do you determine SO_KEEPALIVE parameters?

> I've heard that when Unix socket connections are made, there is an option 
> that can be used to determine if that connection ever goes down.  
> The call is to setsockopt() and the option is SO_KEEPALIVE.  The way 
> I heard that this works is
> that when this option is set, idle time is measured and if a socket
> connection is idle for X amount of time, a TCP message is sent on
> the socket and a response is expected back.  If a response is not
> received in Y amount of time, the TCP message is sent again.
> If no response is received in Z iterations, the socket is closed.
> 
> Now here is my question...On the Unix system, would you have any idea
> where X, Y, and Z are defined?  

X = 2 hours, Y = 75 seconds, and Z = 8 times.  Most Unix systems that I've
seen use the same values.

> I've looked in W. Richard Steven's Unix Network Programming book but it
> seems to leave this detail out.

Check out Chapter 23 of my recent book "TCP/IP Illustrated" (Addison-Wesley,
1994) for a complete chapter on all the gory details on how keepalive works.
Appendix E of this book contains details on changing the X, Y, and Z
parameters for 5 popular flavors of Unix.

	Rich Stevens

-----------[000002][next][prev][last][first]----------------------------------------------------
Date:      Wed, 1 Jun 1994 02:43:13 GMT
From:      robs@join.com (Rob Stevens)
To:        comp.unix.solaris,comp.protocols.tcp-ip
Subject:   Berkeley Packet Filter (BPF) for Solaris2.3

Has anyone out there, whether Public Domain or Commercial,
 configured the Berkeley Packet Filter as a loadable
STREAMS module that is usable with Solaris2.x?

Thanx
Rob Stevens




-----------[000003][next][prev][last][first]----------------------------------------------------
Date:      Wed, 1 Jun 1994 03:02:39 GMT
From:      robs@join.com (Rob Stevens)
To:        comp.protocols.tcp-ip
Subject:   Transport Provider Interface Spec. (TPI)

Anyone know an FTP site where a copy of the TPI
spec. (Transport Provider Interface) can be found?
Prefer postcript, but ordinary text would do.

Thanx
Rob Stevens





-----------[000004][next][prev][last][first]----------------------------------------------------
Date:      Wed, 1 Jun 1994 04:33:20 GMT
From:      d00n@crash.cts.com (Kevin Spousta)
To:        comp.protocols.tcp-ip
Subject:   /etc/hosts /etc/named.data questions

I've been working on an SMTP gateway for Word Perfect Office and some of the
'trickery' I've done involves multiple hostnames for a single IP address in
the /etc/hosts file on our nameserver.  Not being a total TCP/IP guru, I
have raised more than a few eyebrows with the way I've set up the nameservice
for this machine. 

I have 5 entries pointing to the same IP address and also mail exchange
records in the /etc/named.data file to 'fake out' the machine called
smtpgate into thinking it's many machines for addressing reasons.  (Political
reasons really)  Is this OK?  So far it works like a charm, but the keepers
of the DNS say I can't do it like this.

Is it ok to have 1 IP for multiple hosts, when the actual host is *ONE*
machine?  I'm defending my position on the grounds that A) it works, and
B) nothing seems to be affected by this 'trickery'.  Can someone 
prove/disprove my thinking??



-----------[000005][next][prev][last][first]----------------------------------------------------
Date:      Wed, 1 Jun 1994 04:41:38 GMT
From:      d00n@crash.cts.com (Kevin Spousta)
To:        comp.protocols.tcp-ip
Subject:   Mosaic "DNS Lookup Failure" problem..

Subject says it all..  

Computer is a Compaq 486-dx2/66 running on a 4mbps Token Ring network,
Wollongong Pathways 3.0 and Mosaic Release 2 Alpha 3.  I can Telnet/FTP/Ping
to my heart's content but Mosaic chokes with DNS lookup failures.

I have Mosaic running not only on my OS/2 machine at work (16m T/R), but on
about 20 Ethernetted PC running Pathways and even via SLIP from my OS/2
machine at home, but this one PC is driving me bananas.  I've checked and
double checked the Pathways and Mosaic configuration, the entries in the
/etc/hosts file for this machine and even re-run the update_nameserver
script on the DNS to propogate changes across the 'net to make sure, but
the %^%*& thing still chokes.  Hell, I'm even receiving mail within the
mailer that comes with Pathways so I'm pretty sure the machine is config'd
correctly.

This version of Mosaic comes right off my OS/2 machine at work, with the
*ONLY* change to the .INI file being the E-mail address of the machine's
"owner" as opposed to my address.  The only other thing I can think of
is the 4mbps speed of his ring, compared to the 16mbps of the ring my
machine is attached to.  What's the deal?  Is this machine possessed, or
is it time I changed careers?  :)



-----------[000006][next][prev][last][first]----------------------------------------------------
Date:      Wed, 1 Jun 1994 04:46:15 GMT
From:      mintz@cup.hp.com (Ken Mintz)
To:        comp.protocols.tcp-ip
Subject:   Re: How do you determine SO_KEEPALIVE parameters?

Ben Choi (choi@cso.geg.mot.com) wrote:
> connection is idle for X amount of time, a TCP message is sent on
> the socket and a response is expected back.  If a response is not
> received in Y amount of time, the TCP message is sent again.
> If no response is received in Z iterations, the socket is closed.
>
> Now here is my question...On the Unix system, would you have any idea
> where X, Y, and Z are defined?  

  The setsockopt(2) man page should tell you this.  But some such man pages
  are incorrect, it they tell you at all.

  Rich Stevens already posted the "standard" values, at least for a BSD
  derivative system (2 hours, 75 seconds and 8 times, respectively).

  And before we get too critical of these numbers (which most us agree are
  too long to be useful), please note that RFC-1122 "requires" that 2 hours
  be the default.  (IMHO, the default should be a "local matter".)

  Some systems provide a command interface to tune these parameters. 
  Alternatively, on BSD derivatives, the kernel variable tcp_keepidle
  controls X, tcp_keepintvl controls Y, and Z is hardcoded, typically.  The
  units for the two kernel variables are typically __half-seconds__.

  But be wary of changing these variables, not only because of potential
  variations in individual vendor implementations, but also because of
  internal dependencies on these values for unrelated purposes.  Also, 
  changing these values have __global__ impact on all TCP connections, which 
  could have unwanted side-effects.

-- Ken Mintz

-----------[000007][next][prev][last][first]----------------------------------------------------
Date:      1 Jun 1994 05:42:48 GMT
From:      landmark@cs.tu-berlin.de (Torsten Kerschat)
To:        comp.protocols.tcp-ip
Subject:   Re: Transport Provider Interface Spec. (TPI)

robs@join.com (Rob Stevens) writes:

>Anyone know an FTP site where a copy of the TPI
>spec. (Transport Provider Interface) can be found?
>Prefer postcript, but ordinary text would do.
The TPI was specified by UNIX International, which
in fact doesn't exist anymore. Therefore, you 
can't connect to the appropriate file server.
But in fact, I will put the PS file (I can't do it
by myself) on our anonymous ftp server, for
further availablity.

ftp.prz.tu-berlin.de:/net_doc/misc/tpi.ps.gz

(please remember that the connectivity is sometimes
very slow to our fileserver). 
I hope that our service-team will install it as soon
as possible.

Torsten

-- 
Torsten Kerschat - Interdepartmental Research Center for Process Control
		   Technical University of Berlin (PRZ - Room HE 104)
Internet: torsten@prz.tu-berlin.d400.de / landmark@cs.tu-berlin.d400.de
Phone   : ++49 / (0)30 / 314 - 26822    Fax: ++49 / (0)30 / 314 - 21114

-----------[000008][next][prev][last][first]----------------------------------------------------
Date:      1 Jun 1994 05:50:03 GMT
From:      tli@cisco.com (Tony Li)
To:        comp.protocols.tcp-ip
Subject:   Re: IP Loadsharing

In article <2s5gth$62s@hacgate2.hac.com> switt@triceratops.hac.com (Steve
Witt) writes: 

    It is my understanding that a routing policy or protocol, like OSPF,
    executing as a daemon (such as gated), initializes and updates the IP
    routing table that IP uses to forward IP datagrams.  The routes in the
    IP routing table, indicate the next-hop router to which to forward IP
    datagrams for specific destinations (either hosts or networks).  If the
    routing protocol is capable of discovering multiple routes to a
    destination host or network, is IP capable of using this information?
    It would seem that the IP routing table would need to have each route
    from the set of multiple routes to a destination, inserted into the
    table and then IP would need to have some method of using each route.
    My understanding of current IP implementations (which is limited to the
    4.3BSD from which SunOS was developed) is that the IP routing algorithm
    first tries to find a host- specific route for the datagram, then tries
    to find a network route for the datagram, and then uses a default route
    (if it exists).  It would seem that if there were multiple entries in
    the IP routing table for a destination network or host that the IP
    routing algorithm would match on the first one found and forward the
    datagram accordingly and would not be able to make use of multiple
    routes effectively.  Perhaps I have a naive understanding of the IP
    routing algorithm.
    
    Can IP (or particular implementations of IP) perform load sharing given a
    routing policy that is capable of discovering useful multiple routes to a 
    destination?

You're looking at one implementation.  Other implementations do support
load sharing across multiple routes.  It can be done in a variety of ways,
but the simple one is to structure the routing table such that all routes
for a destination exist in some close proximity and that you can easily
switch between the entries.  A pointer into an array will work very
nicely...

Tony


-----------[000009][next][prev][last][first]----------------------------------------------------
Date:      Wed, 1 Jun 94 05:51:18 GMT
From:      hal9001@panix.com (Robert A. Rosenberg)
To:        comp.protocols.tcp-ip
Subject:   Re: rfc1219 Implementation ??, (On the Assignment of Subnet Numbers)

In Article <dox.770306336@slbh04>, dox@bln.sel.alcatel.de (Guntram Dox) wrote:
>If you prefer PM, then please email to 
>frohmuel@bln.sel.alcatel.de and NOT to this sender since it is still not
>reachable from outside.

If you add a "Reply To:" header to messages of this type, any EMAIL (as
opposed to News Follow-Up) Replies would automatically get routed/sent to
your intended EMAIL address and not direct to your address.

-----------[000010][next][prev][last][first]----------------------------------------------------
Date:      1 Jun 1994 14:12:21 -0500
From:      elpede@news.mcc-care.com (Eric Pederson)
To:        comp.protocols.tcp-ip
Subject:   Re: /etc/hosts /etc/named.data questions

Kevin Spousta (d00n@crash.cts.com) wrote:
: I've been working on an SMTP gateway for Word Perfect Office and some of the
: 'trickery' I've done involves multiple hostnames for a single IP address in
: the /etc/hosts file on our nameserver.  Not being a total TCP/IP guru, I
: have raised more than a few eyebrows with the way I've set up the nameservice
: for this machine. 
 
: I have 5 entries pointing to the same IP address and also mail exchange
: records in the /etc/named.data file to 'fake out' the machine called
: smtpgate into thinking it's many machines for addressing reasons.  (Political
: reasons really)  Is this OK?  So far it works like a charm, but the keepers
: of the DNS say I can't do it like this.
 
: Is it ok to have 1 IP for multiple hosts, when the actual host is *ONE*
: machine?  I'm defending my position on the grounds that A) it works, and
: B) nothing seems to be affected by this 'trickery'.  Can someone 
: prove/disprove my thinking??

There's nothing wrong with multiple A records for one IP number, as long as
you realize that you can only have one of those host names in your inverse
name database. Many sites on the Internet have more than one A record for
a single IP address.

If you are a DNS purist  you may not care for this, but as you said,
it does work.

-- 
-------------------------------------------------
Eric L. Pederson		eric@mcc-care.com
System Administrator		(612) 996-2751
MCC Behavioral Care, Inc.

-----------[000011][next][prev][last][first]----------------------------------------------------
Date:      1 Jun 1994 14:25:54 -0400
From:      news@vdd.VLSI.LL.MIT.EDU
To:        comp.protocols.tcp-ip,comp.security.unix
Subject:   ftp ACCT feature?

I need to implement the account (ACCT) feature of ftpd in the
wu-archive source of ftpd, in order to require an extra security
password before the user is allowed to do anything.  Has anyone done
this?  Its the yacc stuff I'm not sure of, and how it should fit with
the PASS command.


George Young,  Rm. B-169		young@vlsi.ll.mit.edu
MIT Lincoln Laboratory			young@vdd.vlsi.ll.mit.edu
244 Wood St.				[129.55.11.1]
Lexington, Massachusetts  02173-9108	(617) 981-2756

-----------[000012][next][prev][last][first]----------------------------------------------------
Date:      Wed, 1 Jun 1994 07:51:48 GMT
From:      cpm@uniplex.co.uk (Chris P Murray)
To:        comp.protocols.tcp-ip
Subject:   Re: server fails when client crashes...

Barry Margolin (barmar@think.com) wrote:
: In article <1994May27.180801.5613@sal.wisc.edu> jwp@bernie.sal.wisc.edu (Jeffrey W Percival) writes:
: >	client dies
: >	server's select() indicates client writeable
: >	server calls write(sock, data, n) where n > 0
: >	write() fails, DOES NOT RETURN (I just get my unix prompt back
: >		in the server window.)
 
: My guess is that write() is sending a signal (EPIPE, EIO?) instead of
: returning an error code, and the signal's default behavior is to kill the
: process.  But in this case I would expect the shell in the server window to
: give the reason for the process exiting.  However, I think the C shell
: doesn't print a message for EPIPE -- it's too common an error (e.g.
: "command | head" almost always exits for this reason), so it's probably this.

The write() call is meant to generate a SIGPIPE signal when the receiver has
terminated.  It should return errno=EPIPE and indicate nothing has been
written.  Install a SIGPIPE signal handler or ignore it to stop your process
exiting.  Then use the handler and/or the return code from write() to notice
when the client dies.

-----------[000013][next][prev][last][first]----------------------------------------------------
Date:      1 Jun 94 10:49:25 GMT
From:      sej@flowbee.interaccess.com (Stephen Johnson)
To:        comp.protocols.tcp-ip
Subject:   Re: /etc/hosts /etc/named.data questions

d00n@crash.cts.com (Kevin Spousta) writes:

>I've been working on an SMTP gateway for Word Perfect Office and some of the
>'trickery' I've done involves multiple hostnames for a single IP address in
>the /etc/hosts file on our nameserver.  Not being a total TCP/IP guru, I
>have raised more than a few eyebrows with the way I've set up the nameservice
>for this machine. 
 
>I have 5 entries pointing to the same IP address and also mail exchange
>records in the /etc/named.data file to 'fake out' the machine called
>smtpgate into thinking it's many machines for addressing reasons.  (Political
>reasons really)  Is this OK?  So far it works like a charm, but the keepers
>of the DNS say I can't do it like this.

I believe that multiple machine names (aka aliases) are not only OK but
supported under DNS using the CNAME record. However, I'm not an expert
on the arcane interactions between MX records and CNAME records and 
aliasing a mail machine might cause problems of which I am unaware.

>Is it ok to have 1 IP for multiple hosts, when the actual host is *ONE*
>machine?  I'm defending my position on the grounds that A) it works, and
>B) nothing seems to be affected by this 'trickery'.  Can someone 
>prove/disprove my thinking??



-----------[000014][next][prev][last][first]----------------------------------------------------
Date:      1 Jun 94 16:13:54
From:      zhao@crl.nmsu.edu (Z. Zhao)
To:        comp.protocols.tcp-ip,comp.protocols.ppp
Subject:   cslip-2.7 for sunos4.1.3

Hello,

I am trying to implement cslip-2.7 on a sparc10/sunos4.1.3.
I am confused about setting config file options for SLMTU. 
Should I set

	options SLMTU
or
	options SLMTU=<N>	
or 
	options SLMTU=<260>

in the SYS_NAME file?

'# config SYS_NAME' would say "options SLMTU=<N>" is a syntax error.
SLMTU=<260> makes sense?


ZiZi



-----------[000015][next][prev][last][first]----------------------------------------------------
Date:      Wed, 1 Jun 1994 16:50:01
From:      waming@cuhk.hk (MING WA)
To:        comp.protocols.tcp-ip
Subject:   Announcing WGopher Version 2.3


         Announcing Gopher for Windows Version 2.3

*****************************************************************

Gopher for Windows version 2.3 is a gopher client running on Microsoft 
Windows 3.1 system with Windows Sockets (WINSOCK.PLL) v1.1 or later.

Features

  1. Bookmarks
  2. Text, Binary capability
  3. Image capability (need to use external image viewer)
  4. telnet,tn3270 capability (need to use external telnet
     application)
  5. Index capability
  6. CSO capability
  7. Attribute information (for Gopher+ item only)
  8. Fonts selection 

Installation

  File is available at ftp server: /ftp.cuhk.hk
      Directory: /pub/gopher/PC
      File: wgoph23.zip

  Use PKUNZIP.EXE to unpack the file wgoph23.zip. Follow the instructions 
  in README.TXT file.

Bugs, comments and suggestions

  Please send any bugs, comments or suggestions to:
           wa-ming@cuhk.hk

  I would like to thank all the people who helped me to test the
  WGopher version 2.2, particular those who sent bugs report and
  made comments for the improvement. I am sorry if I did not reply
  all mails you sent to me since I was busy sort out the problems
  and try to speed up the new release.   




-------------------------------------------------
Ming Wa                                
Computer Services Centre             
The Chinese University of Hong Kong   
E-mail: wa-ming@cuhk.hk
-------------------------------------------------



-----------[000016][next][prev][last][first]----------------------------------------------------
Date:      1 Jun 1994 12:27:38 GMT
From:      jfguilla@imag.fr (J-F Guillaud)
To:        comp.protocols.tcp-ip
Subject:   Where is the archive site for this group?

	I have had a look to available articles and to the FAQ but I
haven't find the archive site for this group. Could someone help me to locate
the site where old articles are stored.

Thank you in advance

Jean-Francois
--
                   +---------------------------------------------------------+
  ---------------  | LGI / IMAG                                              |
 / Jean-Francois \ | 46, av. Felix Viallet - 38031 Grenoble cedex 1 - France |
 \   GUILLAUD    / | Phone : +33 76 57 46 92  -  Fax : +33 76 57 47 17       |

-----------[000017][next][prev][last][first]----------------------------------------------------
Date:      Wed, 1 Jun 1994 13:57:07 GMT
From:      landin@cherokee.nsuok.edu (Mark C. Landin)
To:        comp.protocols.tcp-ip
Subject:   Re: Multiple IP addrs for same hardware interface?

francisr@stupid.ucs.indiana.edu (Rob Francis) writes:

>This is basically what I want to do.  Not for nameservice, but I want
>to gracefully eliminate a machine but its IP addr is fairly well
>distributed.  I actually got around the problem and now I'm just sort
>of curious about the whole thing.

So how did you get around it? I'm going to do the hardware shuffle in a 
month or two and would like any helpful anecdotes from people who've
done it.

-- 
*-----------------------------------------------------------------------------*
*  Mark C. Landin					Northeastern St. Univ *
*  landin@cherokee.nsuok.edu					Tahlequah, OK *
*   "Living in the pools, they soon forget about the sea" - Neil Peart, RUSH  * 

-----------[000018][next][prev][last][first]----------------------------------------------------
Date:      Wed, 1 Jun 1994 19:14:04 UNDEFINED
From:      jlewis@inorganic5.chem.ufl.edu (Jon Lewis)
To:        comp.protocols.ppp,comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject:   Re: Questions regarding SLIP/PPP terminal server setups

NERDC (North East Regional Data Center - I think) has a dialup server setup 
here at UF.  I think NERDC is part of or related to the state university 
system.  They limit the use of slip/ppp by charging $0.01/min.  My NERDC 
account, good on a few of the campus mainframes and the dialup server, is 
given $30/month.  Online time and usage of the mainframes is billed to my 
account, and when the money runs out, I'm locked out until the money is 
replenished at the begining of the next month.  They use Cisco 
hardware and software for the dialup server...thats all I know about that part.

I've also setup my own slip server using KA9Q and SLIPLOG.  SLIPLOG allows me 
to allot x minutes/day to each valid slip user.  There must be something 
similar in function for the systems you'll be using.

If you can do packet filtering, you might even be able to block people from 
telneting to MUDs.

In article <CqqE1u.4Jq@oucsace.cs.ohiou.edu> rbarrett@oucsace.cs.ohiou.edu 
(Rich Barrette) writes:

>The other pressing question was one of usage.  How do we monitor
>usage and decide who is doing real work?  i.e. It would be highly 
>undesireable for someone to be logged into the server all of the 
>time while other people could do work.  How do we monitor and decide 
>who is doing what?  The subject can get complicated because we want 
>to offer this to students, some of which are CS and Engineering types 
>who can beat most simple monitoring systems by sending pings every 
>once in a while or use even more elaborate mechanisms.






|------------------------------------------------------------------|
| jlewis@inorganic5.chem.ufl.edu   If the first address bounces    |
|                                  let me know, and resend to the  |
| jlewis@chem.ufl.edu              second address.                 |
|                                  If the second address bounces   |
|                                  something's seriously wrong.    |
|                                                                  |
|                   Mime attachments are OK                        |
|__________________________________________________________________|



-----------[000019][next][prev][last][first]----------------------------------------------------
Date:      1 Jun 1994 15:07:08 GMT
From:      dunnce@bcuxs2.bc.edu (Chad A Dunn)
To:        comp.sources.wanted,comp.protocols.tcp-ip,comp.dcom.lans.ethernet
Subject:   Re: PD ethernet analysis software?

If your on a Mac platform, there are several good analyzers.  There's
one called NetMinder from Neon software and also one called Etherpeek
which is good for capturing packets and decoding them.

Chad


-----------[000020][next][prev][last][first]----------------------------------------------------
Date:      Wed, 1 Jun 1994 16:12:13 GMT
From:      suzannei@nsa.bt.co.uk (Suzanne Irvine)
To:        comp.protocols.tcp-ip
Subject:   tcp/ip via sunlink dni


Hi,

We are running two networks, one between the suns and another on the vax side.  We have
a sparc 10 (4.1.3) acting as a bridge which runs sunlink dni (7.0).

Up to now mail has been quite happily passed from the suns to the vax, along with 
rlogin's etc.    One of our users wishes to run tcp/ip applications from a dec pc 
via the suns.

Firstly, is this possible and if so how do I go about it.

Many thanks,
-Suzanne Irvine


-----------[000021][next][prev][last][first]----------------------------------------------------
Date:      Wed, 1 Jun 1994 16:51:14 GMT
From:      jas@talking.COM (Jim Shankland)
To:        comp.protocols.tcp-ip
Subject:   Re: accept() core dump!

In article <1994May31.193949.14263@astph> jeff@astph (Jeff Martin) writes:
>If we request an excessive number of client
>socket connections, about 60, the accept call will not return
>an error, but rather will dump a core.  The stack is printed
>below:
>
>        malloc(0x408)   [malloc.c]
>        _findbuf(0x4051b0)   [flsbuf.c]
>        _filbuf(0x4051b0)   [filbuf.c]
>        fgets(0x40462c,0x78,0x4051b0)   [fgets.c]
>        rddev(0x4051b0,2,1,0)   [socket.c]
>        socket(2,1,0)   [socket.c]
>        accept(6,0x7ffffc3c,0x7ffffc38)   [accept.c]
>        main(argc=1,argv=0x7ffffc6c)   [db_root.c:82]
>
>It seem that the accept() call is not too accepting....

The problem is not accept() per se, but the fact that on your
machine, accept() is evidently a library routine that ends up
calling malloc(), and malloc() is dumping core while trying to
allocate 1032 bytes.  malloc() will do this if you've corrupted
its data structures by scribbling on memory (e.g., by allocating
x bytes in a previous call to malloc(), and then writing more than
x bytes).

Look for an unrelated bug in your program.  This is the kind
of problem that makes people thank their deity of choice that
they have Purify.

jas

-----------[000022][next][prev][last][first]----------------------------------------------------
Date:      1 Jun 1994 23:31:52 -0400
From:      bacon@mtu.edu (Jeff Bacon)
To:        comp.protocols.tcp-ip
Subject:   Re: IP Loadsharing

given all this...let's suppose I want to use n>=2 slip or PPP links
to provide a remote IP connection between two machines, unix-based.
(let's assume sun for now)
are there any specifc implementations of this I can get?

-bacon
--
= Jeff Bacon              General Systems Hack, Michigan Technological Univ. =
= bacon@mtu.edu    ph-(906)487-2197 fax-(906)487-2782 DoD#2110   I'm the NRA = 
=I know that I would surely fall away, except the grace by which I'm saved...=

-----------[000023][next][prev][last][first]----------------------------------------------------
Date:      Wed, 1 Jun 1994 17:08:54 GMT
From:      jas@talking.COM (Jim Shankland)
To:        comp.protocols.tcp-ip
Subject:   SO_REUSEADDR, etc.

In article <1994May31.230644.11616@noao.edu> rstevens@noao.edu (W. Richard Stevens) writes:
>SO_REUSEADDR is indeed confusing....  [Followed by a predictably
>articulate description.]

So, my take on this is that SO_REUSEADDR is an unnecessary hack:
there is no reason you shouldn't be able to bind a server socket to
a port/address pair that is an endpoint of one or more connections
in the TIME_WAIT state, as long as you don't allow re-creation
of TCP connections ({lport, laddr, fport, faddr} quadruplets)
that are in the TIME_WAIT state.  BSD-based implementations
are too restrictive when SO_REUSEADDR is not set, and (slightly)
too permissive when SO_REUSEADDR *is* set.  Or have I missed
something?

>Now UDP on a system that supports multicasting (e.g., Solaris 2.x) does
>let you start multiple occurences of a server, all reading from the same
>local port.  But that's another story ...

I don't understand why this should be coupled with multicast
capability.  That is, it seems perfectly reasonable to allow
multiple servers to read from the same UDP port, even on a system
that does *not* allow multicasting (and very desirable in some
circumstances).  Is there any reason other than happenstance 
that this is available only on multicast-capable systems?

jas

-----------[000024][next][prev][last][first]----------------------------------------------------
Date:      Wed, 1 Jun 1994 18:29:53 GMT
From:      rbarrett@oucsace.cs.ohiou.edu (Rich Barrette)
To:        comp.protocols.ppp,comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject:   Questions regarding SLIP/PPP terminal server setups


Greetings,

I have been involved in a project setting up a SLIP/PPP terminal
server and offering these services to Windows and Mac users
throughout campus.  Right now we have a small exerimental group
running smoothly.  We presented our findings to the people who
pay for this sort of thing and a couple of important questions
came up:

What are other Universities using as Hardware/Software for this
sort of thing?  What about public access companies?

Right now we are running a Xyplex server hooked up to a Sun IPC
and a rack of NEC modems.  Aside from the lack of correct fallback
and NO fallforward support on the NEC's things are running smoothly.
We use Kerberos for our authentication which the Xyplex supports.

I would appreciate any emails back with information similar to the
above from any groups who are doing this same sort of thing, or
offering similar services.

The other pressing question was one of usage.  How do we monitor
usage and decide who is doing real work?  i.e. It would be highly 
undesireable for someone to be logged into the server all of the 
time while other people could do work.  How do we monitor and decide 
who is doing what?  The subject can get complicated because we want 
to offer this to students, some of which are CS and Engineering types 
who can beat most simple monitoring systems by sending pings every 
once in a while or use even more elaborate mechanisms.

Any ideas/comments/solutions/etc. greatly appreciated.

Thanks for you time,
-Rich
--
					Rich Barrette 
					rbarrett@oucsace.cs.ohiou.edu

-----------[000025][next][prev][last][first]----------------------------------------------------
Date:      Wed, 1 Jun 1994 18:34:26 GMT
From:      rstevens@noao.edu (W. Richard Stevens)
To:        comp.protocols.tcp-ip
Subject:   Re: SO_REUSEADDR, etc.

> So, my take on this is that SO_REUSEADDR is an unnecessary hack:
> there is no reason you shouldn't be able to bind a server socket to
> a port/address pair that is an endpoint of one or more connections
> in the TIME_WAIT state, as long as you don't allow re-creation
> of TCP connections ({lport, laddr, fport, faddr} quadruplets)
> that are in the TIME_WAIT state.  BSD-based implementations
> are too restrictive when SO_REUSEADDR is not set, and (slightly)
> too permissive when SO_REUSEADDR *is* set.  Or have I missed
> something?

You are correct.
 
> > Now UDP on a system that supports multicasting (e.g., Solaris 2.x) does
> > let you start multiple occurences of a server, all reading from the same
> > local port.  But that's another story ...
> 
> I don't understand why this should be coupled with multicast
> capability.  That is, it seems perfectly reasonable to allow
> multiple servers to read from the same UDP port, even on a system
> that does *not* allow multicasting (and very desirable in some
> circumstances).  Is there any reason other than happenstance 
> that this is available only on multicast-capable systems?

Right again.  I think it's just because multicasting got people to
start thinking about multiple processes reading from the same UDP
port.  Realize, however, that when multiple processes bind the
same UDP port, they all get copies of *only* broadcast or multicast
datagrams.  Unicast datagrams still go to one process only.  Which
one gets the unicast datagram is implementation-dependent if there
are multiple processes bound to the port.

	Rich Stevens

-----------[000026][next][prev][last][first]----------------------------------------------------
Date:      Wed, 1 Jun 1994 19:15:57 GMT
From:      ysun@hotdog.bae.bellcore.com (Yi Sun)
To:        comp.unix.solaris,comp.protocols.tcp-ip
Subject:   Help on TLI


Does anyone know what the value 146 in the reason field of a call to t_rcvdis?

Long:

I am running 2.3 using TLI trying to connect to a server running on pyramid
svr4 box.  t_open was ok, failed in t_connect, so I did a t_look, and tells me
I get a disconnect, so I do a t_rcvdis, the reason field was set to 146, but I
cannot find it in any header files, any idea?

In general, what options do you have when you get a disconnect on t_connect?

thanx.


-----------[000027][next][prev][last][first]----------------------------------------------------
Date:      Wed, 1 Jun 1994 19:22:51 GMT
From:      nebrich@sed.psrw.com (Mark A. Nebrich)
To:        comp.protocols.tcp-ip
Subject:   TCP/IP Cleint/Server Timing Problem?

Hello netters,

I have a client/server timing problem that I hope someone can help me solve.

I am running on a Sun Sparc under SunOS 4.1.3. I have created two applications
(one server, one client) that communicate with one another over the sun
network (each process is running on a different machine).

The server is designed to notify connected clients when it (the server) dies.
Each client has the responsibility to close server connections and try to 
reconnect. Once the server is restarted, it accepts client re-connections.

The problem is that when the server dies and each client disconnects and
immediately trys to reconnect, it connects to the dead server IP address.
This happens even though a new server has not yet started.
I think this occurs because the network has not yet had a chance to clear out
the old IP address on the client application host machine.

This obviously causes problems on client socket reads.  If I put a sleep() call
in after the client application closes the old server socket (close()), this gives 
the network time to clear itself out. This works but I don't think it's an elegant 
solution for the problem (for example if the network is really busy, a sleep(5) may not
be enough time).

Can anyone tell me a more elegant way of determining if the net stats have been
updated so I can reconnect. I need to do this in software. Again, a sleep works but 
the sleep time is not predicatable. Thanks in advance.

**********************************************************************************

----------
----  ---- Pacific-Sierra Research Corp.
--      -- Mark A. Nebrich
-        - Phone: (703) 516-0223
---------- Email: nebrich@sed.psrw.com
  ------
   ----
    --

**********************************************************************************

-----------[000028][next][prev][last][first]----------------------------------------------------
Date:      Wed, 1 Jun 1994 19:24:26 GMT
From:      ysun@hotdog.bae.bellcore.com (Yi Sun)
To:        comp.protocols.tcp-ip
Subject:   test program


Is there public test program to test tcp/ip between two machines using specified
port number using TLI interface?

thanx.

-----------[000029][next][prev][last][first]----------------------------------------------------
Date:      Wed, 1 Jun 1994 19:43:19 GMT
From:      mac@trantor.harris-atd.com (Mike McDonald)
To:        comp.protocols.tcp-ip
Subject:   Re: SO_REUSEADDR, etc.

In article <1994Jun1.183426.12830@noao.edu>, rstevens@noao.edu (W. Richard Stevens) writes:

|> Right again.  I think it's just because multicasting got people to
|> start thinking about multiple processes reading from the same UDP
|> port.  Realize, however, that when multiple processes bind the
|> same UDP port, they all get copies of *only* broadcast or multicast
|> datagrams.  Unicast datagrams still go to one process only.  Which
|> one gets the unicast datagram is implementation-dependent if there
|> are multiple processes bound to the port.
|> 
|> 	Rich Stevens

  Do you know what the reasoning for this behavior is? I've always modeled and
implemented UDP so that every process bound to a port gets a copy of each packet.
I guess I've been screwing it up. It seemed the only reasonable thing to me. I
guess if you had multiple identical servers you wouldn't want them all to execute
the same request.

  Mike McDonald				Advanced Technology Dept.	
					Harris Corp.
  Email: mac@trantor.harris-atd.com	M.S. 16-1912
  Voice: (407) 727-5060			P.O. Box 37
  Fax:   (407) 729-3363			Melbourne, Florida 32902


-----------[000030][next][prev][last][first]----------------------------------------------------
Date:      Wed, 1 Jun 1994 21:09:31 GMT
From:      art@acc.com (Art Berggreen)
To:        comp.protocols.tcp-ip
Subject:   Re: IP Loadsharing

In article <2s5gth$62s@hacgate2.hac.com> switt@triceratops.hac.com (Steve Witt) writes:
>I've been reading RFC1131 describing the OSPF routing protocol and I notice 
>that it is capable of dicovering and using multiple, equal-cost routes to a 
>destination.  This aroused my interest as I'm not sure how multiple routes
>are "used" by IP.  
>
>It is my understanding that a routing policy or protocol, like OSPF, executing
>as a daemon (such as gated), initializes and updates the IP routing table that
>IP uses to forward IP datagrams.  The routes in the IP routing table, 
>indicate the next-hop router to which to forward IP datagrams for specific 
>destinations (either hosts or networks).  If the routing protocol is 
>capable of discovering multiple routes to a destination host or network, is
>IP capable of using this information?  It would seem that the IP routing
>table would need to have each route from the set of multiple routes to a 
>destination, inserted into the table and then IP would 
>need to have some method of using each route.  My understanding of current
>IP implementations (which is limited to the 4.3BSD from which SunOS was
>developed) is that the IP routing algorithm first tries to find a host-
>specific route for the datagram, then tries to find a network route for the
>datagram, and then uses a default route (if it exists).  It would seem that
>if there were multiple entries in the IP routing table for a destination
>network or host that the IP routing algorithm would match on the first one
>found and forward the datagram accordingly and would not be able to make use
>of multiple routes effectively.  Perhaps I have a naive understanding of the
>IP routing algorithm.  
>
>Can IP (or particular implementations of IP) perform load sharing given a
>routing policy that is capable of discovering useful multiple routes to a 
>destination?

First, don't confuse protocol with implementation.
Last time I looked at BSD Unix, it was not capable of maintaining multiple
equal cost routes in the kernel's routing table.  But since the vast majority
of Unix machines are singly homed, with typically one or two routers on
their LAN, it's not a problem.  Many routers can maintain, and use, multiple
equal cost routes.  These routers will usually load share across the available
paths.  It makes more sense with routing protocols where the metrics have
some relationship to link capacity (such as OSPF), than with routing protocols
which deal purely in hop counts (such as RIP).

Art



-----------[000031][next][prev][last][first]----------------------------------------------------
Date:      Wed, 1 Jun 1994 22:14:58 GMT
From:      rstevens@noao.edu (W. Richard Stevens)
To:        comp.unix.solaris,comp.protocols.tcp-ip
Subject:   Re: Help on TLI

> Does anyone know what the value 146 in the reason field of a call to t_rcvdis?
> I am running 2.3 using TLI trying to connect to a server running on pyramid
> svr4 box.  t_open was ok, failed in t_connect, so I did a t_look, and tells me
> I get a disconnect, so I do a t_rcvdis, the reason field was set to 146, but I
> cannot find it in any header files, any idea?

    % grep 146 /usr/include/sys/errno.h
    #define ECONNREFUSED    146     /* Connection refused */

Looks like you got an RST in response to your SYN.  Perhaps the server
process wasn't started, or you have the wrong port?

	Rich Stevens

-----------[000032][next][prev][last][first]----------------------------------------------------
Date:      Wed, 1 Jun 1994 22:29:00 GMT
From:      rstevens@noao.edu (W. Richard Stevens)
To:        comp.protocols.tcp-ip
Subject:   Re: SO_REUSEADDR, etc.

>|> Right again.  I think it's just because multicasting got people to
>|> start thinking about multiple processes reading from the same UDP
>|> port.  Realize, however, that when multiple processes bind the
>|> same UDP port, they all get copies of *only* broadcast or multicast
>|> datagrams.  Unicast datagrams still go to one process only.  Which
>|> one gets the unicast datagram is implementation-dependent if there
>|> are multiple processes bound to the port.
>
>  Do you know what the reasoning for this behavior is? I've always modeled and
>implemented UDP so that every process bound to a port gets a copy of each packet.

I don't know.  As I recall, the first system to let you bind multiple
processes to the same UDP port was the Stanford multicasting code from
Steve Deering, circa 1989.  In his README file dated June 24, 1989:

  "More than one process may bind to the same SOCK_DGRAM UDP port if the bind()
  is preceded by:

	int one = 1;
	setsockopt(sock, SOL_SOCKET, SO_REUSEADDR, &one, sizeof(one))

  In this case, every incoming multicast or broadcast UDP datagram destined to
  the shared port is delivered to all sockets bound to the port.  For backwards
  compatibility reasons, THIS DOES NOT APPLY TO INCOMING UNICAST DATAGRAMS --
  unicast datagrams are never delivered to more than one socket, regardless of
  how many sockets are bound to the datagram's destination port."

	Rich Stevens

-----------[000033][next][prev][last][first]----------------------------------------------------
Date:      2 Jun 1994 09:08:03 -0400
From:      alfredh806@aol.com (AlfredH806)
To:        comp.protocols.tcp-ip
Subject:   Re: WINQVTNET Users

In article <358@trotter.UUCP>, ae6244@leibniz.math.usma.edu (MARKERT
ERICH L. MR.) writes:

Re: WinQVT/Net Printing

I am trying to send the output to the local printer attached to the
workstation running WinQVT/Net.

Any ideas?  Thanks!

-----------[000034][next][prev][last][first]----------------------------------------------------
Date:      2 Jun 1994 09:12:18 -0400
From:      brain@msen.com (Jim Brain)
To:        comp.protocols.tcp-ip
Subject:   Questions about tcp-ip not in FAQ.

Being somewhat new to to TCP-IP programming, I want to ask those in the know
a few questions:

In APPC, most implementations provide a program launch capability similar to
inetd server capabilities.  Can someone detail how inetd works?  If it uses
RAW sockets to do special stuff, can someone point me to a text that describes
what special functions that tcp-ip has to offer?

I have gotten spoiled with other protocols abilities to post my semaphore 
whenever something is received from the channel.  I realize that standard
sockets does not provide this, but does anyone have an extension that does 
this? (MS/IBM/...)

Since my first implementation is for OS/2, followed by UNIX, I would like
those who have done the same answer me.  Is there some sample code available
on the net that I can compile and play with to see how sockets code is
written?

Jim Brain.


--
Jim Brain, Embedded Systems Designer, Brain Innovations.
brain@msen.com  
Dabbling in VR, Old Commodore Computers, and Good Times!
"The above views DO reflect my employer, since I am my employer" - Jim Brain


-----------[000035][next][prev][last][first]----------------------------------------------------
Date:      2 Jun 1994 09:17:17 -0400
From:      acinader@panix.com (Arthur Cinader)
To:        panix.questions,panix.internet.slip,panix.internet.ppp,comp.protocols.tcp-ip
Subject:   Mosaic conflict?

I have mosaic 1.03 on my Quadra 800.  When I launch it, I get
"Unable to connect to remote host" in the status bar and "text
has not been loaded" in the text box.  My home page is set to:
http://www.ncsa.uiuc.edu/SDG/Software/Mosaic/NCSAMosaicHome.html
and I have tried loading other url's such as MTV.com to make
sure that my problem is not just an overloaded home page.  I
am confident that this is not the problem.

My guess is that tcp packets are not moving from mosaic to
MACtcp and vica versa.

I have properly configured computers to run mosaic before, but
I cannot figure out what is wrong this time around.  Two
things come to mind.

1.  I am know using Intercom TCP Conect II as a telnet, ftp
	client.  Is anybody using Connect II and Mosaic suc
	cessfully?

2.  My mac is on an ethertalk network (however, I have gotten
	mosaic to work on such a configured computer before.)


Any Ideas, reccomendations?

Anybpdy know the developers address so I can mail them a copy
of this letter?

ACjr.

-----------[000036][next][prev][last][first]----------------------------------------------------
Date:      Thu, 2 Jun 1994 02:56:35 GMT
From:      bleys@vpnet.chi.il.us (Bleys Ahrens)
To:        comp.protocols.tcp-ip
Subject:   Re: DNS and OpenView

Richard E. Blair (rblair@cabell.vcu.edu) wrote:

: Is anyone out there running HP OpenView on a Name Server?  We are
: running OpenView 3.2 on an HP 715/50 running HP-UX 9.01.  Whenever
: I start named and then run OpenView, I get the error message "ovw:
: unable to resolve "hostname" to get a license."  The name server
: itself work fine, and I believe it's configured properly.  What I
: don't know is exactly how OpenView attempts to resolve a hostname.
 
: Any suggestions would be greatly appreciated.
 
: Richard Blair
: rblair@cabell.vcu.edu

I suspect that what you are seeing is due to some entries in an
Openview registration file.  Running DNS is probably changing
your hostname to a fully qualified domain name which does not
correspond to the info that was entered when you installed and
configured the product.

(I have seen the same thing several times with IBM's Openview
derivative, Netview/6000.

Thanks.
Bleys
--

==========================================================================
=   Bleys Ahrens                                             Chicago, IL =
=                        VPNET/Public Access Usenet                      =
=   Information gains value when shared...         bleys@vpnet.chi.il.us =
==========================================================================

-----------[000037][next][prev][last][first]----------------------------------------------------
Date:      Thu, 2 Jun 1994 03:49:30 GMT
From:      csmoko@relay.nswc.navy.mil (Chuck Smoko - E81)
To:        comp.protocols.tcp-ip
Subject:   Re: Multiple IP addrs for same hardware interface?

In article <1994Jun1.135707.10535@cherokee.nsuok.edu> landin@cherokee.nsuok.edu (Mark C. Landin) writes:
>
>So how did you get around it? I'm going to do the hardware shuffle in a 
>month or two and would like any helpful anecdotes from people who've
>done it.

I have some code allows the multiple addresses per interface.  It
is done with what is called a virtual interface.  I did not write the
code (included), but I have ported it Sunos.

							chuck smoko

PS: If you want the sun mods, please email to csmoko@nswc.navy.mil.  Below
is a old post to this group.


-------------------------------- SNIP ---------------------------------
I have a solution than might suit you.  For my doctoral work (there's
a paper about it in this year's ('91) SIGCOMM, also available for
anonymous FTP from cs.columbia.edu:/pub/ji/sigcomm*.ps.Z), I've
developed what I call the "Virtual Interface" (VIF). To the networking
code, it looks like an interface. It gets ifattach()ed when you open
the /dev/vif* device, and then you can ifconfig it as you like. It
does not have an if_input procedure; it only has an if_output. Packets
that it receives (from higher-level protocols) which have its
IP address, it simply loops back (like any well-behaved if driver).
Packets that it receives that are destined for some other address, it
encapsulates in an encapsulation protocol I call IPIP (IP-within-IP,
protocol number IPPROTO_IPIP == 94), and sends it to another machine
that groks that encapsulation protocol. This feature you won't need,
but here's how to have multiple IP addresses on a machine with a
single real interface:

Let's say your primary interface's IP address is 198.3.2.1, and you
also want it to respond to addresses 198.4.3.2 and 198.5.4.3 (note
that these are three distinct class C addresses in three distinct
class C nets). Here are the ifconfigs:

  ifconfig le0 198.3.2.1 up -trailers	# config primary interface

  ifconfig vif0 198.4.3.2 up 		# config first virtual interface
  route delete net 198.4.3 198.4.3.2	# delete spurious route 
  route add host 198.4.3.2 198.4.3.2 0	# add route for this i/f

  ifconfig vif1 198.5.4.3 up		# config second virtual interface
  route delete net 198.5.4 198.5.4.3	# delete spurious route 
  route add host 198.5.4.3 198.5.4.3 0	# add route for this i/f

The route deletes are needed because the ifconfig creates a default
route to the interface's network, which can cause problems; all that's
needed is the (host) route to the interface's address. 

Now, get le0's ethernet address (say, 8:0:20:3:2:1), and add the
following static ARP entries:

  arp -s 198.4.3.2 8:0:20:3:2:1 pub
  arp -s 198.5.4.3 8:0:20:3:2:1 pub

This will cause any ARP requests for the VIF addresses to be replied
with your machine's ethernet address. 

Now, make sure your default route is to your segment's gateway,
throught the real interface. FInally, make sure your routers and/or
hosts on the same segment as yours know that 198.4.3.2 and 198.5.4.3
are on that cable. 

Here's what you've accomplished.

ARP requests for any of your host's addresses will be replied to with
the host's ethernet address (the real one, because that's what it is,
the virtual ones because of the public static arp entries). Packets
reaching your host with any of these addresses will be accepted by the
ip_input routine because they match the address of one of the host's
interfaces. Packets leaving your host can have any of its addresses
(real and virtual). 

The code for vif follows. To use it, put the stuff in netinet/if_vif.c
and netinet/if_vif.h, configure your kernel with the number of
virtual interfaces you want using a line like:

pseudo-device	vif4		# Virtual IP interface

in your configuration file, and two lines like

netinet/if_vif.c	optional vif device-driver
netinet/if_vif.hc	optional vif device-driver

in the files file. Also, add the appropriate entries in conf.c, so
that you can access the if_attach() routine when you open the device:


------------------------in conf.c------------------------------------------

add this in the appropriate place in the headers of conf.c:

--------------------
#include "vif.h"
#if NVIF > 0
int	vifopen(), vifclose(), vifread(), vifwrite(), vifselect(), vifioctl();
#else
#define vifopen		nodev
#define vifclose	nodev
#define vifread		nodev
#define vifwrite	nodev
#define vifselect	nodev
#define vifioctl	nodev
#endif
--------------------

then, way down in the definition for cdevsw[]:

--------------------
	vifopen,	vifclose,	vifread,	vifwrite,	/*31*/
	vifioctl,	nodev,		nodev,		0,
	vifselect,	nodev,
--------------------

Make sure you remember the correct major device number!

------------------------in conf.c------------------------------------------

Finally, here's the code. It has the tunneling pieces removed (you
need more code to use that anyway), and it comes from a Mach 2.6
kernel; it should compile on any berkeley-derived unix with minor
changes (most likely only in the includes). 

---------------------netinet/if_vif.h--------------------------------------
typedef struct 
{
	struct ifnet	vif_if;
	struct ifnet	*vif_sif;	/* slave interface */
	int		vif_flags;
} vif_softc_t;

#define	VIFMTU	(1024+512)
---------------------------------------------------------------------------

and
---------------------netinet/if_vif.h--------------------------------------
/*
 * HISTORY
 * $Log:$
 */
 
/*
 * $Header:$
 *
 * Virtual IP interface module. 
 */

#include <multicast.h>

#include "param.h"
#include "systm.h"
#include "mbuf.h"
#include "socket.h"
#include "errno.h"
#include "ioctl.h"

#include "../net/if.h"
#include "../net/netisr.h"
#include "../net/route.h"

#ifndef MACH
#include "../machine/mtpr.h"
#endif

#ifdef	INET
#include "../netinet/in.h"
#include "../netinet/in_systm.h"
#include "../netinet/in_var.h"
#include "../netinet/ip.h"
#endif

#ifdef NS
#include "../netns/ns.h"
#include "../netns/ns_if.h"
#endif

#include "in_pcb.h"

#include "ip_var.h"
#include "ipip.h"
#include "ipip_var.h"
#include "micp.h"
#include "micp_var.h"

#include "if_vif.h"
#include "vif.h"

vif_softc_t vif_softc[NVIF];

int vifs_inited = 0;

int	vifoutput(), vififioctl();

vifattach()
{
	register int i;
	register struct ifnet *ifp;
	
	for (i=0; i<NVIF; i++)
	{
		ifp = &vif_softc[i].vif_if;
		ifp->if_name = "vif";
		ifp->if_unit = i;
		ifp->if_mtu = VIFMTU;
#if	MULTICAST
		ifp->if_flags = IFF_MULTICAST | IFF_NOARP;
#else	MULTICAST
		ifp->if_flags = IFF_NOARP;
#endif	MULTICAST
		ifp->if_ioctl = vififioctl;
		ifp->if_output = vifoutput;
		if_attach(ifp);
	}
}

vifopen(dev, flag)
int dev, flag;
{
	int unit;
	
	if (!vifs_inited)
	{
		vifattach();
		vifs_inited = 1;
		printf("vif initialized\n");
	}
	
	unit = minor(dev);
	if ((unit < 0) || (unit >= NVIF))
	{
		return ENXIO;
	}
	
	return 0;
}

vifclose(dev, flag)
int dev, flag;
{
	return 0;
}

vifread()
{
	return ENXIO;
}

vifwrite()
{
	return ENXIO;
}

vifselect()
{
	return ENXIO;
}

vifoutput(ifp, m0, dst)
	struct ifnet *ifp;
	register struct mbuf *m0;
	struct sockaddr *dst;
{
	int s;
	register struct ifqueue *ifq;
	struct mbuf *m;
	struct sockaddr_in *din;
	
	if (dst->sa_family != AF_INET)
	{
		printf("%s%d: can't handle af%d\n", 
		       ifp->if_name, ifp->if_unit,
		       dst->sa_family);
		m_freem(m0);
		return (EAFNOSUPPORT);
	}

	din = (struct sockaddr_in *)dst;
	
	if (din->sin_addr.s_addr == IA_SIN(ifp->if_addrlist)->sin_addr.s_addr)
	{
		printf("%s%d: looping\n", ifp->if_name, ifp->if_unit);
		
		/*
		 * Place interface pointer before the data
		 * for the receiving protocol.
		 */
		if (m0->m_off <= MMAXOFF &&
		    m0->m_off >= MMINOFF + sizeof(struct ifnet *)) {
			m0->m_off -= sizeof(struct ifnet *);
			m0->m_len += sizeof(struct ifnet *);
		} else {
			MGET(m, M_DONTWAIT, MT_HEADER);
			if (m == (struct mbuf *)0)
			  return (ENOBUFS);
			m->m_off = MMINOFF;
			m->m_len = sizeof(struct ifnet *);
			m->m_next = m0;
			m0 = m;
		}
		*(mtod(m0, struct ifnet **)) = ifp;
		s = splimp();
		ifp->if_opackets++;
		ifq = &ipintrq;
		if (IF_QFULL(ifq)) {
			IF_DROP(ifq);
			m_freem(m0);
			splx(s);
			return (ENOBUFS);
		}
		IF_ENQUEUE(ifq, m0);
		schednetisr(NETISR_IP);
		ifp->if_ipackets++;
		splx(s);
		return (0);
	}

	return EHOSTUNREACH;
}

/*
 * Process an ioctl request.
 */
/* ARGSUSED */
vififioctl(ifp, cmd, data)
	register struct ifnet *ifp;
	int cmd;
	caddr_t data;
{
	int error = 0;

	switch (cmd) {

	case SIOCSIFADDR:
		ifp->if_flags |= IFF_UP;
		/*
		 * Everything else is done at a higher level.
		 */
		break;

	default:
		error = EINVAL;
	}
 return (error);
}

vifioctl(dev, cmd, arg, mode)
dev_t dev;
int cmd;
caddr_t arg;
int mode;
{
	int unit;
	
	unit = minor(dev);
	if ((unit < 0) || (unit >= NVIF))
	  return ENXIO;
	
	return EINVAL;
}
---------------------------------------------------------------------------- 

To use it, compile your kernel, and reboot. Then create the vif
device:

# mknod /dev/vif c 31 0

(or whatever major number it ended up being), and echo something into
it:

# echo > /dev/vif

This will cause the device to be opened, which will if_attach the
interfaces. If you feel like playing with the code, you may want to
kmem_alloc() the vif_softc structrure at open time, and use the minor
number of the device to tell it how many interfaces to create. 

Now you can go ahead and ifconfig etc. 

I'll be happy to answer minor questions, and hear about success and
failure stories, but I cannot help you if you don't already know how
to hack kernels.

Good luck! 

/ji

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

-----------[000038][next][prev][last][first]----------------------------------------------------
Date:      Thu, 2 Jun 1994 05:51:56 GMT
From:      jas@talking.COM (Jim Shankland)
To:        comp.protocols.tcp-ip
Subject:   Multiple processes bound to same UDP port (was Re: SO_REUSEADDR, etc.)

In article <1994Jun1.183426.12830@noao.edu> rstevens@noao.edu (W. Richard Stevens) writes:
>Realize, however, that when multiple processes bind the
>same UDP port, they all get copies of *only* broadcast or multicast
>datagrams.  Unicast datagrams still go to one process only.  Which
>one gets the unicast datagram is implementation-dependent if there
>are multiple processes bound to the port.

Which is, of course, exactly what you sometimes want:  e.g., when
you have a cluster of server processes reading service requests as
UDP datagrams, doing some work, and returning to the well for the
next request.  It doesn't matter which server gets the datagram,
as long as each datagram goes to exactly one server ....

jas

-----------[000039][next][prev][last][first]----------------------------------------------------
Date:      2 Jun 1994 18:27:51 -0700
From:      lstowell@pyrnova.mis.pyramid.com (Lon Stowell)
To:        comp.protocols.tcp-ip
Subject:   Re: comp.protocols.tcp-ip

In article <2slml4$o1p@ns9000.furman.edu> mathews@ns9000.furman.edu (E. Owen Mathews) writes:
>
>I'm interested in comprehensive documentation of TCP/IP.
>I need to know details about the hardware level, the
>driver level, and the API level.  Are there any good 
>resources that you could recommend?  I need to start 
>from the very basic level, but I need some in-depth 
>information as well.  Any help would be appreciated.
>

   I'd start with the Comer manuals on TCP/IP. Volume 1 which is
   the protocols themselves, then Volume 2 which gives implementation
   issues (and sample code).  The Richard Stevens Unix Network
   Programming is a must if you are doing this on Unix.  



-----------[000040][next][prev][last][first]----------------------------------------------------
Date:      Thu, 2 Jun 1994 07:33:43 GMT
From:      cpm@uniplex.co.uk (Chris P Murray)
To:        comp.protocols.tcp-ip
Subject:   SO_REUSEADDR equivalent in TLI?


I'm having problems getting a server that uses 'TLI' to rebind after a client
has crashed and left a previous connection in FIN_WAIT2.  The socket implementation
is fine (I use the SO_REUSEADDR option).  Does anyone know if there is an
equivalent option in TLI?!??  I've tried to use the 't_optmgmt()' call but with no
luck - the documentation doesn't explain its parameters very well.  There is a
"TP_REUSEADDR" per-protocol option that, allegedly, can be set/got via t_optmgmt().
Has anyone got this or a REUSEADDR equivalent to work under the TLI interface??

-Chris.

-----------[000041][next][prev][last][first]----------------------------------------------------
Date:      Thu, 2 Jun 1994 14:54:33
From:      CAMARA@novell.wd.cubic.com (Raland Camara)
To:        comp.protocols.tcp-ip
Subject:   hp-ux startup files and hp-vue

All,

I have been encountering a handful of problems surrounding some of the
startup files under HP-UX and HP-VUE.  In particular,

1.  When telneting into my HP-UX system, my ~/.kshrc file is not sourced
    and only ~/.profile is run.  How does one insure that ~/.kshrc is 
    sourced upon login?  When a user has his default shell (/bin/ksh)
    defined in the /etc/passwd file as shown below, shouldn't the .kshrc
    file in his home directory automatically get sourced upon login?

Note:  My entry in the /etc/passwd file is as follows:
          raland:*:201:200:Raland Camara,,,:/users/raland:/bin/ksh

2.  Where can I obtain a set of default (i.e. fairly generic)
    xwindows/window manager/vue resource files to support my xterminal?
    (e.g.  .Xsession, .Xstartup, etc.)
    My xterminal is: HP ENVIZEX A SERIES Model C2731A Monitor HP A2094A.

3.  My .vueprofile is not executed when logining in under VUE.  How
    can I change this such that my .vueprofile DOES execute when logging
    in under VUE?  Also, how can I have my shell startup files get
    sourced when bringing up a hpterm by clicking on the terminal emulator
    icon on the front panel?
    I determined that my .vueprofile was not being executed because
    of the following test.  I defined an environment variable and 
    exported it in my .vueprofile and it does not show up in my 
    environment.

    in ~/.vueprofile:
        TESTVAR=true; export TESTVAR;
.
.
.
    from an hpterm shell prompt:

    $ env | grep TESTVAR
    $

Any help or insight you might be able to provide will be greatly 
appreciated.

Thanks in advance,

Raland
 

-----------[000042][next][prev][last][first]----------------------------------------------------
Date:      2 Jun 1994 12:38:58 GMT
From:      nirad@cs.uq.oz.au (Nirad Sharma)
To:        comp.dcom.lans,comp.protocols.tcp-ip
Subject:   Fault / Performance degradation diagnosis books / articles

Can anyone recommend any detailed work dealing with fault diagnosis on LANs
(and WANs, if available) ?  I'm particularly after something that deals with
OSI and/or TCP/IP.

I'm after this material to round out my own experience to developing some
model-driven knowledge-based diagnosis systems that apply some research that
I am undertaking to some network diagnosis / reconfiguration scenarios.

--
Nirad Sharma
Computer Science, University of Queensland

-----------[000043][next][prev][last][first]----------------------------------------------------
Date:      Thu, 2 Jun 1994 17:39:58 UNDEFINED
From:      treynold@fred.lasalle.edu (Tommi)
To:        comp.protocols.tcp-ip
Subject:   Re: Assign IP address to person or machine?

In article <1994Jun2.182805.28009@nb.rockwell.com> mcfowler@sol.rockwell.com (Mark C. Fowler) writes:
>From: mcfowler@sol.rockwell.com (Mark C. Fowler)
>Subject: Assign IP address to person or machine?
>Keywords: IP, address, person, machine
>Date: Thu, 2 Jun 1994 18:28:05 GMT
 
>There's a situation where PC users (running DOS and MS-Windows) that
>use Banyan Vines download TCP/IP from the Vines server.  The version
>of TCP/IP that they are using needs an .INI file that they get from
>their personal directory on their Vines server.  The .INI file
>contains their IP address.
 
>  This has led to assigning IP addresses to people instead of
>machines.  My gut reaction is that this may cause problems, but I
>can't quite come up with good arguments as to why.  I'm wondering how
>others feel about the assignment of IP addresses to people instead of
>machines.  Is it a good idea?  Bad idea?  Does it really matter?  What
>are the security issues, if any?  What are the network management and
>system administration issues?


If this is the case, hope that your people stay on the same subnet all the 
time.  For example, I'd hate to give people an address that was relative to 
their office wired on the 20 segment (just for example :) and then have them 
use Bob's office downstairs, which is on the 12 segment......

Are your users always going to be on the same machine is what it comes down 
to, I suppose.  If, for example, Joe Average is assigned 200.200.200.200 and 
goes about using that address on several machines, what happens if during your 
management routine one day you discover that the network is overloaded due to 
a bad transmitter in 200.200.200.200?  (Sure, you should be able to look up an 
ethernet address too, which you should in turn be able to track down, but...)

Or am I reading this all wrong? :)

Hope this helps....
---
Tommi

treynold@fred.lasalle.edu

The above are my thoughts; if you don't like them, don't read them!

-----------[000044][next][prev][last][first]----------------------------------------------------
Date:      Thu, 2 Jun 1994 14:36:34 GMT
From:      vjs@calcite.rhyolite.com (Vernon Schryver)
To:        comp.protocols.tcp-ip
Subject:   Re: IP Loadsharing

In article <2sjjr8$h7q@minerva.doe> bacon@mtu.edu (Jeff Bacon) writes:
>given all this...let's suppose I want to use n>=2 slip or PPP links
>to provide a remote IP connection between two machines, unix-based.
>(let's assume sun for now)
>are there any specifc implementations of this I can get?

I know of one, but it's binary only for workstations other than Sun's.

More important, while I've been pushing that "Brute Force and Ignorance"
style of multilinking in the IETF PPP mailing list for years, even I
agree that the forthcoming PPP multi-link protocol is a much better way
do do things.  Even fairly recent BSD TCP/IP gets confused and doesn't
go as fast as it should when given re-ordered segments by such a simplistic
scheme.


Vernon Schryver    vjs@rhyolite.com

-----------[000045][next][prev][last][first]----------------------------------------------------
Date:      2 Jun 1994 14:37:06 GMT
From:      longm@firnvx.firn.edu (Michael Long)
To:        comp.protocols.tcp-ip
Subject:   DNS freeware for DOS/Windows?

I am looking for a DNS server freeware package for DOS or Windows if anyone
knows where I can find one.

Thanks Mike...
*****************************************************************************
Michael Long - Sr. Systems Programmer
Florida State University/Florida Information Resource Network/Florida D.O.E.
E-mail: longm@firnvx.firn.edu         Phone: (904)487-0911
*****************************************************************************

-----------[000046][next][prev][last][first]----------------------------------------------------
Date:      2 Jun 1994 14:49:11 GMT
From:      longm@firnvx.firn.edu (Michael Long)
To:        comp.protocols.tcp-ip
Subject:   Looking for Whois Client/Server package?

I am looking for a Whois Client or Server application for Windows.  Hopefully
freeware.  If anyone knows where I can ftp it from, it would be greatly
appreciated.

Thanks Mike...
*****************************************************************************
Michael Long - Sr. Systems Programmer
Florida State University/Florida Information Resource Network/Florida D.O.E.
E-mail: longm@firnvx.firn.edu         Phone: (904)487-0911
*****************************************************************************

-----------[000047][next][prev][last][first]----------------------------------------------------
Date:      Thu, 2 Jun 1994 15:39:32 GMT
From:      johannes@titan.westfalen.de (Johannes Stille)
To:        comp.protocols.tcp-ip
Subject:   Re: variable subnetting AND static routing, no OSPF .. ?

In article <sej.770324974@interaccess> sej@flowbee.interaccess.com (Stephen Johnson) writes:
[...]
>Yes, static routing will work with variable subnetting. However, it
>may be possible to create a network subnetting scheme that would be
>impossible route through (static or otherwise). Keep it simple and
>you shouldn't have any problems (famous last words :) ).
[...]

I can see (or rather: have encountered) another problem with variable
subnetting: How do you recognize directed broadcasts?

The IP implementation I use doesn't allow the use of broadcast addresses
in certain situations. This makes sense to prevent packet storms e.g.
with directed "ping" broadcasts to another subnetwork. (In this case,
the restriction can be lifted with a socket flag if you really want to
do this.)

With variable subnetting, I don't see how it could be possible to
recognize directed broadcasts. Example: I have a class B network and a
machine on a subnet with mask 255.255.255.192. Now I want to send to
machine x.y.10.255, which is on a subnet with mask 255.255.248.0, and
thus a legal address. But for me, this address lokks like a directed
broadcast to a subnetwork x.y.10.192.

The same problem exists if some machine tries to connect to me with an
address that looks like a subnetwork broadcast address. AFAIK, e.g. a
TCP connection request from a directed broadcast address would be
discarded.


Is there a common solution to this problem, is it perhaps even discussed
in some RFC? Any comments and pointers to information available on the
net are welcome.

	Johannes

-----------[000048][next][prev][last][first]----------------------------------------------------
Date:      Thu, 2 Jun 1994 15:41:47 GMT
From:      atkinson@sundance.itd.nrl.navy.mil (Ran Atkinson)
To:        comp.protocols.tcp-ip
Subject:   Re: long delay TCP

In article <2sfeba$m5b@brachio.zrz.TU-Berlin.DE> rene@dhzb.de (Rene Simon) writes:
>Is there an implementation of a TCP for "long delay" connections like
>RFC1323 ?
>I need it for SunOS and Solaris.

I believe that Solaris 2.x already implements RFC-1323.

For SunOS 4.1.x, _experienced_ kernel hackers can put Tom Skibo's TCP
implementation (includes RFC-1323) into the kernel.  Novices should
not attempt this.

Ran
atkinson@itd.nrl.navy.mil
-- 


-----------[000049][next][prev][last][first]----------------------------------------------------
Date:      Thu, 2 Jun 1994 16:18:13 GMT
From:      cisml@world.std.com (Marty Lebowitz)
To:        comp.protocols.tcp-ip
Subject:   Need help in filling some openings!

Hi,

We currently are conducting a search for people (contract and
direct) with expertise in network protocol software for WAN's.
Any help you can offer in referring somone, would be much
appreciated!

Marty


#6024 - Network Consultants (2) - Network Protocols

Serve as internal expert on performance of protocols across WAN's,
working with customers, providing analytical analysis of performance 
within given configuration. Ability to recommend new products and new 
service offerings and help specify them. Act as mentor to junior 
engineers. Requries 4+ years industry experience with specialties in 
TCP/IP, ATM, SNA, APPN, FRAME RELAY, Windowing, hardware/software 
interfacing.. Location: (OK/TX). Other intermediate and senior level 
openings exists both locally and nationally.

For immediate confidential phone interview, fax/email resume AND call

Marty Lebowitz, President
Computer Interactive Services, Inc.
Tel: 617- 232-8300
Fax: 617- 232-6240



				# # # #


	

-----------[000050][next][prev][last][first]----------------------------------------------------
Date:      Thu, 2 Jun 1994 16:48:08 GMT
From:      rstevens@noao.edu (W. Richard Stevens)
To:        comp.protocols.tcp-ip
Subject:   Re: long delay TCP

> > Is there an implementation of a TCP for "long delay" connections like
> > RFC1323 ?
> > I need it for SunOS and Solaris.
>
> I believe that Solaris 2.x already implements RFC-1323.

Nope.  Someone at Sun told me it probably wouldn't make Solaris 2.4 either.
Anyone at Sun care to comment?

> For SunOS 4.1.x, _experienced_ kernel hackers can put Tom Skibo's TCP
> implementation (includes RFC-1323) into the kernel.

I think you can buy it from Sun as some kind of special request feature.

	Rich Stevens

-----------[000051][next][prev][last][first]----------------------------------------------------
Date:      Fri, 3 Jun 94 01:13:38 -0500
From:      baldwinl@delphi.com
To:        comp.protocols.tcp-ip
Subject:   Telnet response time after packet drop?

I'm currently troubleshooting a Telnet response time problem on a very heavily
u
utilized token ring (50%+).  With a Sniffer, it seems to take nearly two
seconds for TCP to recover from a single dropped packet.  After reading up
on TCP retransmission algorithms it almost seems like this is normal.
If I understand it correctly TCP doesn't retransmit until after receiving
3 duplicate ACKs (packet out of order).
 
The configuration is an PC running OS/2 with IBM's IP stack communicating
with a Sun Sparc 1000.
 
Also can anyone suggest further references on TCP retransmission algorithms?
 
Thanks.

-----------[000052][next][prev][last][first]----------------------------------------------------
Date:      Thu, 2 Jun 1994 17:40:20 GMT
From:      atkinson@sundance.itd.nrl.navy.mil (Ran Atkinson)
To:        comp.protocols.tcp-ip
Subject:   Re: long delay TCP

>> > Is there an implementation of a TCP for "long delay" connections like
>> > RFC1323 ?
>> > I need it for SunOS and Solaris.
>>
>> I believe that Solaris 2.x already implements RFC-1323.
>
>Nope.  Someone at Sun told me it probably wouldn't make Solaris 2.4 either.
>Anyone at Sun care to comment?

  I talked with a developer inside Sun who said they had already done
it for Solaris; I wasn't blindly speculating.  Now I wonder if it is a
"special" for Solaris rather than in the standard release.  It would
help if Sun would comment on the record about this.

Ran
atkinson@itd.nrl.navy.mil

-- 


-----------[000053][next][prev][last][first]----------------------------------------------------
Date:      Thu, 2 Jun 1994 17:58:38 GMT
From:      jimc@jts.jts.com (Jim Carroll )
To:        comp.protocols.tcp-ip,comp.sys.sun.admin
Subject:   how to set up RARP/BOOTP clients?

Sorry if this is a repeat posting, but our nntpd was acting weird lately.

Environment:
		- PCs (MS-DOS & MS-Windows running LWP)
		- Suns running SunOS 4.1.2 and 4.1.3
		- misc (a Solaris 2 box, a Pyramid, an HP)
		- NIS is being run

Goal:	To be able to set up a centrally manageable environment, as
	far as IP addressing is concerned.

I'm looking for a way to set up our LAN so that all PCs and (almost)
all Suns and as many of the none-of-the-above systems so that I can
manage all IP addresses from one (or two, or three) places.

I currently have BOOTP running on my Sun server, probably courtesy
of installing HP JetDirect cards.  In the meantime, I've added as
many hosts as possible to /etc/ethers (and /etc/hosts, of course)
with the hope that I could get one of these 2 technologies to
do what I want.

To be more precise, the PCs successfully use RARP to get their IP
addresses.  The Suns have them configured on the local disks.

I'd like to be able to learn how to either set up the non-server
Suns (and misc.) to use RARP on boot-up, or to set all non-server
nodes to use BOOTP on boot-up.  The latter will require a sample
config entry for /etc/bootptab for both a PC and a Sun, as well
as a pointer to an RFC, if possible.

Hints on how to set up the HP/Pyramid/Solaris2 systems to use
RARP/BOOTP on boot-up would be appreciated, too.

As usual, beg/plead/whimper/grovel yahda yahda yahda.  :-)

Email answers preferred, as I don't know if or when I'll have the
next opportunity to read these newsgroups.  Thanks.
-- 

--
* Jim Carroll * jimc@jts.com * JTS Systems Corp., Toronto, Ont.    *
| bumper sticker seen: " My other car is a Klingon Battle Cruiser" |

-----------[000054][next][prev][last][first]----------------------------------------------------
Date:      Thu, 2 Jun 1994 18:28:05 GMT
From:      mcfowler@sol.rockwell.com (Mark C. Fowler)
To:        comp.protocols.tcp-ip
Subject:   Assign IP address to person or machine?

There's a situation where PC users (running DOS and MS-Windows) that
use Banyan Vines download TCP/IP from the Vines server.  The version
of TCP/IP that they are using needs an .INI file that they get from
their personal directory on their Vines server.  The .INI file
contains their IP address.

  This has led to assigning IP addresses to people instead of
machines.  My gut reaction is that this may cause problems, but I
can't quite come up with good arguments as to why.  I'm wondering how
others feel about the assignment of IP addresses to people instead of
machines.  Is it a good idea?  Bad idea?  Does it really matter?  What
are the security issues, if any?  What are the network management and
system administration issues?


Mark Fowler


-----------[000055][next][prev][last][first]----------------------------------------------------
Date:      2 Jun 1994 19:17:41 GMT
From:      balenson@tis.com (David M. Balenson)
To:        alt.privacy,alt.security,alt.security.pgp,alt.security.ripem,comp.protocols.kerberos,comp.protocols.tcp-ip,comp.security.misc,comp.security.unix,ieee.announce,sci.crypt
Subject:   Call for Papers - 1995 ISOC Symp. on Netw. and Distr. Sys. Security


                             CALL FOR PAPERS
                    The Internet Society Symposium on
                 Network and Distributed System Security

        16-17 February 1995, Catamaran Hotel, San Diego, California

GOAL: The symposium will bring together people who are building
software and/or hardware to provide network and distributed system
security services.  The symposium is intended for those interested in
the more practical aspects of network and distributed system security,
focusing on actual system design and implementation, rather than in
theory.  We hope to foster the exchange of technical information that
will encourage and enable the Internet community to apply, deploy and
advance the state of the available security technology.  Symposium
proceedings will be published by the Internet Society.  Topics for the
symposium include, but are not limited to, the following:

*  Design and implementation of security services -- access control,
   authentication, availability, confidentiality, integrity, and
   non-repudiation.

*  Design and implementation of security mechanisms and support
   services -- encipherment, authentication, and key management
   systems, including fair cryptography -- access control,
   authorization and audit systems -- and intrusion detection systems.

*  Requirements and designs for securing distributed applications
   and network functions -- message handling, file transport, remote
   file access, directories, time synchronization, interactive
   sessions, remote data base management and access, routing, voice and
   video multicast and conferencing, news groups, network management,
   boot services, mobile computing, and remote I/O.

*  Requirements and designs for securing networked information
   resources and tools -- Archie servers, the Wide Area Information
   Servers (WAIS), the Internet Gopher, and the WorldWide Web (WWW).

*  Design and implementation of measures for controlling internetwork
   communication and services in a coherent manner -- firewalls, packet
   filters, application gateways, and user/host authentication
   schemes.

*  Requirements and designs for telecommunications security especially
   for emerging technologies -- very large systems like the
   international Internet, high-speed systems like the gigabit
   testbeds, wireless systems, and personal communication systems.

*  Special issues and problems in security architecture, such as
   interplay between security goals and other goals -- efficiency,
   reliability, interoperability, resource sharing, and cost.

GENERAL CHAIR:
   Jim Ellis, CERT Coordination Center

PROGRAM CHAIRS:
   David Balenson, Trusted Information Systems
   Rob Shirey, The MITRE Corporation

PROGRAM COMMITTEE:
   Tom Berson, Anagram Laboratories
   Matt Bishop, University of California at Davis
   Ravi Ganesan, Bell Atlantic
   Burt Kaliski, RSA Laboratories
   Steve Kent, BBN Communications
   Paul Lambert, Motorola
   John Linn, OpenVision Technologies
   Clifford Neuman, Information Sciences Institute
   Hilarie Orman, University of Arizona
   Michael Roe, Cambridge University (UK)
   Rob Rosenthal, U.S. National Institute of Standards and Technology
   Jeff Schiller, Massachusetts Institute of Technology
   Mike St. Johns, Advanced Research Projects Agency
   Peter Yee, U.S. National Aeronautics and Space Administration
   Roberto Zamparo, Telia Research (Sweden)

SUBMISSIONS:  The committee invites both technical papers and
proposals for panel discussions on technical and other topics of
general interest.  Technical papers should be 10-20 pages in length.
Panel proposals should be two pages in length, and should describe the
panel topic, name the panel chair, explain the format of the panel, and
list three to four potential panelists.  The technical papers will
appear in the proceedings.  Panel chairs and panelists will have the
option of having written statements appear in the proceedings.

All submissions should contain a separate title page which includes the
type of submission (paper or panel), the title or topic, the names of
the author(s), organizational affiliation(s), telephone and FAX
numbers, postal addresses, Internet electronic mail addresses, and the
point of contact, if more than one author.  Since the review process
will be anonymous, the author's names, affiliations and other
information should appear only on the separate title page.

        Deadline for paper submission:      August 15, 1994
        Notification sent to authors by:    October 17, 1994
        Deadline for camera-ready copy:     November 15, 1994

Submissions must be made by 15 August 1994.  Submissions should be made
via electronic mail.  Submissions may be in either of two formats:
PostScript or ASCII.  If the committee is unable to print a PostScript
submission, it will be returned and ASCII requested.  Therefore,
PostScript submissions should arrive well before 15 August.  If
electronic submission is absolutely impossible, submissions should be
sent via postal mail.

All submissions and other correspondence should be directed to the
Program Co-Chair:

                   David M. Balenson
		   Trusted Information Systems, Inc.
                   3060 Washington Road (Rt. 97)
                   Glenwood, Maryland 21738 USA
		   Phone: 301-854-6889
		   FAX:   301-854-5363
		   Email: balenson@tis.com

Each submission will be acknowledged through the medium by which it is
received.  If acknowledgment is not received within seven days, please
contact the Program Co-Chair as indicated above.  Authors and panelists
will be notified of acceptance by 17 October 1994.  Instructions for
preparing camera-ready copy for the proceedings will be postal mailed
at that time.  The camera-ready copy must be received by 15 November
1994.

-----
-- 
David M Balenson

-----------[000056][next][prev][last][first]----------------------------------------------------
Date:      2 Jun 1994 20:50:22 GMT
From:      jdf@nitehawk.East.Sun.COM (Jim Fiori - Special Projects)
To:        comp.protocols.tcp-ip
Subject:   Re: long delay TCP

In article 7r5@ra.nrl.navy.mil, atkinson@sundance.itd.nrl.navy.mil (Ran Atkinson) writes:
>>> > Is there an implementation of a TCP for "long delay" connections like
>>> > RFC1323 ?
>>> > I need it for SunOS and Solaris.
>>>
>>> I believe that Solaris 2.x already implements RFC-1323.
>>
>>Nope.  Someone at Sun told me it probably wouldn't make Solaris 2.4 either.
>>Anyone at Sun care to comment?
>
>  I talked with a developer inside Sun who said they had already done
>it for Solaris; I wasn't blindly speculating.  Now I wonder if it is a
>"special" for Solaris rather than in the standard release.  It would
>help if Sun would comment on the record about this.
>

There is a consulting special called CONSULT-TCPLFN available for SunOS 4.X. See
your local Sun rep for more information.

As for Solaris 2.X, it's being worked on, but there has been no determination
if/when/how it will ship. It will NOT be in 2.4.

Jim





-----------[000057][next][prev][last][first]----------------------------------------------------
Date:      03 Jun 94 10:45:48 -0800
From:      frank@calcom.socal.com (Frank Keeney)
To:        comp.protocols.tcp-ip
Subject:   Appletalk over tcp/ip how?

I can route tcp/ip over my localtalk net to allow MACs to communicate with
the rest of the ethernet. But how can I send Appletalk over a tcp/ip-only
WAN? What equipment/software would I need.


--
 Frank Keeney                   | E-mail  frank@calcom.socal.com
 115 W. California Blvd., #411  | Fidonet 1:102/645
 Pasadena, CA 91105-1509 USA    | UUCP    hatch!calcom!frank
                                | FAX     +1 818 791-0578 
                                | Voice Mail +1 818-791-0578 x402

-----------[000058][next][prev][last][first]----------------------------------------------------
Date:      2 Jun 1994 22:32:04 GMT
From:      mathews@ns9000.furman.edu (E. Owen Mathews)
To:        comp.protocols.tcp-ip
Subject:   comp.protocols.tcp-ip

I'm interested in comprehensive documentation of TCP/IP.
I need to know details about the hardware level, the
driver level, and the API level.  Are there any good 
resources that you could recommend?  I need to start 
from the very basic level, but I need some in-depth 
information as well.  Any help would be appreciated.

Owen Mathews (mathews()furman.edu)

-----------[000059][next][prev][last][first]----------------------------------------------------
Date:      2 Jun 94 22:48:44 GMT
From:      cjw@nwu.edu (Christopher Wargaski)
To:        comp.protocols.tcp-ip
Subject:   Re: /etc/hosts /etc/named.data questions

In <d00n.770445200@crash.cts.com> d00n@crash.cts.com (Kevin Spousta) writes:

>I have 5 entries pointing to the same IP address and also mail exchange
>records in the /etc/named.data file to 'fake out' the machine called
>smtpgate into thinking it's many machines for addressing reasons.  (Political
>reasons really)  Is this OK?  So far it works like a charm, but the keepers
>of the DNS say I can't do it like this.

And why not?  It sure makes sense to me.  In fact, Northwestern has a
machine that is doing multiple services and has multiple names (FQDN) all
with one IP address.

>Is it ok to have 1 IP for multiple hosts, when the actual host is *ONE*
>machine?  I'm defending my position on the grounds that A) it works, and
>B) nothing seems to be affected by this 'trickery'.  Can someone 
>prove/disprove my thinking??

Sure, I will back you up.  Consider this.  You have one macine doing
end-all-be-all SMTP mail forwarding.  If my local workstation does not know
where to send mail to joe@flop.slop.com, then I schwing it to a machine
that does mail relay service.  Call it relay.acns.nwu.edu.

Say that machine does X.400 mail translation as well.  Why not?  It does
the end-all mail resolution anyway?  Lets give it an address of
mhs.nwu.edu, because all X.400 mail would be sent there.

Well, this machine also happens to have a fax-modem on it, and is an
email-fax gateway.  Mail a letter (with a certain username format) to
fax.acns.nwu.edu.  It will fax it to a fax machine whose number you specify
in the user name.  

Hmm, this machine also has the N.U. PH (campus wide email alias) database
on it.  You can send mail to my alias cjw@nwu.edu and the machine nwu.edu
will send it to my real mailbox (cjw@moo.acns.nwu.edu).

Well, to resolve my PH alias to my real mailbox, I need to run a program
called phquery.  Well a phquery asks a machine called ns.nwu.edu (this is
the way the code is written) to resolve the alias to actual email address.

So this poor Sparc 1 is doing all this work and has 5 names!  (Just think,
this machine also used to the primary name server for the university!)
Well, in the near future, different machines will be doing different
services.  It would be VERY difficult to do the big hardware switch-over
without the current configuration.  I attribute this to the introspective
mind of a fellow colleague that did the work.

So, there is a reason why you should have different names for one physical
machine.  

Hope it helped!

cjw
-- 


   Christopher Wargaski    cjw@nwu.edu     Technical Services Supervisor
      Northwestern University Network Operations Center  708-467-NNOC

-----------[000060][next][prev][last][first]----------------------------------------------------
Date:      3 Jun 1994 08:43:01 -0500
From:      gpalmer@blue.weeg.uiowa.edu (Gary Palmer)
To:        comp.sys.ibm.pc.rt,comp.protocols.tcp-ip
Subject:   Networking the old IBM RT-PC


Does anyone have experience in networking the IBM RT-PC (model 6150)
to an ethernet network with TCP/IP?

I have the IBM baseband ethernet card and have loaded the TCP/IP software.
The hardware diagnostics seem to indicate that there is a good connection
back to the network.  But I cannot ping to/from the RT-PC.  A few attempts
to ping out result in an error message and the network software shutting
down.

-----------[000061][next][prev][last][first]----------------------------------------------------
Date:      Fri, 3 Jun 1994 04:26:54 GMT
From:      fitz@wang.com (Tom Fitzgerald)
To:        comp.protocols.tcp-ip
Subject:   Re: /etc/hosts /etc/named.data questions

d00n@crash.cts.com (Kevin Spousta) writes:

> I have 5 entries pointing to the same IP address and also mail exchange
> records in the /etc/named.data file to 'fake out' the machine called
> smtpgate into thinking it's many machines for addressing reasons.  (Political
> reasons really)  Is this OK?  So far it works like a charm, but the keepers
> of the DNS say I can't do it like this.

If you have both multiple A records, and multiple MX records, and all you
care about is e-mail, then you've got a case of overkill, you don't need the
A records at all, the MX's alone are enough.

When you say "5 entries pointing to the same IP address" it's not clear if
you mean 5 A records, or an A record and 4 CNAMEs; the other responses to
your question seem to be unclear about this as well.  CNAMEs are better
than multiple A's, if you DON'T have e-mail going to all those names.  If
you do have mail going to all those names, and for some reason can't use
MX's, then you do need to have multiple A's, and it does work (it's
confusing to someone who's looking at the data, though).

Note that you can't have both a CNAME record and any other record with the
same name.  (On the left-hand side of a record, I mean.  It's fine to have
multiple CNAMEs and MX's pointing to the same canonical name.)

-- 
Tom Fitzgerald   Wang Labs   Lowell MA, USA   1-508-967-5278   fitz@wang.com

-----------[000062][next][prev][last][first]----------------------------------------------------
Date:      Fri, 3 Jun 1994 04:30:24 GMT
From:      fitz@wang.com (Tom Fitzgerald)
To:        comp.protocols.tcp-ip
Subject:   Re: Assign IP address to person or machine?

mcfowler@sol.rockwell.com (Mark C. Fowler) writes:

>   This has led to assigning IP addresses to people instead of
> machines.  My gut reaction is that this may cause problems, but I
> can't quite come up with good arguments as to why.

Laptops, shared systems, people borrowing other people's systems (to get at
their printer/scanner/tape), people dialing in from home on PPP lines....
There's a real chance you'll get two systems on the net with the same
address at the same time, and this will cause major problems.  If you don't
have these things now, you will soon.

I vote for assigning IP addresses to machines, exclusively.

-- 
Tom Fitzgerald   Wang Labs   Lowell MA, USA   1-508-967-5278   fitz@wang.com

-----------[000063][next][prev][last][first]----------------------------------------------------
Date:      Fri, 03 Jun 1994 14:23:20 -0500
From:      patrickr@wr-hits.af.mil (Ron Patrick)
To:        comp.protocols.tcp-ip
Subject:   Internet Access in Saudi Arabia

Greetings,
	I will be traveling to Saudi Arabia and what to be able to access the
internet.  Does anyone know of a site that offers SLIP or Compuserve access
there?  If this is not the proper place to post - please tell me where. 
Thanks in advance for you help.

-Ron

P.S.  Please email back to me directly as I do not read this newsgroup
often.

patrickr@wr-hits.af.mil

-- 
Ron Patrick                   Internet: patrickr@margie.robins.af.mil
WR-ALC,380 2nd St. STE 104             
Robins AFB, GA 31098-1638     Voice: (912) 926-1313 FAX:(912) 926-2170     
        
--------------------------------------------------------------------------
My thoughts are my own and not controlled by the government.

-----------[000064][next][prev][last][first]----------------------------------------------------
Date:      3 Jun 1994 07:18:04 GMT
From:      xjbstah@solsta.ericsson.se (Stefan Ahser TX/DK, until 940701 resp etxjmik)
To:        comp.dcom.sys.cisco,comp.protocols.tcp-ip,comp.unix.admin,erinet.mailing-list.snmp,erinet.mailing-list.sun.managers,erinet.mailing-list.sun.nets,erinet.unix
Subject:   Help, mib on cisco-router in SunNet Manager.

Greetings

We are trying to get a cisco-mib to work through SunNet Manager (SnM), but we have some trouble.
We have installed a mib, we get the name of the agent (CISCO-MIB) to appear in the glyph-menu in SnM.
When we start the agent, first nothing happens for a while (about 1 min) and then we get the error:

   Request CISCO-MIB.lifTable.0 has ended unexpectedly.

The standard snmp-agents (snmp, snmp-mibII) works, so we know that we have contact with the router,
but those agents dont give us the information we need.

Please help		Stefan Ahser & Magnus Eriksson


Systeminfo
----------------------------------------
SPARCstation LX
----------------------------------------
OS-version:	Solaris 2.3
----------------------------------------
SnM-version:	SunNet Manager 2.2
----------------------------------------
MIB-version:	cisco-mib 9.1
----------------------------------------
Routerdata (solsta-gw>sh version)

solsta-gw>sh version
GS Software (GS2-RX), Version 8.2(3) 
Copyright (c) 1986-1991 by cisco Systems, Inc.
Compiled Tue 12-Feb-91 12:02 by mlb

System Bootstrap, Version 4.3(2) 

solsta-gw uptime is 1 week, 3 days, 2 hours, 27 minutes
System restarted by reload
Running default software

CSC2 (68020) processor with 1024K bytes of memory.
X.25 software.
4 MCI controller.
8 Ethernet/IEEE 802.3 interface.
4 Serial network interface.
48K bytes of multibus memory.
32K bytes of non-volatile configuration memory.
Configuration register is 0x301
-------------------------------------------

          		  \|||/
         		  (. .)
+----------------------ooO-(_)-Ooo--------------------------+
  Stefan Ahser                 Ericsson Telecom AB
  xjbstah@solsta.ericsson.se   Karlstad, Sweden
+-----------------------------------------------------------+



-----------[000065][next][prev][last][first]----------------------------------------------------
Date:      3 Jun 1994 16:57:55 GMT
From:      leonard@telcom.arizona.edu (Aaron Leonard)
To:        comp.protocols.tcp-ip
Subject:   Re: Telnet response time after packet drop?


In article <RC5t2By.baldwinl@delphi.com>, baldwinl@delphi.com writes:
|I'm currently troubleshooting a Telnet response time problem on a very heavily
|u
|utilized token ring (50%+).  With a Sniffer, it seems to take nearly two
|seconds for TCP to recover from a single dropped packet.  After reading up
|on TCP retransmission algorithms it almost seems like this is normal.

Yup, that's just about normal--although the actual retransmission
delay will be based upon TCP's estimated round-trip time.

|If I understand it correctly TCP doesn't retransmit until after receiving
|3 duplicate ACKs (packet out of order).

Nope, TCP retransmits when it DOESN'T get ACKs (of course).

|The configuration is an PC running OS/2 with IBM's IP stack communicating
|with a Sun Sparc 1000.
| 
|Also can anyone suggest further references on TCP retransmission algorithms?

For a nice gory practical discussion, see chapter 21 in Stevens'
_TCP/IP Illustrated_ (which you ought to buy in any case.

Aaron

Aaron Leonard (AL104), <Leonard@Arizona.EDU>
University of Arizona Network Operations, Tucson AZ 85721
  \ Don't lock yourself into open systems. /

-----------[000066][next][prev][last][first]----------------------------------------------------
Date:      Fri, 3 Jun 1994 18:16:57 GMT
From:      rstevens@noao.edu (W. Richard Stevens)
To:        comp.protocols.tcp-ip
Subject:   Re: Telnet response time after packet drop?

>|If I understand it correctly TCP doesn't retransmit until after receiving
>|3 duplicate ACKs (packet out of order).
>
>Nope, TCP retransmits when it DOESN'T get ACKs (of course).

No.  The reason for Jacobson's fast retransmit, fast recovery algorithm
(retransmitting after receiving 3 duplicate ACKs) is to avoid having to
wait for the retransmission timer to expire.  You'll normally get the
3 duplicate ACKs before the timer expires, letting the sender keep the
pipe filled before it empties.

	Rich Stevens

-----------[000067][next][prev][last][first]----------------------------------------------------
Date:      3 Jun 1994 19:44:31 GMT
From:      barmar@think.com (Barry Margolin)
To:        comp.protocols.tcp-ip
Subject:   Re: IP Loadsharing

In article <1994Jun1.210931.12927@acc.com> art@acc.com (Art Berggreen) writes:
>Last time I looked at BSD Unix, it was not capable of maintaining multiple
>equal cost routes in the kernel's routing table.

Hmm, I think SunOS and Ultrix just uses the old BSD routing table
implementation, and they have no problem with this.  I've used the route(8)
command to install multiple routes to the same subnet, and they both get
used.  I always assumed this is what the Refcnt field in the routing table
was for.

However, when a socket is connected, I believe it gets a reference to a
particular route, as an optimization.  Thus, if there's only a single TCP
connection going to a destination with multiple routes, it won't take
advantage of the load sharing.  But if you have multiple connections,
some will take one route while others will take the other.

Routed(8), on the other hand, will never install a new route to a
destination unless it has a strictly lower cost than one that it installed
previously.  I don't know whether gated will do it, either.
-- 
Barry Margolin
System Manager, Thinking Machines Corp.

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

-----------[000068][next][prev][last][first]----------------------------------------------------
Date:      3 Jun 1994 20:19:46 GMT
From:      barmar@think.com (Barry Margolin)
To:        comp.protocols.tcp-ip
Subject:   Re: SO_REUSEADDR, etc.

In article <CqqAAu.5HC@xinet.com> jas@talking.COM (Jim Shankland) writes:
>So, my take on this is that SO_REUSEADDR is an unnecessary hack:
>there is no reason you shouldn't be able to bind a server socket to
>a port/address pair that is an endpoint of one or more connections
>in the TIME_WAIT state, as long as you don't allow re-creation
>of TCP connections ({lport, laddr, fport, faddr} quadruplets)
>that are in the TIME_WAIT state.  BSD-based implementations
>are too restrictive when SO_REUSEADDR is not set, and (slightly)
>too permissive when SO_REUSEADDR *is* set.  Or have I missed
>something?

Yes, you've got it correct.  BSD-based implementations perform too simple a
test to see whether a local port is available -- it fails if any socket, in
any state, has the same local port.

>>Now UDP on a system that supports multicasting (e.g., Solaris 2.x) does
>>let you start multiple occurences of a server, all reading from the same
>>local port.  But that's another story ...
>
>I don't understand why this should be coupled with multicast
>capability.  That is, it seems perfectly reasonable to allow
>multiple servers to read from the same UDP port, even on a system
>that does *not* allow multicasting (and very desirable in some
>circumstances).  Is there any reason other than happenstance 
>that this is available only on multicast-capable systems?

Until multicast came along, there weren't many applications that needed
this capability.  With multicast, you have the possibility that two users
on the same system will start up the same multicast-based application.
Since a multicast datagram can go to sockets on different systems, it makes
sense that it should also go to multiple sockets on the same system.

Prior to that, I suspect it just simplified the implementation, and no one
considered multiple, independent processes binding to the same port to be
sometime that was necessary.  The most obvious, simplest way to implement
UDP is with a one-to-one localport->socket mapping.

Even unicast-only Unix systems support multiple processes listening on the
same port, but they have to be using the same socket.  They can get the
socket either through inheritance (this is the most common way -- a process
binds a socket and then forks a bunch of children, and they all read from
it) or by passing it around through Unix domain sockets.  Only when
multicast came along did the need for multiple
-- 
Barry Margolin
System Manager, Thinking Machines Corp.

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

-----------[000069][next][prev][last][first]----------------------------------------------------
Date:      Fri, 3 Jun 1994 21:16:24 GMT
From:      jdunham@world.std.com (Jim Dunham)
To:        comp.protocols.tcp-ip
Subject:   Whose TCP/IP has an IP interface?

If your TCP/IP has enough hooks or the API for a protocol to talk
directly through IP, please reply to this message.  I'm interested
in hearing about implementations for all versions of UNIX, Windows,
OS/2, MacOS, NextStep, etc.  I also need to know which implementations
hide their IP and only present a UDP or TCP interface.

Our product contains a protocol that runs directly over network-layer 
protocols, and needs a direct interface to IP.

Thanks in advance,
jim
jdunham@world.std.com

-----------[000070][next][prev][last][first]----------------------------------------------------
Date:      3 Jun 1994 22:46:39 GMT
From:      leonard@telcom.arizona.edu (Aaron Leonard)
To:        comp.protocols.tcp-ip
Subject:   Re: Telnet response time after packet drop?


In article <2snnej$em0@news.CCIT.Arizona.EDU>, leonard@telcom.arizona.edu 
(Aaron Leonard) writes:
[...]
|| With a Sniffer, it seems to take nearly two
||seconds for TCP to recover from a single dropped packet.  After reading up
||on TCP retransmission algorithms it almost seems like this is normal.
|
|Yup, that's just about normal--although the actual retransmission
|delay will be based upon TCP's estimated round-trip time.
| [...]
|For a nice gory practical discussion, see chapter 21 in Stevens'
|_TCP/IP Illustrated_ (which you ought to buy in any case.

Rich Stevens corrected me (blush):

|No.  The reason for Jacobson's fast retransmit, fast recovery algorithm
|(retransmitting after receiving 3 duplicate ACKs) is to avoid having to
|wait for the retransmission timer to expire.  You'll normally get the
|3 duplicate ACKs before the timer expires, letting the sender keep the
|pipe filled before it empties.
|
|	Rich Stevens

See, I told you: what Rich Stevens said!

Aaron

-----------[000071][next][prev][last][first]----------------------------------------------------
Date:      Sat, 4 Jun 1994 02:28:34 GMT
From:      vjs@calcite.rhyolite.com (Vernon Schryver)
To:        comp.protocols.tcp-ip
Subject:   Re: Telnet response time after packet drop?

In article <2snnej$em0@news.CCIT.Arizona.EDU> Leonard@Arizona.EDU writes:
>
>In article <RC5t2By.baldwinl@delphi.com>, baldwinl@delphi.com writes:
 
> ...
>|If I understand it correctly TCP doesn't retransmit until after receiving
>|3 duplicate ACKs (packet out of order).
>
>Nope, TCP retransmits when it DOESN'T get ACKs (of course).

What about Van Jacobson's fast retransmission algorithm which involves
retransmissions in response to duplicate ACKs?


Vernon Schryver    vjs@rhyolite.com

-----------[000072][next][prev][last][first]----------------------------------------------------
Date:      Sat, 4 Jun 1994 02:47:35 GMT
From:      kyma@netcom.com (Matt Young)
To:        comp.protocols.tcp-ip
Subject:   Voice


Fellow Netters:

As part of my consulting business my clients are asking
when can they send voice files over Internet.

Hence, the title.  Let me break down the question:

Who is currently pushing for some delay management over
routers which will allow voice support?

What is the current state of the standards?

Will a new ARP be required?

Will SNMP play a major role in bandwidth management?

The driving applications seems to be Whiteboard conferencing.
Clients will want to manage conferences and sub-conferences within
larger conferences.  Current systems (Future labs) are struggling
with having to maintain two different network environments, one
for data and one for voice.

Along with this, where are the ethernet vendors regarding a
bandwidth management scheme for ethernet?  IOf completed, how
will an ethernet bandwidth management scheme be compatible
with an enterprise wide TCP bandwidth management scheme?

Are any voice vendors emerging with the goal of integrating
voice across multiple platforms and network technologies?

Thank You very much for your information.
Matt Young
KYMA




-----------[000073][next][prev][last][first]----------------------------------------------------
Date:      4 Jun 1994 03:28:17 GMT
From:      mjr@tis.com (Marcus J Ranum)
To:        comp.protocols.tcp-ip
Subject:   Re: Voice

>As part of my consulting business my clients are asking
>when can they send voice files over Internet.
>
>Hence, the title.  Let me break down the question:
>
>Who is currently pushing for some delay management over
>routers which will allow voice support?
>
>What is the current state of the standards?
>
>Will a new ARP be required?
>
>Will SNMP play a major role in bandwidth management?

	You forgot "why"?

	I'm as big a fan of neet tecknology as the next guy, but
the best way to get guaranteed, uninterruptable bandwidth with
relatively easy call setup and low hardware cost is - the telephone.

	I dread a day when we'll start getting 15Mb mail messages
which take minutes to decode, and consist of someone saying,
"uh, hi, uh, this is bob, uh, um, can you give me a call at around
2:00? uh, ok? thanks."

	And of course if I'm on the road, I have to login and
download this crud in order to discover I've wasted my time? It's
like when I worked for a certain Big Company and we had this one
guy who blasted a message to a whole mailing list that was a huge
300kb Postscript file. Printed out, it was a 1 page memo with a
cool page header graphic that said something about the company
car plan.

>As part of my consulting business my clients are asking
>when can they send voice files over Internet.

	Sell them voice mail and tell 'em it's internet. They'll
just love it.

mjr.

-----------[000074][next][prev][last][first]----------------------------------------------------
Date:      3 Jun 1994 08:31:36 +1200
From:      qsmart@papaioea.manawatu.planet.co.nz (Quentin Smart)
To:        comp.protocols.tcp-ip
Subject:   Re: /etc/hosts /etc/named.data questions

In article <d00n.770445200@crash.cts.com>,
Kevin Spousta <d00n@crash.cts.com> wrote:
>I've been working on an SMTP gateway for Word Perfect Office and some of the
>'trickery' I've done involves multiple hostnames for a single IP address in
>the /etc/hosts file on our nameserver.  Not being a total TCP/IP guru, I
>have raised more than a few eyebrows with the way I've set up the nameservice
>for this machine. 
 ......
>Is it ok to have 1 IP for multiple hosts, when the actual host is *ONE*
>machine?  I'm defending my position on the grounds that A) it works, and
>B) nothing seems to be affected by this 'trickery'.  Can someone 
>prove/disprove my thinking??
>
Using multiple MX records to point to one host is correct. And in fact 
is exactly how we recommend configuration of our SMTP WordPerfect Office 
gateway. 

- Quentin.

-----------[000075][next][prev][last][first]----------------------------------------------------
Date:      3 Jun 1994 08:38:16 +1200
From:      qsmart@papaioea.manawatu.planet.co.nz (Quentin Smart)
To:        comp.protocols.tcp-ip
Subject:   Re: /etc/hosts /etc/named.data questions

In article <sej.770467765@interaccess>,
Stephen Johnson <sej@flowbee.interaccess.com> wrote:
>d00n@crash.cts.com (Kevin Spousta) writes:
>
>>I've been working on an SMTP gateway for Word Perfect Office and some of the
>>'trickery' I've done involves multiple hostnames for a single IP address in
>>the /etc/hosts file on our nameserver.  Not being a total TCP/IP guru, I
>>have raised more than a few eyebrows with the way I've set up the nameservice
>>for this machine. 
 ......
>
>I believe that multiple machine names (aka aliases) are not only OK but
>supported under DNS using the CNAME record. However, I'm not an expert
>on the arcane interactions between MX records and CNAME records and 
>aliasing a mail machine might cause problems of which I am unaware.
>
If you use a CNAME record you will most likely find that the mail turning 
up at your gateway has the addresses changed to what the CNAME record was 
pointing to. With an MX record the address will be preserved and you can 
then do your SMTP address to WPO host mapping.

-----------[000076][next][prev][last][first]----------------------------------------------------
Date:      04 Jun 1994 05:16:50 GMT
From:      jtw@lcs.mit.edu (John Wroclawski)
To:        comp.protocols.tcp-ip
Subject:   Re: Voice

In article <kymaCquqFB.GJH@netcom.com> kyma@netcom.com (Matt Young) writes:

   As part of my consulting business my clients are asking
   when can they send voice files over Internet.

Are you talking about "live" voice or data files? Assuming you are
talking about live voice,

   Who is currently pushing for some delay management over
   routers which will allow voice support?

The IETF integrated services working group ("int-srv") is concerned
with developing overall architectural extensions to the internet
which will help to support these applications.

The IETF RSVP working group is concerned with developing and
standardizing RSVP, a protocol to support resource reservation in an
internet environment. This work takes particular account of multicast
and the requirements of heterogeneous systems.

The work mentioned above aims to add bandwidth management capabilities
to the IP protocol architecture. An alternative approach replaces IP
with a different internetwork protocol, STII, in situations where
bandwidth management is required. STII has been around for a while,
and has a number of implementations, although it is not widely
deployed.

The IETF AVT working group is concerned with transport protocols for
(pseudo) real-time data, encoding formats, and the like.

The IETF multimedia conferencing control wg ("MMUSIC") is looking at a
number of issues relating to conferencing applications and common
sesson-control standards.

In addition to these specific working groups, a number of activites
underway in the IETF, including advanced routing architectures (to
support choosing routes based on quality of service needs, and to
support wide-area multicast services), and the next-generation IP
design effort, will have an impact on supporting these applications.

A number of research and advanced development projects are
demonstrating the possibilities of this technology today. The MBONE is
a large (800+ network, 20+ countries) virtual network embedded in the
internet which supports multicast distribution of audio and video
programs, among other things.  Some applications in wide use are the
"vat" audio tool, the "sd" session manager, and the "wb" shared
whiteboard, all from Lawrence Berkeley Labs; the "nv" video
conferencing tool from Xerox PARC, and the "ivs" video tool from
INRIA. (There are a number of other equally interesting projects
happening, and I certainly don't mean to single these out as the only
ones of merit...). A key point of all of these applications is their
focus on group communication as well as A-to-B communication. A lot of
effort is going into making sure the whole thing scales well.

   What is the current state of the standards?

Young. The AVT folks have done a substantial amount of work, and are
nearing completion of some initial draft standards and profiles. These
will then enter the official IETF standards process, which allows (or
perhaps "requires") additional time for evaluation of the work. Most
of the other work is much newer, and while implementations will appear
quickly, actual IETF-approved standards will take longer.

It is important to understand what will be standardized and what won't
be. The intent is to standardize only those things which must be
agreed on globally, while leaving substantial flexibility in matters
of local concern, such as the scheduling algorithm used in a specific
router or network. This is because there is no one right answer for
all conditions, and because both applications and technology will
continue to improve over time.

   Will a new ARP be required?

No.

   Will SNMP play a major role in bandwidth management?

Seems unlikely, although it will play a role in allowing network
managers to control the link usage policies of their local routers.
This is a traditional network management role.

   Along with this, where are the ethernet vendors regarding a
   bandwidth management scheme for ethernet?  If completed, how
   will an ethernet bandwidth management scheme be compatible
   with an enterprise wide TCP bandwidth management scheme?

First, experiments over several years have demonstrated that b/w
management is not always required at the local ethernet level. In
situations where it is, a couple of approaches are possible, depending
on whether you imagine that all nodes on the ethernet are cooperating
or not. An alternative to this is to put b/w management in a switching
hub, and use the hub-host connections as point-to-point links. This
alternative is simple to deploy and can give excellent performance.

The internet architectural work will use the bandwidth management
capabilities of lower-level nets where it exists. To handle a broader
spectrum of nets, one might assume that a b/w-managed internet path
will have a "reliability level" associated with it, as well as the
more traditional parameters. This matches well with the requirements
of perceptual applications. For example, you might put up with an
occasional crackle if you are just chatting with a group of friends,
but would demand excellent service if you were giving a remote piano
recital. In the first case, an uncontrolled ethernet would be OK. In
the second, it might not be. So the application should have a knob,
and the network should do path choice and bandwidth management to
provide whatever service the application needs.

			regards,
			  -john

John Wroclawski
jtw@lcs.mit.edu

-----------[000077][next][prev][last][first]----------------------------------------------------
Date:      4 Jun 1994 06:31:10 GMT
From:      barmar@think.com (Barry Margolin)
To:        comp.protocols.tcp-ip
Subject:   Re: Assign IP address to person or machine?

In article <1994Jun2.182805.28009@nb.rockwell.com> mcfowler@sol.rockwell.com (Mark C. Fowler) writes:
>  This has led to assigning IP addresses to people instead of
>machines.  My gut reaction is that this may cause problems, but I
>can't quite come up with good arguments as to why.

What happens if a user logs in from two machines at the same time?  They'll
both try to use the same IP address, won't they?
-- 
Barry Margolin
System Manager, Thinking Machines Corp.

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

-----------[000078][next][prev][last][first]----------------------------------------------------
Date:      Sat, 4 Jun 1994 15:42:53 GMT
From:      dch2@netcom.com (D. Hobbs)
To:        comp.protocols.tcp-ip
Subject:   TCP/IP vs. LU 0 (tuning)

Hello All!

I'd really like to start a discussion on tuning TCP/IP for various
platforms (different Unix boxes, PCs/Macs, IBM/Tandem big boxes, etc.),
but I don't know where these kinds of things are documented.

For example, there are several people where I work that have pointed
out various books, magazines, etc. on tuning LU 0 and LU 6.2 on SNA
networks (VPACING, PACING, I-Frame size, RU Size, etc.), and this is
all doc'd well in IBM literature (ok, you'll need about 10 different
books weighing 100 lbs.).

I have Comer's I and III (not II) volumes, but I don't see where he
shows HOW/WHERE to modify settings.  This seems reasonable since his
books seem to avoid "platform-dependence."

Are the Steven's books a good place?  What about RFC's?  I tend to doubt
the Steven's books will do much good since they are more concerned with
programming.  And I'm afraid the RFC's might get too deep too quick, but
I'm willing to look.

What kind of recommendations do y'all have?  Anyone care to just jump
in and start this discussion?  I once mentioned this to a friend of mine
who manages a decent-sized Network.  His recommendation was to leave
TCP/IP alone since it could adversely affect overall network performance.

I understand this point of view from him (being a network mgr), but I
really want my TCP/IP to hum!  I'm always being jabbed by my fellow
SNA'ers about the speed of TCP/IP in our network (to IBM 3090).  I can
get access to make changes on MVS and Unix both.  I also have customers
asking these kinds of questions, and I'd really like to discuss this
semi-intelligently with them.

Thanks,

D.
-- 
David Hobbs
dch2@netcom.com, 71175.166@compuserve.com
All typos are my own.  The spelling errors are someone else's.

-----------[000079][next][prev][last][first]----------------------------------------------------
Date:      Sat, 4 Jun 1994 16:58:56 GMT
From:      vjs@calcite.rhyolite.com (Vernon Schryver)
To:        comp.protocols.tcp-ip
Subject:   Re: IP Loadsharing

In article <2so16vINNcpt@early-bird.think.com> barmar@think.com (Barry Margolin) writes:
>In article <1994Jun1.210931.12927@acc.com> art@acc.com (Art Berggreen) writes:
>>Last time I looked at BSD Unix, it was not capable of maintaining multiple
>>equal cost routes in the kernel's routing table.
>
>Hmm, I think SunOS and Ultrix just uses the old BSD routing table
>implementation, and they have no problem with this.  I've used the route(8)
>command to install multiple routes to the same subnet, and they both get
>used.  I always assumed this is what the Refcnt field in the routing table
>was for.
>
>However, when a socket is connected, I believe it gets a reference to a
>particular route, as an optimization.  Thus, if there's only a single TCP
>connection going to a destination with multiple routes, it won't take
>advantage of the load sharing.  But if you have multiple connections,
>some will take one route while others will take the other.
> ...

The old style (4.3BSD) code I think I know about does cache a pointer
to the route with each TCP connection, and so different TCP connections
can use different routes.  However, each time the system looks for a
route, it simply looks for the first one.  Unless the routing table is
change (either manually or by a daemon), all TCP connections will use
the same route.  There is no load sharing.

People regularly suggests patches that rotate entries in the routing
table so that such load sharing would happen.

That routing table look up can happen on every UDP transmission, which
is why under some circumstances, UDP can be slower than TCP.


Vernon Schryver    vjs@rhyolite.com

-----------[000080][next][prev][last][first]----------------------------------------------------
Date:      Sat, 4 Jun 1994 17:22:10 GMT
From:      gnn@netcom.com (George Neville-Neil)
To:        comp.protocols.tcp-ip
Subject:   TCP-IP FAQ for June 1994

Hi Folks,

	OK here is the latest FAQ, complete with corrections and some
additions.  Remember, this is also available for anonymous ftp from
ftp.netcom.com:~ftp/pub/gnn/tcp-ip.faq

Enjoy,
George


Internet Protocol Frequently Asked Questions

Maintained by: George V. Neville-Neil (gnn@netcom.com)
Contributions from:
Ran Atkinson
Stephane Bortzmeyer
Phill Conrad 
Jon Kay 
Barry Margolin 
Jim Muchow
W. Richard Stevens 
 
Version 1.2

Last Update:  June 4, 1994

************************************************************************

	The following is a list of Frequently Asked Questions, and
their answers, for people interested in the Internet Protocols,
including TCP, UDP, ICMP and others.  Please send all additions,
corrections, complaints and kudos to the above address.  This FAQ will
be posted on or about the first of every month.

************************************************************************

Table of Contents:
Glossary
1) Are there any good books on IP?
2) Where can I find example source code for TCP/UDP/IP?
3) Are there any public domain programs to check the performance of an
IP link? 
4) Where do I find RFCs?
5) How can I detect that the other end of a TCP connection has
crashed?  Can I use "keepalives" for this?
6) Can the keepalive timeouts be configured?
7) Can I set up a gateway to the Internet that translates IP
addresses, so that I don't have to change all our internal addresses 
to an official network? 


Glossary:

I felt this should be first given the plethora of acronyms used in the
rest of this FAQ.

IP: Internet Protocol.  The lowest layer protocol defined in TCP/IP.
This is the base layer on which all other protocols mentioned herein
are built.  IP is often referred to as TCP/IP as well.

UDP: User Datagram Protocol.  This is a connectionless protocol built
on top of IP.  It does not provide any guarantees on the ordering or
delivery of messages.  This protocol is layered on top of IP.

TCP: Transmission Control Protocol.  TCP is a connection oriented
protocol that guarantees that messages are delivered in the order in
which they were sent and that all messages are delivered.  If a TCP
connection cannot deliver a message it closes the connection and
informs the entity that created it.  This protocol is layered on top
of IP.

ICMP:  Internet Control Message Protocol.  ICMP is used for
diagnostics in the network.  The Unix program, ping, uses ICMP
messages to detect the status of other hosts in the net.  ICMP
messages can either be queries (in the case of ping) or error reports,
such as when a network is unreachable.

RFC: Request For Comment.  RFCs are documents that define the
protocols used in the IP Internet.  Some are only suggestions, some
are even jokes, and others are published standards.  Several sites in
the Internet store RFCs and make them available for anonymous ftp.

SLIP:  Serial Line IP.  An implementation of IP for use over a serial
link (modem).  CSLIP is an optimized (compressed) version of SLIP that
gives better throughput.

Bandwidth:  The amount of data that can be pushed through a link in
unit time.  Usually measured in bits or bytes per second.

Latency:  The amount of time that a message spends in a network going
from point A to point B.

Jitter:  The effect seen when latency is not a constant.  That is, if
messages experience a different latencies between two points in a
network.

RPC:  Remote Procedure Call.  RPC is a method of making network access
to resource transparent to the application programmer by supplying a
"stub" routine that is called in the same way as a regular procedure
call.  The stub actually performs the call across the network to
another computer.

Marshalling:  The process of taking arbitrary data (characters,
integers, structures) and packing them up for transmission across a
network.

MBONE: A virtual network that is a Multicast backBONE.  It is still a
research prototype, but it extends through most of the core of the
Internet (including North America, Europe, and Australia).  It uses IP
Multicasting which is defined in RFC-1112.  An MBONE FAQ is available
via anonymous ftp from: ftp.isi.edu"  There are frequent broadcasts of
multimedia programs (audio and low bandwidth video) over the MBONE.


1) Are there any good books on IP?

A) Yes.  Please see the following:

Internetworking with TCP/IP Volume I
(Principles, Protocols, and Architecture)
Douglas E. Comer
Prentice Hall 1991

This volume covers all of the protocols, including IP, UDP, TCP, and
the gateway protocols.  It also includes discussions of higher level
protocols such as FTP, TELNET, and NFS.

Internetworking with TCP/IP Volume II
(Design, Implementation, and Internals)
Douglas E. Comer / David L. Stevens
Prentice Hall 1991

Discusses the implementation of the protocols and gives numerous code
examples.

Internetworking with TCP/IP Volume III (BSD Socket Version)
(Client - Server Programming and Applications)
Douglas E. Comer / David L. Stevens
Prentice Hall 1993

This book discusses programming applications that use the internet
protocols.  It includes examples of telnet, ftp clients and servers.
Discusses RPC and XDR at length.

TCP/IP Illustrated, Volume 1: The Protocols, 
W. Richard Stevens
(c) Addison-Wesley, 1994 

An excellent introduction to the entire TCP/IP protocol suite,
covering all the major protocols, plus several important applications.

Unix Network Programming
W. Richard Stevens
Prentice Hall 1990

An excellent introduction to network programming under Unix.

The Design and Implementation of the 4.3 BSD Operating System
Samuel J. Leffler, Marshall Kirk McKusick, Michael J. Karels, John S.
Quarterman 
Addison-Wesley 1989

Though this book is a reference for the entire operating system, the
eleventh and twelfth chapters completely explain how the networking
protocols are implemented in the kernel.


2)  Where can I find example source code for TCP/UDP/IP?

A)  Code from the Internetworking with TCP/IP Volume III is available
for anonymous ftp from:

arthur.cs.purdue.edu:/pub/dls

Code used in the Net-2 version of Berkeley Unix is available for
anonymous ftp from:

ftp.uu.net:systems/unix/bsd-sources/sys/netinet 

and

gatekeeper.dec.com:/pub/BSD/net2/sys/netinet

Code from Richard Steven's book is available on:
ftp.uu.net:/published/books/stevens.*

3)  Are there any public domain programs to check the performance of
an IP link?

A)  

TTCP:  Available for anonymous ftp from....

Host gatekeeper.dec.com

    Location: /.0/BSD/NetBSD/NetBSD-current/othersrc
      DIRECTORY dr-xr-xr-x        512  Apr  8 09:57  ttcp
    Location: /.0/BSD/NetBSD/NetBSD-current/othersrc/ttcp
           FILE -r--r--r--       3885  Nov  7 03:35  ttcp.1
           FILE -r--r--r--      19225  Nov  7 03:35  ttcp.c

Host world.std.com

    Location: /src/wuarchive/graphics/graphics/mirrors/sgi.com/sgi/src/ttcp
           FILE -r--r--r--       3885  Oct  4 1991  ttcp.1
           FILE -r--r--r--      19170  May 17 1993  ttcp.c
           FILE -r--r--r--      13033  Sep  5 1989  ttcp.c-brl

On ftp.sgi.com are netperf (from Rick Jones at HP) and nettest
(from Dave Borman at Cray).  ttcp is also availabel at ftp.sgi.com.




There is suite of Bandwidth Measuring programs from gnn@netcom.com.
Available for anonymous ftp from ftp.netcom.com in
~ftp/gnn/bwmeas-0.3.tar.Z These are several programs that meausre
bandwidth and jitter over several kinds of IPC links, including TCP
and UDP.


4) Where do I find RFCs?

A)  RFCs are available for anonymous ftp from the following servers.
You should pick the one geographically closest to you. 

North America

ftp.internic.net (canonical set)

FTP.NISC.SRI.COM 

and nic.cerf.net

Austrailia and Pacific Rim

munnari.oz.au

Denmark

ftp.denet.dk

Germany

walhalla.informatik.uni-dortmund.de

Finland

funet.fi

Netherlands

mcsun.eu.net

Norway

ugle.unit.no

Sweden

sunic.sunet.se and chalmers.se


Using Web, WAIS, and gopher:

Web:

http://web.nexor.co.uk/rfc-index/rfc-index-search-form.html

WAIS access by keyword:

wais://wais.cnam.fr/RFC

Excellent presentation with a full-text search too:

http://www.cis.ohio-state.edu/hypertext/information/rfc.html

With Gopher:

gopher://r2d2.jvnc.net/11/Internet%20Resources/RFC
gopher://muspin.gsfc.nasa.gov:4320/1g2go4%20ds.internic.net%2070%201%201/.ds/
.internetdocs



5) How can I detect that the other end of a TCP connection has crashed?
Can I use "keepalives" for this?

A) Detecting crashed systems over TCP/IP is difficult.  TCP doesn't require
any transmission over a connection if the application isn't sending
anything, and many of the media over which TCP/IP is used (e.g. ethernet)
don't provide a reliable way to determine whether a particular host is up.
If a server doesn't hear from a client, it could be because it has nothing
to say, some network between the server and client may be down, the server
or client's network interface may be disconnected, or the client may have
crashed.  Network failures are often temporary (a thin ethernet will appear
down while someone is adding a link to the daisy chain, and it often takes
a few minutes for new routes to stabilize when a router goes down), and TCP
connections shouldn't be dropped as a result.

Keepalives are a feature of the sockets API that requests that an empty
packet be sent periodically over an idle connection; this should evoke an
acknowledgement from the remote system if it is still up, a reset if it has
rebooted, and a timeout if it is down.  These are not normally sent until
the connection has been idle for a few hours.  The purpose isn't to detect
a crash immediately, but to keep unnecessary resources from being allocated
forever.

If more rapid detection of remote failures is required, this should be
implemented in the application protocol.  There is no standard mechanism
for this, but an example is requiring clients to send a "no-op" message
every minute or two.  An example protocol that uses this is X Display
Manager Control Protocol (XDMCP), part of the X Window System, Version 11;
the XDM server managing a session periodically sends a Sync command to the
display server, which should evoke an application-level response, and
resets the session if it doesn't get a response (this is actually an
example of a poor implementation, as a timeout can occur if another client
"grabs" the server for too long).

6) Can the keepalive timeouts be configured?

A) I know they can on many systems, but I don't know the details.

7) Can I set up a gateway to the Internet that translates IP addresses, so
that I don't have to change all our internal addresses to an official
network?

A) There's no general solution to this.  Many protocols include IP
addresses in the application-level data (FTP's "PORT" command is the most
notable), so it isn't simply a matter of translating addresses in the IP
header.  Also, if the network number(s) you're using match those assigned
to another organization, your gateway won't be able to communicate with
that organization (RFC 1597 proposes network numbers that are reserved for
private use, to avoid such conflicts, but if you're already using a
different network number this won't help you).

However, if you're willing to live with limited access to the Internet from
internal hosts, the "proxy" servers developed for firewalls can be used as
a substitute for an address-translating gateway. See the firewall FAQ.
-- 
gnn@netcom.com

Gentlemen, I will not have you fighting in the War Room.
					--- The President in Dr. Strangelove

-----------[000081][next][prev][last][first]----------------------------------------------------
Date:      5 Jun 1994 01:02:23 -0400
From:      adiwan@bbn.com (Arif Diwan)
To:        comp.unix.internals,comp.unix.wizards,comp.protocols.tcp-ip
Subject:   Re: Way for faster IPC than TCP/IP ?

In article <2rtmdiINNmvs@duncan.cs.utk.edu>,
	hzhou@cs.utk.edu (Honbo Zhou) writes:
>I would like to know if there is a way to do faster IPC between processes
>on different machines than TCP/IP. I am aware of RAW socket. Unfortunately,
>it need to have root access.

Why would you want to do that? You will probably not gain much over UDP
let alone RAW IP. I can get close to wire speed no loss thruput over
Ethernet or FDDI using the TCP/IP stack (UDP). The limiting factor is
your hardware (interface card + bus etc) and your OS.

Here are some figures [pps = packets/sec]:

Ethernet (Theoretical wire speed: 10MB/s):
	8400 pps  128 byte packets  -> 8.2 MB/s
       1200 pps 1024 byte packets    -> 9.375 MB/s

and this is going across an ethernet thru a router, across a FDDI ring,
thru another router and back out on another ethernet, traversing TCP/IP
stacks all along -without- dropping a single packet and running
continuously while other activity is going on at the routers and the
end systems (OSPF etc etc)!

FDDI (Theoretical wire speed: 100MB/s):

	9500 pps 1024 byte packets -> 74.2 MB/s

going over three FDDI rings, two routers and two end stations. Here the
results do not appear to be that great but the problem is in the FDDI
driver which needs tuning. The scenario is the same as above
otherwise.

If I stay on just one ring or ethernet segment then I can pump very
close to wire speed - over 95%.

-- 

				-- Arif Diwan (adiwan@bbn.com)
						617.873.6274

-----------[000082][next][prev][last][first]----------------------------------------------------
Date:      Sun, 5 Jun 1994 02:15:53
From:      tnert@bisque.cc.utexas.edu (Trent Stevens)
To:        comp.protocols.tcp-ip
Subject:   Re: Voice

In article <2srjq7$f7t@gaia.internex.net> Blaine Kubesh <blaine@sonicsys.com> writes:

>You can send voice over the internet right now. There is a Macintosh App 
>called Maven that will do the trick. It is an internet speech program
>that allows two people to talk over the Internet using your microphone 
>sound input. Query archie for the exact whereabouts. If you cannot find
>it let me know and I will send it to you.

You can do the same with Windows, using Internet Voice Chat by Richard Ahrens. 
The filename is IVC10.ZIP.

>You will need a Macintosh with MacTCP and Sound Manager 3.0 to use it.

You need a PC running Windows, a sound card, a microphone, and a network 
connection in conjunction with a Winsock to run IVC.  I haven't gotten it to 
work correctly yet, but that may be because I'm using SLIP!

Trent Stevens  tnert@bisque.cc.utexas.edu

-----------[000083][next][prev][last][first]----------------------------------------------------
Date:      Sat, 4 Jun 1994 23:45:36 GMT
From:      root@sizone.pci.on.ca (the mouth is where the lies come from)
To:        comp.protocols.tcp-ip
Subject:   'host' problems

I have 'host' for linux setup... well, I got the binaries, which I assume
were compiled correctly since they were on sunsite.

For some reason, I cant get IP#s for hosts outside the university! (my
slip is provided from the u.) - it seems as if only stuff in THEIR
/etc/hosts (I moved mine to a different name to see if it was affecting
things) is reported. For eg, even using uunet.ca as domain server
(usually its spadina.csri. toronto.edu which is what alot of systems at
UfT use) doesnt work - only for local university sites! What gives?

Are they stuck with giving info from their /etc/hosts only and when I use
another server it doesnt route my request out of the domain i'm SLIPed to?

(I dont know much about this stuff...)

I had the domain in my /etc/resolv.conf set to our local network domain
name and the nameserver set to my slip provider's IP# - nameservice
works fine with them as I said, but I couldnt get host to even match
ANYTHING until I set the resolv.conf domain to match my real internet
domain (as opposed to the local domain, since only one machine as a net
IP#). Now local hosts at the university are reported, but anything
outside that reports "host not found".

I've read the man page for 'host', and I grepped for "resolv.conf" here ('host'
comes up with too many matches!) but found nothing, so I am posting. Sorry
if this is duplicating info elsewhere.
	
/kc
-- 
Ken P. Chasse -- Sysadmin, Sonic Interzone   - Marion Boyd & the OPP must 
Public Access email/Usenet -- 416-968-7292    acknowledge that carrying netnews
spooge@sizone.pci.on.ca -- Toronto, CANADA    does NOT a publisher make!

-----------[000084][next][prev][last][first]----------------------------------------------------
Date:      5 Jun 1994 04:20:23 GMT
From:      Blaine Kubesh <blaine@sonicsys.com>
To:        comp.protocols.tcp-ip
Subject:   Re: Voice

In article <kymaCquqFB.GJH@netcom.com> Matt Young, kyma@netcom.com writes:
> As part of my consulting business my clients are asking
> when can they send voice files over Internet.

You can send voice over the internet right now. There is a Macintosh App 
called Maven that will do the trick. It is an internet speech program
that allows two people to talk over the Internet using your microphone 
sound input. Query archie for the exact whereabouts. If you cannot find
it let me know and I will send it to you.

You will need a Macintosh with MacTCP and Sound Manager 3.0 to use it.

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Blaine Kubesh                  Internet:  blaine@sonicsys.com
Sonic Systems, Inc.           Call Sign:  ke6gsx
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

-----------[000085][next][prev][last][first]----------------------------------------------------
Date:      Sun, 5 Jun 94 17:26:30 -0500
From:      baldwinl@delphi.com
To:        comp.protocols.tcp-ip
Subject:   Re: Telnet response time after packet drop?

W. Richard Stevens <rstevens@noao.edu> writes:
 
>>|If I understand it correctly TCP doesn't retransmit until after receiving
>>|3 duplicate ACKs (packet out of order).
>>
>>Nope, TCP retransmits when it DOESN'T get ACKs (of course).
>
>No.  The reason for Jacobson's fast retransmit, fast recovery algorithm
>(retransmitting after receiving 3 duplicate ACKs) is to avoid having to
>wait for the retransmission timer to expire.  You'll normally get the
>3 duplicate ACKs before the timer expires, letting the sender keep the
>pipe filled before it empties.
 
First let me say that I do own "TCP/IP Illustrated" and I think its the best
packet level book on TCP/IP on the market.	I must say however, that
TCP retransmissions was one of the very few places where you lost me.
 
Back to the issue.	My understanding of TCP retransmissions has now been
enhanced as follows:
 
1) Sender measures round trip response time
 
More?
2) Sender setsretransmit timeout (RTO) to	2x RTT (or more?)
 
3) RTO varies depending on future RTT
 
4) Sender sends packet and sets retransmission timer
 
5) Sender continues to send packets as long as there is available
	window and RTO seconds have not expired, unless:
 
6) However, if:
	a) RTO seconds expire before receiving ACK
 
	-or-
 
	b) Three (may vary?) duplicate ACKs received from receiver
 
	then:	INITIATE RETRANSMIT
 
Is this more accurate?

-----------[000086][next][prev][last][first]----------------------------------------------------
Date:      5 Jun 1994 13:19:01 GMT
From:      etxkrjg@solsta.ericsson.se (Kristian Jorg TX/DK)
To:        comp.protocols.tcp-ip,comp.protocols.ppp
Subject:   Re: cslip-2.7 for sunos4.1.3

References: <ZHAO.94Jun1161354@sparta.crl.nmsu.edu>

zhao@crl.nmsu.edu (Z. Zhao) writes:

>Hello,
 
>I am trying to implement cslip-2.7 on a sparc10/sunos4.1.3.
>I am confused about setting config file options for SLMTU. 
>Should I set
 
>	options SLMTU
>or
>	options SLMTU=<N>	
>or 
>	options SLMTU=<260>
 
>in the SYS_NAME file?
 
>'# config SYS_NAME' would say "options SLMTU=<N>" is a syntax error.
>SLMTU=<260> makes sense?


try:	options SLMTU=260

After you have run config and started make you will see the -DSLMTU=260
somewhere in the compilation commands that make creates. If not, something is
still wrong...

/Kristian

>ZiZi


--
_______________________________________________________
Kristian Jörg, Design Tools Development and Support
Ericsson Telecom AB, Karlstad, Sweden
E-mail: etxkrjg@solsta.ericsson.se, Tel: +46 54 193149

-----------[000087][next][prev][last][first]----------------------------------------------------
Date:      5 Jun 1994 13:36:09 GMT
From:      rodney@sabletech.com (Rodney Thayer)
To:        comp.protocols.tcp-ip
Subject:   DHCP Server

Can anybody recommend a DHCP server - on any platform?
Is there an update to the bsd bootp server to add dhcp support?

-----------[000088][next][prev][last][first]----------------------------------------------------
Date:      Sun, 5 Jun 1994 15:27:28 GMT
From:      kyma@netcom.com (Matt Young)
To:        comp.protocols.tcp-ip
Subject:   Re: Voice

John Wroclawski (jtw@lcs.mit.edu) wrote:

Thanks John for stepping up to the plate on this issue.
Now to help us all out, can I have you expand on some
of the issues you raised.  Users need to have a flavor of
some of the issues so they can make intelligent choices
from the various proposals which will result.

: Are you talking about "live" voice or data files? Assuming you are
: talking about live voice,

Yes, live interactive.

:    Who is currently pushing for some delay management over
:    routers which will allow voice support?
 
: The IETF integrated services working group ("int-srv") is concerned
: with developing overall architectural extensions to the internet
: which will help to support these applications.
 
: The IETF RSVP working group is concerned with developing and
: standardizing RSVP, a protocol to support resource reservation in an
: internet environment. This work takes particular account of multicast
: and the requirements of heterogeneous systems.

How does RSVP work, say compared to an ARP.  I use ARP as an
example since it is an approximation to call set up.  Is RVSP like
a call set up?  Does one issue an RSVP to modify the delay and
throughput characteristics of a particular connection?

What is used to identify a connection that has resource reservation?
It must be identified in intermediate nodes, is their a resource
ID associated with a particular Source-Destination IP pair?


: The work mentioned above aims to add bandwidth management capabilities
: to the IP protocol architecture. An alternative approach replaces IP
: with a different internetwork protocol, STII, in situations where
: bandwidth management is required. STII has been around for a while,
: and has a number of implementations, although it is not widely
: deployed.

Explain a little more about STII.  Is it lighter weight IP?
What does it claim to have that IP doesn't have?  


: The IETF multimedia conferencing control wg ("MMUSIC") is looking at a
: number of issues relating to conferencing applications and common
: sesson-control standards.
 
: In addition to these specific working groups, a number of activites
: underway in the IETF, including advanced routing architectures (to
: support choosing routes based on quality of service needs, and to
: support wide-area multicast services), and the next-generation IP
: design effort, will have an impact on supporting these applications.

Explain the issues regarding next generation IP?  Is easier IP
switching an issues?  How about a VCI style address option?

: A number of research and advanced development projects are
: demonstrating the possibilities of this technology today. The MBONE is
: a large (800+ network, 20+ countries) virtual network embedded in the
: internet which supports multicast distribution of audio and video
: programs, among other things.  

Great, what form of the various directions mentioned above are 
they using.  Is this being demoed with standard IP using the 
RSVP mechanism?

Some applications in wide use are the
: "vat" audio tool, the "sd" session manager, and the "wb" shared
: whiteboard, all from Lawrence Berkeley Labs; the "nv" video
: conferencing tool from Xerox PARC, and the "ivs" video tool from
: INRIA. (There are a number of other equally interesting projects
: happening, and I certainly don't mean to single these out as the only
: ones of merit...). A key point of all of these applications is their
: focus on group communication as well as A-to-B communication. A lot of
: effort is going into making sure the whole thing scales well.


: It is important to understand what will be standardized and what won't
: be. The intent is to standardize only those things which must be
: agreed on globally, while leaving substantial flexibility in matters
: of local concern, such as the scheduling algorithm used in a specific
: router or network. This is because there is no one right answer for
: all conditions, and because both applications and technology will
: continue to improve over time.


:    Along with this, where are the ethernet vendors regarding a
:    bandwidth management scheme for ethernet?  If completed, how
:    will an ethernet bandwidth management scheme be compatible
:    with an enterprise wide TCP bandwidth management scheme?
 
: First, experiments over several years have demonstrated that b/w
: management is not always required at the local ethernet level.

You mean if someone makes a long file transfer, then my phone
call isn't bashed?  Don't we have to at least limit packet sizes?
Is a corporation going to place critical white board activities
in an environment where long file transfers shake thing up?

: In
: situations where it is, a couple of approaches are possible, depending
: on whether you imagine that all nodes on the ethernet are cooperating
: or not. An alternative to this is to put b/w management in a switching
: hub, and use the hub-host connections as point-to-point links. This
: alternative is simple to deploy and can give excellent performance.

Good introduction to the next question.  ISO Ethernet is one solution
gaining some adherents.  Is this the solution from National 
Semiconductor with Apple support?

Does anyone know how Intel is going to meet resource reservation
for their Indeo conferencing over ethernet?

Ethernet management which assume cooperating nodes yield one or two
approaches.  A simple one says that each node simply observes a
period time period in which only reserved activity takes place.  Who
is working on solutions like this?

: The internet architectural work will use the bandwidth management
: capabilities of lower-level nets where it exists.

And I assume that SNMP management will cross all layers, allowing
some semblence of uniform monitoring, if not control.

 To handle a broader
: spectrum of nets, one might assume that a b/w-managed internet path
: will have a "reliability level" associated with it, as well as the
: more traditional parameters. This matches well with the requirements
: of perceptual applications. For example, you might put up with an
: occasional crackle if you are just chatting with a group of friends,
: but would demand excellent service if you were giving a remote piano
: recital. In the first case, an uncontrolled ethernet would be OK. In
: the second, it might not be. So the application should have a knob,
: and the network should do path choice and bandwidth management to
: provide whatever service the application needs.
 
: 			regards,
: 			  -john
 
: John Wroclawski
: jtw@lcs.mit.edu

-----------[000089][next][prev][last][first]----------------------------------------------------
Date:      5 Jun 1994 16:40:39 GMT
From:      km@mathcs.emory.edu (Ken Mandelberg)
To:        comp.protocols.tcp-ip
Subject:   TCP over ATM reading list?

Does anyone have a bibliography for TCP over ATM?


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



-----------[000090][next][prev][last][first]----------------------------------------------------
Date:      6 Jun 1994 01:42:59 -0500
From:      greg@gagme.wwa.com (Gregory Gulik)
To:        comp.protocols.tcp-ip
Subject:   bootp and SLIP?


A customer inquired about using bootp to receive his nodes
parameters (hostname, netmask, etc..) when dialing in on
a SLIP connection.

Is this possible?
I thought that bootp needed a hardware address to work.

Can someone clear this up or show how it can be done?

I've tried several configurations, but nothing works.  I know
bootp works since we use it with our Xterminals.

-- 
Gregory Gulik            greg@wwa.com            http://gagme.wwa.com/~greg
Computing Engineers, Inc.                        Home of WorldWide Access (SM)
Data: +1 312 282 8605    +1 708 367 1871         Voice: +1 708 367 1870
Info: info@wwa.com                               Support: support@wwa.com

-----------[000091][next][prev][last][first]----------------------------------------------------
Date:      5 Jun 94 23:46:22
From:      billw@glare.cisco.com (William )
To:        comp.protocols.tcp-ip,comp.security.unix
Subject:   Re: Is IP source routing a bad idea?

A correct and bug-free implementation of IP source routing allows
any host on the internet to masquerade as any IP address that it would
like to, thus breaking any access control based on the source IP address
(eg, most of the unix r-utilities.)

Exactly how to do this is left as an excercise to the reader, but the
fundamental problem is that the source route allows the packet to travel
"through" possibly suspect IP entities that have not had the slightest
amount of authentication as "trustworthy" routers applied to them.

BillW
cisco

-----------[000092][next][prev][last][first]----------------------------------------------------
Date:      6 Jun 94 00:47:36
From:      billw@glare.cisco.com (William )
To:        comp.protocols.tcp-ip
Subject:   Re: bootp and SLIP?

    A customer inquired about using bootp to receive his nodes
    parameters (hostname, netmask, etc..) when dialing in on
    a SLIP connection.

    Is this possible?
    I thought that bootp needed a hardware address to work.

Some SLIP servers can support this by using the particular async port to
"imply" a hardware address.  (eg, you only really need a HW address to
differeniate between hosts on a broadcast network like ethernet.)  This
does pretty much require that the bootp server be implemented on the slip
server itself, rather than have the slip server forward the bootp request
to some other server on the net.

BillW
cisco


-----------[000093][next][prev][last][first]----------------------------------------------------
Date:      5 Jun 1994 17:16:50 +0200
From:      jor@krynn.solace.mh.se (Joakim Rastberg)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc,vmsnet.networks.tcp-ip.misc
Subject:   Put/Get files on PC (in a TSR, under DOS, while running another program


Goddag

Does anyone have a Terminate-and-Stay-Resident (TSR) version of ftpd
for any standard TCPIP-stack under DOS?

I need to put/get/delete files on a PC that is simultaneously running
a data acquisition program.

No, I cannot use Windows in this case, the application is Rational DOS4GW
32bit extended (methinx Windows don't allow that:-)

I have found some ftpd's under DOS (such as the one in PCTCP) but they
don't allow another application to run at the same time.

TCPIP stack on NDIS (using ISDN but thats beside the point).

It is ok for the data acquisition programs to supended during a ftp
session, I dont play to put/get any files during critical measures.
SHARE is ok too...

If anyone answers I will summarize.

Joakim Rastberg
-------
Joakim (jor@solace.mh.se) Rastberg, Solace Computer Society, Sundsvall, Sweden
Important note: This posting was a shareware. If you read it more than once,
send me all your money. Then go and see a psychologist.  Or kill me.

-----------[000094][next][prev][last][first]----------------------------------------------------
Date:      Sun, 5 Jun 1994 21:54:07 GMT
From:      davido@flagstaff.Princeton.EDU (David Lawrence Oppenheimer)
To:        comp.unix.admin,comp.unix.misc,comp.unix.questions,comp.sys.sun.admin,comp.sys.sun.apps,comp.sys.sun.misc,comp.protocols.tcp-ip
Subject:   Need cslip help!

I am having a very difficult time trying to get cslip to work on my Sun SS5. (I
am using the version currently on the math.berkeley.edu FTP site.)

Pertinent information: I am using a Sun SS5 with SunOS 4.1.3_U1. I am using a
Hayes modem but am having no trouble communicating with the modem (i.e. regular
tip dialout works). I do not have Ethernet connected to my system, just the
modem through Serial Port A. I have created /dev/cua0 as specified in the cslip
instructions. I have installed the cslip loadable kernel module for sun4m. I
have modified the cslip login script to suit the SLIP terminal server I dial
into. 

My problem: I run on_all_times as root (after modifying the /etc/remote,
/etc/phones, slip.hosts, slip.login, and slip.logout files appropriately for my
site) and get "login failed: exit status 2 from /etc/slip.login"

Then I decided to try the commands by hand. First I did

ifconfig sl0 my_ip_address terminal_server_ip_address netmask correct_netmask

but I get

ifconfig: ioctl (SIOCSIFADDR): Invalid argument

I have no idea what the invalid argument is here--this fits the argument
prototype given in the man page!

Sometimes (and I don't know how) the ifconfig gets configured right, i.e. when
I do an ifconfig -a I get the correct information. I am always able to get the
route -n add default default_ip_address to work.

On the rare occassions when I am able to get the ifconfig to register, when I
run sliplogin davido (davido is the name in my slip.hosts file) nothing 
happens.

I must be missing something here--I am not sure what else I am supposed to do.
When I try ping, the machine goes for the Ethernet port (I have no ethernet
connection) so I get a bunch of le0 errors on the console. When I try "ifconfig
le0 down" the whole machine crashes. :-(

I assume that the "exit code 2" from /etc/slip.login is a result of ifconfig
failing with the SIOCSIFADDR error. But perhaps someone could explain why I get
the SIOCSIFADDR error? [The man page said this means I gave a bad interface
address.] I have my machine listed in /etc/hosts as well as in the NIS database
(I am running my machine as an NIS server) but this really shouldn't matter
since I am using IP addresses and not hostnames.

Any help would be appreciated! Please respond by email; I will summarize
the answers in the newsgroups to which I am posting this message.

Thanks,


David Oppenheimer
davido@phoenix.Princeton.EDU


-----------[000095][next][prev][last][first]----------------------------------------------------
Date:      Sun, 5 Jun 1994 22:27:53 GMT
From:      rturner@qms.com (Randy Turner)
To:        comp.protocols.tcp-ip
Subject:   BSD-style socketlib for MacTCP


Does anyone know if there is a BSD-style socket library interface for MacTCP? or, if not,
is Apple working on one?

Thanks!

Randy

---


/* Rt */




-----------[000096][next][prev][last][first]----------------------------------------------------
Date:      Mon, 6 Jun 1994 02:19:31 GMT
From:      ashok@biochemistry.cwru.edu (Ashok Aiyar)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc,vmsnet.networks.tcp-ip.misc
Subject:   Re: Put/Get files on PC (in a TSR, under DOS, while running another program

In article <jor.770829337@krynn> jor@krynn.solace.mh.se (Joakim Rastberg) writes:


>Goddag
 
>Does anyone have a Terminate-and-Stay-Resident (TSR) version of ftpd
>for any standard TCPIP-stack under DOS?
 
>I need to put/get/delete files on a PC that is simultaneously running
>a data acquisition program.

I know of a TSR version of KA9Q that has an FTP server, and supports
packet drivers.  This was compiled by Jonathan Bloom sometime around
1990-'91.  It loads as a large (130KB) TSR, and works quite well.

You can pick it using the following URL.
file://shasta.scl.cwru.edu/dos/tcpip/ka9q/tsrnet.arc

Later,
Ashok
--
Ashok Aiyar                        Mail: ashok@biochemistry.cwru.edu
Department of Biochemistry                       Tel: (216) 368-3300
CWRU School of Medicine, Cleveland, Ohio         Fax: (216) 368-4544
MIME Enclosures OK

-----------[000097][next][prev][last][first]----------------------------------------------------
Date:      6 Jun 1994 10:51:28 -0500
From:      dpm@bga.com (David P. Maynard)
To:        comp.protocols.tcp-ip
Subject:   Re: bootp and SLIP?


John Hascall <john@iastate.edu> wrote:
>William  <billw@glare.cisco.com> wrote:
>}    A customer inquired about using bootp to receive his nodes
>}    parameters (hostname, netmask, etc..) when dialing in on
>}    a SLIP connection.
>}
>}    Is this possible?
>}    I thought that bootp needed a hardware address to work.
>}
>}Some SLIP servers can support this by using the particular async port to
>}"imply" a hardware address.  (eg, you only really need a HW address to
>}differeniate between hosts on a broadcast network like ethernet.)  This
>}does pretty much require that the bootp server be implemented on the slip
>}server itself, rather than have the slip server forward the bootp request
>}to some other server on the net.

I implemented something like this under cslip-2.7, BSD/386, and
NetBSD-0.9.  The solution is something between a hack and a feature,
but it is used daily by a few hundred SLIP clients.

The SLIP driver watches for inbound BOOTP requests.  When it sees one,
it "stuffs" the IP address of the client into the appropriate fields
(ciaddr & yiaddr).  There is the additional overhead of checking each
inbound packet, but I tried to keep it to a minimum.

The approach violates the protocol layering, but a more correctly
layered solution would have involved adding ioctls in other parts of
the kernel.  I reasoned that since I was making up for a deficiency in
SLIP (lack of address negotiation), it was better to isolate the cruft
to the SLIP code itself.

-dpm

P.S.  You also need to keep the MTU higher than the BOOTP packet size
since most BOOTP clients won't do fragment reassembly.

-- 
 David P. Maynard, Carnegie Mellon University & Dependable Solutions
 USMail: 14312 Richard Walker Blvd, Austin, TX 78728-6862
 EMail: dpm@depend.com,  Tel: +1 512 251 8122,  Fax: +1 512 251 8308
--

-----------[000098][next][prev][last][first]----------------------------------------------------
Date:      Mon, 6 Jun 1994 07:33:37
From:      CLAY@ucssun1.sdsu.edu (Robert D. Clay)
To:        comp.protocols.misc,comp.protocols.ppp,comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject:   Problems with Trumpet Winsock, SLIP ans UDP

I have been successful in getting Trumpet Winsock to run in internal Slip mode
with one exception:  I can only access hosts by IP number.  When I try by
name, I get the following error dump.  This has me stumped.  I am unable to
determine why I am getting this IP checksum error.  At first I thought I had
my modem configured wrong, and that it was not properly doing error
correction.  I have ruled out this possibility.  I am using LAPM.  Do you
have any ideas?  The only clue I have is that TCP works, and UDP does not.

If you can help. please reply via e-mail.  Thanks.

Thanks.

Bob Clay
------------------------------ 
WSAStartup(257,1E87:4198)
gethostbyname ucssun1
id=0001 fl=0100 ucssun1.sdsu.edu 0001 0001
Ether 00:00:00:00:00:00->00:00:00:00:00:00
IP 130.191.2.30   ->130.191.224.2   len 62 prot 17
UDP 1024->53 34
00 01 01 00 00 01 00 00 00 00 00 00 07 75 63 73 
73 75 6E 31 04 73 64 73 75 03 65 64 75 00 00 01 
00 01 
IP header checksum error
IP header checksum error
id=0001 fl=0100 ucssun1.sdsu.edu 0001 0001
Ether 00:00:00:00:00:00->00:00:00:00:00:00
IP 130.191.2.30   ->130.191.224.2   len 62 prot 17
UDP 1024->53 34
00 01 01 00 00 01 00 00 00 00 00 00 07 75 63 73 
73 75 6E 31 04 73 64 73 75 03 65 64 75 00 00 01 
00 01 
IP header checksum error
id=0001 fl=0100 ucssun1.sdsu.edu 0001 0001
Ether 00:00:00:00:00:00->00:00:00:00:00:00
IP 130.191.2.30   ->130.191.224.2   len 62 prot 17
UDP 1024->53 34
00 01 01 00 00 01 00 00 00 00 00 00 07 75 63 73 
73 75 6E 31 04 73 64 73 75 03 65 64 75 00 00 01 
00 01 
IP header checksum error

(This continues for quite awhile)

Robert D. Clay                    San Diego State University
Data Communications Manager       Telecommunications and Network Services
619/594-7309 (Voice)              San Diego, CA 92182	
619/594-2912 (FAX)                Robert.Clay@sdsu.edu (Internet)

-----------[000099][next][prev][last][first]----------------------------------------------------
Date:      Mon, 6 Jun 1994 03:29:35 GMT
From:      venu@voodoo.utcc.utk.edu (Nair Venugopal)
To:        comp.protocols.tcp-ip,comp.security.unix
Subject:   Is IP source routing a bad idea?

Hi,

Apologies, if these are newbie questions.

IP level options are disallowed in the post BSD 4.3 rlogin/rsh daemons and 
in the tcp wrappers package, 


The tcp wrapper man page says that 
     "tcpd disables source-routing socket  options  on
     every  connection that it deals with. This will take care of
     most attacks from hosts that pretend to have an address that
     belongs  to someone elses network."

1) How can rlogind or rshd be compromised if the source routing is enabled?
    (If some one tries to spoof a host on another network, wouldnt the
     intermediate routers reject the spoofed packets.)

2) Is there any situation, other than trouble shooting, where 
   the source routing option will be of use?

3) Are the rlogind/rshd daemons in SunOS 4.1.x susceptible to source
   routing attacks?

4) Is there any patch for fixing the  getsockopt() system call bug in
   SunOS 4.1.x ?


Thanks

Venu

-----------[000100][next][prev][last][first]----------------------------------------------------
Date:      6 Jun 1994 14:17:58 -0400
From:      mharrop@interlog.com (Matt Harrop)
To:        comp.protocols.tcp-ip
Subject:   Multi-homed host


I am currently moving from one provider to another.  During the move, I would
like to maintain my primary nameserver, so I need to keep at least one IP
address the same.  My current IP address is 199.0.20.47.  This is from my
current providers network.  I'd like to keep that address (my nameserver
is at that address) _and_ put the same machine on an ethernet that is routed
to my new provider.  The one machine would then have two IP addresses, each
on networks that connect to different providers.

I can then have the NIC transfer my nameserver to the new address and once
that's done, be rid of the old IP address.  I've never delt with a host on 
two networks; will this cause a problem?  If so, how can I pull of this
switch?

Cheers,
-- 
Matt Harrop                                       mharrop@interlog.com
InterLog Internet Services   voice (416) 537-7453   fax (416) 532-5015
Online   Publishing,   Marketing,   and   Support  on   the   Internet
Coming in July -- Lowest Cost Dial-Up Internet Connectivity in Toronto

-----------[000101][next][prev][last][first]----------------------------------------------------
Date:      6 Jun 1994 08:10:59 GMT
From:      casper@fwi.uva.nl (Casper H.S. Dik)
To:        comp.protocols.tcp-ip,comp.security.unix
Subject:   Re: Is IP source routing a bad idea?

venu@voodoo.utcc.utk.edu (Nair Venugopal) writes:

>Apologies, if these are newbie questions.
 
>IP level options are disallowed in the post BSD 4.3 rlogin/rsh daemons and 
>in the tcp wrappers package, 


>The tcp wrapper man page says that 
>     "tcpd disables source-routing socket  options  on
>     every  connection that it deals with. This will take care of
>     most attacks from hosts that pretend to have an address that
>     belongs  to someone elses network."
 
>1) How can rlogind or rshd be compromised if the source routing is enabled?
>    (If some one tries to spoof a host on another network, wouldnt the
>     intermediate routers reject the spoofed packets.)

No, because the packets are source-routed.  They will only be
rejected if the router is configured to reject source routed
packets or to reject packets coming from anotehr interface than
expected.  (I.e., if you have an interface with a subnet associated,
you should reject all packets coming into the router from any
of the other interfaces that have a source address on that one interface.)

>2) Is there any situation, other than trouble shooting, where 
>   the source routing option will be of use?

Not many, though as work-around for temporary routing failures, it can
be useful.  But even that is mostly under the heading of trouble
shooting.

>3) Are the rlogind/rshd daemons in SunOS 4.1.x susceptible to source
>   routing attacks?

As far as I could determine, SunOS 4.1.x machines with only one ethernet
interface are not susceptible to a source routing attack.
It think this is because the source routed code requires that a source
routed packet leaves another interface than the one it came in on.
Anyway, I couldn't get any of our SunOS machines react to source routed
packets.  I could get our Solaris 2.x machines react to source routed
packets.

I could be wrong about SunOS, though, so switching of source routing through
tcpd is better.

>4) Is there any patch for fixing the  getsockopt() system call bug in
>   SunOS 4.1.x ?

Yes, patch 100804-03.

Casper

-----------[000102][next][prev][last][first]----------------------------------------------------
Date:      6 Jun 94 15:53:18
From:      billw@glare.cisco.com (William )
To:        comp.protocols.tcp-ip
Subject:   Re: Telnet response time after packet drop?

Will a telnet connection ever establish the circumstances necessary to get
"quick retransmit" to work?  (This would be implementation specific, I
think.  "quick retransmit" would normally be of value in a stead-state
connection where the ACK are clocking out new data.  A typical telnet
connection will never reach steady state, effectively getting stuck at
the beginning of "slow start" and staying there.)

BillW


-----------[000103][next][prev][last][first]----------------------------------------------------
Date:      6 Jun 1994 11:33:57 GMT
From:      jfguilla@imag.fr (J-F Guillaud)
To:        comp.protocols.tcp-ip
Subject:   No archive site for this group???


        Last week, I ask for the name of the archive site for this group. 
The location is not in the FAQ.
        I haven't received any answer. Could someone please reply.

Thank you in advance

Jean-Francois


-----------[000104][next][prev][last][first]----------------------------------------------------
Date:      Mon, 6 Jun 1994 11:42:53 GMT
From:      rstevens@noao.edu (W. Richard Stevens)
To:        comp.protocols.tcp-ip
Subject:   Re: Telnet response time after packet drop?

> Back to the issue.	My understanding of TCP retransmissions has now been
> enhanced as follows:
>  
> 1) Sender measures round trip response time
>  
> More?
> 2) Sender setsretransmit timeout (RTO) to	2x RTT (or more?)

Actually RTO = srtt + 4*rttvar, where srtt is the smoothed RTT
estimate and rttvar is the smoothed mean deviation estimator.
  
> 3) RTO varies depending on future RTT

And mean deviation.  Adding in the deviation is critical for accurate
estimates on WANs.  Check out the figure in Jacobson's 1988 paper for
a comparison of this versus the original RFC 793 technique (which
just used the mean).

> 4) Sender sends packet and sets retransmission timer
>  
> 5) Sender continues to send packets as long as there is available
> 	window and RTO seconds have not expired, unless:
>  
> 6) However, if:
> 	a) RTO seconds expire before receiving ACK
>  
> 	-or-
>  
> 	b) Three (may vary?) duplicate ACKs received from receiver

The magic number 3 is configurable (a kernel variable), but I wouldn't
recommend changing unless you have a specific reason for doing so.

> 	then:	INITIATE RETRANSMIT
>  
> Is this more accurate?

Yes.  Again, the reason for the "fast retransmit" (3 dup ACKs) is
to initiate a retransmission *before* waiting for the retransmission
timer to expire, as you'll often get the 3 dup ACKs long before the
timer expires.

	Rich Stevens

-----------[000105][next][prev][last][first]----------------------------------------------------
Date:      6 Jun 1994 12:15:27 GMT
From:      barryf@iol.ie (Barry Flanagan)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc,vmsnet.networks.tcp-ip.misc
Subject:   Re: Put/Get files on PC (in a TSR, under DOS, while running another program

Joakim Rastberg (jor@krynn.solace.mh.se) wrote:

: Goddag
 
: Does anyone have a Terminate-and-Stay-Resident (TSR) version of ftpd
: for any standard TCPIP-stack under DOS?
 
: I need to put/get/delete files on a PC that is simultaneously running
: a data acquisition program.
 
: No, I cannot use Windows in this case, the application is Rational DOS4GW
: 32bit extended (methinx Windows don't allow that:-)


DESQView would handle the background FTP, though I am not sure about the 32bit
extended.

-Barry



--
   *********************************************************************** 
              IRELAND ON-LINE, West Wing, Furbo, Galway, Ireland
                 Tel: +353 (0)91 92727 : Fax: +353 (0)91 92726
            IOL Internet Services - Dublin: 671-5185 : Galway 92711

-----------[000106][next][prev][last][first]----------------------------------------------------
Date:      Mon, 6 Jun 1994 12:52:27 GMT
From:      frontline@cix.compulink.co.uk ("Frontline Distributi")
To:        comp.protocols.tcp-ip
Subject:   FTPd Variants for SunOS

Can someone please recommend an FTPd variant for SunOS v4.11 ?

I am making do with the one as supplied by Sun at the moment and 
although I have seen many alternatives, would like to know which are the 
better ones.

Facilities I would like include 

        * detailed logging of FTPs
        * reverse DNS "authentication"
        * messages per CWD (.CWDmessage.TXT, etc)

Cheers ... Chris Miles

-------------------------------------------------------------------
Chris Miles                 | EMail: cmiles@frontline.co.uk
Frontline Tech Supp Centre  |        cmiles@cix.compulink.co.uk
Hampshire House, Wade Road  | CIS  : 100065,621
Basingstoke, Hampshire      | Tel  : +44 (0)256 847220
ENGLAND, RG24 8PL           | Fax  : +44 (0)256 847900
-------------------------------------------------------------------


-----------[000107][next][prev][last][first]----------------------------------------------------
Date:      Mon, 6 Jun 94 21:29:00 -0500
From:      baldwinl@delphi.com
To:        comp.protocols.tcp-ip
Subject:   Re: Telnet response time after packet drop?

William <billw@glare.cisco.com> writes:
 
>think.  "quick retransmit" would normally be of value in a stead-state
>connection where the ACK are clocking out new data.  A typical telnet
 
In this context, what do you mean by steady state and "clocking out new data"?
 
 
>connection where the ACK are clocking out new data.  A typical telnet
>connection will never reach steady state, effectively getting stuck at
>the beginning of "slow start" and staying there.)
 
This almost seems like what I'm seeing.  The following is a summary of a client
PC with an established telnet session to a Sun Sparc.  Both are on a
local 10Mbps token ring.
 
1) I hold down "j" key on Pc
 
2) "j" gets sent to Sun and immediately echoed back.  Round trip response
is about 50ms (10ms of transit time and 40ms of delayed ACK by the PC)
 
3) About once every minute, Sun receives "j" packet into its adapter
but does not pass it to the higher layer applications.  Thus, TCP on the
Sun does NOT receive the packet--it therefore does NOT send an ACK.
 
4) The client PC eventually sends the dropped packet, but it takes 1400ms
fromthe time it originally sent the packet.
 
On a local token ring, how could the PC have ever arrived at a retransmit
timeout value of 1400ms?  Is it because fast retransmit does not function
for telnet session, or is it simply that the PC client is not following
protocol?

-----------[000108][next][prev][last][first]----------------------------------------------------
Date:      6 Jun 1994 13:50:32 GMT
From:      john@iastate.edu (John Hascall)
To:        comp.protocols.tcp-ip
Subject:   Re: bootp and SLIP?

In article <BILLW.94Jun6004736@glare.cisco.com>,
William  <billw@glare.cisco.com> wrote:
}    A customer inquired about using bootp to receive his nodes
}    parameters (hostname, netmask, etc..) when dialing in on
}    a SLIP connection.
}
}    Is this possible?
}    I thought that bootp needed a hardware address to work.
}
}Some SLIP servers can support this by using the particular async port to
}"imply" a hardware address.  (eg, you only really need a HW address to
}differeniate between hosts on a broadcast network like ethernet.)  This
}does pretty much require that the bootp server be implemented on the slip
}server itself, rather than have the slip server forward the bootp request
}to some other server on the net.

   If the host already knows its IP address (say, either hardwired or
   obtained from the SLIP login script), then many bootp servers can
   answer its request by looking it up via its IP address (ignoring
   the hardware address field).  The CMU bootp server does this (as
   I recall).

John

-- 
John Hascall                   ``An ill-chosen word is the fool's messenger.''
Systems Software Engineer
Project Vincent
Iowa State University Computation Center  +  Ames, IA  50011  +  515/294-9551

-----------[000109][next][prev][last][first]----------------------------------------------------
Date:      6 Jun 1994 15:00:55 GMT
From:      kwalters@PBS.ORG (Ken Walters)
To:        comp.protocols.tcp-ip
Subject:   Re: hp-ux startup files and hp-vue

I may be able to help you concerning question #1.  Forgive me if you
have already done this.

Make sure you .profile file has the following line in it:

ENV=$HOME/.kshrc
export ENV

P.S. There is a comp.sys.hp.hpux news group that might provide you with
more responses.

------------------------------------------------------------
Ken Walters
kwalters@pbs.org

Made possible by the generous support of viewers like you...
------------------------------------------------------------

-----------[000110][next][prev][last][first]----------------------------------------------------
Date:      Mon, 6 Jun 1994 15:44:40 GMT
From:      braun@wc.novell.com (Karl Tunnell-Braun)
To:        comp.protocols.tcp-ip
Subject:   Re: Wierd netork behaviour

In article <2sgm37$jn5@hq.hq.af.mil> rwoodard@pafosu2 (Robert Woodard) writes:
>Mathias Koerber (mathias@solomon.technet.sg) wrote:
>: Hi there.
>: I am at my wit's end.
 
>: I have a local network (Thin Ethernet) with

Ahh.  Enough said :).


From your problem description (see original article) I'd say you have a bad
terminator somewhere.  Take your Ohm meter and start a binary tree test down
the wire.  You will probably find either a problem in the cable above the
IBM machines, or a bad terminator at either the first IBM machine, or the
host above it.

Good luck.

--
Karl Tunnell-Braun   408/577-7301			braun@novell.com
LAN Engineer	 					Novell IS Lan Eng.
"That which does not kill us, makes us stronger" 		- Nietzche

-----------[000111][next][prev][last][first]----------------------------------------------------
Date:      Mon, 06 Jun 1994 16:28:44 GMT
From:      garyrich@qdeck.com (Gary Rich)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc,vmsnet.networks.tcp-ip.misc
Subject:   Re: Put/Get files on PC (in a TSR, under DOS, while running another program

In article <2sv40v$6v@barnacle.iol.ie> barryf@iol.ie (Barry Flanagan) writes:
>Joakim Rastberg (jor@krynn.solace.mh.se) wrote:
>
>: Goddag
 
>: Does anyone have a Terminate-and-Stay-Resident (TSR) version of ftpd
>: for any standard TCPIP-stack under DOS?
 
>: I need to put/get/delete files on a PC that is simultaneously running
>: a data acquisition program.
 
>: No, I cannot use Windows in this case, the application is Rational DOS4GW
>: 32bit extended (methinx Windows don't allow that:-)
>
>
>DESQView would handle the background FTP, though I am not sure about the 32bit
>extended.

Should be no problem at all.  The Rational DOS4GW is a VCPI based DOS extender
that's *very* well known to us.  I use it and apps that use it in DV and DVX
constantly.  If you set this up with DESQview rather than DESQview/X you will
probably want to contact us (support@qdeck.com) about virtualizing 
whatever network transport you are using.  If you use DESQview/X then you 
can just use the included TCP/IP stack and have your ftp daemon always 
running.

FWIW, the DOS4GW app should run in WIN/S, but not in WIN/3 unless it can use
DPMI memory instead of VCPI.

+--------------------------------------------------------------------------+
|   Quarterdeck Office Systems                    ____________________/_   |
|         Gary Rich				  _________________///__\  |
|  _____________________________________________  ______________/////___\  |
|   Anonymous FTP site = qdeck.com                ___________///////____\  |
|          ---For---          ---Write to---      ________/////////_____\  |
|    Pricing/Ordering info :  info@qdeck.com      _____///////////______\  |
|     Technical Questions  : support@qdeck.com    __/////////////_______\  |
|<A HREF="http://www.qdeck.com/">Our home page</A>\\\\\\\\\\\\\\\\\\\\\\\  |
+--------------------------------------------------------------------------+
You all know that Quarterdeck isn't responsible for my ramblings, right?


-----------[000112][next][prev][last][first]----------------------------------------------------
Date:      6 Jun 1994 16:28:57 GMT
From:      john@iastate.edu (John Hascall)
To:        comp.protocols.misc,comp.protocols.ppp,comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject:   Re: Problems with Trumpet Winsock, SLIP ans UDP

In article <CLAY.12.00078FAA@ucssun1.sdsu.edu>,
Robert D. Clay <CLAY@ucssun1.sdsu.edu> wrote:
}I have been successful in getting Trumpet Winsock to run in internal Slip mode
}with one exception:  I can only access hosts by IP number.  When I try by
}name, I get the following error dump.  This has me stumped.  I am unable to
}determine why I am getting this IP checksum error.  At first I thought I had
}my modem configured wrong, and that it was not properly doing error
}correction.  I have ruled out this possibility.  I am using LAPM.  Do you
}have any ideas?  The only clue I have is that TCP works, and UDP does not.
}
}If you can help. please reply via e-mail.  Thanks.
}
}Thanks.
}
}Bob Clay
}------------------------------ 
}WSAStartup(257,1E87:4198)
}gethostbyname ucssun1
}id=0001 fl=0100 ucssun1.sdsu.edu 0001 0001
}Ether 00:00:00:00:00:00->00:00:00:00:00:00
}IP 130.191.2.30   ->130.191.224.2   len 62 prot 17
}UDP 1024->53 34
}00 01 01 00 00 01 00 00 00 00 00 00 07 75 63 73 
}73 75 6E 31 04 73 64 73 75 03 65 64 75 00 00 01 
}00 01 
}IP header checksum error
}IP header checksum error
}id=0001 fl=0100 ucssun1.sdsu.edu 0001 0001
}Ether 00:00:00:00:00:00->00:00:00:00:00:00
}IP 130.191.2.30   ->130.191.224.2   len 62 prot 17
}UDP 1024->53 34
}00 01 01 00 00 01 00 00 00 00 00 00 07 75 63 73 
}73 75 6E 31 04 73 64 73 75 03 65 64 75 00 00 01 
}00 01 
}IP header checksum error
}id=0001 fl=0100 ucssun1.sdsu.edu 0001 0001
}Ether 00:00:00:00:00:00->00:00:00:00:00:00
}IP 130.191.2.30   ->130.191.224.2   len 62 prot 17
}UDP 1024->53 34
}00 01 01 00 00 01 00 00 00 00 00 00 07 75 63 73 
}73 75 6E 31 04 73 64 73 75 03 65 64 75 00 00 01 
}00 01 
}IP header checksum error
}
}(This continues for quite awhile)
}
}Robert D. Clay                    San Diego State University
}Data Communications Manager       Telecommunications and Network Services
}619/594-7309 (Voice)              San Diego, CA 92182	
}619/594-2912 (FAX)                Robert.Clay@sdsu.edu (Internet)


-- 
John Hascall                   ``An ill-chosen word is the fool's messenger.''
Systems Software Engineer
Project Vincent
Iowa State University Computation Center  +  Ames, IA  50011  +  515/294-9551

-----------[000113][next][prev][last][first]----------------------------------------------------
Date:      Mon, 6 Jun 1994 17:04:39 GMT
From:      gregc@stealth.ml.com (Greg Caldwell)
To:        comp.protocols.tcp-ip
Subject:   Help with SunNet Manager beeper facility

Question
1) Is there a command line option to run SunNet Manager
2) Can I bring up a second invocation if one gui is already running?
3) I have a problem with multiple beeps when my system(s) reboot.

I appreciate any expierences you have had in this area.



---
                                  ####
				 (o  o)
+--------------------------oooO---(__)---Oooo-----------------------------+
|                                                                         |
| Gregory Caldwell,Systems Architect  INTERNET : gregc@ml.com	          | 
| Security Pricing Systems 						  |
| Merrill Lynch 		      TELEPHONE: (212)449-0220            |
| New York, York 10281-1309	      FAX : (212)449-8612                 |
+-------------------------------------------------------------------------+
 	                        ||    ||
			       (__)  (__)


-----------[000114][next][prev][last][first]----------------------------------------------------
Date:      06 Jun 1994 19:43:24 GMT
From:      siedelbe@steam.ucar.edu (Gregory M. Siedelberg)
To:        comp.networks,comp.org.ieee,comp.protocols.tcp-ip,comp.dcom.lans.ethernet
Subject:   mac layer addresses



Hi all,

Just a question on a topic that probably has been beaten to death in the past.
Someone is trying to bridge two nets together using a bridge that is also
connected to an fddi ring.  Some of the computers in question have two ethernet
interfaces(Suns).  When each one of the nets is connected into this bridge,
it complains that it sees the same MAC layer address on two different ports,
no surprise.  When I tell this person that this should not be done, ie., 
bridging two separate nets onto the same net is not proper, I get a lot of, 
"who says" and "show me where it says that" replies.  Sun does provide a 
feature that one can arbitrarily change the MAC address, but only provides
one address per machine and that is burned into the sun id prom.  So these are
the questions that I hope some of you will have the answeres to.

1.  what is the publication that sets out the rules why tcp-ip networks can
have only logical net per physical net, if that is indeed true?

2.  where is it spelled out on how to use bridges and MAC layer addresses?  I
suspect that this is probably in 802.1, but don't have a copy yet to look it
up, but any other references would be appreciated.

3.  who owns mac addresses?  who is the authorized grantor of mac layer
addresses?  I suspect that this is the IEEE.  If someone were to just invent
an address and use it are they violating any patent/trademark/copyrights/
license issues.  Yes, I am trying to be technical here.  I like to look at
the worst case and go from there.


What is happening here is that we are trying to put together a network
correctly and not use quick fixes like having to set all the second enet
interfaces to different mac layer addresses on all machines that span two
networks.  I am thinking now that a router should have been puchased instead of
a bridge.


Thanks so much to you-all for any thing you might send to reference this.

see ya,


mike

-----------[000115][next][prev][last][first]----------------------------------------------------
Date:      6 Jun 1994 20:58:17 GMT
From:      dauns@andrews.edu (Frank Dauns)
To:        comp.protocols.tcp-ip
Subject:   pcnfsd for SCO3.2V4.2


I would like to get a PCNFS daemon for SCO3.2V4.2.  Unfortunately this
machine doesn't have the development set so doesn't have a compiler.

Are there any FTP sites where I can obtain this binary ?

Thanks in advance.

-- 
Frank Dauns                               Programmer/Support 
dauns@andrews.edu                         Lake Michigan College 

-----------[000116][next][prev][last][first]----------------------------------------------------
Date:      6 Jun 94 21:03:33 GMT
From:      chrisc@fir.canberra.edu.au (Chris Chlap)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP over ATM reading list?

In <2ssv67$j2v@emory.mathcs.emory.edu> km@mathcs.emory.edu (Ken Mandelberg) writes:

>Does anyone have a bibliography for TCP over ATM?
You might like to try gopher to cell-relay.indiana.edu. They have heaps
of stuff there.
Also, gwen.cs.purdue.edu in /pub/atm have a collection of ATM documents.

Chris Chlap
University of Canberra, Australia.


-----------[000117][next][prev][last][first]----------------------------------------------------
Date:      6 Jun 94 21:08:23 GMT
From:      chrisc@fir.canberra.edu.au (Chris Chlap)
To:        comp.protocols.tcp-ip
Subject:   Re: bootp and SLIP?

In <2sughj$imn@gagme.wwa.com> greg@gagme.wwa.com (Gregory Gulik) writes:


>A customer inquired about using bootp to receive his nodes
>parameters (hostname, netmask, etc..) when dialing in on
>a SLIP connection.
 
>Is this possible?
>I thought that bootp needed a hardware address to work.
 
>Can someone clear this up or show how it can be done?
 
>I've tried several configurations, but nothing works.  I know
>bootp works since we use it with our Xterminals.
Bootp sits on top of UDP, ie. it sends UDP packets with the IP local
broadcast address. Therefore, it should work over SLIP. If it doesn't, I
would first check if the BOOTP server knows about the ethernet address being
used in the BOOTP request being sent over the SLIP connection. It's this
ethernet address which identifies the host to the BOOTP server and
enables it to look up the IP address and other info for it.

Chris Chlap
University of Canberra, Australia.
>-- 
>Gregory Gulik            greg@wwa.com            http://gagme.wwa.com/~greg
>Computing Engineers, Inc.                        Home of WorldWide Access (SM)
>Data: +1 312 282 8605    +1 708 367 1871         Voice: +1 708 367 1870
>Info: info@wwa.com                               Support: support@wwa.com

-----------[000118][next][prev][last][first]----------------------------------------------------
Date:      6 Jun 1994 22:56:05 GMT
From:      barmar@think.com (Barry Margolin)
To:        comp.protocols.tcp-ip
Subject:   Re: mac layer addresses

In article <SIEDELBE.94Jun6141702@steam.ucar.edu> siedelbe@steam.ucar.edu (Gregory M. Siedelberg) writes:
>1.  what is the publication that sets out the rules why tcp-ip networks can
>have only logical net per physical net, if that is indeed true?

It's not true.  RFC 1122, section 3.3.4.1, specifically mentions the
possibility of multiple logical networks on a physical network.  It admits
that the original TCP/IP designers assumed that each physical net would be
a unique logical net; however, the protocols don't actually require this.

>3.  who owns mac addresses?  who is the authorized grantor of mac layer
>addresses?  I suspect that this is the IEEE.  If someone were to just invent
>an address and use it are they violating any patent/trademark/copyrights/
>license issues.  Yes, I am trying to be technical here.  I like to look at
>the worst case and go from there.

IEEE hands out blocks of MAC addresses, and vendors are supposed to give
their devices numbers within their assigned blocks.  I don't think there's
any "ownership" status to this, but a vendor who was contracted to provide
an interface that conforms to IEEE 802 and doesn't follow these conventions
might be in breach of the contract (just as if they didn't implement some
other aspect of the protocol).  But if a site makes use of a facility for
manually setting the MAC address, I don't think this would cause any legal
problems; it might cause network management problems if another device
shows up that happens to use that address.

>What is happening here is that we are trying to put together a network
>correctly and not use quick fixes like having to set all the second enet
>interfaces to different mac layer addresses on all machines that span two
>networks.  I am thinking now that a router should have been puchased instead of
>a bridge.

Yes, I think so, too.
-- 
Barry Margolin
System Manager, Thinking Machines Corp.

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

-----------[000119][next][prev][last][first]----------------------------------------------------
Date:      6 Jun 1994 23:38:13 GMT
From:      cliu@cs.sunysb.edu (Cheng-mean Liu)
To:        comp.protocols.tcp-ip
Subject:   Old FAQ?

   Hi Folks:
        Could anyone show me how to get old FAQs ?
   Soccer

-----------[000120][next][prev][last][first]----------------------------------------------------
Date:      Tue, 07 Jun 94 11:55:22 -0700 (PDT)
From:      KCARPENT@mindlink.bc.ca (Ken Carpenter)
To:        comp.protocols.tcp-ip
Subject:   Limiting IP Broadcasting

I am trying to find a way to limit the number of packets generated when
performing a broadcast over an internetwork of Ethernet subnets.  Before
now, we strictly limited networks to be normal trees with no cycles.

However, now, we would like to be able to have redundant loops in the
network, primarily in case the main link goes down.  The problem is that we
were using a flooding algorithm for broadcasting over all the subnets
(using a proprietary network protocol).  This worked fine, the gateways
simply forwarded the incoming broadcast onto all other subnets.

In the presence of loops, however, an enourmous number of packets will be
generated unless the Gateway can be smarter about forwarding the
broadcasts.

I have considered a hop count, but this will still generate more traffic
than desired.

Also, I have looked at having the Gateway maintain some kind of list of the
last time it received a broadcast from each host (part of the routing
table?), and a unique identification (packet ID) from the broadcast packet.
Then when a broadcast packet is received, if its packet ID is less than the
packet ID in the list associated with the sending host (within some delta,
and watching for wrapping), then don't forward the packet.

This has the possible disadvantage of a Gateway not forwarding a legitimate
packet if the right sequence of events occurs.

If anyone has solved this problem before (as I am sure someone MUST have),
please enlighten me either here, or via email.

Thanks,


Ken Carpenter
Network Group R&D
Delta Controls

-----------[000121][next][prev][last][first]----------------------------------------------------
Date:      7 Jun 1994 01:18:20 GMT
From:      paulf@panic.Eng.Sun.COM (Paul Fronberg [CONTRACTOR])
To:        ba.internet,alt.bbs.internet,comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc,comp.os.ms-windows.networking.tcp-ip,comp.protocols.ppp,comp.unix.solaris,comp.unix.programmer
Subject:   SVNet meeting 6/15/94: PPP, evolution, state, and direction


SVNet Meeting/Program, Wednesday, June 15, 1994  7:30pm, Mountain View (FREE)


          **********************************************
          *                                            *
          *  PPP, Evolution, State & Directions        *
          *                                            *
          **********************************************

WHAT:   PPP, Evolution, State & Directions

  With the exposive interest in the Internet, so has grown the interest in
  internetworking-related protocols, particularly PPP.

  PPP, seen as many as the successor to SLIP (Serial Line IP), allows TCP/IP
  connections across serial lines, such as typical analog modem connections 
  across voice-grade telephone lines.  Our speaker will talk about the 
  evolution of PPP, the basic concepts behind PPP, the current state-of-the-art 
  in PPP, and the direction of PPP development.

WHO:    Brian Lloyd, Lloyd Internetworking

  Brian Lloyd is the co-author of RFC-1334 (PPP authentication), is co-author
  of the PPP inverse multiplexing draft document (multilink), and is past
  chairman of the IETF PPP working group.  His company, Lloyd Internetworking,
  is actively involved in development of PPP software for a number of different
  systems.


WHEN:   Wednesday, June 15, 1994 at 7:30pm
        (We meet regularly on the 3rd Wednesday of each month)


WHERE:  Sun Microsystems Bldg 6, 2750 Coast Avenue, Mountain View
      Coast Ave appears to be just a driveway next to Bldg 5 on Garcia Ave 
      between Amphitheatre Pkwy and San Antonio, so don't get confused.

FOR MORE INFORMATION: please call either Paul Fronberg at (415) 366-6403 
      or Ralph Barker at (408) 559-6202.

FUTURE TALKS:
	July 20th 1994 - Bill Jolitz on the 386BSD 1.0 release.

                  ---------------+--------------------
          SVNet is a UNIX  and open systems user group supported by 
                   member dues and donations.


             SVNet Meetings are FREE and OPEN TO THE PUBLIC.

              UNIX is now a registered trademark of X/Open 





-----------[000122][next][prev][last][first]----------------------------------------------------
Date:      6 Jun 1994 23:23:59 +0200
From:      wietse@wzv.win.tue.nl (Wietse Venema)
To:        comp.protocols.tcp-ip,comp.security.unix
Subject:   Re: Is IP source routing a bad idea?

casper@fwi.uva.nl (Casper H.S. Dik) writes:

>>3) Are the rlogind/rshd daemons in SunOS 4.1.x susceptible to source
>>   routing attacks?
 
>As far as I could determine, SunOS 4.1.x machines with only one ethernet
>interface are not susceptible to a source routing attack.
>It think this is because the source routed code requires that a source
>routed packet leaves another interface than the one it came in on.

I must disagree here. Read the BSD/NET1 or NET2 code again. The number
of interfaces does not matter (as long as it is > 0). Reading kernel
source for breakfast is a nice way to begin the day :-)

	Wietse

-----------[000123][next][prev][last][first]----------------------------------------------------
Date:      Tue, 7 Jun 1994 05:54:07 GMT
From:      dhesi@rahul.net (Rahul Dhesi)
To:        comp.protocols.tcp-ip,comp.security.unix
Subject:   Re: Is IP source routing a bad idea?

In <BILLW.94Jun5234622@glare.cisco.com> billw@glare.cisco.com (William ) writes:

>A correct and bug-free implementation of IP source routing allows
>any host on the internet to masquerade as any IP address that it would
>like to...

I am a little puzzled about this.  How do you arrange for
replies to come back to you?
-- 
Rahul Dhesi <dhesi@rahul.net>
also:  dhesi@cirrus.com

-----------[000124][next][prev][last][first]----------------------------------------------------
Date:      Tue, 7 Jun 94 14:59:55 -0500
From:      Peter Chapman <bankrupt@delphi.com>
To:        comp.protocols.tcp-ip
Subject:   Connecting the PC to the Internet

Okay . . . here goes.  Can someone direct me to a source for connecting my
lonesome extra 386 machine to the Internet so that other people can FTP
or TELNET to my machine to retrieve certain law-related information at no
charge.  I'd love to put some information out on the Information Highway
for others to see and use, but I can't figure out where to begin.  A book
entitled "How to connect a PC to the Internet over the phone lines in 100
easy steps" would be really convenient.  Any ideas?

-----------[000125][next][prev][last][first]----------------------------------------------------
Date:      7 Jun 94 07:19:43 GMT
From:      jkay@cs.ucsd.edu (Jon Kay)
To:        comp.protocols.tcp-ip
Subject:   Re: Way for faster IPC than TCP/IP ?


adiwan@bbn.com (Arif Diwan) sez:
> hzhou@cs.utk.edu (Honbo Zhou) writes:
> >I would like to know if there is a way to do faster IPC between
 processes
> >on different machines than TCP/IP. 
> 
> Why would you want to do that? You will probably not gain much over UDP
> let alone RAW IP. I can get close to wire speed no loss thruput over
> Ethernet or FDDI using the TCP/IP stack (UDP). The limiting factor is
> your hardware (interface card + bus etc) and your OS.

There is more than one kind of performance.  He may be interested in
latency rather than max throughput.  This is quite common because it
is the form of performance that limits RPC-style interactions.  In
that case, host software is firmly the bottleneck.

Even at 10,000 pps throughput, if the processing latency were as low
as 100 usec (which it won't be because there's no hysteresis aiding
the latency case), which is quite good for a workstation, you'd see
nearly half a millisecond's worth of round-trip latency.

Oh: the answer is to the original question is, on Unix, unfortunately
not.  If you have administrative control over your own computer, you
might look into installing BPF (comes with the tcpdump package), which
might or might not be faster than TCP/IP.  But then you'll have to
roll your own transport protocol and reliability gunk.  Not
recommended.

						Jon

-----------[000126][next][prev][last][first]----------------------------------------------------
Date:      7 Jun 1994 08:26:23 GMT
From:      eb@iunet.it (Enrico Badella)
To:        comp.os.linux.misc,comp.os.linux.development,comp.os.linux.help,comp.protocols.tcp-ip
Subject:   Broadcast address on raw sockets return EACCES

When I try to ping from my linux box a broadcast address (193.42.2.255) to
see what hosts will reply I get the error sendto: permission denied. I looked
at the network code (kernel 1.1.0) and found only 3 places where EACCESS
is returned; in udp.c (udp_connect, udp_sendto) and sock.c (inetbind). I would
exclude udp.c since ping uses a SOCK_RAW socket; in sock.c the error is
returned if the usere isn't root and the port is priviledged, none of which
are true when I try to ping. All other Oses I have around (SunOS, Solarisx86,
SCO, HP_UX) permit this operations and I receive several replies from the
network. I did notice the comment in udp.c that says that you must
turn on broadcast first but I'm not sure if this applies to raw sockets.

Can someone show me what I'm doing wrong?

================================================================================
Enrico Badella					email  softstar@pol88a.polito.it
Soft*Star s.r.l.				       eb@vax.cnuce.cnr.it
Via Camburzano 9				phone  +39-11-746092
10143 Torino, Italy				fax    +39-11-746487

	People are strange
	When you're a stranger	(J. Morrison)
================================================================================

-----------[000127][next][prev][last][first]----------------------------------------------------
Date:      7 Jun 1994 20:53:24 -0600
From:      thayne@xmission.com (Thayne Forbes)
To:        comp.protocols.tcp-ip
Subject:   Re: NetManage Chameleon for Windows and SLIP

Ramzi BAROODY (rbaroody@cs.mcgill.ca) wrote:

:> Hello,
 
:> I am trying to use NetManage's Chameleon (version 3.10) TCP/IP for Windows
:> to connect to Internet through a SLIP address.  However, the problem
:> is that Chameleon keeps insisting on dialing the phone number and connecting
:> automatically using a simple script language.  I can never seem to get
:> connected, probably because the connection procedure on the SLIP server
:> side is a bit complicated.  Is there a way I could connect manually?  Or
:> maybe I could connect through another dialer and then have Chameleon take
:> over from there?   The manual was not much of a help.  I would appreciate
:> any suggestions.

Well, at the risk of blasphemy, I would suggest that you might use
Trumpet Winsock as a debugging tool.  It allows just this sort of 
debugging, all the way up to putting the IP number in, and handing
over the connection to the SLIP process.  This may be sub-optimal,
but it worked for me.  I use it whenever trouble crops up.

-- 
Thayne Forbes           thayne@xmission.com
Computer Weenie no longer at large

-----------[000128][next][prev][last][first]----------------------------------------------------
Date:      Tue, 7 Jun 1994 12:05:16 GMT
From:      wklaus@relay.nswc.navy.mil (oanews)
To:        comp.protocols.tcp-ip
Subject:   Info request 3-Tiered Architecture

I am looking for information on  Triple tiered client/server architectures 
(or 3-tiered).  Looking for pros and cons for this form of client/server 
architecture; experiences, good or bad with implementation; identification 
of products; pitfalls for the unwary; standards, documentation and references.

If you could spend a couple of minutes I would appreciate a direct reply
via Email.

Address: jlynch@relay.nswc.navy.mil

Thank you in advance.

-- 
                               ######
                                ####
                               (*  0)
-------------------------oooO---(__)---Oooo---------------------------

-----------[000129][next][prev][last][first]----------------------------------------------------
Date:      Tue, 7 Jun 1994 12:17:01 GMT
From:      doug@siegfried.VF.GE.COM (Doug Hughes)
To:        comp.protocols.tcp-ip
Subject:   Re: Appletalk over tcp/ip how?



In article <2e4_9406031052@calcom.socal.com>, frank@calcom.socal.com (Frank Keeney) writes:
|> I can route tcp/ip over my localtalk net to allow MACs to communicate with
|> the rest of the ethernet. But how can I send Appletalk over a tcp/ip-only
|> WAN? What equipment/software would I need.
|> 
|> 
|> --
|>  Frank Keeney                   | E-mail  frank@calcom.socal.com
|>  115 W. California Blvd., #411  | Fidonet 1:102/645
|>  Pasadena, CA 91105-1509 USA    | UUCP    hatch!calcom!frank
|>                                 | FAX     +1 818 791-0578 
|>                                 | Voice Mail +1 818-791-0578 x402

Well, you can use KIP or a variant.. lots of devices support this.  
Cayman gatorboxes, Kinetics Fastpaths, Webster Multi-ports.  Of course, you 
usually want tohave the same kind of device on both ends.  Several devices 
support this in software as well. you can get UAR (unix appletalk router), 
or CAP (columbia Appletalk Package).  
  Also, Cisco lets you do appletalk tunneling between two of their 
interfaces on a quasi interface.  (e.g. show apple tunnel 0,1,etc)
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Doug Hughes              Internal Information Systems (NorthEast)   
System/Net Admin         Martin Marietta, Valley Forge, PA          
doug@vf.ge.com           doug@land.vf.ge.com                        
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
   "The light at the end of the tunnel is the headlamp of a train"  


-----------[000130][next][prev][last][first]----------------------------------------------------
Date:      7 Jun 94 18:06:01
From:      billw@glare.cisco.com (William )
To:        comp.networks,comp.org.ieee,comp.protocols.tcp-ip,comp.dcom.lans.ethernet
Subject:   Re: mac layer addresses

    Physical interfaces are supposed to be unique. One MAC physical
    address per port, one port per MAC physical address. MAC group
    addresses, of course, can be assigned to many ports.

Actually, several companies, including two of the inventors of ethernet,
seem to believe (or used to believe) that there was one MAC address per
node, regardless of how many ports there were on that node.

BillW

-----------[000131][next][prev][last][first]----------------------------------------------------
Date:      7 Jun 1994 19:53:33 -0400
From:      mharrop@interlog.com (Matt Harrop)
To:        comp.protocols.tcp-ip,comp.protocols.ppp,comp.dcom.servers,comp.sys.mac.comm
Subject:   Strange Macintosh<-->Unix sl/ip problem


I am having a problem with slip that I am having a great deal of trouble
soving.  I can't even isolate that problem.  The network is essentialy this:

power	<------sl/ip-------->gold<---------ppp--------->internet provider

power=199.0.23.2, and is a PowerBook 170 running MacTCP2.0.4 with InterSLIP
version 1.02.
gold=199.0.20.47, and is a BSDI bsd/386 box running sliplogin.

As the diagram shows, gold is connected to my internet provider a dial up
PPP link.  The sl/ip link between power and gold is a null-modem cable.

  Whenever I try to access Internet resources from power, it is extreamly
slow.  If I bring up mosaic is takes 10 to 15 minutes to get a home page.
FTP sessions from power also take minutes to connect.  Once a file transfer
starts, it moves reasonably fast.  This delay does not occur when I access
resources that are directly on gold.  The delay only occers when going past
gold out onto the internet.  If I login to gold and access the internet from
there, there is no delay.

  Now, this would point to a problem on gold, correct?  BUT, if I ping power
from a remote host out on the 'net, the turn around time is aobut 450ms.  
Considering it's going through a dial up link _and_ a 9600bps serial
connection, 450ms is not bad. 

  So, I'm stumped.  I would think that the problem probably lies in the
Macintosh, except that performance is just fine when I'm accessing resources
local to the slip server.  This points to a problem with the slip server.
Perhaps the packet forwarding is very, very slow.  But ping times through
the server are just fine, so packets are getting through.  My head hurts.

Thanks in advance for any help,
-- 
Matt Harrop                                       mharrop@interlog.com
InterLog Internet Services   voice (416) 537-7453   fax (416) 532-5015
Online   Publishing,   Marketing,   and   Support  on   the   Internet
Coming in July -- Lowest Cost Dial-Up Internet Connectivity in Toronto

-----------[000132][next][prev][last][first]----------------------------------------------------
Date:      Tue, 7 Jun 1994 16:15:43 GMT
From:      bbosen@netcom.com (Bob Bosen)
To:        comp.protocols.tcp-ip,comp.security.unix
Subject:   Re: ftp ACCT feature?

news@vdd.VLSI.LL.MIT.EDU wrote:
: I need to implement the account (ACCT) feature of ftpd in the
: wu-archive source of ftpd, in order to require an extra security
: password before the user is allowed to do anything.  Has anyone done
: this?  Its the yacc stuff I'm not sure of, and how it should fit with
: the PASS command.


: George Young,  Rm. B-169		young@vlsi.ll.mit.edu
: MIT Lincoln Laboratory			young@vdd.vlsi.ll.mit.edu
: 244 Wood St.				[129.55.11.1]
: Lexington, Massachusetts  02173-9108	(617) 981-2756

If you have an IBM PC with a VGA display, you might enjoy taking a
look at my animated tutorial software on this subject. Just ftp to:

ftp.netcom.com

Then cd to:

/pub/bbosen/Enigma/Tutorials/Vga/Grasp/Firewall

and get everything that's there. The readme file should make it clear
how to proceed from that point.

Enjoy!

-- 

Bob Bosen
Enigma Logic Inc.
2151 Salvio St. #301
Concord, CA   94520
USA

Tel: +1 510 827-5707
Internet: bbosen@netcom.com
**************************************************************************
* "It wasn't me!!! Somebody must have captured my username/password!!!"  *
**************************************************************************

-----------[000133][next][prev][last][first]----------------------------------------------------
Date:      7 Jun 1994 16:51:14 GMT
From:      koning@koning.enet.dec.com (Paul Koning)
To:        comp.networks,comp.org.ieee,comp.protocols.tcp-ip,comp.dcom.lans.ethernet
Subject:   Re: mac layer addresses


In article <SIEDELBE.94Jun6134324@steam.ucar.edu>, siedelbe@steam.ucar.edu (Gregory M. Siedelberg) writes:
|>2.  where is it spelled out on how to use bridges and MAC layer addresses?  I
|>suspect that this is probably in 802.1, but don't have a copy yet to look it
|>up, but any other references would be appreciated.

Quoting from 802.1d, section 3.12 (Addressing):

	...  The specific MAC address used by every MAC entity
	communicating across the Bridged Local Area Network shall
	be unique in that network in order to specify the
	addressed station unambiguously.

So, it is invalid to use the same address on multiple segments of a bridged
LAN.  This is a well-known limitation; the section I just quoted both states
it and explains why it is there.

|>3.  who owns mac addresses?  who is the authorized grantor of mac layer
|>addresses?  I suspect that this is the IEEE.  If someone were to just invent
|>an address and use it are they violating any patent/trademark/copyrights/
|>license issues.  Yes, I am trying to be technical here.  I like to look at
|>the worst case and go from there.

There are two possibilities.

If the second bit of the address is 0 (in the "canonical" form written
address, a.k.a. the "ethernet form" that is the 02 bit in the first byte),
then the address is "universally administered".  In that case, it is
supposed to be constructed from a 24-bit prefix ("OUI", "Organizationally
Unique Identifier") issued by the IEEE standards office, and a 24 bit
suffix issued by the organization that holds the OUI in question.

If the second bit is 1, then the address is "Locally administered".  In
that case, the remaining bits are unspecified, and the allocation and
control of these addresses is up to local network management.

Universally administered addresses are (supposed to be) globally unique;
you should never see two interfaces with the same universally administered
address.  Any implementation that does put the same universally
administered address out on multiple interfaces violates the IEEE 802
standard.

Locally administered addresses have no guarantees of uniqueness, and may
well be duplicated across organizations.  They may even be duplicated
within an organization, if the administrator chooses to do so (or is
careless).  That may in fact be perfectly ok, so long as the two interfaces
in question don't communicate at the datalink layer.  In other words, they
must not be either on the same LAN segment, or on the same Bridged LAN.

If you want to make up addresses, make up Locally Administered form addresses.
Those are guaranteed not to clash with any Universally Administered ones.
It's up to you to make sure they don't clash with any other Locally
administered ones, of course.

If you make up addresses that are (by their form) Universally administered,
you're risking address conflicts.  I haven't heard of any legal repercussions
from that, but certainly you would catch (justified) blame for breaking
things.

	paul
!-----------------------------------------------------------------------
! Paul Koning, NI1D, B-16504
! Digital Equipment Co., LKG1-2/A19, Littleton, MA 01460, USA
! phone: (508) 486-7313, fax: (508) 486-5279, koning@koning.enet.dec.com
!-----------------------------------------------------------------------
! "The only purpose for which power can be rightfully exercised over 
!  any member of a civilized community, against his will, is to prevent
!  harm to others.  His own good, either physical or moral, is not
!  a sufficient warrant."    -- John Stuart Mill, "On Liberty" 1859


-----------[000134][next][prev][last][first]----------------------------------------------------
Date:      7 Jun 1994 17:21:25 GMT
From:      rbaroody@cs.mcgill.ca (Ramzi BAROODY)
To:        comp.protocols.tcp-ip
Subject:   NetManage Chameleon for Windows and SLIP


Hello,

I am trying to use NetManage's Chameleon (version 3.10) TCP/IP for Windows
to connect to Internet through a SLIP address.  However, the problem
is that Chameleon keeps insisting on dialing the phone number and connecting
automatically using a simple script language.  I can never seem to get
connected, probably because the connection procedure on the SLIP server
side is a bit complicated.  Is there a way I could connect manually?  Or
maybe I could connect through another dialer and then have Chameleon take
over from there?   The manual was not much of a help.  I would appreciate
any suggestions.

Thanks

Ramzi

-- 



-----------[000135][next][prev][last][first]----------------------------------------------------
Date:      Tue, 7 Jun 1994 17:25:45 GMT
From:      fitz@wang.com (Tom Fitzgerald)
To:        comp.protocols.tcp-ip,comp.security.unix
Subject:   Re: Is IP source routing a bad idea?

> billw@glare.cisco.com (William ) writes:
 
> >A correct and bug-free implementation of IP source routing allows
> >any host on the internet to masquerade as any IP address that it would
> >like to...

dhesi@rahul.net (Rahul Dhesi) writes:

> I am a little puzzled about this.  How do you arrange for
> replies to come back to you?

That's required for TCP.  From RFC 1122:

         4.2.3.8  IP Options
[...]
            When a TCP connection is OPENed passively and a packet
            arrives with a completed IP Source Route option (containing
            a return route), TCP MUST save the return route and use it
            for all segments sent on this connection.  If a different
            source route arrives in a later segment, the later
            definition SHOULD override the earlier one.

Source routing will get even more interesting in the future.... many of the
IPng proposals depend heavily on source-routing, to the extent that you
probably won't be able to disable it on routers.  If you could, the
protocols wouldn't work.

-- 
Tom Fitzgerald   Wang Labs   Lowell MA, USA   1-508-967-5278   fitz@wang.com

-----------[000136][next][prev][last][first]----------------------------------------------------
Date:      Tue, 7 Jun 1994 17:44:16 GMT
From:      apollo1@netcom.com (Doug A. Chan)
To:        biz.sco.general,comp.protocols.tcpip,comp.unix.admin
Subject:   Strange rcp/rcmd response times in SCO Unix.

I've recently discovered a strange problem with rcp and rcmd:
 The first time I do an rcmd to a particular machine, the response
 time is fairly quick but every time after that it is extremely slow.

 Here is what I did:
  $ timex rcmd SOMEMACHINE -l USER date
   real   3.00
   user   0.05
   sys    0.26
  $ timex rcmd SOMEMACHINE -l USER date
   real   11.96
   user   0.03
   sys    0.20

If I wait a minute or two, the response time goes back to normal.
The response of rcp is also similar...
In additional, if I do the same thing to my own machine (ie. rcp or
rcmd to localhost) I get the same type of wierdness!

All the machines I've tested on are running SCO 3.2v4.2, TCP 1.2.1o
with the latest LLI (3.3.0) driver.

Is there a problem with rshd or inetd?
Can anyone clue me in as to what is happening?

-Doug
apollo1@netcom.com
apollo@world.std.com

-----------[000137][next][prev][last][first]----------------------------------------------------
Date:      Tue, 7 Jun 1994 18:00:09 GMT
From:      barnett@grymoire.crd.ge.com (Bruce Barnett)
To:        comp.protocols.tcp-ip
Subject:   Re: Voice

In article <kymaCqxK9s.93G@netcom.com> kyma@netcom.com (Matt Young) writes:
>   How does RSVP work, say compared to an ARP.  I use ARP as an
>   example since it is an approximation to call set up.  Is RVSP like
>   a call set up?  Does one issue an RSVP to modify the delay and
>   throughput characteristics of a particular connection?




As I (barely) understand it, RSVP negotiates with routers and reserves
bandwidth. It is not sufficient to talk to the end nodes. You must
deal with all routers in-between.

>   Explain a little more about STII.  Is it lighter weight IP?
>   What does it claim to have that IP doesn't have?  

STII is a different IP. Advantages include bandwidth reservation.
Disadvantages: it only works with STII traffic. IP traffic isn't
modified,  controlled or managed. Also, it doesn't interoperate.
You need two stacks. Since you are going to have some IP anyway,
and since STII doesn't control IP, you cannot reserve IP bandwidth.

>   And I assume that SNMP management will cross all layers, allowing
>   some semblence of uniform monitoring, if not control.


I don't think this is that simple. I wouldn't allow some outside party
control, monitor and reconfigure my routers and hosts.
--
Bruce Barnett <barnett@crd.ge.com> uunet!crdras!barnett

-----------[000138][next][prev][last][first]----------------------------------------------------
Date:      Tue, 7 Jun 1994 18:34:43 GMT
From:      barnett@grymoire.crd.ge.com (Bruce Barnett)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP/IP vs. LU 0 (tuning)

In article <dch2CqvqBH.HK8@netcom.com> dch2@netcom.com (D. Hobbs) writes:
>   What kind of recommendations do y'all have? 


If you want fast TCP, you must consider the possible causes.

One cause of slowness is congestion. This is dynamic in nature, and
has no "values" to tweak. Most of the decisions are in the
implementation and algorithms used. Proper tuning requires replacing
the algorithms, not changing constants.

Another cause of slowdown is application specific parameters, like
window size.  Grab "ttcp" from sgi.com or brl.mil to experiment with
application level parameters.

A third possible cause is network failures, like dropped packets,
retransmits, etc. Find the cause and eliminate these problems.
Maybe it's an overloaded server or router.

A fourth cause is slow implementations. ttcp will help you find the
fastest throughput your system can achieve. But if it still isn't fast
enough, get a faster processor or more recent software.  

A fifth cause is bandwidth delay. This is related to bandwith and
distance. 

There aren't many system-level parameters.

--
Bruce Barnett <barnett@crd.ge.com> uunet!crdras!barnett

-----------[000139][next][prev][last][first]----------------------------------------------------
Date:      Tue, 7 Jun 1994 18:44:48 GMT
From:      barnett@grymoire.crd.ge.com (Bruce Barnett)
To:        comp.protocols.tcp-ip
Subject:   Re: Way for faster IPC than TCP/IP ?

hzhou@cs.utk.edu (Honbo Zhou) writes:
>I would like to know if there is a way to do faster IPC between  processes
>on different machines than TCP/IP. 

Why not use UDP? TCP setups take several extra packets and often
require the server to fork for each new connection. Use UDP and you
don't need to worry about it. You do have to worry about reliability
and timeouts...

--
Bruce Barnett <barnett@crd.ge.com> uunet!crdras!barnett

-----------[000140][next][prev][last][first]----------------------------------------------------
Date:      7 Jun 1994 18:50:39 GMT
From:      zagar@chester.cms.udel.edu (Randy Zagar)
To:        comp.protocols.tcp-ip
Subject:   Re: Way for faster IPC than TCP/IP ?

In article 150723@bbn.com,  adiwan@bbn.com (Arif Diwan) writes:
>
>Here are some figures [pps = packets/sec]:
>
>Ethernet (Theoretical wire speed: 10MB/s):
>	8400 pps  128 byte packets  -> 8.2 MB/s
>       1200 pps 1024 byte packets    -> 9.375 MB/s
>
>If I stay on just one ring or ethernet segment then I can pump very
>close to wire speed - over 95%.
>

Pardon my incredulousness, but I find those numbers to be a little too good
to believe.  You're talking about ACTUAL MEASURED THROUGHPUT aren't you ?

I'd also be interested in knowing what hardware/OS you were running on
when you did these tests...  *Some* vecdors have better implementations of IP
than others...

-Randy

---
 ____________________________________________________________________________
/                                                                            \
| Randy Zagar                       |      Voice: 302/831-1130               |
| College of Marine Studies         |        FAX: 302/831-6838               |
| University of Delaware            |   Internet: zagar@Chester.CMS.UDel.Edu |
| Newark, DE 19711                  | Compu$erve: 73072,1413                 |
|----------------------------------------------------------------------------|
|               PGP Key available on request, or by 'finger'.                |
\____________________________________________________________________________/



-----------[000141][next][prev][last][first]----------------------------------------------------
Date:      Tue, 7 Jun 1994 19:32:28 GMT
From:      shah@abba (Sanjeev Shah)
To:        comp.protocols.tcp-ip.domains,comp.protocols.tcp-ip,comp.protocols.ppp
Subject:   routing on a router/gateway

I have a class C address and use a UnixWare host (SVR4.2) to connect
to the internet via a dialout PPP link.  The machine has two interfaces
(wd0 and ppp) and IPFORWARDING is set to 1.  I am using separate IP
addresses for the two interfaces.

When I rlogin to a host on the internet, I see that I have come over the
ppp0 interface's IP.  i.e. 'who' on a SunOS host shows my userid and the
IP address of ppp0 (199.xxx.xxx.3).  I had really like to see this as
the IP associated with wd0 (199.xxx.xxx.2).  i.e. I want the unix box
to act as a router and just pass the IP packets via the ppp0 interface.
i.e. icon->icon2->provider->internethost.  Is this possible using routed?

This scenario should be true of any router (cisco, etc.) in a big
organization.  I am sure their router passes the IP of the originating host
and not its own IP as the originator IP or is my case special because of PPP?

I have also tried subnetting with the same results.  For subnetting
I used 199.xxx.xxx.33 for ppp0 and 199.xxx.xxx.65 for wd0 and a
netmask of 199.xxx.xxx.224.  Any help is appreciated.


    +----------+          [icon2]           [provider]    +----------+
    |          | ppp0 (199.xxx.xxx.3)      (164.xx.xx.xx) |          |
    | unixware |------------------------------------------| internet | internet
    |   host   |                                          | provider |-------->
    |          | wd0 (199.xxx.xxx.2)                      |          |
    |          |------+   [icon]                          |          |
    +----------+      |                                   +----------+
                      |
                   [iconnet]
                 199.xxx.xxx.0
					  |
                (planned LAN)


netstat -r
----------
Routing tables
Destination      Gateway            Flags  Refs   Use      Interface
localhost        localhost          UH     0      0        lo0
provider         icon2              UH     0      0        ppp0
default          provider           UG     1      1276     ppp0
iconnet          icon               U      0      0        wd0

--
Sanjeev Shah   shah@abba.fcmc.com
-- 
--
Sanjeev Shah     internet: shah@abba.fcmc.com

-----------[000142][next][prev][last][first]----------------------------------------------------
Date:      7 Jun 1994 19:34:32 GMT
From:      dsiebert@icaen.uiowa.edu (Doug Siebert)
To:        comp.protocols.tcp-ip
Subject:   Re: Way for faster IPC than TCP/IP ?

zagar@chester.cms.udel.edu (Randy Zagar) writes:

>In article 150723@bbn.com,  adiwan@bbn.com (Arif Diwan) writes:
>>
>>Here are some figures [pps = packets/sec]:
>>
>>Ethernet (Theoretical wire speed: 10MB/s):
>>	8400 pps  128 byte packets  -> 8.2 MB/s
>>       1200 pps 1024 byte packets    -> 9.375 MB/s
>>
>>If I stay on just one ring or ethernet segment then I can pump very
>>close to wire speed - over 95%.
>>
 
>Pardon my incredulousness, but I find those numbers to be a little too good
>to believe.  You're talking about ACTUAL MEASURED THROUGHPUT aren't you ?
 
>I'd also be interested in knowing what hardware/OS you were running on
>when you did these tests...  *Some* vecdors have better implementations of IP
>than others...



Obviously they aren't measured -- you can't get more than 1.25MB (megabytes)
out of Ethernet even if all 10Mb (megabits) it is capable of were totally
devoted to data, with no overhead, etc., etc.  Maybe he was using UDP and
only measuring packets sent, rather than sent and receiving.  Many current
Unix workstations can send at such rates, the packets that can't be sent
because of limitations of wire speed are just dropped, since UDP is
unreliable.

As for vendor TCP/IP, I've read/heard/seen in several places that SGI is
currently tops on TCP/IP capability, followed closely by HP.  Both have
machines that are capable of essentially saturating an FDDI ring (100Mb/sec)
Even the lowest end workstations from just about any major vendor should be
able to saturate an Ethernet without any difficulty these days.  (I remember
seeing experiments Van Jacobsen did with highly optimized TCP/IP kernels
saturating an Ethernet on a lowly Sun 3!



-- 
Doug Siebert             |  I have a proof that everything I have stated above
dsiebert@isca.uiowa.edu  |  is true, but this .sig is too small to contain it.

-----------[000143][next][prev][last][first]----------------------------------------------------
Date:      Tue, 7 Jun 1994 20:03:19 GMT
From:      mitch@cirrus.com (Mitch Wright)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP over ATM reading list?

/* chrisc@fir.canberra.edu.au (Chris Chlap) writes: */

>>Does anyone have a bibliography for TCP over ATM?
>You might like to try gopher to cell-relay.indiana.edu. They have heaps
>of stuff there.
>Also, gwen.cs.purdue.edu in /pub/atm have a collection of ATM documents.
>
The ATM Forum is also running an HTTP server now, so you might check
that out.  The URL is http://www.atmforum.com/

   ~mitch


-----------[000144][next][prev][last][first]----------------------------------------------------
Date:      Wed, 8 Jun 1994 01:56:27 UNDEFINED
From:      treynold@fred.lasalle.edu (Tommi)
To:        comp.protocols.tcp-ip,comp.security.unix
Subject:   Re: Is IP source routing a bad idea?

In article <1994Jun6.032935.17859@martha.utcc.utk.edu> venu@voodoo.utcc.utk.edu (Nair Venugopal) writes:
[stuff deleted]

>The tcp wrapper man page says that 
>     "tcpd disables source-routing socket  options  on
>     every  connection that it deals with. This will take care of
>     most attacks from hosts that pretend to have an address that
>     belongs  to someone elses network."
 
>1) How can rlogind or rshd be compromised if the source routing is enabled?
>    (If some one tries to spoof a host on another network, wouldnt the
>     intermediate routers reject the spoofed packets.)

Well, source routing is used to do just that... disallow routing decisions 
from occuring along the path.  When source routing is specified, then the 
sender specifies the entire route that the packet should take; i.e., the 
routers in the middle wouldn't reject...

>2) Is there any situation, other than trouble shooting, where
>the source routing option will be of use?

Not as far as I can think of off hand; about the only thing that I can think 
of/remember that source routing is used for is (as you mentioned) when 
troubleshooting--it can eliminate the possibility of different packets 
taking different routes along their merry way...

>3) Are the rlogind/rshd daemons in SunOS 4.1.x susceptible to source
>routing attacks?
 
>4) Is there any patch for fixing the  getsockopt() system call bug in
>   SunOS 4.1.x ?

Sorry; OS specific (especially SUNs) stuff I really am not all that good 
with...

Hope this helps....


---
Tommi

treynold@fred.lasalle.edu

The above are my thoughts; if you don't like them, don't read them!

-----------[000145][next][prev][last][first]----------------------------------------------------
Date:      07 Jun 1994 21:05:02 GMT
From:      Steinar.Haug@runit.sintef.no (Steinar Haug)
To:        comp.protocols.tcp-ip,comp.unix.solaris
Subject:   Re: Way for faster IPC than TCP/IP ?

> >Here are some figures [pps = packets/sec]:
> >
> >Ethernet (Theoretical wire speed: 10MB/s):
> >	8400 pps  128 byte packets  -> 8.2 MB/s
> >       1200 pps 1024 byte packets    -> 9.375 MB/s
> >
> >If I stay on just one ring or ethernet segment then I can pump very
> >close to wire speed - over 95%.
> >
> 
> Pardon my incredulousness, but I find those numbers to be a little too good
> to believe.  You're talking about ACTUAL MEASURED THROUGHPUT aren't you ?
> 
> I'd also be interested in knowing what hardware/OS you were running on
> when you did these tests...  *Some* vecdors have better implementations of IP
> than others...

It should be obvious from the posting that 'B' means bit here. I like to
use lowercase b for bit myself and B for Byte. However, that doesn't change
the validity of the measurements.

It's been several years now since I measured more than 1 Mbyte/s (1048576
byte/s) using ttcp between two Sparcstation IPC on an otherwise quiet Ethernet
segment (ie only those two hosts were actrive). IPCs are not exactly fast by
current standards. This is an easy test to make for yourself.

I *expect* all reasonable workstation vendors nowadays to be able to saturate
an Ethernet. I *hope* it won't be too long before they can all saturate an
FDDI ring also. I still haven't seen anything which indicates that Suns can do
this, even if several other well known workstation vendors can.

Steinar Haug, SINTEF RUNIT, University of Trondheim, NORWAY
Email: Steinar.Haug@runit.sintef.no

-----------[000146][next][prev][last][first]----------------------------------------------------
Date:      Tue, 7 Jun 1994 21:40:44 GMT
From:      iiitac@uk.ac.swan.pyr (Alan Cox)
To:        comp.os.linux.misc,comp.os.linux.development,comp.os.linux.help,comp.protocols.tcp-ip
Subject:   Re: Broadcast address on raw sockets return EACCES

In article <2t1avf$8lh@sgi.iunet.it> eb@iunet.it (Enrico Badella) writes:
>When I try to ping from my linux box a broadcast address (193.42.2.255) to
>see what hosts will reply I get the error sendto: permission denied. I looked

Add the lines

	int bcast=1;
	
	setsockopt(socket_fd, SOL_SOCKET,SO_BROADCAST,&bcast,sizeof(bcast));
	
into ping so that it sets the broadcast allowed option.

Alan


-----------[000147][next][prev][last][first]----------------------------------------------------
Date:      7 Jun 1994 18:34:16 +0200
From:      wietse@wzv.win.tue.nl (Wietse Venema)
To:        comp.protocols.tcp-ip,comp.security.unix
Subject:   Re: Is IP source routing a bad idea?

>A correct and bug-free implementation of IP source routing allows
>any host on the internet to masquerade as any IP address that it would
>like to...

dhesi@rahul.net (Rahul Dhesi) writes:
>I am a little puzzled about this.  How do you arrange for
>replies to come back to you?

That is what the source route is for: the client specifies the route
that datagrams (both ways) should take.

	Wietse

-----------[000148][next][prev][last][first]----------------------------------------------------
Date:      Tue, 7 Jun 1994 22:44:00 GMT
From:      manfredi@rockwell.com (Bert Manfredi, 747-6735)
To:        comp.networks,comp.org.ieee,comp.protocols.tcp-ip,comp.dcom.lans.ethernet
Subject:   Re: mac layer addresses

In article <SIEDELBE.94Jun6134324@steam.ucar.edu>, siedelbe@steam.ucar.edu (Gregory M. Siedelberg) writes...
> 
>Someone is trying to bridge two nets together using a bridge that is also
>connected to an fddi ring.  Some of the computers in question have two ethernet
>interfaces(Suns).  When each one of the nets is connected into this bridge,
>it complains that it sees the same MAC layer address on two different ports,
>no surprise.  When I tell this person that this should not be done, ie., 
>bridging two separate nets onto the same net is not proper, I get a lot of, 
>"who says" and "show me where it says that" replies.  Sun does provide a 
>feature that one can arbitrarily change the MAC address, but only provides
>one address per machine and that is burned into the sun id prom.  So these are
>the questions that I hope some of you will have the answeres to.

Physical interfaces are supposed to be unique. One MAC physical address per
port, one port per MAC physical address. MAC group addresses, of course,
can be assigned to many ports.
> 
>1.  what is the publication that sets out the rules why tcp-ip networks can
>have only logical net per physical net, if that is indeed true?

Check RFC 1122. You can have many logical nets on a physical net.
> 
>2.  where is it spelled out on how to use bridges and MAC layer addresses?  I
>suspect that this is probably in 802.1, but don't have a copy yet to look it
>up, but any other references would be appreciated.

Try Radia Perlman's _Interconnections_, ISBN 0-201-56332-0. It's even a
fun read!
> 
>3.  who owns mac addresses?  who is the authorized grantor of mac layer
>addresses?  I suspect that this is the IEEE.  If someone were to just invent
>an address and use it are they violating any patent/trademark/copyrights/
>license issues.  Yes, I am trying to be technical here.  I like to look at
>the worst case and go from there.

Yes, it is the IEEE. Perhaps someone can give you the details off the top.

Bert
manfredi@rockwell.com

-----------[000149][next][prev][last][first]----------------------------------------------------
Date:      7 Jun 1994 23:04:53 GMT
From:      zhao@ERC.MsState.Edu (Xiaodong Zhao)
To:        comp.protocols.tcp-ip
Subject:   Re: Way for faster IPC than TCP/IP ?

In article 94Jun7144448@grymoire.crd.ge.com, barnett@grymoire.crd.ge.com (Bruce Barnett) writes:
>hzhou@cs.utk.edu (Honbo Zhou) writes:
>>I would like to know if there is a way to do faster IPC between  processes
>>on different machines than TCP/IP. 
>
>Why not use UDP? TCP setups take several extra packets and often
>require the server to fork for each new connection. Use UDP and you
>don't need to worry about it. You do have to worry about reliability
>and timeouts...
>
>--
>Bruce Barnett <barnett@crd.ge.com> uunet!crdras!barnett


I'd like to join this discussion and have been curious about how much speedup you could
get by using UDP instead of TCP particularly if in a local area environment like a building.
W. Richard Stevens' UNIX NETWORK PROGRAMMING shows there might be double.
Any body has done any test?  What about using raw packet?

-Zhao
ERC, MSU




-----------[000150][next][prev][last][first]----------------------------------------------------
Date:      7 Jun 1994 23:12:07 GMT
From:      zhao@ERC.MsState.Edu (Xiaodong Zhao)
To:        comp.protocols.tcp-ip
Subject:   Re: Way for faster IPC than TCP/IP ?

In article 94Jun7230502@bokfink.runit.sintef.no, Steinar.Haug@runit.sintef.no (Steinar Haug) writes:
>> >Here are some figures [pps = packets/sec]:
>> >
>> >Ethernet (Theoretical wire speed: 10MB/s):
>> >	8400 pps  128 byte packets  -> 8.2 MB/s
>> >       1200 pps 1024 byte packets    -> 9.375 MB/s
>> >
>> >If I stay on just one ring or ethernet segment then I can pump very
>> >close to wire speed - over 95%.
>> >
>> 
>> Pardon my incredulousness, but I find those numbers to be a little too good
>> to believe.  You're talking about ACTUAL MEASURED THROUGHPUT aren't you ?
>> 
>> I'd also be interested in knowing what hardware/OS you were running on
>> when you did these tests...  *Some* vecdors have better implementations of IP
>> than others...
>
>It should be obvious from the posting that 'B' means bit here. I like to
>use lowercase b for bit myself and B for Byte. However, that doesn't change
>the validity of the measurements.
>
>It's been several years now since I measured more than 1 Mbyte/s (1048576
>byte/s) using ttcp between two Sparcstation IPC on an otherwise quiet Ethernet
>segment (ie only those two hosts were actrive). IPCs are not exactly fast by
>current standards. This is an easy test to make for yourself.
>
>I *expect* all reasonable workstation vendors nowadays to be able to saturate
>an Ethernet. I *hope* it won't be too long before they can all saturate an
>FDDI ring also. I still haven't seen anything which indicates that Suns can do
>this, even if several other well known workstation vendors can.
>
>Steinar Haug, SINTEF RUNIT, University of Trondheim, NORWAY
>Email: Steinar.Haug@runit.sintef.no


Does andybody know anything about the 100M Ethernet?   How did they do that!

-Zhao
 



-----------[000151][next][prev][last][first]----------------------------------------------------
Date:      7 Jun 1994 23:16:18 GMT
From:      zhao@ERC.MsState.Edu (Xiaodong Zhao)
To:        comp.protocols.tcp-ip
Subject:   tcp/ip using for high-speed network


I'd like to people in this group to talk about the potential of using TCP/IP as a communication
protocal for high-speed network.   Is it good, better or best?  what's advantage or disadvantage
of using tcp/ip especially for high-speed network such as FDDI?

-Zhao
ERC, MSU



-----------[000152][next][prev][last][first]----------------------------------------------------
Date:      Wed, 08 Jun 1994 14:28:38 -0800
From:      michael_munoz@smtp.esl.com (Michael D. Munoz)
To:        comp.protocols.tcp-ip
Subject:   Fetch for the Mac?

Please disregard if this is in the wrong place, can anyone tell me where I
can get a copy of " Fetch " for the mac, if you think you can help me ,
could you E-mail it to me in an enclosure.

-- 
******************* The above opinions are mine alone.
*********************

                               
************* Thing are NOT always what they seem, even if they ARE.
************* 
 
 

-----------[000153][next][prev][last][first]----------------------------------------------------
Date:      Wed, 8 Jun 1994 02:45:42 GMT
From:      barnett@grymoire.crd.ge.com (Bruce Barnett)
To:        comp.protocols.tcp-ip
Subject:   Re: Way for faster IPC than TCP/IP ?

In article <2t2uel$4qg@Tut.MsState.Edu> zhao@ERC.MsState.Edu (Xiaodong Zhao) writes:

>   I'd like to join this discussion and have been curious about how much speedup you could
>   get by using UDP instead of TCP particularly if in a local area environment like a building.
>   W. Richard Stevens' UNIX NETWORK PROGRAMMING shows there might be double.
>   Any body has done any test?  What about using raw packet?


Well, if you open a TCP socket, send a query, get a response, and
close the socket, there will probably be 10 packets sent back and forth:

# open a socket

Host A Syn
Host B Syn & Ack
Host A Ack

# Send data

Host A send data
Host B Ack
# reply
Host B send data
Host A Ack

#Close socket
Host A FIN
Host B FIN & ACK
Host A ACK

With UDP, it's

Host A send data
Host B send data
---

However, if you miss a UDP packet, you have to timeout and
retransmit. The UDP server must maintain state for each connection, if
necessary.


Also - some kernels may decide to not send UDP packets if the machine
is overloaded. Using ttcp with UDP packets vs. TCP packets will
demonstrate this. 
--
Bruce Barnett <barnett@crd.ge.com> uunet!crdras!barnett

-----------[000154][next][prev][last][first]----------------------------------------------------
Date:      Wed, 8 Jun 1994 02:59:11 GMT
From:      henry@zoo.toronto.edu (Henry Spencer)
To:        comp.org.ieee,comp.protocols.tcp-ip,comp.dcom.lans.ethernet
Subject:   Re: mac layer addresses

In article <BILLW.94Jun7180601@glare.cisco.com> billw@glare.cisco.com (William ) writes:
>    Physical interfaces are supposed to be unique. One MAC physical
>    address per port, one port per MAC physical address. MAC group
>    addresses, of course, can be assigned to many ports.
>
>Actually, several companies, including two of the inventors of ethernet,
>seem to believe (or used to believe) that there was one MAC address per
>node, regardless of how many ports there were on that node.

In fact, the XNS protocols demand -- or used to demand, anyway -- this
situation.  This is why the original DIX Ethernet spec explicitly required
that it be possible to change the address of an Ethernet port from the
protocol software.  (To understand this, it is helpful to know that XNS
folks did not have the notion of a mapping between a logical address and
a MAC address:  an XNS host had one 48-bit address, period.)
-- 
"...the Russians are coming, and the    | Henry Spencer @ U of Toronto Zoology
launch cartel is worried." - P.Fuhrman  |  henry@zoo.toronto.edu  utzoo!henry

-----------[000155][next][prev][last][first]----------------------------------------------------
Date:      8 Jun 1994 03:08:37 GMT
From:      visser@convex.com (Lance Visser)
To:        comp.protocols.tcp-ip
Subject:   Re: Way for faster IPC than TCP/IP ?

In <2t2uel$4qg@Tut.MsState.Edu> zhao@ERC.MsState.Edu (Xiaodong Zhao) writes:



+>I'd like to join this discussion and have been curious about how much speedup you could
+>get by using UDP instead of TCP particularly if in a local area environment like a building.
+>W. Richard Stevens' UNIX NETWORK PROGRAMMING shows there might be double.
+>Any body has done any test?  What about using raw packet?

	If you can open the tcp window large enough and have delayed
acks working properly and are running checksums on both tcp and udp
then the results should be similar.  tcp only "stalls" when it has
sent a full window and has not yet received an ack.  

	The thing to remember about TCP is that it only starts getting
expensive if you have loss on the net.  You don't do timeouts or retrans
missions if there is no loss.  




-----------[000156][next][prev][last][first]----------------------------------------------------
Date:      8 Jun 1994 04:07:00 GMT
From:      kenton@space.mit.edu (Kenton C. Phillips)
To:        comp.sys.sun.admin,comp.protocols.tcp-ip
Subject:   Sparcstation as filtering bridge?

I am trying to figure out how to use a Sun Sparcstation with two ethernet
ports as a filtering bridge.  That is, I would like to put one port on the
backbone, and connect one or more computers to the second port, but without
configuring the second port as a logical subnet (as is the more typical
arrangement).  There are several reasons for this, one of which is that we
will be putting data acquisition machines on the second port, and we would
like to be able to move those machines around without having to reassign
IP addresses and reconfigure routing information with every move.  If all
machines on both sides of each bridging Sparcstation are seen as the same
subnet, then such reconfiguration could be avoided.

However, it would seem that this is a non-standard thing to do, at least as
far as I can tell.  Is there a way to configure the system (SunOS 4.1.3) to
make it work this way, or does there exist software to do this?

Thanks in advance for any advice.

-- 
Kenton C. Phillips
Computer Systems Manager
MIT Center for Space Research
kenton@space.mit.edu

-----------[000157][next][prev][last][first]----------------------------------------------------
Date:      Wed, 8 Jun 1994 04:32:20 GMT
From:      mfork@dorsai.org (Mike Forkash)
To:        comp.protocols.tcp-ip
Subject:   TCP/IP FAQ?

I'm kinda new to TCP/IP. Is there a FAQ lying around here somewhere?
Thanks in advance.


-- 
**   ** * *  * ***        Mike Forkash - User Deluxe    
* * * * * * *  *\         Mfork@Dorsai.Dorsai.Org
*  *  * * * *  */         Mfork@Cyberspace.org
*     * * *  * ***

-----------[000158][next][prev][last][first]----------------------------------------------------
Date:      Wed, 8 Jun 1994 09:35:28
From:      mscarton@mudshark.sunquest.com (Mark A. Scarton)
To:        comp.protocols.tcp-ip
Subject:   Re: Info request 3-Tiered Architecture

>I am looking for information on  Triple tiered client/server architectures 
>(or 3-tiered).  Looking for pros and cons for this form of client/server 
>architecture; experiences, good or bad with implementation; identification 
>of products; pitfalls for the unwary; standards, documentation and references.

The principle issue seems to be how to abstract the "business logic" of the
application from both client and server, even when the server is essentially
a data "sink" such as a DBMS.  Done well, the idea is that you thereby
reduce the algorithmic tangling of logical constructs, lowering the cost of
modification and enhancement and increasing the generality of both client
and server components [reuse].

My experiences with 3-tier have been positive so far.  The performance
penalty associated with the addtional layer must be controlled, a la
Transarc's Encina or Sybase registered procedures.  Squeeky clean
transport and data protocol boundaries are key.

The main difficulty seems to be that it takes a higher level of design[er] 
sophistication andit is much more difficult to convey to management, 
particularly upper level.  Many of them just got to the point where they 
understand moving independentlogic components off of the primary [server] 
machine.  An additional problem that I've faced is that you often end up
wanting to use different languages and tool sets on the various platforms
that require that you reimplement the same classes/methods multiple
times.  For example, our current client is Visual C++ on Windows.  The
servers are C and Sybase (with its stored procedures, triggers, and
registered procedures).  Much of the existing middleware is sybperl.
========================================================================
Mark A. Scarton, ABD                 | Sunquest Information Systems
801/278-7597, fax 278-0192           | 4505 S. Wasatch Blvd Suite 100
mscarton@mudshark.sunquest.com       | Salt Lake City, Utah  84124
========================================================================

-----------[000159][next][prev][last][first]----------------------------------------------------
Date:      8 Jun 1994 05:33:18 GMT
From:      tli@cisco.com (Tony Li)
To:        comp.protocols.tcp-ip
Subject:   Re: Limiting IP Broadcasting

In article <46171@mindlink.bc.ca> KCARPENT@mindlink.bc.ca (Ken Carpenter)
writes: 

    I am trying to find a way to limit the number of packets generated when
    performing a broadcast over an internetwork of Ethernet subnets.  ...
    In the presence of loops, however, an enourmous number of packets will
    be generated unless the Gateway can be smarter about forwarding the
    broadcasts.
    
    If anyone has solved this problem before (as I am sure someone MUST have),
    please enlighten me either here, or via email.
    
cisco routers have the ability to compute a spanning tree and to forward
UDP broadcasts along the spanning tree.  This eliminates problems with
duplicates, allows you to have a robust topology for unicast routing, and
fail-over for limited broadcast distribution.

Tony Li
cisco Engineering

-----------[000160][next][prev][last][first]----------------------------------------------------
Date:      8 Jun 1994 05:59:14 GMT
From:      shair@uiuc.edu (Bob Shair)
To:        comp.sys.ibm.pc.rt,comp.protocols.tcp-ip
Subject:   Re: Networking the old IBM RT-PC

gpalmer@blue.weeg.uiowa.edu (Gary Palmer) writes:


>Does anyone have experience in networking the IBM RT-PC (model 6150)
>to an ethernet network with TCP/IP?
>
>I have the IBM baseband ethernet card and have loaded the TCP/IP software.
>The hardware diagnostics seem to indicate that there is a good connection
>back to the network.  But I cannot ping to/from the RT-PC.  A few attempts
>to ping out result in an error message and the network software shutting
>down.

Well, if no one else will answer...  are you still down?

Yes, I have done this, but not for years.  As I recall, the only
problem which arose frequently was having the ?interrupt level?
of the card set wrong.  

What error message?
-- 

Bob Shair                          shair@uiuc.edu
Open Systems Specialist    	   SHAIR@UIUCVMD (bitnet)
Champaign, Illinois		   217/356-2684

-----------[000161][next][prev][last][first]----------------------------------------------------
Date:      8 Jun 94 06:02:29 GMT
From:      ddl@harvard.edu (Dan Lanciani)
To:        comp.os.os2.networking.tcp-ip,comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject:   Re: Talk won't connect (TCPIP 2.0)

[I'm cross posting this because the question comes up every few months and
this is the most complete answer I've written...]

In article <paulf.771021450@abercrombie.Stanford.EDU>, paulf@abercrombie.Stanford.EDU (Paul Flaherty) writes:

| In a word, endianism.  The original talk program (4.2bsd on a VAX) code was
| endian sensitive, so big endian machines (motorola, sun) won't talk to
| little endian (DEC, Intel) boxes.  Annoying as heck.

It's even worse than that.  The original protocol was also sensitive to
structure packing!  The vax unix compiler aligns longs on long boundaries
while the sun2/3 compiler packs them on short boundaries.  Sure enough, one
of the talk packets had a non-padded long.

Now, a clever programmer somewhere noticed that you could usually tell
(by looking at the address family field in one of the sockaddr structures)
whether you were receiving vax-style or sun2/3-style packets.  (The
heuristic failed sometimes if the id word had a "2" byte in the wrong
place.  This would lead to situations where an initial talk request
would return an unpleasant error about bad addresses, but subsequent
requests would work.)  Anyway, conditional code was added to talk/talkd
so that both the sun2/3 version and the vax version could understand
native packets from the other.  Note that translation was done on
input only--no attempt was made to respond in kind.  Life was good
for a while and everybody could talk to everybody else.  (We can ignore
the special protocol version with 16-byte user names that Harvard used
for a while.  We can also ignore the protocol that would have resulted
by simply compiling the talk source on a pdp-11--it was easy enough
to cause it to mimic a vax instead. :)

Then along came the sun4.  It had sun2/3-style byte order but
vax-style structure packing.  For reasons that I will never comprehend,
Sun chose to allow sun4 talkd programs to emit ``native'' format packets,
thus creating a third form of the protocol.  At about that time, Sun
also changed the heuristic in talk to deal with sun2/3 and sun4 cases,
but not the vax case.  (It's important to understand that the structure
packing problem exists only in response packets while the byte order
problem exists in both request and response packets.  Therefore, sun4
request packets already look like sun2/3 request packets and it wasn't
necessary to change talkd.)  This broke several combinations that had
worked before, and didn't make any new sun<->non-sun combination work.

My own PC otalk/otalkd programs had always sent vax-style packets
(padded) while understanding vax and sun2/3-style packets.  It was
simple enough to get otalk to understand all of vax, sun2/3, and
sun4 responses by looking at the length of the packet in addition to
the byte order.  But, if you followed the convoluted explanation above,
you will see that input translation alone is no longer enough.  It
was necessary to make otalkd send response packets that correspond
to the requests that it receives.  Of course, it isn't possible to
distinguish a sun4-style request from a sun2/3-style request so one
sends sun2/3-style responses for either.  (This doesn't hurt anything
since the sun4 client already has to deal with true sun2/3 servers.)

At this point, I thought I had achieved complete interoperability
without requiring users to pester their administrators to install
ntalk on all their Suns.  Alas, somehow the sun4 talkd has picked
up a sign-extension bug in its byte-swapping code.  The IP address
will get 1-filled if its third byte has the high bit set.  So the
final answer is that, given the right PC talk programs, you can
talk to anybody unless he/she is on a sun4 and your IP address
a.b.c.d has c > 127.

				Dan Lanciani
				ddl@harvard.*

-----------[000162][next][prev][last][first]----------------------------------------------------
Date:      Wed, 08 Jun 1994 18:02:03 -0500
From:      resnick@uiuc.edu (Pete Resnick)
To:        comp.protocols.tcp-ip
Subject:   Re: Fetch for the Mac?

In article <michael_munoz-080694142838@m21124.esl.com>,
michael_munoz@smtp.esl.com (Michael D. Munoz) wrote:

>Please disregard if this is in the wrong place, can anyone tell me where I
>can get a copy of " Fetch " for the mac

The home site for Fetch is ftp.dartmouth.edu. The better group to ask
questions about this program is comp.sys.mac.comm.

pr
-- 
Pete Resnick    	(...so what is a mojo, and why would one be rising?)
Doctoral Student - Philosophy Department, Gregory Hall, UIUC
System manager - Cognitive Science Group, Beckman Institute, UIUC
Internet: resnick@uiuc.edu

-----------[000163][next][prev][last][first]----------------------------------------------------
Date:      8 Jun 94 09:43:44 +0200
From:      ivo.drvaric@ext.uni-mb.si
To:        comp.protocols.tcp-ip
Subject:   Tcp/IP and Ethernet performance per Query

	Hello !

I have a problem that i can't solve by myself.
I have to make a decision between two architectures.
First is Client-Server with Ethernet and TCP/IP protocol
( where we plan Etherne in the house on twisted -pair, and on digital
 leased lines (48Kb or 64Kb lines ) ).
The second architecture is distribute environment with refreshment of 
central
database on some delta time intervals.
I would like make a calculation where parameter would be the length 
of longest and average query.
But i would need some actual data on the length of administration data
in TCP/IP protocol, then some data on Ethernet.
Can somebody help me?


-----------[000164][next][prev][last][first]----------------------------------------------------
Date:      Wed, 08 Jun 1994 14:45:41 GMT
From:      larryp@sco.COM (Larry Philps)
To:        biz.sco.general,comp.unix.programmer,comp.protocols.tcp-ip
Subject:   Re: Problem with limited number of clients to TLI server solved

In <2t4b34$4uq@gulfa.ods.gulfnet.kw> john@gulfa.ods.gulfnet.kw (John Temples) writes:

> I went through the manuals and did find a couple of kernel tunable
> parameters related to TLI: NUMTIM and NUMTRW.  The fact that these were
> both set to 48 -- twice the number of clients I could connect -- made
> me suspicious.  Not heeding the manual's ominous warning that "Users
> should not modify this parameter," I increased them both to 120, and my
> problem was solved.

You are right the ODT 3.0 manual does say that.  I will report this,
it is an error.  Not only can you tune these, the manual tels you on page
625 that Lan Manager client raises these to 128.

> SCO: If you haven't already, please fix the manuals so they A) document
> the meaning of the ENOSPC return from t_open(),

I will report this also.  A major problem is the ENOSPC is kind of
over used and that error can mean too many things.

> B) Explain that NUMTRW
> actually controls the number of TLI connections allowed,

Actually, it was almost certainly the NUMTIM value that was biting you.
The NUMTRW controls the number tirdwr modules pushed onto the stream which
only happens when you want to use the read and write system calls on a
TLI stream.  Not many things do this.

NUMTIM controls the number of timod modules, which is the kernel half
of the TLI protocol, ie. the part that talks with the user space TLI
library.  _Every_ TLI connection needs one of these.

---
Larry Philps              Senior Software Engineer            larryp@sco.com
SCO Canada, Inc., 130 Bloor St. West, 10th floor, Toronto, Ontario.  M5S 1N5
Phone: (416) 922-1937                                    Fax: (416) 922-2704

-----------[000165][next][prev][last][first]----------------------------------------------------
Date:      8 Jun 1994 15:44:29 GMT
From:      koning@koning.enet.dec.com (Paul Koning)
To:        comp.networks,comp.org.ieee,comp.protocols.tcp-ip,comp.dcom.lans.ethernet
Subject:   Re: mac layer addresses


In article <BILLW.94Jun7180601@glare.cisco.com>, billw@glare.cisco.com (William ) writes:
|>    Physical interfaces are supposed to be unique. One MAC physical
|>    address per port, one port per MAC physical address. MAC group
|>    addresses, of course, can be assigned to many ports.
|>
|>Actually, several companies, including two of the inventors of ethernet,
|>seem to believe (or used to believe) that there was one MAC address per
|>node, regardless of how many ports there were on that node.

I wouldn't put it that way.  What IS the case is that some protocols
effectively map a node address to a particular single MAC address.

Note that the standard DOES allow that (provided that the addresses are
"locally administered" which at least in the case of DECnet they are).
However, if you do this then you cannot bridge the multiple interfaces
of a single node.  That's a well-documented restriction.  If you don't
put bridges between the interfaces, then all this is entirely legal and
reasonable.

	paul
!-----------------------------------------------------------------------
! Paul Koning, NI1D, B-16504
! Digital Equipment Co., LKG1-2/A19, Littleton, MA 01460, USA
! phone: (508) 486-7313, fax: (508) 486-5279, koning@koning.enet.dec.com
!-----------------------------------------------------------------------
! "The only purpose for which power can be rightfully exercised over 
!  any member of a civilized community, against his will, is to prevent
!  harm to others.  His own good, either physical or moral, is not
!  a sufficient warrant."    -- John Stuart Mill, "On Liberty" 1859


-----------[000166][next][prev][last][first]----------------------------------------------------
Date:      Wed, 8 Jun 1994 16:28:18 GMT
From:      mvm@cbnewsb.cb.att.com (michael.v.murphy)
To:        comp.protocols.tcp-ip
Subject:   Deadlock situation

	The project we are currently working on entails a the use of tli calls
between distrubuted machines (unix and mvs). The mvs side does updates to
a database; and when a deadlock occures it automatically kills a process. We
would like to deal with this situation gracefully, and have code the following
tli sequences:

		Client				Server
		------				------

		t_open				t_open
		t_bind				t_bind
		t_listen			t_connect
		t_accept			
		t_snd				t_rcv
		t_rcv
		-------------  Deadlock --------------- (server process dies)
                t_listen                        t_connect
                t_accept                        
                t_snd                           t_rcv
                t_rcv				t_snd
		t_close				t_close

	When the deadlock occurs, the client is blocked to recieve the data and
the server sends a async disconnect after it is killed off by mvs. We want to
capture this disconnect and loop back into the listen on the same bound port
(as shown). For some reason our 2nd t_listen is failing with an "asynch event 
has occured" error and t_look of 10 which maps to DISCONN (even though getstate
shows the connection is T_IDLE). Our question: is there any reason why we can't
use the connection after the server connection has been killed. Do we have to
start with a new open/bind? Any insight would be greatly appreciated...

						Mike Murphy
						mvmurphy@attmail.att.com

-----------[000167][next][prev][last][first]----------------------------------------------------
Date:      8 Jun 1994 18:44:05 GMT
From:      booloo@framsparc.ocf.llnl.gov (Mark Boolootian)
To:        comp.protocols.tcp-ip
Subject:   What is the MTU of FDDI?

I'm trying to get some agreement on MTU between hosts and routers on one of
our FDDI rings, and I've realized that I don't know what the "appropriate"
MTU should be.

My understanding is that the true MTU for FDDI is 4500 bytes.  However, I 
have found a recommended value of 4470 in an NSC router manual, I've seen
defaults of 4352 on both RS/6000s and Sun 4s, and have been told that 4096
is the default for at least one router vendor.

Clearly, 4096 would be a poor choice, as 4096 is a nice size for
allocating memory.  4136 would be better which would account for the TCP/IP
header.  But since we've still got some headroom, why not bump it up so
that packets with TCP/IP options don't need to be fragmented?  

Can anyone explain why choices like 4352 or 4470 were made.  Vernon, can you
tell me what SGI recommends?  A popular, although not uniformly used, 
Ethernet MTU is 1500 bytes.  Does any such MTU exist for FDDI, or is there
really a lot of disagreement?

Any help is, as always, greatly appreciated.

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

-----------[000168][next][prev][last][first]----------------------------------------------------
Date:      8 Jun 1994 18:59:16 GMT
From:      barmar@think.com (Barry Margolin)
To:        comp.protocols.tcp-ip
Subject:   Re: Questions about tcp-ip not in FAQ.

In article <jGTxjmoZjyGJ064yn@msen.com> brain@mail.msen.com writes:
>In APPC, most implementations provide a program launch capability similar to
>inetd server capabilities.  Can someone detail how inetd works?  If it uses
>RAW sockets to do special stuff, can someone point me to a text that describes
>what special functions that tcp-ip has to offer?

inetd doesn't do anything special.  It just binds to all the ports in
inetd.conf, and when a TCP connection or UDP packet comes in it forks a
subprocess, dup()s the socket to the standard file descriptors, and exec's
the specified server program.  I think there's a sample implementation of
inetd in Richard Stevens's "Unix Network Programming".

>I have gotten spoiled with other protocols abilities to post my semaphore 
>whenever something is received from the channel.  I realize that standard
>sockets does not provide this, but does anyone have an extension that does 
>this? (MS/IBM/...)

You can use select() to wait for something to come in on any of multiple
sockets.

>Since my first implementation is for OS/2, followed by UNIX, I would like
>those who have done the same answer me.  Is there some sample code available
>on the net that I can compile and play with to see how sockets code is
>written?

ftp.uu.net has the examples from the above book.
-- 
Barry Margolin
System Manager, Thinking Machines Corp.

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

-----------[000169][next][prev][last][first]----------------------------------------------------
Date:      8 Jun 1994 18:59:40 GMT
From:      john@iastate.edu (John Hascall)
To:        comp.protocols.misc,comp.protocols.ppp,comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject:   Re: Problems with Trumpet Winsock, SLIP ans UDP

Robert D. Clay <CLAY@ucssun1.sdsu.edu> wrote:
}I have been successful in getting Trumpet Winsock to run in internal Slip mode
}with one exception:  I can only access hosts by IP number.  When I try by
}name, I get the following error dump.  This has me stumped.  I am unable to
}determine why I am getting this IP checksum error.  At first I thought I had
}my modem configured wrong, and that it was not properly doing error
}correction.  I have ruled out this possibility.  I am using LAPM.  Do you
}have any ideas?  The only clue I have is that TCP works, and UDP does not.

  Well, I managed to botch my previous reply.  Anyway, because

    0x11 == XON == IPPROTO_UDP

  this is almost a sure sign that your modem(s) is(are) dropping XON/XOFF.

  Some (many? most? all?) modems have a "pass/don't pass XON/XOFF"
  flags in addition to the select XON/XOFF vs hardware flow control flag.

John
-- 
John Hascall                   ``An ill-chosen word is the fool's messenger.''
Systems Software Engineer
Project Vincent
Iowa State University Computation Center  +  Ames, IA  50011  +  515/294-9551

-----------[000170][next][prev][last][first]----------------------------------------------------
Date:      Wed, 8 Jun 1994 19:39:55 GMT
From:      mccoll@cse.uta.edu (Roddy McColl)
To:        comp.protocols.tcp-ip,alt.winsock
Subject:   help with slip please

I am trying to set up a SLIP server on a Sparcstation 2, running SunOS
4.4.1. I have obtained cslip-2.7 and installed the software.

I am running Windows Sockets on a PC with ethernet and modem access,
so I am using this machine to test proper SLIP connections.

I find that under SLIP, I can only connect to the Sparc station
providing the sliplogin, but I cannot connect to any other machine on
the network, nor can I connect to the campus name server and get off campus.

When I put the winsock trace on IP packets, I see the following for
connections to the Sparcstation (129.112.104.5) from the PC
(129.112.104.129) :-

IP 129.112.104.129 -> 129.112.104.5 len 44 prot 6
IP 129.112.104.5 -> 129.112.104.129 len 46 prot 6

etc and I can launch WinQCT/Net telnet or ftp etc.

But if I try to connect to other machines on the network which have IP
addresses contained in the host tables of both Sparc and PC, I get the
following trace :-

IP 129.112.104.129 -> 129.112.104.1 len 44 prot 6
IP 129.112.104.129 -> 129.112.104.1 len 44 prot 6
IP 129.112.104.129 -> 129.112.104.1 len 44 prot 6
IP 129.112.104.129 -> 129.112.104.1 len 44 prot 6
.
.
.

etc with never any reply back.
I suspect that the problem is therefore with the slip running on the Sparc.

Note that my winsock setup has the Gateway as 129.112.101.254 which is
the campus Internet gateway, and the campus nameserver as
129.112.101.112 which is the campus name server. This works fine for
E-net connections.

Following sliplogin, the slip.login script executes the following
(found from echoing the execution to a disk file) :-

slifconfig sl0 129.112.104.5 129.112.104.129 netmask 0xffff0000
route -n delete default 129.112.104.129
route -n add default 129.112.104.129 1
route set default 129.112.104.129 mtu 552

I wonder if there is no understood route for packets through the Slip
server onto the network, or perhaps back from the network through the
Slip server to the PC ?

I have not set the Sparc up for dialing out, so there is no device cua0
and there is no entry for such a device in my /etc/ttytab.

Most suggestions gratefully received, and I will summarize responses
to the net if necessary.

Thanks

       -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
         Roddy McColl                     
         Assistant Professor of Radiology
         Radiology Imaging Center     
         UT Southwestern Medical Center at Dallas
         5323 Harry Hines Blvd
         Dallas TX 75235-9058 
         (214) 648-2910
         (214) 648-4538 FAX            roddy@mri.swmed.EDU
       -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-



-----------[000171][next][prev][last][first]----------------------------------------------------
Date:      8 Jun 1994 14:46:44 +0300
From:      john@gulfa.ods.gulfnet.kw (John Temples)
To:        biz.sco.general,comp.unix.programmer,comp.protocols.tcp-ip
Subject:   Problem with limited number of clients to TLI server solved


I had a problem with a TLI-based server on SCO 3.2v4.1, in that I could
only connect 24 clients to it before getting an undocumented ENOSPC
error from t_open().  Several netters suggested I was out of file
descriptors, but that wasn't the case -- the same server rewritten 
using sockets allowed the expected 60 clients to connect.

I went through the manuals and did find a couple of kernel tunable
parameters related to TLI: NUMTIM and NUMTRW.  The fact that these were
both set to 48 -- twice the number of clients I could connect -- made
me suspicious.  Not heeding the manual's ominous warning that "Users
should not modify this parameter," I increased them both to 120, and my
problem was solved.

SCO: If you haven't already, please fix the manuals so they A) document
the meaning of the ENOSPC return from t_open(), B) Explain that NUMTRW
actually controls the number of TLI connections allowed, and C) removes
the warning about not modifying parameters that are safe to modify.
-- 
John W. Temples, III       ||       Providing the only public access Internet
Gulfnet Kuwait             ||            site in the Arabian Gulf region

-----------[000172][next][prev][last][first]----------------------------------------------------
Date:      Wed, 8 Jun 1994 19:54:15 GMT
From:      ronf@phx.sectel.mot.com (Ron Feigen)
To:        comp.protocols.tcp-ip
Subject:   Re: NetManage Chameleon for Windows and SLIP

If you use Trumpet you can connect manually then just type "SLIP" to enter slip
mode.  Cameleon probably allows something similar.  Why not try their support line?


In article bnp@homer.cs.mcgill.ca, rbaroody@cs.mcgill.ca (Ramzi BAROODY) writes:
>
>Hello,
>
>I am trying to use NetManage's Chameleon (version 3.10) TCP/IP for Windows
>to connect to Internet through a SLIP address.  However, the problem
>is that Chameleon keeps insisting on dialing the phone number and connecting
>automatically using a simple script language.  I can never seem to get
>connected, probably because the connection procedure on the SLIP server
>side is a bit complicated.  Is there a way I could connect manually?  Or
>maybe I could connect through another dialer and then have Chameleon take
>over from there?   The manual was not much of a help.  I would appreciate
>any suggestions.
>
>Thanks
>
>Ramzi
>
>-- 
>
>





-----------[000173][next][prev][last][first]----------------------------------------------------
Date:      8 Jun 1994 20:01:00 GMT
From:      fjl0014@ucs.usl.edu (Lombardo Fernando J)
To:        comp.protocols.tcp-ip
Subject:   HELP FINDING traceroute

Hi!
I'm trying to find a program called traceroute for a friend of mine.
I was wondering if anyone out there can help me with this. Thank you
in advance...
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
                          Fernando Lombardo
 Univ. of Southwestern Louisiana      EECE              DA CAJUNS!!!  
fjl@trakker.mcdermott.com  fernando.lombardo@nola.mcdermott.com(SUMMER) 
             fjl0014@usl.edu              f.lombardo@ieee.org  
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 


-----------[000174][next][prev][last][first]----------------------------------------------------
Date:      8 Jun 1994 21:45:43 GMT
From:      spurgeon@ccwf.cc.utexas.edu (Charles Spurgeon)
To:        comp.networks,comp.org.ieee,comp.protocols.tcp-ip,comp.dcom.lans.ethernet
Subject:   Re: mac layer addresses

In article <BILLW.94Jun7180601@glare.cisco.com> billw@glare.cisco.com (William ) writes:
>    Physical interfaces are supposed to be unique. One MAC physical
>    address per port, one port per MAC physical address. MAC group
>    addresses, of course, can be assigned to many ports.
>
>Actually, several companies, including two of the inventors of ethernet,
>seem to believe (or used to believe) that there was one MAC address per
>node, regardless of how many ports there were on that node.

Funny you should mention that, since I had just dug out one of the
original papers on this from my piling system to show someone where
the 48-bit addresses came from.  

It makes interesting reading since it lays out a vision that always
views the operation of the LAN as part of a large internetwork filled
with all manner of network technologies.  That's an impressively
forward-looking view given the state of networking in the early 1980s.
(Or today, for that matter.)

It's a PARC "blue-and-white" technical report by Yohen Dalal and
Robert Printis entitled "48-bit Absolute Internet and Ethernet Host
Numbers."  OPD-T8101, July 1981

The abstract reads: "Xerox internets and Ethernet local computer
networks use 48-bit absolute host numbers.  This is a radical
departure from practices currently in use in internetwork systems and
local networks. ..."  

An excerpt from the main document: 
"We view the Ethernet local network as one component in a
store-and-forward datagram *internetwork* system that provides
communications services to many diverse devices connected to different
networks." (emphasis theirs)

The authors make it clear that they were designing for complex
internets and wanted an end-node identifier that would persist for
each host, to avoid the requirement that hosts be re-addressed when
moved.  

In their view, this number would provide a host identity independent
of the network addressing structure.  The network address would be
another number, dynamically obtained from a network server when the
host required internet access.

They mention the decision to use one 48-bit number per host in their
summary.  They also note in the paper that a host with multiple
interfaces *could* have multiple 48-bit numbers, one of which was
chosen to be the host's internet identity.  They note that when this
happens, "the mapping from internet address to local address is now
more cumbersome."

From the summary:
"We believe that all hosts should have a unique physical host number
independent of the type or number of networks to which they are
physically connected. ...

As a policy decision our internetwork architecture legislates that a
host (multiply) connected to one or more Ethernet local networks has
the same physical host number on each one.

In summary, absolute host numbers have the following properties:
	o they permit hosts to be added to, or removed from networks
on the internetwork with minimum administrative overhead.
	o they permit mapping internet addresses to network addresses
during encapsulation without translation.
	o they permit the separation of routing from addressing, which
is especially useful in internetworks with multihomed or mobile hosts.
	o they provide the basis for unique identification of files,
programs and other objects on stand-alone and networked hosts.
	o they support multicast, or the delivery of data to a group
of recipients rather than to a single physical host."







-- 

Charles Spurgeon		Campus Networking
c.spurgeon@utexas.edu		University of Texas at Austin
(512) 471-3241 ex 265		Room COM1, Austin TX 78712

-----------[000175][next][prev][last][first]----------------------------------------------------
Date:      8 Jun 94 22:00:18 GMT
From:      shuenn@tora.swdc.stratus.com (serene2)
To:        comp.protocols.tcp-ip
Subject:   link-layer multiplexing

Hi there,
	Does anyone know/familiar with this concept described in rfc1122
3.3.4,

            Finally, we note another possibility that is NOT
            multihoming:  one logical interface may be bound to multiple
            physical interfaces, in order to increase the reliability or
            throughput between directly connected machines by providing
            alternative physical paths between them.  For instance, two
            systems might be connected by multiple point-to-point links.
            We call this "link-layer multiplexing".  With link-layer
            multiplexing, the protocols above the link layer are unaware
            that multiple physical interfaces are present; the link-
            layer device driver is responsible for multiplexing and
            routing packets across the physical interfaces.

I'm looking for any protocol, standard, rfcs, etc. might have being
developed for this concept. Please respond by email since my host doesn't
save all the news.


thanks,
-shuenn@swdc.stratus.com

-----------[000176][next][prev][last][first]----------------------------------------------------
Date:      08 Jun 1994 22:38:54 GMT
From:      jtw@lcs.mit.edu (John Wroclawski)
To:        comp.protocols.tcp-ip
Subject:   Re: Voice

In article <kymaCqxK9s.93G@netcom.com> kyma@netcom.com (Matt Young) writes:

   : Are you talking about "live" voice or data files? Assuming you are
   : talking about live voice,

   Yes, live interactive. ...

   Is RVSP like a call set up?  Does one issue an RSVP to modify the
   delay and throughput characteristics of a particular connection?

That's about right, although the internet work does not focus on
traditional point-to-point connections - for example it is supportive
of the IP multicast "drop in" model where different people may join
and leave a conversation at random times.

The current draft of the RSVP protocol specification is available as
an internet draft (internet drafts are the "working documents" of the
internet engineering community). The file is available for anonymous
FTP as "internet-drafts/draft-ietf-rsvp-spec-02.txt" on any of the
IETF's archive servers. ds.internic.net is one such server, though
there are better ones if you are not in the northeastern US.

A nice overview article about RSVP appeared in the September, 1993
issue of IEEE Network magazine.

   What is used to identify a connection that has resource reservation?
   It must be identified in intermediate nodes, is their a resource
   ID associated with a particular Source-Destination IP pair?

RSVP has a flexible reservation model. Using RSVP one can talk about
things like "enough bandwidth for three people to talk to me at once"
or "I'm talking to Bob, Carol, Ted, and Alice" or "reserve bandwidth
for any one of Mike, Sue, and Sally, and right now I'm listening to
Sue but please make sure the b/w is there if I want to switch to Sally
later".

The exact information used to identify data flows covered by a
reservation depends on the type of reservation in use, although the
destination IP address, protocol, and port almost always figure into
it.

   Explain a little more about STII.  Is it lighter weight IP?
   What does it claim to have that IP doesn't have?  

I would call ST-II heavier weight than IP, in that it contains within
a single protocol several functions, such as routing and resource
setup, that are provided by separate protocols in the IP model. It is
much more traditionally connection oriented than the IP/RSVP approach.

   Explain the issues regarding next generation IP?  Is easier IP
   switching an issues?  How about a VCI style address option?

Yes, the issue is making it easier to match up a packet arriving at a
router with the state needed to process that packet. This state will
be used for many things - routing, resource management, perhaps some
security functions, and so on. So any mechanism that makes this lookup
faster will improve performance in many ways.

IP is and will remain a connectionless protocol. I don't think you'll
see a "VCI style address option" in the narrow sense of the word. But,
there are ways to speed up this state lookup in a quasi-connectionless
environment, and some of these are being considered for
next-generation IP. They revolve around making it easy for routers to
cache frequently used state information, and making it easy to match
an arriving packet to an entry in the cache. In that way they are
quite similar to what a VCI does in a connection-oriented environment.

   : A number of research and advanced development projects are
   : demonstrating the possibilities of this technology today. The MBONE is
   : a large (800+ network, 20+ countries) virtual network embedded in the
   : internet which supports multicast distribution of audio and video
   : programs, among other things.  

   Great, what form of the various directions mentioned above are 
   they using.  Is this being demoed with standard IP using the 
   RSVP mechanism?

At the moment it is being done with standard IP without using a
reservation mechanism. From this experiment people are learning a lot
about how to write voice applications which work well with varying
resource levels and network errors. Rather than being strictly
isochronous, these applications "adapt" to the level of service they
are receiving at the time.

This capability will continue to be important in a system with
resource reservations. It will allow you to reserve (and pay for)
resources sufficient to give the minimum quality you need at a given
time. If you reserve more resources, the same application will give
better quality. If the network is not fully loaded, the same
application will give better quality. If the network is not heavily
loaded, the same application will operate well with no specifically
reserved resources at all (== lower cost) - this may be perfectly
acceptable for, say, a quick chat among friends, even though you would
want a reservation for your remote piano recital later that evening.

   : First, experiments over several years have demonstrated that b/w
   : management is not always required at the local ethernet level.

   You mean if someone makes a long file transfer, then my phone
   call isn't bashed?  Don't we have to at least limit packet sizes?
   Is a corporation going to place critical white board activities
   in an environment where long file transfers shake thing up?

Yes, exactly. I realise many people find this a counter-intuitive
result, but we and others routinely run teleconferences on fairly
loaded ethernets with good performance. This is because of the
adaptive nature of the applications, as described above.

This is not to say that bandwidth control mechanisms are not required
in the general case. It may suggest, however, that the mechanism can
provide looser control than is commonly believed.

   And I assume that SNMP management will cross all layers, allowing
   some semblence of uniform monitoring, if not control.

Yes, I'd assume that SNMP will continue to be used for traditional
network management functions, such as monitoring the performance of
routers and hosts. 

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


-----------[000177][next][prev][last][first]----------------------------------------------------
Date:      Thu, 9 Jun 1994 00:33:41 GMT
From:      mccoll@cse.uta.edu (Roddy McColl)
To:        comp.protocols.tcp-ip
Subject:   cslip 2.7 on Sparc 2 SunOS 4.1.1 server dropping packets

I am trying to set up a SLIP server on a Sparcstation 2, running SunOS
4.1.1. I have obtained cslip-2.7 and installed the software.

I am running Windows Sockets on a PC with ethernet and modem access,
so I am using this machine to test proper SLIP connections.

I find that under SLIP, I can only connect to the Sparc station
providing the sliplogin, but I cannot connect to any other machine on
the network, nor can I connect to the campus name server and get off campus.

When I put the winsock trace on IP packets, I see the following for
connections to the Sparcstation (129.112.104.5) from the PC
(129.112.104.129) :-

IP 129.112.104.129 -> 129.112.104.5 len 44 prot 6
IP 129.112.104.5 -> 129.112.104.129 len 46 prot 6

etc and I can launch WinQCT/Net telnet or ftp etc.

But if I try to connect to other machines on the network which have IP
addresses contained in the host tables of both Sparc and PC, I get the
following trace :-

IP 129.112.104.129 -> 129.112.104.1 len 44 prot 6
IP 129.112.104.129 -> 129.112.104.1 len 44 prot 6
IP 129.112.104.129 -> 129.112.104.1 len 44 prot 6
IP 129.112.104.129 -> 129.112.104.1 len 44 prot 6
.
.
.

etc with never any reply back.
I suspect that the problem is therefore with the slip running on the Sparc.

Note that my winsock setup has the Gateway as 129.112.101.254 which is
the campus Internet gateway, and the campus nameserver as
129.112.101.112 which is the campus name server. This works fine for
E-net connections.

Following sliplogin, the slip.login script executes the following
(found from echoing the execution to a disk file) :-

slifconfig sl0 129.112.104.5 129.112.104.129 netmask 0xffff0000
route -n delete default 129.112.104.129
route -n add default 129.112.104.129 1
route set default 129.112.104.129 mtu 552

where ``slifconfig'' is the name of the SLIP-ready ifconfig supplied
with cslip-2.7.

Running ``slinfo'' reveals :-

	if_unit		if_mtu		if_addr		ia_net
	      0		   552	  129.112.104.5	   129.112.0.0
    ifa_dstaddr     ia_netmask        ia_subnet  ia_subnetmask	
129.112.104.129    255.255.0.0      129.112.0.0    255.255.0.0

and various other stats.

I wonder if there is no understood route for packets through the Slip

server onto the network, or perhaps back from the network through the
Slip server to the PC ?

Most suggestions gratefully received, and I will summarize responses
to the net if necessary.

Thanks

       -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
         Roddy McColl                     
         Assistant Professor of Radiology
         Radiology Imaging Center     
         UT Southwestern Medical Center at Dallas
         5323 Harry Hines Blvd
         Dallas TX 75235-9058 
         (214) 648-2910
         (214) 648-4538 FAX            roddy@mri.swmed.EDU
       -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-



-----------[000178][next][prev][last][first]----------------------------------------------------
Date:      9 Jun 1994 09:15:41 -0500
From:      mikea@MCS.COM (Mike Andrews)
To:        comp.dcom.sys.cisco,comp.protocols.tcp-ip
Subject:   Re: IPX over PPP over serial line between CS500 and PC.

In article <CqxC18.634@freenet.carleton.ca>,
Ron Woodall <at760@FreeNet.Carleton.CA> wrote:
>
>
>In a previous article, Doug@rds.com (Doug Kaye) says:
>
>>In article <1994May31.084634.4000@vms.huji.ac.il> yehavi@vms.huji.ac.il writes:
>>>  We would like to connect PC's running IPX to our network using dial-in lines
>>>with CS500 terminal server. Assuming I turn-on IPX processing on the CS500 and
>>>want to use it inside PPP, what should I do on the PC? Is there some additional
>>>software package that can be installed on the PC to enable it to pass IPX
>>>inside PPP over serial line? Our Novell people say that it is currently
>>>possible to do it only by encapsulating IPX inside IP.
>>
>>I believe your Novell people are correct.  We live in that world and I don't 
>>know of any IPX implementations over PPP.
>>
>>    ...doug
>
>
>Hy guys: I have heard of one installation of IPX running over PPP. Gandalf
>is coming out with a router that will route IPX over PPP. For more info,
>contact HCHAYRA@gandalf.ca and he will put you on the appropriate sales type.
>
>Ron
>-- 
>

Telebit NetBlazers do IPX over PPP.  They've had that for over a year.
The client drivers come with the NetBlazer.  They spoof an ODI stack on the
client PC. You can run IPX and/or TCP/IP over that. Configuration on the client
side is menu driven and really easy to set up.  The NetBlazer PPP link security
supports a cryptic challenge handshake and Kerberos along with a standard
password.

Our experience with it was that it was a bit slow, but it worked.

-- 
Mike Andrews                             mikea@Genesis.MCS.Com
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=
"The chances of Sun today are...uhhhnnnhh...iffy, if that."
       -Brant Miller, Chicago TV weatherman/radio DJ, 03/20/93

-----------[000179][next][prev][last][first]----------------------------------------------------
Date:      09 Jun 1994 01:03:54 GMT
From:      rand@cs.UND.NoDak.edu (Douglas K. Rand)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject:   Mobil laptops

We are starting a project this fall that will give every student a
laptop computer. We will be wiring some class rooms and labs for
Ethernet. Can anyone suggest a method of supplying dynamic IP
addressing? Inside of a single day, one lap top computer may be part
of different networks, even in different buildings.

I've read the RFCs for DHCP and it seems like the solution, but I have
yet to find an implementation. Also, does this situtation require the
cooperation of the client software? (We are looking at winsock that at
best supports BOOTP.) 

Thanks in advance for any info/advice.

PS: Although we have pretty much decided on wire instead of wireless
    (not set in conduit yet, though) does anyone have experience with
    wireless networks in a classroom environment? The classrooms range
    in size from 30 to 130 seats.
--
Douglas K. Rand                                        rand@aero.und.nodak.edu
System/Network Administrator      Scientific Computing Center -- UND Aerospace
Office: +1 701 777 2801                             University of North Dakota
FAX:    +1 701 777 2940                   Box 9022, Grand Forks ND  58202-9022

-----------[000180][next][prev][last][first]----------------------------------------------------
Date:      9 Jun 1994 02:37:00 GMT
From:      boyd@gauss.math.fsu.edu (Mickey Boyd)
To:        comp.sys.sun.admin,comp.protocols.tcp-ip
Subject:   Re: Sparcstation as filtering bridge?

Kenton C. Phillips (kenton@space.mit.edu) wrote:
> I am trying to figure out how to use a Sun Sparcstation with two ethernet
> ports as a filtering bridge.  
> [....]
> If all
> machines on both sides of each bridging Sparcstation are seen as the same
> subnet, then such reconfiguration could be avoided.

It sounds to me as though you just need a bridge (and that it is optional if 
it is the Sun).  I really like the KarlBridge software, which turns a PC 
(286/16 or 386SX/DX) with two SMC Ethernet cards into a nifty filtering 
bridge.  The software is free (they also sell turn-key units), and provides 
the most configurable bridge I have ever worked with.  I have had two running 
for a couple of years now, with no problems.  You do not need a monitor, 
keyboard, or hard disk (you do need a color monitor and a keyboard to 
configure it, but not on the bridge machine itself).  It is available from 
nisca.acs.ohio-state.edu.  By default, is it works as a transparent learning
bridge (which would probably do the trick for you, from the above description).
If you turn on the filtering options, you can bridge or pass packets on 
many different criteria.

Depending on how busy the network is, you could take a perceptable hit in 
performance if you used the Sun as a bridge.  Anyway, Kbridge gives you 
something to do with all those old PCs :-).  Hope that helps.

> That is, I would like to put one port on the
> backbone, and connect one or more computers to the second port, but without
> configuring the second port as a logical subnet (as is the more typical
> arrangement).  [....]
> There are several reasons for this, one of which is that we
> will be putting data acquisition machines on the second port, and we would
> like to be able to move those machines around without having to reassign
> IP addresses and reconfigure routing information with every move.  

A device that sits between logical subnets is typically a router or a 
gateway.  A bridge simply looks at packets and selectively repeats them to 
the other port (depending on whether or not it thinks the destination machine
is on the other side).  Thus, its primary function is to localize traffic 
on either side of, while allowing communications across, the bridge.  If the
Sun that needs to talk to the data acquisition machines does not need to 
talk to other machines (as much), then bridging the Sun and the data acq. 
machines would make sense.

--
******************************************************************************
*                                Mickey Boyd                                 *
*                           Systems Administrator                            *
*              Florida State University Mathematics Department               *
* email:  boyd@math.fsu.edu  Office:  (904) 644-7167  Pager:  (904) 657-6425 *
******************************************************************************

-----------[000181][next][prev][last][first]----------------------------------------------------
Date:      Thu, 09 Jun 1994 16:09:39 -0800
From:      peak@halcyon.com (Paul K. Kim)
To:        comp.protocols.tcp-ip
Subject:   Mosaic 1.0.3 for Mac problem

I run Mosaic 1.0.3 for Mac on my Powerbook with system 7.1 and MacTcp. 
Somehow, when I try to start sometimes, the program fails to load, making
all the title bars and menu fonts huge and reporting a problem...  Any
hints why?

-- 
Paul K. Kim
peak@halcyon.com

-----------[000182][next][prev][last][first]----------------------------------------------------
Date:      Thu, 9 Jun 1994 10:56:50
From:      CAMARA@novell.wd.cubic.com (Raland Camara)
To:        comp.protocols.tcp-ip
Subject:   HP-UX reliable signals and "Unix Network Programming"

In writing a test program under HP-UX, I have discovered some rather 
disturbing results concerning the use of reliable signas and socket I/O.
Hopefully, I am just mistaken or missing some pearl of wisdom.  Under HP-UX
using the sigvector() system call for setting up an interrupt handler, I have
noticed that multiple SIGIO signals are not blocked but instead are ignored.
More specifically when execution is inside of the SIGIO signal handler (setup
by sigvector()), additional SIGIO signals are ignored instead of blocked.
    My understanding of reliable signals comes primarily from "Unix Network
Programming" by W. Richard Stevens.  It states the following concerning
reliable signals:

"A process must be able to prevent selected signals from occurring when
desired.  But we don't want a signal discarded..... Instead we want the signal
remembered, so that when we're ready the signal is delivered.  4.3BSD terms 
this 'blocking' a signal and System V calles it 'holding'  a signal.
While a signal is being delivered to a process, that signal is blocked (held).
By this we mean that if a signal is generated a second time, while the process
is handling its first occurrence, the signal handler is not called again.
Instead, the second occurrence of the signal is remembered.  If the signal
handler that is processing the first occurrence of the signal returns
normally, only then it is called again to handle the remembered signal."

My experience seems contrary to what is described above.  One other peculiar
bit of information,  is in the HP publication "Berkeley IPC Programmer's Guide"
in the sample program "async.clnt.c"  there exists the comment:

"Send data to the server over the streams socket.
This will cause yet another SIGIO interrupt of the server.  In
this case the interrupt will be ignored because the server is
already waiting for data"

(Note: the server that this demo program refers to waits for data inside of 
its SIGIO interrupt handler.)

This also seems contrary to the idea of signals being blocked or remembered.
Am I missing something? Or did I discover/re-discover something?

Raland

-----------[000183][next][prev][last][first]----------------------------------------------------
Date:      9 Jun 94 15:28:18
From:      scott@harbard.gso.saic.com (& Grier)
To:        comp.protocols.tcp-ip
Subject:   Logging anoymous FTP access

Can anyone inform me as to how we can capture and save
the e-mail addresses of people who anonymously ftp on 
to our system?
Scott
scott@gso.saic.com

-----------[000184][next][prev][last][first]----------------------------------------------------
Date:      9 Jun 1994 12:25:51 GMT
From:      longm@firnvx.firn.edu (Michael Long)
To:        comp.protocols.tcp-ip
Subject:   Looking for DNS for Mac and/or Windows?


I am looking for a Domain Name Server for either the Mac or windows platform.
Please no suggestions for Linux or UNIX.  I do not have the time for Linux
and I cannot afford a UNIX box.  I know there is a DNS for DOS/Windows out
there, all I need is the NAME!  I will do an Archie search on it.

If anyone has any suggestions please e-mail me.

Thanks Mike...
*****************************************************************************
Michael Long - Sr. Systems Programmer
Florida State University/Florida Information Resource Network/Florida D.O.E.
E-mail: longm@firnvx.firn.edu         Phone: (904)487-0911
*****************************************************************************

-----------[000185][next][prev][last][first]----------------------------------------------------
Date:      Thu, 9 Jun 1994 13:57:00 GMT
From:      manfredi@rockwell.com (Bert Manfredi, 747-6735)
To:        comp.org.ieee,comp.protocols.tcp-ip,comp.dcom.lans.ethernet
Subject:   Re: mac layer addresses

In article <Cr25Mo.EHp@zoo.toronto.edu>, henry@zoo.toronto.edu (Henry Spencer) writes...
>In article <BILLW.94Jun7180601@glare.cisco.com> billw@glare.cisco.com (William ) writes:
>>Actually, several companies, including two of the inventors of ethernet,
>>seem to believe (or used to believe) that there was one MAC address per
>>node, regardless of how many ports there were on that node.
> 
>In fact, the XNS protocols demand -- or used to demand, anyway -- this
>situation.  This is why the original DIX Ethernet spec explicitly required
>that it be possible to change the address of an Ethernet port from the
>protocol software.  (To understand this, it is helpful to know that XNS
>folks did not have the notion of a mapping between a logical address and
>a MAC address:  an XNS host had one 48-bit address, period.)

Pretty weird. I think that if multi-homed hosts used the same MAC physical
address for each of their ports, and if they also used IP, we'd have a
mess on our hands. Unless, of course, the system designers add in all the
requisite firewalls. Something to ponder.

Bert
manfredi@rockwell.com

-----------[000186][next][prev][last][first]----------------------------------------------------
Date:      9 Jun 1994 21:12:02 -0400
From:      paulrn@aol.com (PaulRN)
To:        comp.protocols.tcp-ip
Subject:   Host volume information

I work in an environment with Macs, Unix workstations, a Vax
mainframe and other stuff on Ethernet.

I frequently FTP our Mac server from my Unix station and would like
to know if there is a way to receive the volume info for the server. 
I need to know the storage space available on the Mac.

The mac runs Mac TCP Connect ][ and allows the usual ftp operations,
but I can't get it to give me volume info.

Thanks.

PRN

-----------[000187][next][prev][last][first]----------------------------------------------------
Date:      9 Jun 1994 16:36:44 GMT
From:      hoehle@inf-wiss.uni-konstanz.de (Joerg-Cyril Hoehle)
To:        comp.protocols.tcp-ip
Subject:   security issues when adding a slip node?

Hi,

We are planning to make the slip access to our modems a little bit
freer than it was before. I'm wondering if there are some security
issues (or holes) that are important if we allow people to start slip
on our dial-in modem and thus get into our UNIX (Sun) network. Every
normal user suddenly becomes root when he's on his own machine at
home. Are there more security holes here than for anyone coming in
through the normal Internet?

Thanks for any information,
 	Joerg Hoehle.
hoehle@inf-wiss.uni-konstanz.de

-----------[000188][next][prev][last][first]----------------------------------------------------
Date:      Thu, 9 Jun 1994 17:39:17 GMT
From:      donp@novell.com (don provan)
To:        comp.protocols.tcp-ip
Subject:   Re: What's the matter with this rips?

In article <199406090955.AA01700@bank.kemerovo.su> sova@bank.kemerovo.su writes:
> Below is a core part of my current network.
>
>       addr   193.124.197.67     193.124.197.66
>       mask   255.255.255.240    255.255.255.240
>                          |      |
>        ----------+-------+------+-----   broadcast 193.124.197.79
>                  |   193.124.197.65
>        mnws      |   255.255.255.240
>           -------+--------
>           | NetWare 3.11 |   LOAD TCPIP FORWARD=YES RIP=YES
>           |              |
>           -------+--------
>                  |   193.124.196.170
>                  |   255.255.255.128   
>    ------+-------+------------------------------+-------------
>          |   193.124.196.131                    |  193.124.196.132
> keeper   |   255.255.255.128           mgw      |  255.255.255.128
>   -------+--------                       -------+--------
>   | BSDI 1.0     |  routed -q            | BSDI 1.1     |  routed -s
>   |              |                       |              |
>   -------+--------                       -------+--------
>          |  Taylor UUCP                         |  193.124.197.49
>          |                                      |  255.255.255.240
>          |                          ------------+----------------------
>     Relcom /EUnet                               |  193.124.197.55
>          |                            decora    |  255.255.255.240
>                                          -------+--------
>                                          | Ultrix 4.3   |   routed -q
>                                          |              |
>                                          ----------------

You've got two errors. The one which is causing your immediate
problem is that you've split the network 193.124.197.x with the
network 193.124.196.x. All subnets of a single network must be
contiguous. Nodes not on any of the subnets view the entire network as
a single entity. They do not have enough information to make a
decision between the two possible routes they know about to the
network, so they will often pick the wrong route.

Your second error is that the network mask 255.255.255.128 is not
allowed for a class C network. The subnet portion of that mask,
0.0.0.128, includes only one bit. The subnet number with all zeros and
the subnet number will all ones are not allowed, so a single bit the
subnet number can contain no permitted subnet numbers. You need to use
a two bit mask, 0.0.0.192, in order to have two subnets. I'm not
exactly sure why this hasn't caused you any problems yet. Once you
clear up the first problem, I feel confident secondary problems will
start to appear if you don't expand the network mask for the
193.124.196.x network.

					don provan
					donp@novell.com

-----------[000189][next][prev][last][first]----------------------------------------------------
Date:      Thu, 09 Jun 1994 20:40:08 GMT
From:      mark@cyantic.com (Mark T. Dornfeld)
To:        comp.protocols.tcp-ip
Subject:   Compile/link problem on DG UX

I'm not sure if this is the proper newsgroup for this posting, but
hopefully some network developers live here who can help me.

I am trying to compile a program supplied by QMS with their network
printers that sends print data from a System V lp spooler to the printer
which is set up as a TCP/IP node on the network.

The linker is looking for a library (libnet.a) which does not exist on DG
UX System Vr4.  I do not know what functions are in libnet.a, so I don't
know where else these functions might be on DG/UX.

The program actually compiles and links without this library, and does not
crash when run.  However, all it does is spit back a list of options to me.

If anyone can help with the library issues, it would be greatly
appreciated.

Thanks in advance.
-- 

Mark T. Dornfeld, Cyantic Systems Corporation       Voice: (416) 621-6166
1 Eva Road Suite 301                            Facsimile: (416) 621-6212
Etobicoke, Ontario, M9C 4Z5 CANADA                  Email: mark@cyantic.com

-----------[000190][next][prev][last][first]----------------------------------------------------
Date:      Thu, 9 Jun 1994 20:56:07 GMT
From:      d00n@crash.cts.com (Kevin Spousta)
To:        comp.protocols.tcp-ip
Subject:   DNS Problems galore.  Somebody help!

Previously I had posted a message regarding multiple hostnames 'pointing' to 
one IP address in the /etc/hosts file on our DNS.  I received a bunch of mail
regarding the 'badness' of multiple A records for one IP, some info on CNAME
records and mail exchange records.  I passed all of this info on to the
keepers of the DNS here and they've managed to completely hose things up.

Here's what I need to accomplish:

I've got WP Office installed in multiple sites, all gating SMTP mail through
the machine, smtpgate.sannet.gov.  For political reasons, I need to 'trick'
this machine into thinking it's also called cd7.sannet.gov, cd1.sannet.gov,
rosecyn.sannet.gov and acctrep.sannet.gov, with more names to come.  I've 
aliased WP Office users as user@cd7.sannet.gov, user@rosecyn.sannet.gov etc
with all SMTP services being handled by the smtpgate machine.

Outbound mail works like a charm and previously with the following entries
in the DNS it worked great:

156.29.1.107	smtpgate.sannet.gov	smtpgate
156.29.1.107	rosecyn.sannet.gov	rosecyn
156.29.1.107	acctrep.sannet.gov	acctrep
156.29.1.107	cd1.sannet.gov		cd1
156.29.1.107	cd7.sannet.gov		cd7

I need to be able to have all mail sent to the last 4 hostnames processed by themachine at 1.107 (smtpgate)  This method, along with MX records in the
/etc/named.data file worked, however, I was told by somebody here that
multiple A records in the /etc/hosts file were not a good thing and I should
use CNAME records.  The keepers of the DNS are trying this and now nothing
works.  What's the skinny on CNAME & MX records?  Can someone tell me,
in straight English, how to set this up?  This trial by error bit is getting
old.  (and unfortunately, I don't have access to make these changes so I need
to tell these guys EXACTLY how to do it - Anyone want a job as a systems
admin?)

As usual, thanks for saving my bacon.


-----------[000191][next][prev][last][first]----------------------------------------------------
Date:      9 Jun 1994 21:10:20 GMT
From:      wwds2@clark.net ()
To:        comp.protocols.tcp-ip
Subject:   What is XTP?

I heard for the first time today about a protocol called XTP that is 
supposed to be an alternative to UDP providing guaranteed delivery. 

Does anyone know what XTP is, how it compares to TCP and UDP (pros+cons...)
where I can get more information, supliers, etc?

Thanks
------------------------
Walt Brauckmann <wwds2@clark.net>
Westighouse Electric Corp.



-----------[000192][next][prev][last][first]----------------------------------------------------
Date:      9 Jun 1994 21:42:04 GMT
From:      glenn@creator.ucns.uga.edu (Glenn Leavell)
To:        comp.protocols.tcp-ip
Subject:   slip-4.0 access denied problem

I'm trying to configure slip-4.0 (Rayan Zachariassen <rayan@ai.toronto.edu>)
on a Sun Sparcstation 1+ running SunOS 4.1.3.  Everything seems to be working
well in the sense that the sliplogin program will configure the slip0 device
when run as superuser.  However, if a normal user logs into a pseudo slip
ID (one that has sliplogin as its shell), then the message 

		SLIP access denied

appears, and the connection is broken.  The /etc/hosts.slip file looks like
this:

		slipid normal 128.192.ww.xx 128.192.yy.zz

I know that this is a vague question, but can anyone provide any pointers,
hints, suggestions, etc. as to what would cause the "access denied" error?

Thanks very much.

-- 
Glenn Leavell  University of Georgia  glenn@creator.ucns.uga.edu  706-542-3135
     University Computing and Networking Services, Athens, GA 30602-1911


-----------[000193][next][prev][last][first]----------------------------------------------------
Date:      10 Jun 1994 10:43:33 -0700
From:      jantypas@ccnet.com (John Antypas)
To:        comp.protocols.tcp-ip
Subject:   Where to find pointers to DHCP discussions?

Subject says it all.  Where can I find DHCP info.  (Not to mention
all of the other "next generation IP" material.


-----------[000194][next][prev][last][first]----------------------------------------------------
Date:      9 Jun 1994 09:48:16 +0800
From:      richard@iinet.com.au (Richard Keeves)
To:        comp.os.ms-windows.programmer.misc,comp.os.ms-windows.programmer.tools,comp.os.ms-windows.programmer,comp.os.ms-windows.apps,comp.os.ms-windows.apps,comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc,comp.protocols.tcp-ip.domains,comp.unix.dos-under-unix,comp.unix.questions
Subject:   `Beeping' thru a Window. Help!

Hi there,

     Here's the challenge...

I want to be able to alert someone in another internet location ie at 
another node in another country) when i wish to talk with them

Now I know that `talk' will do that, however if the other party is in 
another window (using ms windows) they will not get the `talk' alert. 
So is there anything (ie any program or clever stuff) that can be done 
to cause the other machine to beep ???
Or sound some other alarm??

This assumes of course that the other person is logged on...

btw I am assuming that the normal beep will not work when the other party 
is not in same window as modem. 
 
If you can understand my question, I hope you can help..
thanks... my email is 
richard@iinet.com.au

Hope to hear from you if you can help

Cheers
 
Richard Keeves



-----------[000195][next][prev][last][first]----------------------------------------------------
Date:      Thu, 9 Jun 1994 23:46:59 GMT
From:      vjs@calcite.rhyolite.com (Vernon Schryver)
To:        comp.protocols.tcp-ip
Subject:   Re: What is the MTU of FDDI?

In article <2t53hl$fj4@lll-winken.llnl.gov> booloo@framsparc.ocf.llnl.gov (Mark Boolootian) writes:
>I'm trying to get some agreement on MTU between hosts and routers on one of
>our FDDI rings, and I've realized that I don't know what the "appropriate"
>MTU should be.
>
>My understanding is that the true MTU for FDDI is 4500 bytes.  However, I 
>have found a recommended value of 4470 in an NSC router manual, I've seen
>defaults of 4352 on both RS/6000s and Sun 4s, and have been told that 4096
>is the default for at least one router vendor.
>
>Clearly, 4096 would be a poor choice, as 4096 is a nice size for
>allocating memory.  4136 would be better which would account for the TCP/IP
>header.  But since we've still got some headroom, why not bump it up so
>that packets with TCP/IP options don't need to be fragmented?  
>
>Can anyone explain why choices like 4352 or 4470 were made.  Vernon, can you
>tell me what SGI recommends?  A popular, although not uniformly used, 
>Ethernet MTU is 1500 bytes.  Does any such MTU exist for FDDI, or is there
>really a lot of disagreement?


RFC-1103,...,1188 say the MTU for IP over FDDI is 4352.

]     Therefore, the MTU of FDDI networks shall be 4352 octets.  This
]     provides for 4096 octets of data and 256 octets of headers at the
]     network layer and above.  Implementations must not send packets
]     larger than the MTU.

4352 was choosen in a long ago FDDI birds-of-a-feather InterOp meeting.
It is less than 4500 "just in case", and more than 4096 so allow for
various headers including the 100 bytes of RPC/XDR in NFS.

I like to use 4096 of payload in TCP kernel code to go fast, but that's
ok because since there is no law that says you must transmit full-siced
frames.  You need only be prepared to accept bigger frames.


Vernon Schryver    vjs@rhyolite.com

-----------[000196][next][prev][last][first]----------------------------------------------------
Date:      10 Jun 1994 11:58:06 -0700
From:      moliver@pyramid.com (Mike Oliver)
To:        comp.protocols.tcp-ip
Subject:   Re: What is the MTU of FDDI?

In article <1994Jun10.003410.15080@ns.network.com>,
Andrew Molitor <amolitor@network.com> wrote:
>In article <2t53hl$fj4@lll-winken.llnl.gov>, booloo@framsparc.ocf.llnl.gov
>	(Mark Boolootian) writes:
>|> I'm trying to get some agreement on MTU between hosts and routers on one of
>|> our FDDI rings, and I've realized that I don't know what the "appropriate"
>|> MTU should be.
>|> 
>|> My understanding is that the true MTU for FDDI is 4500 bytes.  However, I 
>|> have found a recommended value of 4470 in an NSC router manual, I've seen
>|> defaults of 4352 on both RS/6000s and Sun 4s, and have been told that 4096
>|> is the default for at least one router vendor.
>
>	Not surprisingly, I'm going to say that 4470 is the right number (see
>my email address!).

Unless and until you can get an RFC issued to supersede RFC1188 the
correct answer is 4352.  Above that you're in violation of the RFC and
are depending on the kindness of strange device driver developers.
Choose your own meaning of "strange".

RFC1390 is a standards track document intended to obsolete RFC1188, but
1390 makes no change to the FDDI MTU.

>                    The reason is that the max size of a FDDI frame is 4500,
>and if you add up the headers down to and including the SNAP header, and the
>FDDI weirdnesses and so on, you get 30 bytes of other stuff as the maximum
>size of, say, an IP datagram you can push over it.

The rationale for choosing 4352 is presented in RFC1188, which says:

      The FDDI MAC specification [4] defines a maximum frame size of
      9000 symbols (4500 octets) for all frame fields, including four
      symbols (two octets) of preamble.  This leaves roughly 4470 octets
      for data after the LLC/SNAP header is taken into account.

      However, in order to allow future extensions to the MAC header and
      frame status fields, it is desirable to reserve additional space
      for MAC overhead.

      Therefore, the MTU of FDDI networks shall be 4352 octets.  This
      provides for 4096 octets of data and 256 octets of headers at the
      network layer and above.  Implementations must not send packets
      larger than the MTU.

RFC1390 retains this text verbatim.

Incidentally, I imagine that the phrase "future extensions to the MAC
header" refers to source routing, which thankfully hasn't caught on for
FDDI.

>                                                   If you heave SNAP
>encapsulation, you get back a few bytes, but SNAP is a Good Thing, so don't.

Whether it's a Good Thing or not, SNAP is mandatory for IP over FDDI,
Don't leave it out if you want to talk to anyone else's implementation.

>	I speculate that other vendors probably use smaller numbers for
>some sort if internal convenience.

I speculate that they'll use a smaller number than 4470 so as to be in
compliance with the RFC.

Your speculation that they might use smaller number than 4352 has been
confirmed for at least one prominent vendor by Vernon's posting -- but,
as he mentions, an implementation must still be prepared to accept
datagrams up to the full MTU size.

>	Off the top of my head, I'd say the largest issue is to avoid
>fragmenting maximally sized NFS datagrams into 2 big frames, and then a
>little one extra because the first two weren't quite enough, but anything
>much over 4096 will do that for you.

I happen to agree, but oddly enough the rationale in the RFC doesn't
provide for this.  MTU's for some other media do allow a little over 8K
in deference to NFS.  I don't know how useful it is in practice.

>                                     Intelligent transport protocols, like
>TCP, shouldn't really care about a few bytes one way or the other.

The protocol doesn't care.  Someone striving to create an efficient
implementation very well might.

Cheers, Mike.

moliver@pyramid.com
{allegra,decwrl,hplabs,munnari,sun,utai,uunet}!pyramid!moliver

-----------[000197][next][prev][last][first]----------------------------------------------------
Date:      Fri, 10 Jun 94 00:34:10 GMT
From:      amolitor@blefscu.network.com (Andrew Molitor)
To:        comp.protocols.tcp-ip
Subject:   Re: What is the MTU of FDDI?

In article <2t53hl$fj4@lll-winken.llnl.gov>, booloo@framsparc.ocf.llnl.gov
	(Mark Boolootian) writes:
|> I'm trying to get some agreement on MTU between hosts and routers on one of
|> our FDDI rings, and I've realized that I don't know what the "appropriate"
|> MTU should be.
|> 
|> My understanding is that the true MTU for FDDI is 4500 bytes.  However, I 
|> have found a recommended value of 4470 in an NSC router manual, I've seen
|> defaults of 4352 on both RS/6000s and Sun 4s, and have been told that 4096
|> is the default for at least one router vendor.

	Not surprisingly, I'm going to say that 4470 is the right number (see
my email address!). The reason is that the max size of a FDDI frame is 4500,
and if you add up the headers down to and including the SNAP header, and the
FDDI weirdnesses and so on, you get 30 bytes of other stuff as the maximum
size of, say, an IP datagram you can push over it. If you heave SNAP
encapsulation, you get back a few bytes, but SNAP is a Good Thing, so don't.

	I speculate that other vendors probably use smaller numbers for
some sort if internal convenience.

	Off the top of my head, I'd say the largest issue is to avoid
fragmenting maximally sized NFS datagrams into 2 big frames, and then a
little one extra because the first two weren't quite enough, but anything
much over 4096 will do that for you. Intelligent transport protocols, like
TCP, shouldn't really care about a few bytes one way or the other.

		Andrew Molitor

-----------[000198][next][prev][last][first]----------------------------------------------------
Date:      Fri, 10 Jun 1994 01:12:00 GMT
From:      west@osi.ncsl.nist.gov (Jim West)
To:        comp.protocols.tcp-ip
Subject:   Re: What is XTP?

In article <2t80fs$f48@clarknet.clark.net> wwds2@clark.net () writes:
>I heard for the first time today about a protocol called XTP that is 
>supposed to be an alternative to UDP providing guaranteed delivery. 
>
>Does anyone know what XTP is, how it compares to TCP and UDP (pros+cons...)
>where I can get more information, supliers, etc?
>

XTP appeared about five years ago.  One of my first projects at NIST
was examining XTP and comparing it to other Transport layer protocols.
I haven't looked at it in four and a half years, but I'll try to tell
you what I know.

XTP stands for eXpress Transport Protocol.  It was supposed to solve
the preceived performance limitations of protocols like TCP and OSI's
TP[0-4].  As I remember it incorporated both layer 3 and layer 4
(Network layer and Transport layer) functionality.  XTP was designed
so that it could be implemented on a chip.  This was how developers
proposed to get really high thoughput and low latency.  A company
called Protocol Engines Incorporated (PEI) was staffing up to do
this five years ago.  I don't remember the name of the developer
of XTP but he was one of the founders of PEI (I think that they
got some of their start-up money from SGI).  A Dr. Alf Weaver
at the University of Virginia (I think he's at UVa) was doing a lot
of work with XTP.

IMHO XTP got caught up in polotics.  Also Van Jacobson had some interesting
data that TCP could run at the levels the designs of XTP proposed.
(Jacobson's research showed that TCP/IP could be optimized to have
a best case path of about 300 lines of assembly code (if I remember
right)).  I think at one time there was an ANSI document based on XTP;
I don't know how far it got.

Sorry I don't have any more data but I at home right now and I threw
out all my XTP notes last year (still have all my Van Jacobson papers.
They are great sources of info).

Jim West

-- 
----------------------------------------------------------------------
Speaking only for myself, not necessarily for my employer.
west@mgmt3.ncsl.nist.gov

-----------[000199][next][prev][last][first]----------------------------------------------------
Date:      10 Jun 94 02:23:41 GMT
From:      cjw@nwu.edu (Christopher Wargaski)
To:        comp.protocols.tcp-ip
Subject:   Re: DNS Problems galore. Somebody help!

In <d00n.771195367@crash.cts.com> d00n@crash.cts.com (Kevin Spousta) writes:


>Outbound mail works like a charm and previously with the following entries
>in the DNS it worked great:
 
>156.29.1.107	smtpgate.sannet.gov	smtpgate
>156.29.1.107	rosecyn.sannet.gov	rosecyn
>156.29.1.107	acctrep.sannet.gov	acctrep
>156.29.1.107	cd1.sannet.gov		cd1
>156.29.1.107	cd7.sannet.gov		cd7
 
>I need to be able to have all mail sent to the last 4 hostnames processed by themachine at 1.107 (smtpgate)  This method, along with MX records in the
>/etc/named.data file worked, however, I was told by somebody here that
>multiple A records in the /etc/hosts file were not a good thing and I should
>use CNAME records.  The keepers of the DNS are trying this and now nothing
>works.  What's the skinny on CNAME & MX records?  Can someone tell me,
>in straight English, how to set this up?  This trial by error bit is getting
>old.  (and unfortunately, I don't have access to make these changes so I need
>to tell these guys EXACTLY how to do it - Anyone want a job as a systems
>admin?)


CNAMEs are Canonical NAMEs, basically just an alias.  Use a CNAME record
instead of multiple A records.  Mail will not pass through a CNAME record.

MX records are for machines that do Mail eXchanging for another.  For
example I want mail bound for rc-noc.acns.nwu.edu (which has an alias of
bohica.acns.nwu.edu) to be accepted by antioch.acns.nwu.edu.  So I add the
records for the tables should look like this: 

rc-noc.acns     IN      A       129.105.31.56    ; DSS, HP 9000/710
		IN      MX      0       antioch.acns.nwu.edu. ; 
bohica.acns     IN      CNAME   rc-noc.acns


The first line is an A record that you are familiar with.

The absence of a name in the first line means "ditto" for the name.  So we
use rc-noc.acns for the name.  We see that the machine that accepts mail
for rc-noc is antioch.

The third line is just an alias.

If someone sends mail to cjw@bohica.acns.nwu.edu, the machine sending the
mail (say moo.acns.nwu.edu) will resolve the name "bohica.acns.nwu.edu" and
find that the real name is "rc-noc.acns.nwu.edu".  It will then also notice
that the machine "antioch.acns.nwu.edu" is the machine that is accepting
mail.  So moo will resolve the IP address for antioch and send the mail
message to that machine.

Now, the sendmail.cf for antioch has to have a rule added so that it will
accept mail for the machine called rc-noc.  If you would like info on that,
let me know.


Good luck!

cjw



-- 


   Christopher Wargaski    cjw@nwu.edu     Technical Services Supervisor
      Northwestern University Network Operations Center  708-467-NNOC

-----------[000200][next][prev][last][first]----------------------------------------------------
Date:      10 Jun 1994 11:31:42 -0500
From:      dawkins@bnr.ca (Spencer Dawkins)
To:        comp.protocols.tcp-ip
Subject:   Stop me before I kill again (TCP vs UDP)

We have "a product" that runs over proprietary link-layer-and-up
protocols, that we also want to use over "corporate lans". I've
been asked my opinion on a few points, and I've given them, but
if I'm giving horrible advice, I'd appreciate hearing alternative
viewpoints.

The deal: all applications use a proprietary link-layer protocol
(call it PLL, for convenience). A unix process MUXes all applications
on a physical point-to-point connection. The interface between the
application and the MUX software is connectionless.

The development group plans to keep the same interface between the 
applications and the MUX layer, and to rewrite the MUX layer to
use TCP or UDP.

Other stuff: Most application-to-application conversations will be
over Ethernet, but some conversations will take place over WAN
connections.

What I said: "If you're going to keep the same application-level
interface, which is connectionless, you might as well use UDP."

Why I said it:

	The applications already run timers and sequence numbers,
	because of the connectionless interface to the MUX software.

	The developers planned to MUX all conversations over a single
	TCP connection, if they used TCP. I was concerned about
	applications which sent large numbers of packets back-to-back
	causing other applications sending relatively time-critical
	"query/response" exchanges to be flow controlled.

	The developers planned to use the FTP application (over TCP,
	obviously) to move several types of large files between nodes.
	much of the need for TCP-level flow control was already being
	diverted to FTP, which uses TCP anyway.

	The classic "large number of clients per service" scenerio
	applies. I did not want to support, potentially, hundreds of
	clients using TCP for (most often) application-level datagram
	exchanges anyway.

Caveats I've already said:

	The applications really _do_ have to run their own timers and
	sequence numbers. (If they don't, it's a problem on the PLL
	product anyway, so they have to anyway).

	If an application is sending large numbers of messages "back-
	to-back", it needs to be at least minimally aware of congestion,
	and slow itself down until congestion clears. We may not need
	all of Van Jacobson's code, but we do need to back off more
	aggressively than we probe for bandwidth. Applications with
	this characteristic will probably be able to be replaced by
	ftp _in our product_ (this is not a general assertion).

What I know to worry about:

	Most corporate firewalls allow relatively little in the way of
	UDP traffic (heck, most allow relatively little in the way of
	TCP traffic). Is what I'm suggesting dead out-of-the-box?

	I don't know everything. What else should I investigate to make
	sure I don't give the developers bad advice that _everyone_
	knows is bad advice? (I sure don't mind encountering _new_
	problems -- I just hate _"used"_ problems.)

If you phrase your favorite concern in the form of a question pregnant
with meaning, such as "ummm, how will that work when you have a customer
who refuses to pass _any_ UDP traffic?", that's everything I can hope
for from this posting. If you phrase it as "What I'd do in that case is 
use Transport-Independent RPC" or some other miracle cure, that would 
be fantastic, but it's not required -- just the heads-up is appreciated.

Spencer
-- 
-  Spencer Dawkins	Internet: dawkins@bnr.ca   (214) 684-4827           -
-  A flashing "12:00" on the VCR of life.				    -

-----------[000201][next][prev][last][first]----------------------------------------------------
Date:      10 Jun 1994 03:23:21 GMT
From:      iddasl@iddis.com (Alan Siping Liu)
To:        comp.protocols.tcp-ip
Subject:   message lost in UDP socket

Hi everyone,

We are using UDP socket to transfer data across hosts. We find
that messsage get lost when the sending speed is increased. The
problem is that the speed at which we start lossing message is
quite low -- about 500 messages per second, each contains
about only 40 bytes. The receiving process doesn't have heavy
processing on the received data. The testing is conducted on
a coupe of Sparc10's on a rather quiet, isolated Ether net.

A related question is: when using BSD sockets, is there any
way to increase the buffer beyond 64K? In the testing described above,
netstat reported IP message loss at the receiver side. Can I
conclude that the message loss is due to the limited socket buffer?

Or maybe the OS is not configured properly?

Thanks i advance.

Alan Liu.



-----------[000202][next][prev][last][first]----------------------------------------------------
Date:      10 Jun 1994 10:48:06 -0400
From:      hzhou@cs.utk.edu (Honbo Zhou)
To:        comp.protocols.tcp-ip
Subject:   UDP flow control and retransmission?

I would like to know if there is a book about EFFICIENT (preferably with 
source codes) flow control and retransmission over UDP socket? Thanks.hb 


-----------[000203][next][prev][last][first]----------------------------------------------------
Date:      Fri, 10 Jun 1994 08:57:48 EDT
From:      rbecker@sup.xyplex.com (Ralph Becker)
To:        comp.protocols.ppp,comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject:   Re: Questions regarding SLIP/PPP terminal server setups

In article <CqqE1u.4Jq@oucsace.cs.ohiou.edu> rbarrett@oucsace.cs.ohiou.edu (Rich Barrette) writes:

>I have been involved in a project setting up a SLIP/PPP terminal
>server and offering these services to Windows and Mac users
>throughout campus.  Right now we have a small exerimental group
>running smoothly. 

[snip]

>The other pressing question was one of usage.  How do we monitor
>usage and decide who is doing real work?  i.e. It would be highly 
>undesireable for someone to be logged into the server all of the 
>time while other people could do work.  How do we monitor and decide 
>who is doing what?  The subject can get complicated because we want 
>to offer this to students, some of which are CS and Engineering types 
>who can beat most simple monitoring systems by sending pings every 
>once in a while or use even more elaborate mechanisms.

The Xyplex server is not really going to provide you much in the way
of traffic analysis.  About all you can do is set up inactivity timeouts
that will logout the port if there is no activity on it for some time.  As you
said, this is easily defeated.  You can do IP address security, however.
This will let you restrict where users can connect to.  If, for example, you
wanted to limit users to your local subnet only, this is easy to do.

Ralph Becker
Xyplex Customer Support [Tech. Support hotline 800-435-7997]
rbecker@sup.xyplex.com or 71174.1262@compuserve.com

-----------[000204][next][prev][last][first]----------------------------------------------------
Date:      10 Jun 94 07:22:57 GMT
From:      tom@wcc.oz.au (Tom Evans)
To:        comp.protocols.tcp-ip
Subject:   ICMP Redirect THEN Host Unreachable?

I've got a packet trace here that looks WEIRD to me. There's two
famous-name IP routers on a backbone with a host, call them R1, R2 and
H1. There's another host on the other side of R2:

      [ R1 ]============[ R2 ]======[ H2 ]
                 ||
               [ H1 ]

H1 sends a packet (an ICMP Ping reply) to H2, but via R1 (its default gateway).

R1 forwards the packet via R2 to H2, and sends an ICMP Redirect to H1. Fine.

Then R1 sends an ICMP Host Unreachable to H1 for the same packet. Not fine.

This doesn't seem to be what the RFC says. Any opinions? Is this
legal? Is R1 busted? 

If this is judged to be "illegal" I'll post details when I get model
numbers and more complete packet-dumps and so on

========================
Tom Evans  tom@wcc.oz.au
Webster Computer Corp P/L, 11 Glenvale Crescent Mulgrave, Melbourne 3170
Victoria, Australia 61-3-561-9999  FAX ...560-0067  A.C.N. 004 818 455


-----------[000205][next][prev][last][first]----------------------------------------------------
Date:      10 Jun 1994 14:31:54 -0400
From:      danglert@source.asset.com (Terry Dangler)
To:        comp.protocols.tcp-ip,comp.unix.aix
Subject:   IP Adressing of Multiple Interfaces

Hi
We are using an RS/6000, is there any reason why the following IP
addressing scheme would not work:

Ethernet Interface IP Address: 192.131.125.10 connects to gateway and Internet
SLIP Interface IP Address: 192.131.125.25 attached to Xstation
Token Ring Interface IP Address: 192.131.125.33 connects to LAN

currently:
Ethernet Interface IP Address: 192.131.125.10
Token Ring Interface is 192.132.104.33

Please respond directly:

TIA


-----------[000206][next][prev][last][first]----------------------------------------------------
Date:      Fri, 10 Jun 1994 08:41:24 GMT
From:      gta@server1.ewi.ch (Gerster)
To:        comp.protocols.tcp-ip
Subject:   telnet/ftp with  American Online


Dear Members,

I' have a question about American Online.  I hope I'm in the right group.

It is possible for an American Online User to make telnet or ftp connection
to hosts on the INTERNET ?. In case of yes, what the user should do.

Andreas

----------------------------------------------------------------------------
Andreas Gerster                         | phone: +41 (0)1-385 21 86 (direct)
Electrowatt Engineering Services, Ltd.  |        +41 (0)1-385 33 22 (main)
Bellerivestrasse 36, P.O. Box           | fax:   +41 (0)1-385 24 25
CH-8034 Zurich                          | e-mail: gta@ewi.ch
Switzerland                             | X400  : O=EWI/p=EUNET/a=ARCOM/c=CH 
----------------------------------------------------------------------------


-----------[000207][next][prev][last][first]----------------------------------------------------
Date:      Fri, 10 Jun 1994 09:15:08 GMT
From:      hjb@netcom.com (squeedy)
To:        comp.protocols.tcp-ip
Subject:   Re: What is XTP?

Jim West (west@osi.ncsl.nist.gov) wrote:
: A company called Protocol Engines Incorporated (PEI) was staffing up to do
: this five years ago.  I don't remember the name of the developer
: of XTP but he was one of the founders of PEI (I think that they
: got some of their start-up money from SGI).  

trivia:
PEI is no longer, they closed the shop a couple of years ago.  it was
founded by Greg Chesson (UUCP-g protocol, Datakit protocol engine), who
was and still is at SGI as a chief scientist.  Greg, the PEI/XTP TAB
members and engineers at PEI designed the protocol.  PEI actually
finished the first chipset that could do a subset of TCP/IP (with some
provisions for XNS and XTP), but the design never went to production.
a lot of us who worked at PEI are now working at different places now,
some are consultants, many are working at SGI and Hybrid Networks,
Inc.  the XTP itself has been taken over by XTP consortium, a left-over
from PEI.

-- 
hwajin
PEACEFUL STAR

-----------[000208][next][prev][last][first]----------------------------------------------------
Date:      Fri, 10 Jun 1994 16:42:35
From:      MSNIDER@rapnet.sanders.lockheed.com (Marc Snider)
To:        comp.protocols.tcp-ip.ibmpc,comp.protocols.tcp-ip,comp.os.msdos.apps
Subject:   BOOTP server for PC ?



Does anyone out there know of a BOOTP server implementation which will run 
under either DOS or Windows?

Thanks in advance,
Marc Snider
msnider@rapnet.sanders.lockheed.com
Marc Snider
msnider@rapnet.sanders.lockheed.com

-----------[000209][next][prev][last][first]----------------------------------------------------
Date:      10 Jun 1994 13:36:19 GMT
From:      goeritz@conware.de (Huergen Goeritz)
To:        comp.protocols.tcp-ip
Subject:   HELP: IP(ARP) over Token Ring

Hi,

we are a company which develops Bridges/Routers.
We support Ethernet/FDDI/Token Ring/ISDN/WAN-Interfaces.

Right now I am dealing with Token Ring and there I encountered a problem.

In an IP-environment, ARP is used to translate Internet addresses to Token Ring
addresses when needed.

The ARP protocol has several fields that parameterize its use in any specific context.
One of these fields is the Hardware Type Code hrd - 16-bits. The hardware type code
assigned for IEEE 802 networks (Token Ring, FDDI ...) is 6. The hardware type code
assigned for Ethernet networks is 1. Unfortunaltely, differing values between Ethernet
and IEEE 802 networks cause interoperability problems in bridged environments. 

In order to not preclude interoperability with Ethernets in a bridged environment,
ARP packets shall be transmitted with a hardware type code of 1. ARP packets shall be
accepted if received with a hardware type code of 1.

In order to not preclude interoperability in a bridged environment, the hardware
addresses in ARP packets must be carried in 'canonical' bit order, with the Group bit
positioned as the low order bit of the first octet. As Token Ring (and FDDI) addresses
are normally expressed with the Group bit in the high order bit position, the addresses
must be bit-reversed within each octet.


This is true for FDDI (see RFC 1390), but do you know something about Token Ring how I 
save to deal with ARP and the MAC-address representation.

How do you solve the problem in a bridged environment?

Do you have a solution or can you help me in some way.

Thank you

Juergen Goeritz                 e-mail : goeritz@conware.de

-----------[000210][next][prev][last][first]----------------------------------------------------
Date:      Fri, 10 Jun 1994 18:38:25 UNDEFINED
From:      treynold@fred.lasalle.edu (Tommi)
To:        comp.protocols.tcp-ip
Subject:   Bootp: Across routers/Segments/Etc. ?

Hi all,
	I've recently been fiddling with using bootp to try and dish out IP's for a 
small subnet which will eventually contain some slip and ppp access points.
	My problem is this: The segment I am setting up will be the 13 segment 
(xxx.xxx.13.xxx), which will be connected via router to the 10 segment.  On 
the 10 segment rest several of our un*x machines, including the linux box 
which plans on running bootpd.
	I don't want to move the linux box to the 13 segment.
	Isn't bootp supposed to travel over routers, much like rarp would not?  I 
thought that I remembered reading this a while ago (has been a while 
though...), but monitoring the traffic on the new 13 segment as I tried to get 
a request across to the 10 showed several broadcast udp packets at fixed 
intervals from the client.  Now, certainly realizing that a router should not 
in any case forward a broadcast packet, is there any way to get bootp across a 
router??? (the routers are, currently, running md-dosip routed (yes, I know, 
get a real router :)
	Also, will bootp allow for me to eventually distribute ip's from a certain 
sort of "available ip" pool rather than by ethernet address, so that I can 
accomodate ppp ???

	Any help appreciated!

---
Tommi

treynold@fred.lasalle.edu

The above are my thoughts; if you don't like them, don't read them!

-----------[000211][next][prev][last][first]----------------------------------------------------
Date:      Fri, 10 Jun 1994 13:40:55 GMT
From:      bob@astph (Bob Ford)
To:        comp.protocols.tcp-ip
Subject:   Broken rwho & ruptime on ISC

We are running ISC v. 3.0 on one system, and ISC v. 4.0 on another.
They are connected via a bridge running on a 56K leased line.
From the 3.0 to the 4.0 machine, ruptime and rwho work correctly,
showing who is on both remote and local systems.  Going the other
way, from 4.0 to 3.0, neither ruptime or rwho works, reporting
no users on the systems, and machines down that are in reality up.
Thinking that /etc/rwhod was broken, I tried using the 3.0
rwhod on the 4.0 system, but it didn't help.  I also tried the
reverse (4.0 rwhod on 3.0 system), and no joy.

I should also mention that ruptime and rwho work fine on the 4.0 
machine for locally connected systems; the problem is over the 56K line.
In fact, on one of the locally connected machines, we are also
running v. 3.0, so it probably isn't a 4.0 to 3.0 incompatability.

Any help or pointers on what we are doing wrong would be much
appreciated.
-- 
Bob Ford                            Voice:(814)234-8592 x36
INTERNET: astph!bob@cse.psu.edu	    FAX:  (814)234-1269
Philadelphia Phillies - 1993 National League Champions

-----------[000212][next][prev][last][first]----------------------------------------------------
Date:      Fri, 10 Jun 1994 14:57:31 GMT
From:      d00n@crash.cts.com (Kevin Spousta)
To:        comp.protocols.tcp-ip
Subject:   Re: Connecting the PC to the Internet

In <Zi9PX0j.bankrupt@delphi.com> Peter Chapman <bankrupt@delphi.com> writes:

>Okay . . . here goes.  Can someone direct me to a source for connecting my
>lonesome extra 386 machine to the Internet so that other people can FTP
>or TELNET to my machine to retrieve certain law-related information at no
>charge.  I'd love to put some information out on the Information Highway
>for others to see and use, but I can't figure out where to begin.  A book
>entitled "How to connect a PC to the Internet over the phone lines in 100
>easy steps" would be really convenient.  Any ideas?

Certainly..  Call your local Internet service provider and get yourself a SLIP
account.  Tyupically, you'll be able to download some SLIP software from the 
provider's machine and the rest of the TCP/IP suite can be had by rummaging
around the 'net.  (Try ftp'ing to zaphod.ncsa.uiuc.edu)  About a year ago
I did the same thing.  I'm now using commercial products (since I have some
money - finally) but I did it for about 8 months with the free stuff.

If ya have any questions, blast me some E-mail and I'll try and help ya out.


-----------[000213][next][prev][last][first]----------------------------------------------------
Date:      Fri, 10 Jun 1994 15:54:02 GMT
From:      kangs@minerva.cis.yale.edu (Sung Moon Kang  BK94)
To:        comp.protocols.tcp-ip
Subject:   Appletalk through tcp-ip


Hi, I don't usually read this newsgroup, but this topic came up during a
conversation and this seems like a good group to ask....

I know that in theory it is possible to tunnel Appletalk through tcp-ip,
so theoretically it should be possible to create a wide area *appletalk*
network from say... Yale to Stanford through the internet.  So it should
be possible to say... access an Appletalk fileshare server in Stanford
from a Mac at Yale... in theory.

Beside the fact it would be really really really slow...

Is there an application/extension/whatever that actually does this?

Please email to kangs@minerva.cis.yale.edu as I don't regularly read
this newsgroup. Thanx very much.
-- 
---------------------------------------------------------------------------
Sung Moon Kang  BK 94       | "You don't belong in this century
kangs@minerva.cis.yale.edu  |  do you, Sung?"
                            |      - Richard Cho 5/30/94

-----------[000214][next][prev][last][first]----------------------------------------------------
Date:      10 Jun 1994 16:05:48 GMT
From:      underlan@jumbo.Read.TASC.COM (Samuel L/ Underland)
To:        comp.protocols.tcp-ip
Subject:   Subnetting with multiple nets


Hello,

I have a question about OSPF and subnetting with two different Class C 
addresses. I have a configuration, pictured below, with a central hub 
router and numerous remote sites. I want to subnet but don't have enough 
subnets (allowing for expansion) within the range for one Class C address.
OSPF doesn't permit routing from a subnet in one network through a different 
network, to a subnet of the originating network. I would like to divide the 
available address space approximately evenly among the sites.

Questions: 
1) When I route through a Hub system (AGS+ in this case), which network
   is it considered part of? A, B, or Both?
2) Will the Hub router route from all combinations of A and B? Does it
   matter what the LAN is at the Hub site?
3) Is making this work vendor or software rev dependent?

Configuration:
                          
                          central site LAN (subnet A.A.A.n)
                          ----------------
                                 |
                          ----------------
                          |  Hub Router  |
                          ----------------   Remote LANs
                           | | | | | |
                           | | | | | --A.A.A subnet1
                           | | | | ----A.A.A subnet2
                           | | | ------A.A.A subnetn-1
                           | | --------B.B.B subnet1
                           | ----------B.B.B subnet2
                           ------------B.B.B subnetn

Many thanks,

Sam Underland

-----------[000215][next][prev][last][first]----------------------------------------------------
Date:      10 Jun 1994 16:18:18 GMT
From:      tudball@lis.pitt.edu (A. Bruce McDonald)
To:        comp.protocols.tcp-ip.domains,comp.protocols.tcp-ip,comp.protocols.ppp
Subject:   Re: routing on a router/gateway

Sanjeev Shah (shah@abba) wrote:
: I have a class C address and use a UnixWare host (SVR4.2) to connect
: to the internet via a dialout PPP link.  The machine has two interfaces
: (wd0 and ppp) and IPFORWARDING is set to 1.  I am using separate IP
: addresses for the two interfaces.
 
: When I rlogin to a host on the internet, I see that I have come over the
: ppp0 interface's IP.  i.e. 'who' on a SunOS host shows my userid and the
: IP address of ppp0 (199.xxx.xxx.3).  I had really like to see this as
: the IP associated with wd0 (199.xxx.xxx.2).  i.e. I want the unix box
: to act as a router and just pass the IP packets via the ppp0 interface.
: i.e. icon->icon2->provider->internethost.  Is this possible using routed?
 
: This scenario should be true of any router (cisco, etc.) in a big
: organization.  I am sure their router passes the IP of the originating host
: and not its own IP as the originator IP or is my case special because of PPP?


Are you doing your rlogin from the SVR4 machine?  i.e. are you telneted to
that machine, or are you on another machine and using the Unixware box
purely as a router?  If you are using it just as a router, then you should
be seeing what you want, however if your logged onto it, then the ppp0
interface is the source interface of your packets.  This is as it should
be according to the IP routes.  I do not know if there is someway to
play around with routing internally to use another interface as your IP
source interface...

--Bruce

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

A. Bruce McDonald
tudball@icarus.lis.pitt.edu
University of Pittsburgh				"All Good Things..."

Work Phone: (412) 624-9499
Home Phone: (412) 731-0767

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

-----------[000216][next][prev][last][first]----------------------------------------------------
Date:      10 Jun 1994 16:21:52 GMT
From:      tudball@lis.pitt.edu (A. Bruce McDonald)
To:        comp.protocols.tcp-ip
Subject:   Re: What is XTP?

wwds2@clark.net wrote:
: I heard for the first time today about a protocol called XTP that is 
: supposed to be an alternative to UDP providing guaranteed delivery. 
 
: Does anyone know what XTP is, how it compares to TCP and UDP (pros+cons...)
: where I can get more information, supliers, etc?
 
: Thanks
: ------------------------
: Walt Brauckmann <wwds2@clark.net>
: Westighouse Electric Corp.

There are a number of articles and a book.  Eamil me if you would like references.

--Bruce

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

A. Bruce McDonald
tudball@icarus.lis.pitt.edu
University of Pittsburgh				"All Good Things..."

Work Phone: (412) 624-9499
Home Phone: (412) 731-0767

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

-----------[000217][next][prev][last][first]----------------------------------------------------
Date:      10 Jun 1994 16:23:47 GMT
From:      tudball@lis.pitt.edu (A. Bruce McDonald)
To:        comp.protocols.tcp-ip
Subject:   Re: UDP flow control and retransmission?

Honbo Zhou (hzhou@cs.utk.edu) wrote:
: I would like to know if there is a book about EFFICIENT (preferably with 
: source codes) flow control and retransmission over UDP socket? Thanks.hb 

Why don't you use TCP?  Efficient flow control and retran have the topic of
a great deal of research in this areana. 

--Bruce
 
--
-------------------------------------------------------------------------------

A. Bruce McDonald
tudball@icarus.lis.pitt.edu
University of Pittsburgh				"All Good Things..."

Work Phone: (412) 624-9499
Home Phone: (412) 731-0767

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

-----------[000218][next][prev][last][first]----------------------------------------------------
Date:      Fri, 10 Jun 1994 16:44:24 GMT
From:      shah@abba.fcmc.com (Sanjeev Shah)
To:        comp.protocols.tcp-ip
Subject:   routing on a router/gateway

I have a class C address and use a UnixWare host (SVR4.2) to connect
to the internet via a dialout PPP link.  The machine has two interfaces
(wd0 and ppp) and IPFORWARDING is set to 1.  I am using separate IP
addresses for the two interfaces.
 
When I rlogin to a host on the internet, I see that I have come over the
ppp0 interface's IP.  i.e. 'who' on a SunOS host shows my userid and the
IP address of ppp0 (199.xxx.xxx.3).  I had really like to see this as
the IP associated with wd0 (199.xxx.xxx.2).  i.e. I want the unix box
to act as a router and just pass the IP packets via the ppp0 interface.
i.e. icon->icon2->provider->internethost.  Is this possible using routed?
 
This scenario should be true of any router (cisco, etc.) in a big
organization.  I am sure their router passes the IP of the originating host
and not its own IP as the originator IP or is my case special because of PPP?
 
I have also tried subnetting with the same results.  For subnetting
I used 199.xxx.xxx.33 for ppp0 and 199.xxx.xxx.65 for wd0 and a
netmask of 199.xxx.xxx.224.  Any help is appreciated.
 
 
    +----------+          [icon2]           [provider]    +----------+
    |          | ppp0 (199.xxx.xxx.3)      (164.xx.xx.xx) |          |
    | unixware |------------------------------------------| internet | internet
    |   host   |                                          | provider |-------->
    |          | wd0 (199.xxx.xxx.2)                      |          |
    |          |------+   [icon]                          |          |
    +----------+      |                                   +----------+
                      |
                   [iconnet]
                 199.xxx.xxx.0
                      |
                (planned LAN)
 
 
netstat -r
----------
Routing tables
Destination      Gateway            Flags  Refs   Use      Interface
localhost        localhost          UH     0      0        lo0
provider         icon2              UH     0      0        ppp0
default          provider           UG     1      1276     ppp0
iconnet          icon               U      0      0        wd0

--
Sanjeev Shah     internet: shah@abba.fcmc.com


-----------[000219][next][prev][last][first]----------------------------------------------------
Date:      Fri, 10 Jun 1994 17:41:33 GMT
From:      venki@actel.com (venki muthanna)
To:        comp.protocols.tcp-ip
Subject:   Redirection of stdout and stderr to a socket.


	Hi,
	
	I would like to know the easy way out to redirect stdout and stderr
	to sockets. I need this to work on a PC platform. I am using PCTCP from
	FTP Software.

	Thank you,
	Venki.

	venki@actel.com

-----------[000220][next][prev][last][first]----------------------------------------------------
Date:      10 Jun 1994 18:05:41 GMT
From:      mfagan@dude.watson.ibm.com (Michael Fagan)
To:        comp.os.ms-windows.programmer.misc,comp.os.ms-windows.programmer.tools,comp.os.ms-windows.programmer,comp.os.ms-windows.apps,comp.os.ms-windows.apps,comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc,comp.protocols.tcp-ip.domains,comp.unix.dos-under-unix,comp.unix.questions
Subject:   Re: `Beeping' thru a Window. Help!


> I want to be able to alert someone in another internet location ie at 
> another node in another country) when i wish to talk with them
> <rest deleted>

How about zephyr?  In fact, you can forget about talk altogether and use
zephyr.  I must confess, though, I am not sure if zephyr has been ported
to the Dos/Windows world.

Cheers,

Mike

--

-------------------------------------------------------------------------
Michael S. Fagan       | IBM Research
mfagan@watson.ibm.com  | http://www.watson.ibm.com/homes/mfagan/home.html
-------------------------------------------------------------------------

-----------[000221][next][prev][last][first]----------------------------------------------------
Date:      10 Jun 1994 18:10:25 GMT
From:      netcom@nbnet.nb.ca (Atlantic Netcom Inc)
To:        comp.protocols.tcp-ip
Subject:   FAQ?

Could some kind soul point me to the FAQ? I can't find it posted in
comp/news.answers or anywhere else.

Tks a 10E6
Rod

-----------[000222][next][prev][last][first]----------------------------------------------------
Date:      Fri, 10 Jun 1994 20:11:35 GMT
From:      jprado@lauca.usach.cl (Jorge Andres Prado Troncoso)
To:        comp.protocols.tcp-ip
Subject:   NIS <----> PCNFS problem !



Hello...

	We are running PCNFS 5.0 under Ultrix 4.3 (DEC System 5000/240)
and yellow page (yp).

	All works fine, but in Windows 3.1, pc-nfs' network services
(telnetw, ftpw and others) only use the NIS map (Hostmap) and doesn't
resolve in the name server host.

	What shall I do to correct this problem?, i.e., pc-nfs' services
under Windows work with the name server host.

	Thanks in advance....

                                Jorge Prado T.



-----------[000223][next][prev][last][first]----------------------------------------------------
Date:      Fri, 10 Jun 1994 20:13:00 GMT
From:      meadogc@poup1.dnet.dupont.com  (Greg C. Meador)
To:        comp.protocols.tcp-ip
Subject:   TCP/IP Protocol Stack for Macintosh Comp?

I am looking for a freeware or shareware TCP/IP protocol stack to use
with Macintosh computers? We are trying to establish a FreeNet and we
are wondering what is available.
If possible can you please provide the site and directory path. If
not just a file name will do.
Thanks,
Greg C. Meador
meadogc@poup1.dnet.dupont.com

-----------[000224][next][prev][last][first]----------------------------------------------------
Date:      10 Jun 1994 20:17:14 GMT
From:      shair@uiuc.edu (Bob Shair)
To:        comp.protocols.tcp-ip,comp.unix.aix
Subject:   Re: IP Adressing of Multiple Interfaces

danglert@source.asset.com (Terry Dangler) writes:

>We are using an RS/6000, is there any reason why the following IP
>addressing scheme would not work:
>
>Ethernet Interface IP Address: 192.131.125.10 connects to gateway and Internet
>SLIP Interface IP Address: 192.131.125.25 attached to Xstation
>Token Ring Interface IP Address: 192.131.125.33 connects to LAN

Yup, almost certainly won't work.

You don't state what your netmask is, but it's likely 255.255.255.0 .

This means that the first three octets are used to address the network,
and the last octet the device (adapter) on the network.

You have place your Ethernet, Token Ring, and SLIP interfaces all 
on the same physical network.  

They'll have to be:
192.131.125.10 Ethernet ... connects to outsied world, must be an assigned 
address.

Something else for the other two.  e.g. 192.131,100.1  
Ask yourself what the 3-octet network addresses will be.

Unfortunately, this means that the workstations on the Token Ring and SLIP
won't be visible to/from the Internet.  

This could be fixed with:
   More assigned class C networks (Good luck!),
   Subnetmasking further... e.g 255.255.255.240, which would allow up
to 14 addresses on your token ring, or
   Proxy ARP, which I believe is not available on AIX.
-- 

Bob Shair                          shair@uiuc.edu
Open Systems Specialist    	   SHAIR@UIUCVMD (bitnet)
Champaign, Illinois		   217/356-2684

-----------[000225][next][prev][last][first]----------------------------------------------------
Date:      Fri, 10 Jun 1994 20:27:15 GMT
From:      LJ13285@LMSC5.IS.LMSC.LOCKHEED.COM
To:        comp.protocols.tcp-ip
Subject:   Mac requesting a RPC to Unix

Does anyone know how to execute a process on a Unix machine with the request be
ing initiated by a Macintosh.  The Macintosh should send a message/request over
 the network to a Unix machine.  After the Unix machine receives the request,
 it will process the request and send back the results.
 
I think this requires a RPC protocol but I haven't found one for the Macintosh.
Also, does anyone know how to access MAC/TCP or know if there is a socket
program on the Macintosh to access TCP/IP.
 
Thanks.

-----------[000226][next][prev][last][first]----------------------------------------------------
Date:      Fri, 10 Jun 1994 20:36:41 GMT
From:      LJ13285@LMSC5.IS.LMSC.LOCKHEED.COM
To:        comp.protocols.tcp-ip
Subject:   How do you program MAC/TCP?

How do you program TCP/IP calls on a Macintosh.
Are there any sockets that you can use?
Or do you know how to interface with MAC/TCP.
 
Please let me know.
Thanks.

-----------[000227][next][prev][last][first]----------------------------------------------------
Date:      Fri, 10 Jun 1994 20:41:09 GMT
From:      LJ13285@LMSC5.IS.LMSC.LOCKHEED.COM
To:        comp.protocols.tcp-ip
Subject:   Sockets for the MAC?

Is there a Socket program for the Macintosh to access TCP/IP?

-----------[000228][next][prev][last][first]----------------------------------------------------
Date:      10 Jun 94 21:00:57 GMT
From:      mjg@cs.stanford.edu (Michael J Graven)
To:        comp.protocols.tcp-ip
Subject:   Re: DNS Problems galore. Somebody help!

With a nod to Chris, may I present my own interpretation of the
questions, and perhaps a few answers.

I will approach the issue purely from a DNS/BIND standpoint.  If you've
got more than just the canonical hostname and localhost in your
/etc/hosts, I'll disclaim responsibility.  Never was that responsible,
anyway.

d00n@crash.cts.com (Kevin Spousta) writes:

> I've got WP Office installed in multiple sites, all gating SMTP mail through
> the machine, smtpgate.sannet.gov.  For political reasons, I need to 'trick'
> this machine into thinking it's also called cd7.sannet.gov, cd1.sannet.gov,
> rosecyn.sannet.gov and acctrep.sannet.gov, with more names to come.  I've 
> aliased WP Office users as user@cd7.sannet.gov, user@rosecyn.sannet.gov etc
> with all SMTP services being handled by the smtpgate machine.

Interpretation: you have a machine whose true name (as returned by
hostname, for example) is smtpgate.  (I'll leave off the suffix for
brevity.)  This machine needs also to be able to receive mail addressed
to users at machines named cd7, rosecyn, et alia.

> Outbound mail works like a charm and previously with the following entries
> in the DNS it worked great:
>
> 156.29.1.107	smtpgate.sannet.gov	smtpgate
> 156.29.1.107	rosecyn.sannet.gov	rosecyn
> 156.29.1.107	acctrep.sannet.gov	acctrep
> 156.29.1.107	cd1.sannet.gov		cd1
> 156.29.1.107	cd7.sannet.gov		cd7

Now, hold on a minute.  That looks a lot like a hosts file, not a DNS
database.  First step: get rid of the duplicate entries in your hosts file
excepting the one for the canonical name, smtpgate.

> I need to be able to have all mail sent to the last 4 hostnames processed 
> by themachine at 1.107 (smtpgate)  

In other words, you want all the mail intended for hosts cd1, cd7,
acctrep, and rosecyn to be processed through the host smtpgate.

> I was told by somebody here that
> multiple A records in the /etc/hosts file were not a good thing and I should
> use CNAME records.  

Depends on what you want to do; it's not a unilaterally "bad" thing and
does have its uses.

> What's the skinny on CNAME & MX records?  

Briefly (very briefly), if a CNAME record for a host X points to a
host Y, then the To: address of the mail is rewritten from "user@X" to
"user@Y".  A connection is opened to host Y, and the mail is delivered
as though X never were in the picture at all.  A CNAME resource record is 
like a pointer that's automatically dereferenced before any delivery is
attempted.

If host X has an MX record that points to host Y, then the mail is not
rewritten at all.  Sendmail opens a connection to host Y and says,
"Here's mail for user@X.  Can you take care of it?"

If host X has neither a CNAME nor an MX record, then its A record is
consulted and a connection opened.  Some will contend this behavior is
pathological.  I'll offer no opinion.

It sounds like what you want to do is use MX records.  This way, hosts
on the outside will first try to deliver to smtpgate, and you'll still
be able to have a unique A record for each of the other servers.

In order to do that, you'll need to make some configuration decisions in
the mailer software on smtpgate.  If you're running Sendmail, you can
set a class (class w on older Sun sendmail.cf's) with the names of
machines on whose behalf smtpgate should accept mail.   Then, you can
add rules in the machine-dependent parts of sendmail's rulesets to allow
receiving (and redelivering) mail for these aliases.  A discussion of
that is far, far beyond the scope of domains.  I suggest
Costales/Rickert/Allman's {Sendmail}, published by O'Reilly and
Associates, in lovely (hot) Sebastopol, CA.  

If you're not running Sendmail on smtpgate, well ... you'll have to
peruse your mail delivery software manuals to see how to relay mail.

-- 
-Michael                           "Jealous gun-toting ex ends a cozy weekend"
mjg@cs.stanford.edu                    --Headline, {Chicago Tribune}, 5 Jan 92

-----------[000229][next][prev][last][first]----------------------------------------------------
Date:      Fri, 10 Jun 1994 21:06:52 GMT
From:      rstevens@noao.edu (W. Richard Stevens)
To:        comp.protocols.tcp-ip
Subject:   Re: message lost in UDP socket

> We are using UDP socket to transfer data across hosts. We find
> that messsage get lost when the sending speed is increased. The
> problem is that the speed at which we start lossing message is
> quite low -- about 500 messages per second, each contains
> about only 40 bytes. The receiving process doesn't have heavy
> processing on the received data. The testing is conducted on
> a coupe of Sparc10's on a rather quiet, isolated Ether net.

Welcome to the world of unreliable, connectionless protocols.

> A related question is: when using BSD sockets, is there any
> way to increase the buffer beyond 64K? In the testing described above,
> netstat reported IP message loss at the receiver side. Can I
> conclude that the message loss is due to the limited socket buffer?
> Or maybe the OS is not configured properly?

Assuming you are checking the return value of sendto(), realize that
there are *few* causes for it to return an error.  Assuming your
system has a route to the destination, that the kernel has enough
mbufs, and that the selected interface has room on its send queue,
sendto() returns OK.  The size of the UDP send buffer really doesn't
matter, since nothing is queued at the UDP layer.  UDP takes your
data, plots on a UDP header, calls ip_output(), who queues the IP
datagram on the interface send queue.  Most interfaces have a send
queue limit of 50 and I think you need kernel sources to change this.

So, if sendto() is returning OK, the datagrams are being dropped either
by an intermediate router or by the destination.  The size of the
socket receive buffer on the destination *does* indeed matter, as this
could be where they're being lost.  Run "netstat -s" before and after,
in the receiver, and check the UDP socket overflows to see if this is
the problem.  Increasing SO_RCVBUF by the application will help this.

There was a thread on some newsgroup recently where someone claimed
that UDP was "faster" than TCP.  That's false in most situations,
since you lose all flow control as you're finding out.  A good,
well-tuned implementation of TCP should be able to beat any naive
UDP application.  And if you take your naive UDP application and start
putting in all the features from TCP (slow start, sliding window,
acknowledgments, ...) you're reinventing the wheel.

	Rich Stevens

-----------[000230][next][prev][last][first]----------------------------------------------------
Date:      Fri, 10 Jun 94 22:44:40 GMT
From:      valenzue@mmpc.ssd.lmsc.lockheed.com (C. Valenzuela)
To:        comp.protocols.tcp-ip
Subject:   TEST

Test

-----------[000231][next][prev][last][first]----------------------------------------------------
Date:      Fri, 10 Jun 1994 23:03:37 GMT
From:      davido@flagstaff.Princeton.EDU (David Lawrence Oppenheimer)
To:        comp.unix.admin,comp.unix.misc,comp.unix.questions,comp.sys.sun.admin,comp.sys.sun.apps,comp.sys.sun.misc,comp.protocols.tcp-ip
Subject:   SUMMARY: Need cslip help!


Thanks to those who responded to my problem with CSLIP on a Sun SS5 
running SunOS 4.1.3_U1. My question was:


---------- Forwarded message ----------

I am having a very difficult time trying to get cslip to work on my Sun SS5.
(I am using the version currently on the math.berkeley.edu FTP site.)

Pertinent information: I am using a Sun SS5 with SunOS 4.1.3_U1. I am using
a Hayes modem but am having no trouble communicating with the modem (i.e.
regular tip dialout works). I do not have Ethernet connected to my system,
just the modem through Serial Port A. I have created /dev/cua0 as specified
in the cslip instructions. I have installed the cslip loadable kernel module
for sun4m. I have modified the cslip login script to suit the SLIP terminal
server I dial into. 

My problem: I run on_all_times as root (after modifying the /etc/remote,
/etc/phones, slip.hosts, slip.login, and slip.logout files appropriately for
my site) and get "login failed: exit status 2 from /etc/slip.login"

Then I decided to try the commands by hand. First I did

ifconfig sl0 my_ip_address terminal_server_ip_address netmask correct_netmask

but I get

ifconfig: ioctl (SIOCSIFADDR): Invalid argument

[more material was here, but deleted]

The problem seems to be that I had hacked the slip.login script to bits, 
without understanding well enough what was going on in it.

In the process of investigating this problem, I discovered that I was 
using an outdated version of cslip (2.6 instead of 2.7). So I took cslip 
2.7 from ee.lbl.gov and was pleasantly surprised that it came with 
excellent documentation, unlike the 2.6 docs which was sparse and had 
typos (only the specific version I took; this comment does not 
necessarily apply to all versions of 2.6 on the net.). I followed the 2.7 
instructions, didn't hack any files, and it worked on the first try.

Thanks to those who responded.

David Oppenheimer
davido@phoenix.Princeton.EDU


-----------[000232][next][prev][last][first]----------------------------------------------------
Date:      Sat, 11 Jun 1994 02:48:39 GMT
From:      nigel@coles.com.au (Nigel Harwood)
To:        comp.protocols.tcp-ip,comp.sys.ncr
Subject:   How to tear down a TCP over X.25 connection?

Folks,

I have a System 3000/3450 AT&T box running Unix SVR4 and Win-TCP/IP.
This box talks to 400 other 3450 boxes over an X.25 private network.
I use Win-TCP/IP over X.25 to do RPC calls from the 400 boxes to the
one box.
The work being done is very quick <4 secs per connection.
The 400 systems call time is hashed over an, that is all the systems are
distributed more or less evenly over a 60 minute window.  They may also
however be trying to call in different hours due to their own processing
constraints.

The problem is that the host box has only 32 svcs and TCP/IP has a minimum
timeout of 1 minute.  This means that one a system connects and does
its RPC stuff the 2 SVCs it used remain after it has finished for a further
56 seconds.  This leads to a total choke up of the 32 svcs.

Questions:

1/ Is there a way for the host/remote end to tear down the connection after
   completion?

2/ Is there a way to cause the TCP/IP timeout to be something more reasonable
   for my circumstances such as 10 seconds.

Any help appreciated.

Regards
--
<<<<<<<<<<<<<<<<<<<<<<<<<<<  Nigel Harwood  >>>>>>>>>>>>>>>>>>>>>>>>>>
<<  Post: Coles Supermarkets, PO Box 480, Glen Iris 3146, Australia >>
<< Phone: +61 3 829 6090                 E-mail: nigel@coles.com.au >>
<<   FAX: +61 3 829 6886                                            >>
-- 
The opinions of the poster do not necessarily represent those of the company.

-----------[000233][next][prev][last][first]----------------------------------------------------
Date:      Fri, 10 Jun 94 15:26:46 +0800
From:      Mark Dignam <digger@omenii.omen.it.com.au>
To:        comp.protocols.tcp-ip
Subject:   LWP TCP/IP API calls - Docs anywhere?

I am trying to set up some TCP/IP connectivity on my system here, and require the specs for the Lan Workplace API.

Any ideas on where to start looking?

Mark...
digger@omen.it.com.au





-----------[000234][next][prev][last][first]----------------------------------------------------
Date:      11 Jun 1994 08:11:18 GMT
From:      bq274@cleveland.Freenet.Edu (Andy J. Berkvam)
To:        comp.protocols.tcp-ip.ibmpc,comp.protocols.tcp-ip,comp.os.msdos.apps
Subject:   Re: BOOTP server for PC ?


In a previous article, MSNIDER@rapnet.sanders.lockheed.com (Marc Snider) says:

>Does anyone out there know of a BOOTP server implementation which will run 
>under either DOS or Windows?
>
  The FAQ does.  This is all straight from it. (Except for the comments in
brackets).

  Hope this helps you.

----------------
B-12. What NetWare TCP/IP NLMs are out there and how do I get them to
work? 

A public and known to work reliable TFTP and BOOTP daemon for NetWare
OS 3.1x/4.0x and NetWare/IP are available from ftp.novell.de at
~/pub/netwire/unsupported/server/bootpd.exe. Contact: dirk@rhein-main.de

---------------
Recommendation
BOOTP	Free

A bootp server available via 
file://biochemistry.cwru.edu/pub/dos/bootp.zip or 
file://ftp-ns.rutgers.edu/pub/msdos/wattcp/bootp.zip

---------------
Downright Speculation
LPD	Free
FTP and BOOTP server  included

This software is a freeware line printer daemon as 
well as an FTP and BOOTP server.  Available via 
file://tacky.cs.olemiss.edu/pub/lpd/lpd.zip, lpdsrc.zip

[This is the one we use at University of Wisconsin - Stevens Point]
--------------

Andy
-- 
Andy Berkvam                          |  Few are wholly dead:
U of Wisconsin - Stevens Point        |  Blow on a dead man's embers
Cleveland Freenet: bq274              |  And a live flame will start.
Internet: aberkvam@spbsd1.uwsp.edu    |                -Robert Graves

-----------[000235][next][prev][last][first]----------------------------------------------------
Date:      11 Jun 1994 08:51:26 GMT
From:      tli@cisco.com (Tony Li)
To:        comp.protocols.tcp-ip
Subject:   Re: Bootp: Across routers/Segments/Etc. ?

In article <treynold.35.000FCE6D@fred.lasalle.edu>
treynold@fred.lasalle.edu (Tommi) writes: 

    I've recently been fiddling with using bootp to try and dish out
    IP's for a small subnet which will eventually contain some slip and ppp
    access points.  My problem is this: The segment I am setting up
    will be the 13 segment (xxx.xxx.13.xxx), which will be connected via
    router to the 10 segment.  On the 10 segment rest several of our un*x
    machines, including the linux box which plans on running bootpd.  	I
    don't want to move the linux box to the 13 segment.  Isn't bootp
    supposed to travel over routers, much like rarp would not?  

Yes, if you configure the router properly.

    I thought that I remembered reading this a while ago (has been a while
    though...), but monitoring the traffic on the new 13 segment as I tried
    to get a request across to the 10 showed several broadcast udp packets
    at fixed intervals from the client.  Now, certainly realizing that a
    router should not in any case forward a broadcast packet, is there any
    way to get bootp across a router??? (the routers are, currently,
    running md-dosip routed (yes, I know, get a real router :) 	

Problem solved. ;-)  Yes, it does require special code to forward bootp.

    Also, will bootp allow for me to eventually distribute ip's from a
    certain sort of "available ip" pool rather than by ethernet address, so
    that I can accomodate ppp ???
    
Yes.  It's called Dynamic Host Configuration Protocol (DHCP).  It's based
on Bootp.

Tony

-----------[000236][next][prev][last][first]----------------------------------------------------
Date:      11 Jun 1994 08:55:09 GMT
From:      tli@cisco.com (Tony Li)
To:        comp.protocols.tcp-ip
Subject:   Re: Subnetting with multiple nets

In article <2ta30sINN88b@jumbo.read.tasc.com> underlan@jumbo.Read.TASC.COM
(Samuel L/ Underland) writes: 
    
    I have a question about OSPF and subnetting with two different Class C 
    addresses. I have a configuration, pictured below, with a central hub 
    router and numerous remote sites. I want to subnet but don't have enough 
    subnets (allowing for expansion) within the range for one Class C address.

    OSPF doesn't permit routing from a subnet in one network through a
    different network, to a subnet of the originating network. 

OSPF explicitly _allows_ this.  That's not to say that it necessarily makes
sense for you.

    I would like to divide the 
    available address space approximately evenly among the sites.
    
    Questions: 
    1) When I route through a Hub system (AGS+ in this case), which network
       is it considered part of? A, B, or Both?

Both.

    2) Will the Hub router route from all combinations of A and B? Does it
       matter what the LAN is at the Hub site?

All.  No.

    3) Is making this work vendor or software rev dependent?
    
No, at least not from what you've said here.

Tony

    Configuration:
                              
                              central site LAN (subnet A.A.A.n)
                              ----------------
                                     |
                              ----------------
                              |  Hub Router  |
                              ----------------   Remote LANs
                               | | | | | |
                               | | | | | --A.A.A subnet1
                               | | | | ----A.A.A subnet2
                               | | | ------A.A.A subnetn-1
                               | | --------B.B.B subnet1
                               | ----------B.B.B subnet2
                               ------------B.B.B subnetn
    

-----------[000237][next][prev][last][first]----------------------------------------------------
Date:      11 Jun 1994 11:05:56 GMT
From:      droms@regulus.cs.bucknell.edu (Ralph E. Droms)
To:        comp.protocols.tcp-ip
Subject:   Re: Where to find pointers to DHCP discussions?

The mailing list host-conf@sol.cs.bucknell.edu is focused on DHCP
(admin requests to host-conf-request, please).  RFCs 1541, 1533 and
1534 (sic) give the current DHCP specs.

--
- Ralph Droms                 Co-Director, Computer and Communication Services
  droms@bucknell.edu          Associate Professor of Computer Science
  (717) 524-1795              Bucknell University
  (717) 524-1790 (fax)        Lewisburg, PA 17837

-----------[000238][next][prev][last][first]----------------------------------------------------
Date:      Sat, 11 Jun 1994 17:25:49 GMT
From:      todds@Newbridge.COM (Todd Sandor)
To:        comp.protocols.tcp-ip
Subject:   Non-blocking accept()...

I'm implementing an application that uses non-blocking
TCP sockets under SunOS 4.1.X and have a question concerning
using the accept() call on the non-blocking server socket fd.

Assumption:
- the accept() is used only when the server socket fd indicates
something to read on it via the select() system call.

Question: Given the above assumption would accept() ever 
return -1 with the errno set to EWOULDBLOCK? 

If it does, how do I get it to do it?

=========================================================

I've implemented a tcp server in the above manner, but havn't
had accept() return -1 with errno set to EWOULDBLOCK in the testing
I've done so far, ... but ...

(I know if the select() call etc. is not used this can happen, but 
can it "theorically" happen if the select() call indicates there
is something to read of the socket descriptor?)....
-- 
OSI buys you the promise of richer applications than the IP suite, at the cost 
of immaturity, complexity, inefficiency and incompleteness (unknown author).
Todd Sandor		Newbridge Networks:  Kanata, Ontario Canada
todds@newbridge.com   Phone: 591-3600 (ext 1011)

-----------[000239][next][prev][last][first]----------------------------------------------------
Date:      Sat, 11 Jun 1994 20:56:58 GMT
From:      kangs@minerva.cis.yale.edu (Sung Moon Kang  BK94)
To:        comp.protocols.tcp-ip
Subject:   Appletalk through tcpip (clarification)

This is a clarification of the question I posted several days ago about
tunnelling Appletalk through tcp-ip.

What I should have asked is if there was something I could run on two
*personal* Mac's so that... say I have a friend at Stanford running it,
I (at Yale) could open something so that I get the chooser that my
friend at Stanford sees, and vice versa.

The answers that I have gotten so far all indicated that Appletalk
tunneling through tcpip is done already by routers (such as those made
Gatorboxen made by Cayman, etc).  Although something like that would
effectively join two campuses Appletalk networkes, it would also require
the coporation of the two system adminstrative bodies... which always
doesn't happen.

I was wondering if anyone know of an application/extension/whatever I
can run on a personal Mac (one at each campus) that will let me access
another campus's Appletalk network through tcp-ip (internet).

Please mail your replies to kangs@minerva.cis.yale.edu.  I will post a
followup with the answers I collect.

Thanx very much.

-- 
---------------------------------------------------------------------------
Sung Moon Kang  BK 94       | "You don't belong in this century
kangs@minerva.cis.yale.edu  |  do you, Sung?"
                            |      - Richard Cho 5/30/94

-----------[000240][next][prev][last][first]----------------------------------------------------
Date:      11 Jun 1994 21:22:15 GMT
From:      barmar@think.com (Barry Margolin)
To:        comp.protocols.tcp-ip
Subject:   Re: ICMP Redirect THEN Host Unreachable?

In article <3928@wcc.oz.au> tom@wcc.oz.au (Tom Evans) writes:
>H1 sends a packet (an ICMP Ping reply) to H2, but via R1 (its default gateway).
>R1 forwards the packet via R2 to H2, and sends an ICMP Redirect to H1. Fine.
>Then R1 sends an ICMP Host Unreachable to H1 for the same packet. Not fine.

Seems wrong to me.  Host Unreachable should only be sent if the router has
no route to the destination.  If it can send a redirect for the destination
then it obviously thinks it's reachable.
-- 
Barry Margolin
System Manager, Thinking Machines Corp.

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

-----------[000241][next][prev][last][first]----------------------------------------------------
Date:      12 Jun 1994 05:09:56 GMT
From:      easu586@rigel.oac.uci.edu (Dave Rosenberg)
To:        comp.dcom.lans.ethernet,comp.protocols.tcp-ip,comp.protocols.tcp-ip.domains
Subject:   Can I get a Class B Address Assisgnment


--
Dave R.



-----------[000242][next][prev][last][first]----------------------------------------------------
Date:      Mon, 13 Jun 1994 03:33:30 -0800
From:      len@netsys.com (Len Rose)
To:        comp.protocols.tcp-ip
Subject:   Documenting "discard" service

Can anyone point me to anything that really documents the 
inet "discard" service? I've looked through the source and 
I'd like more background.. Thanks..

Len

-- 
"What a long strange trip it's been..." or "Gee, I  am free..."
"http://www.netsys.com"   --- Len Rose, 415-233-0441 (voice) len@netsys.com

-----------[000243][next][prev][last][first]----------------------------------------------------
Date:      12 Jun 1994 22:41:38 GMT
From:      desilva@ee.tamu.edu (Buveneka K Desilva)
To:        comp.protocols.tcp-ip.ibmpc,comp.protocols.tcp-ip
Subject:   Printing via a Printer connected to an ethernet line?

Hi Netters,

I assume this is the correct newsgroup. If not please do excuse!
We have a couple of DOS/Windows based 486's with Ethernet connections
and some workstations, all of which are connected to the net.

We are interested in connecting a fast printer via an ethernet adapter
to the campus network and sharing the printer.
The questions I have,

1. Is there a driver or some method to install this printer for windows
   printing? (is it possible to do this?)

2. If not can it be done thru a tcp-ip based utility (such as Winqvt or
   some other)?

3. I know that the sun's can print via an ethernet printer, but is it
   possible to have 2 or more W/S or/and Servers accessing it directly

4. Any other pointers?


Thank you'll. Appreciate a quick response,

-kanishka deSilva


-----------[000244][next][prev][last][first]----------------------------------------------------
Date:      Mon, 13 Jun 94 02:51:13 GMT
From:      amolitor@blefscu.network.com (Andrew Molitor)
To:        comp.protocols.tcp-ip
Subject:   Re: What is the MTU of FDDI?

	A couple people have pointed out that RFC1188 says flatly that
4352 bytes is the MTU for IP and ARP, so that's that, and it's right.
If you're doing IP on a FDDI ring, use an MTU of 4352 regardless of
whether or not you've got an NSC router or NSC manual which says 4470
is good.

	However, for non-IP/ARP datagrams, you still get 4470, or a
little more if you decide not to use SNAP.


		Andrew

-----------[000245][next][prev][last][first]----------------------------------------------------
Date:      Mon, 13 Jun 94 13:43:00 -0600
From:      mark.stapleton@cld9.com (Mark Stapleton)
To:        comp.protocols.tcp-ip
Subject:   Looking for Whois Client

ML>I am looking for a Whois Client or Server application for Windows.
ML>Hopefully freeware.  If anyone knows where I can ftp it from, it
ML>would be greatly appreciated.

Can't help you with freeware, but NetManage's Chameleon has it.

Mark
-30-

---
þ CmpQwk #UNREGþ UNREGISTERED EVALUATION COPY

-----------[000246][next][prev][last][first]----------------------------------------------------
Date:      13 Jun 1994 12:12:26 -0500
From:      gpalmer@blue.weeg.uiowa.edu (Gary Palmer)
To:        comp.protocols.tcp-ip
Subject:   BOOTP and NCSA Telnet

I am having trouble in getting the myip=BOOTP to work with the latest
release of NCSA Telnet, 2.3.07.

It seems that the FTP client works fine with this parameter, but if
I don't specifiy an exact ip address with myip=, Telnet will eventually
come back with an error that it cannot communicate with a BOOTP
server.

Again, I think I have the server working, because it satisifies FTP,
and it satisifies other TCP/IP software that I've been working with,
like WINSOCK, but NSCA Telnet 2.3.07 it does not.

Has anyone come across this problem?

-----------[000247][next][prev][last][first]----------------------------------------------------
Date:      13 Jun 94 04:19:43 GMT
From:      smiller@jafar.qualcomm.com (Scott Miller)
To:        comp.protocols.tcp-ip
Subject:   PPP/CHAP

Are there any public domain/shareware versions of CHAP for PPP out there?
Any help would be appreciated.

Scott Miller <smiller@qualcomm.com>
QUALCOMM Incorporated

-----------[000248][next][prev][last][first]----------------------------------------------------
Date:      13 Jun 1994 04:27:30 GMT
From:      iddasl@iddis.com (Alan Siping Liu)
To:        comp.protocols.tcp-ip
Subject:   IP multicast: igmp library?

Hi everyone,

I am trying to do IP multicast on Sparc10 under Solaris 2.3.
I find igmp.h file in directory /usr/include/netinet but cannot
find library file for the functions defined in the header file.
Can anyone help? Thanks a lot.

- Alan


-----------[000249][next][prev][last][first]----------------------------------------------------
Date:      13 Jun 1994 07:54:10 GMT
From:      jel@tel.vtt.fi (Jerry Lahti)
To:        comp.protocols.tcp-ip.ibmpc,comp.protocols.tcp-ip
Subject:   Re: Printing via a Printer connected to an ethernet line?

It depends quite a lot on the Ethernet connected printer you are using.
For example, the HP Laserjet 4Si with the JetDirect card is able
to support several printing protocols at the same time. This allows
UNIX hosts to print using TCP/IP while Windows for Workgroups workstations
can use a DLC based printing protocol with a special printer driver
provided by HP.  Mixed access is possible, because the clients can
be set up the tear down the printer connection after each job.  Note
that this does not work with lower-end or older HP printers because
they are constrained to using a single printing protocol, selected
by the first client which uses the printer.  I'm sure other manufactures
have printers with similar capabilities.

--
Jerry Lahti             |Voice:+358 0 456 5624, Fax:+358 0 456 7013
Technical Research      |Internet: Jerry.Lahti@vtt.fi 
Centre of Finland (VTT) |X.400: C=FI,ADMD=MAILNET,PRMD=VTT,PN=Jerry Lahti

-----------[000250][next][prev][last][first]----------------------------------------------------
Date:      Mon, 13 Jun 1994 09:12:58 GMT
From:      smithm@lincoln.gpsemi.com (Matt Smith)
To:        comp.protocols.tcp-ip.ibmpc,comp.protocols.tcp-ip
Subject:   Re: Printing via a Printer connected to an ethernet line?

In article <2tg2v2$q37@news.tamu.edu> desilva@ee.tamu.edu (Buveneka K Desilva) writes:
>From: desilva@ee.tamu.edu (Buveneka K Desilva)
>Subject: Printing via a Printer connected to an ethernet line?
>Date: 12 Jun 1994 22:41:38 GMT
 
>Hi Netters,
 
>I assume this is the correct newsgroup. If not please do excuse!
>We have a couple of DOS/Windows based 486's with Ethernet connections
>and some workstations, all of which are connected to the net.
 
>We are interested in connecting a fast printer via an ethernet adapter
>to the campus network and sharing the printer.
>The questions I have,
 
>1. Is there a driver or some method to install this printer for windows
>   printing? (is it possible to do this?)
 
>2. If not can it be done thru a tcp-ip based utility (such as Winqvt or
>   some other)?
 
>3. I know that the sun's can print via an ethernet printer, but is it
>   possible to have 2 or more W/S or/and Servers accessing it directly
 
>4. Any other pointers?

We have the same sort of set up that your looking for.
We use a HP JetDirect box that plugs into Ethernet and in my opinion
they are pretty good.

You get software that turns either a PC or a Server (Windows/Lan Manager/NT) 
into a print server and it will also use TCP/IP although you do need a 
Bootp server to configure it. These are all at the same time.

We have one accepting prints from a PC network, from a VAX, and from a UNIX
machine.

Hope this is of some help.

Matt





-----------[000251][next][prev][last][first]----------------------------------------------------
Date:      Mon, 13 Jun 1994 09:28:41 GMT
From:      rsgawera@fiveg.icl.co.uk (Raj Gawera)
To:        comp.protocols.tcp-ip
Subject:   Bootp

Dear netters,
	What is bootp ?
	Is it described in the FAQ?

	yours briefly but to the pointly,
		Raj Gawera


-----------[000252][next][prev][last][first]----------------------------------------------------
Date:      13 Jun 1994 18:24:52 -0400
From:      jcarroll@panix.com (Jim Carroll)
To:        comp.protocols.tcp-ip
Subject:   lpr protocol impementation details

 We have a rather technical problem with the lpd protocol. We are submitting 
 a job to a remote Sun/Unix system using the lpr  protocol.  The  server  is 
 however  responding  with  NACK(107)  to our request for "Receive a Printer 
 Job" command (0x02).

 We have verified that the host making the  request  is  in  the  /etc/hosts 
 file, and that /etc/hosts.equiv and /etc/hosts.lpd are both set to +.
 
 We have also tried 'lpr'ing the job from a DOS box, and it appears to work. 
 Does  anyone  have  any  idea  as  to what a NACK-107 response from the lpd 
 means?
 
 Thanks
 Jim C.
 
-- 
************************************************
* Infinite Diversity, in Infinite Combinations *
************************************************


-----------[000253][next][prev][last][first]----------------------------------------------------
Date:      13 Jun 94 12:19:07 GMT
From:      tom@wcc.oz.au (Tom Evans)
To:        comp.protocols.tcp-ip,comp.dcom.sys.wellfleet
Subject:   Re: ICMP Redirect THEN Host Unreachable?

In article <3928@wcc.oz.au>, tom@wcc.oz.au (Tom Evans) writes:
> I've got a packet trace here that looks WEIRD to me. There's two
> famous-name IP routers on a backbone with a host, call them R1, R2 and
> H1. There's another host on the other side of R2 - call it H2:
> 
>       [ R1 ]============[ R2 ]======[ H2 ]
>                  ||
>                [ H1 ]
> 
> H1 sends a packet (an ICMP Ping reply) to H2, but via R1 (its
> default gateway).  R1 forwards the packet via R2 to H2, and sends
> an ICMP Redirect to H1. Fine. Then R1 sends an ICMP Host
> Unreachable to H1 for the same packet. Not fine. This doesn't
> seem to be what the RFC says. Any opinions? Is this legal?

I got mail from "THE famous router vendor" asking if R1 was them, and
expressing the opinion that R1 isn't playing by the rules. By chance
R2 happens to be a Cisco :-), but R1 is a "Wellfleet model FN
running 5.75 software".

Here's a packet dump. The customer has asked me to disguise his IP
addresses and machine names - the first two bytes of all IP
addresses have been changed to "xx.yy" and the checksum is "zz zz"
to stop clever people from reconstructing the IP addresses in spite
of this :-)
                                             icmp type
 lnth proto         source     destination   src port   dst port
   70 icmp          gw         megan         redirect
 00 00 18 00 08 66 00 00 a2 01 28 9c 08 00 45 00
 00 38 ee 34 00 00 1e 01 zz zz xx yy 44 01 xx yy
 44 05 05 01 b3 8d xx yy 44 02 45 00 00 54 fc d8
 00 00 3b 01 zz zz xx yy 44 05 xx yy 48 02 00 00
 47 6e 32 28 00 3e

   70 icmp          gw         megan         dst unreachable
 00 00 18 00 08 66 00 00 a2 01 28 9c 08 00 45 00
 00 38 ee 35 00 00 1e 01 zz zz xx yy 44 01 xx yy
 44 05 03 01 83 2a 00 00 00 00 45 00 00 54 fc d8
 00 00 3b 01 zz zz xx yy 44 05 xx yy 48 02 00 00
 47 6e 32 28 00 3e

========================
Tom Evans  tom@wcc.oz.au
Webster Computer Corp P/L, 11 Glenvale Crescent Mulgrave, Melbourne 3170
Victoria, Australia 61-3-561-9999  FAX ...560-0067  A.C.N. 004 818 455


-----------[000254][next][prev][last][first]----------------------------------------------------
Date:      13 Jun 94 13:16:52 GMT
From:      bparker@pilot.njin.net (Bruce Parker)
To:        comp.protocols.tcp-ip,comp.security.unix
Subject:   Re: Is IP source routing a bad idea?

treynold@fred.lasalle.edu (Tommi) writes:

>In article <1994Jun6.032935.17859@martha.utcc.utk.edu> venu@voodoo.utcc.utk.edu (Nair Venugopal) writes:
>[stuff deleted]
 
>>2) Is there any situation, other than trouble shooting, where
>>the source routing option will be of use?
 
>Not as far as I can think of off hand; about the only thing that I can think 
>of/remember that source routing is used for is (as you mentioned) when 
>troubleshooting--it can eliminate the possibility of different packets 
>taking different routes along their merry way...

Bhagwat and Perkins (Mobile and Location-Independent Computing
Symposium), Johnson (CMU TR), and Rekhter and Perkins (Internet draft
"Loose Source Routing for Mobile Hosts") use LSR to allow mobile hosts
to retain the same IP address while moving through the internet.

Cheers,
Bruce
-- 
Bruce Parker
4314 Infotech   				        (201) 596-3369
Computer and Information Science Department 	        parker@vienna.njit.edu
New Jersey Institute of Technology, Newark, New Jersey  07102 USA

-----------[000255][next][prev][last][first]----------------------------------------------------
Date:      Mon, 13 Jun 1994 13:56:19 GMT
From:      prodrig@gundam.batdd (Paul)
To:        comp.protocols.tcp-ip
Subject:   TCP ports

Hello;

	I'm hoping someone can answer a couple of basic questions, or help me to get started on the right track by letting me know where some of this information can be obtained.  What I'm trying to do is connect a vax to a sparc station and use TCP for data transfer. Thank you very much in advance. 

1. When establishing a TCP connection, how does one determine what the port numbers will be in use on both machines?

2. When transfering data between a vax and a sparc station, will the data be transfered in a pre-determined format such as binary or ASCII, or will both users have to determine which format will be used in advance.




-----------[000256][next][prev][last][first]----------------------------------------------------
Date:      Mon, 13 Jun 94 23:30:03 -0500
From:      baldwinl@delphi.com
To:        comp.protocols.tcp-ip
Subject:   Re: Telnet response time after packet drop?

Tom Graham <ucistdg@st.unocal.COM> writes:
 
>Just recently saw this for myself!!!!  User complaning that TCP/IP files
>transfers were taking forever.  Did a Sniffer trace, saw dropped packets
>and retransmission times of 16 seconds!!!  Talk about a snails pace.
 
That can be normal if it was the 8th attempt to retrasmit the same packet.
What you want to see is the initial delay to retransmit the packet
(excuse me, the segment) the FIRST time.
My problem was that IBM's TCP for OS/2 enfources a MINIMUM retransmission
timeout of 1000-1500ms.  Meaning that if you drop a packet it will be
1 - 1.5 seconds before you even TRY to retransmit, REGARDLESS of the
actual normal round trip response time.  THIS kind of delay is
too excessive for local LAN segments, but very appropriate for
low-speed wide area links.
 
I don't know what implementation of TCP you are using but thre
(there) may be parameters that allow you to configure this
timeout value. Rememember, however, that speeding retranmission
can increase congestion--making the problem even worse.  You have
to be careful and understand where you're dropping packets and
why.  Move the Sniffer from one segment to another and determine
exactly where you're dropping packets.
 

-----------[000257][next][prev][last][first]----------------------------------------------------
Date:      13 Jun 1994 15:26:19 GMT
From:      brawls@beeblebrox (Brad Rawls)
To:        comp.protocols.tcp-ip
Subject:   OSPF and address maintenance

Can anyone identify whether "canned" software packages exist that perform
IP address administration for you automatically?  Specifically, we have
an environment with multiple class B's, many class C's using OSPF and
BGP.  VLSM's are being employed on a global nature.

Any ideas for IP address administration short of custom coding or 
database?

--
----------------------------------------------------------------------
|  Brad Rawls                            Work: 703-708-1176           |
|  Citicorp Global Information Network   Fax:  703-708-1184	      |
|  1900 Campus Commons Dr.               brad.rawls@mail.citicorp.com | 
|  Reston, VA 22091						      |
|  Mail Stop 3/8                                                      |
 ----------------------------------------------------------------------

-----------[000258][next][prev][last][first]----------------------------------------------------
Date:      Mon, 13 Jun 1994 16:29:55 +0000
From:      ggoodey@sblack.demon.co.uk (Graham Goodey)
To:        comp.protocols.tcp-ip.ibmpc,comp.protocols.tcp-ip
Subject:   Re: Printing via a Printer connected to an ethernet line?

Kanishka,

We are using a HP 4M with a Jet Direct Card and a serial line 
connection (for historic reasons)  - works perfectly. 

The advantage of this over the Jetdirect box is that there isn't 
another box and power cables hanging around.

You also *don't* need bootp, which I didn't think you needed with the box
but I don't have 1 of those and I bow to experience of a box owner. However,
you can use a bootp server should you wish.

I am just about to purchase an HP 4M+ based on my experiences which 
now comes with the Jetdirect card already installed (TCP/IP, appletalk, etc).

hope this is of help

regards Graham

-- 
Graham Goodey
Internet: ggoodey@sblack.demon.co.uk

-----------[000259][next][prev][last][first]----------------------------------------------------
Date:      Mon, 13 Jun 94 16:41:57 GMT
From:      thssaaf@iitmax.iit.edu (Abdulkader A. Al-Fantookh)
To:        comp.protocols.tcp-ip
Subject:   A transport Protocol Simulator is needed

Hello everybody,
Currently, I'm in a process of evaluating some transport protocol techniques.
I really need a simulator that I can use for this evaluation. For example, I
will give the simulator several parameters including, the speed of the link, the
speed of the processor, checksum, packet size, and some others. In the second
run, I will give the same parameters except that I will change the packet size,
and then compare the two runs.

Thanks.

-Abdul Alfantookh
Illinois Institute of Technology
Phone : (708)594-0475

-----------[000260][next][prev][last][first]----------------------------------------------------
Date:      13 Jun 1994 15:12:39 +0100
From:      robjan@rabo.nl (Rob Janssen)
To:        comp.protocols.tcp-ip
Subject:   Re: Documenting "discard" service

In <len-130694033330@fx.netsys.com> len@netsys.com (Len Rose) writes:

>Can anyone point me to anything that really documents the 
>inet "discard" service? I've looked through the source and 
>I'd like more background.. Thanks..

Try RFC 863

Rob

-----------[000261][next][prev][last][first]----------------------------------------------------
Date:      13 Jun 1994 17:10:02 GMT
From:      Adam Wildavsky <adamw@panix.com>
To:        panix.questions,panix.internet.slip,panix.internet.ppp,comp.protocols.tcp-ip
Subject:   Re: Mosaic conflict?

In article <2skm4t$d2u@panix.com>
Arthur Cinader, acinader@panix.com writes:

> I have mosaic 1.03 on my Quadra 800.  When I launch it, I get
> "Unable to connect to remote host" in the status bar and "text
> has not been loaded" in the text box.

... (more details omitted)

> Any ideas, recommendations?

What happens when you open a local html file?

> Anybody know the developers address so I can mail them a copy
> of this letter?

According to the NCSA Mac home page

http://www.ncsa.uiuc.edu/SDG/Software/MacMosaic/MacMosaicHome.html

it's mosaic-mac@ncsa.uiuc.edu.

AW

-----------[000262][next][prev][last][first]----------------------------------------------------
Date:      13 Jun 1994 20:00:29 GMT
From:      barmar@think.com (Barry Margolin)
To:        comp.protocols.tcp-ip,comp.unix.aix
Subject:   Re: IP Adressing of Multiple Interfaces

In article <2tabiq$173t@source.asset.com> danglert@source.asset.com (Terry Dangler) writes:
>We are using an RS/6000, is there any reason why the following IP
>addressing scheme would not work:
>
>Ethernet Interface IP Address: 192.131.125.10 connects to gateway and Internet
>SLIP Interface IP Address: 192.131.125.25 attached to Xstation
>Token Ring Interface IP Address: 192.131.125.33 connects to LAN

You haven's said what your subnet mask is.  Assuming it's just the default
mask for a class C network, the above won't work.  All those addresses are
on the same subnet, so the interfaces must all be connected to the same
physical (possibly bridged) network.

If your network uses a subnet mask of 255.255.255.240 then the above
addressing scheme would work.  But this subnet mask only allows 14 nodes
per subnet.
-- 
Barry Margolin
System Manager, Thinking Machines Corp.

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

-----------[000263][next][prev][last][first]----------------------------------------------------
Date:      Tue, 14 Jun 94 07:30:00 -0640
From:      john.will@dscmail.com (John Will)
To:        comp.protocols.tcp-ip
Subject:   NIS <----> PCNFS problem

J > All works fine, but in Windows 3.1, pc-nfs' network services
J >(telnetw, ftpw and others) only use the NIS map (Hostmap) and doesn't
J >resolve in the name server host.
J >
J > What shall I do to correct this problem?, i.e., pc-nfs' services
J >under Windows work with the name server host.

Wait until Sun's PC-NFS supports something other than NIS? :-)

-----------[000264][next][prev][last][first]----------------------------------------------------
Date:      13 Jun 1994 21:09:32 GMT
From:      abch91@control.auc.dk (alex bo christensen)
To:        comp.protocols.tcp-ip
Subject:   how to get local inet. addr ?

I have a simple problem, but it seems hard to solve. To problem is :

A program runs on a host in a network, and is going to use the internet address for this host.
Is it possible to get this internet addresse, and how ?

The os is SunOs solaris.
Compiler gcc






-----------[000265][next][prev][last][first]----------------------------------------------------
Date:      13 Jun 94 21:15:59 GMT
From:      jkay@cs.ucsd.edu (Jon Kay)
To:        comp.protocols.tcp-ip
Subject:   Re: What is the MTU of FDDI?

In article <Cr5M2B.GzB@calcite.rhyolite.com> vjs@calcite.rhyolite.com (Vernon Schryver) writes:
>4352 was choosen in a long ago FDDI birds-of-a-feather InterOp meeting.
>
>I like to use 4096 of payload in TCP kernel code to go fast, but that's
>ok because since there is no law that says you must transmit full-siced
>frames.  You need only be prepared to accept bigger frames.

I like 4352 for an if_mtu because most networked workstations do
orders of magnitude more NFS than TCP, and needing to process 3/2 as
many packets for 8k data transmissions does take significantly more
time.  However, most TCPs incorporate rounding down to MCLBYES, so if
that's 4096 bytes and your page size is 4k, and you implement page
flipping, you can have your cake and eat it too.

							Jon

-----------[000266][next][prev][last][first]----------------------------------------------------
Date:      14 Jun 1994 04:50:37 -0400
From:      r6788@hopi.dtcc.edu (Joe Rach)
To:        comp.protocols.tcp-ip
Subject:   get_user_name()???


Hello,

  I was wondering if there is a function that will return a user's login
name from a socket. I've got gethostname, etc.. working and want to varify
login names. Some ftp servers from what i've been told can do this.

  Any pointers to information would be greatly apriacted...

                         Thanks in advance,
                         Newby at TCP/IP...


-----------[000267][next][prev][last][first]----------------------------------------------------
Date:      Mon, 13 Jun 1994 22:39:09 GMT
From:      ucistdg@st.unocal.COM (Tom Graham)
To:        comp.protocols.tcp-ip
Subject:   Re: Telnet response time after packet drop?

In article <2sobsf$jdv@news.ccit.arizona.edu>,
Aaron Leonard <Leonard@Arizona.EDU> wrote:
>
>In article <2snnej$em0@news.CCIT.Arizona.EDU>, leonard@telcom.arizona.edu 
>(Aaron Leonard) writes:
>[...]
>|| With a Sniffer, it seems to take nearly two
>||seconds for TCP to recover from a single dropped packet.  After reading up
>||on TCP retransmission algorithms it almost seems like this is normal.
>|
>|Yup, that's just about normal--although the actual retransmission
>|delay will be based upon TCP's estimated round-trip time.
>| [...]
>|For a nice gory practical discussion, see chapter 21 in Stevens'
>|
Just recently saw this for myself!!!!  User complaning that TCP/IP files
transfers were taking forever.  Did a Sniffer trace, saw dropped packets
and retransmission times of 16 seconds!!!  Talk about a snails pace.
This was caused by hub/repeater that does not like to pass large packets!!
That is, with packet sizes starting at about 1200 bytes, the hub drops
more as the packets get larger.  Just posted this in comp.dcom.lans.ethernet.
Looking for validation or a sanity check on this, hubs that like only small
etherner packets.  The user was saying,  "TCP/IP stinks, IPX is much faster".
Any input anyone????
Tom

-- 
Tom Graham                               Unocal Corporate Information Services
Phone: (714)693-5808                     5460 E. La Palma Ave.
Internet: tom.graham@st.unocal.com       Anaheim Hills, Ca 92807

-----------[000268][next][prev][last][first]----------------------------------------------------
Date:      Tue, 14 Jun 1994 00:48:38 GMT
From:      atkinson@sundance.itd.nrl.navy.mil (Ran Atkinson)
To:        comp.protocols.tcp-ip
Subject:   Re: lpr protocol impementation details

In article <2timbk$roi@panix.com> jcarroll@panix.com (Jim Carroll) writes:
> We have a rather technical problem with the lpd protocol. We are submitting 
> a job to a remote Sun/Unix system using the lpr  protocol.  The  server  is 
> however  responding  with  NACK(107)  to our request for "Receive a Printer 
> Job" command (0x02).
>
> We have verified that the host making the  request  is  in  the  /etc/hosts 
> file, and that /etc/hosts.equiv and /etc/hosts.lpd are both set to +.
> 
> We have also tried 'lpr'ing the job from a DOS box, and it appears to work. 
> Does  anyone  have  any  idea  as  to what a NACK-107 response from the lpd 
> means?

With lpr/lpd it is usually best to start by looking at the BSD sources.
BSD sources for this sort of thing are probably available online
from ftp.uu.net someplace.  There is an RFC on the protocol, but the
RFC came out long after the program was widespread and isn't all that
definitive in practice.

Ran
atkinson@itd.nrl.navy.mil



-----------[000269][next][prev][last][first]----------------------------------------------------
Date:      Tue, 14 Jun 1994 00:55:23 GMT
From:      atkinson@sundance.itd.nrl.navy.mil (Ran Atkinson)
To:        comp.protocols.tcp-ip
Subject:   Re: Telnet response time after packet drop?

In article <CrCxL9.Cty@unocal.com> ucistdg@st.unocal.COM (Tom Graham) writes:
>
> Just recently saw this for myself!!!!  User complaning that TCP/IP
> files transfers were taking forever.  Did a Sniffer trace, saw dropped
> packets and retransmission times of 16 seconds!!!  Talk about a snails
> pace.  This was caused by hub/repeater that does not like to pass
> large packets!!  That is, with packet sizes starting at about 1200
> bytes, the hub drops more as the packets get larger.  Just posted this
> in comp.dcom.lans.ethernet.  Looking for validation or a sanity check
> on this, hubs that like only small etherner packets.  The user was
> saying, "TCP/IP stinks, IPX is much faster".
>
> Any input anyone????

Yes.  The "Path MTU Discovery" technique documented in a
standards-track RFC can often be helpful in such circumstances.
However, if one or more of the critical components is badly enough
implemented to drop legal packets, that same component is not likely
to be implementing Path MTU Discovery.  Hence, Path MTU Discovery
doesn't always help.  The bug you describe is in the hub/repeater,
which might not even be implementing IP or ICMP.

  If you can manually set the MTU size on the host interfaces, you
might be able to work around it.  This is not demonstrating that IPX
is better; IPX is just getting lucky.

Ran
atkinson@itd.nrl.navy.mil



-----------[000270][next][prev][last][first]----------------------------------------------------
Date:      14 Jun 1994 11:45:54 -0500
From:      lin@cs.purdue.edu (John Chueng-Hsien Lin)
To:        comp.protocols.tcp-ip
Subject:   Re: Telnet response time after packet drop?

In article <R69N39r.baldwinl@delphi.com>, baldwinl@delphi.com writes:
> Tom Graham <ucistdg@st.unocal.COM> writes:
>
> >Just recently saw this for myself!!!!  User complaning that TCP/IP files
> >transfers were taking forever.  Did a Sniffer trace, saw dropped packets
> >and retransmission times of 16 seconds!!!  Talk about a snails pace.
>
> That can be normal if it was the 8th attempt to retrasmit the same packet.
> What you want to see is the initial delay to retransmit the packet
> (excuse me, the segment) the FIRST time.
> My problem was that IBM's TCP for OS/2 enfources a MINIMUM retransmission
> timeout of 1000-1500ms.  Meaning that if you drop a packet it will be
> 1 - 1.5 seconds before you even TRY to retransmit, REGARDLESS of the
> actual normal round trip response time.  THIS kind of delay is
> too excessive for local LAN segments, but very appropriate for
> low-speed wide area links.

  Under normal operating condition, a LAN should not drop TCP packets
often (it it does, then something must be broken). For an interesting
discussion about the reasons for setting a lower bound on TCP
Retransmission Time-Out (RTO) and how to determine it without accessin
the TCP source code, see the following paper:

ftp:gwen.cs.purdue.edu:/pub/lin/probing.TCP.ps.Z

John Lin (lin@cs.purdue.edu)









-----------[000271][next][prev][last][first]----------------------------------------------------
Date:      14 Jun 1994 11:46:23 -0500
From:      dpm@bga.com (David P. Maynard)
To:        comp.protocols.tcp-ip
Subject:   Re: bootp server response times

Paul J Lustgraaf <grpjl@iastate.edu> wrote:
>Charl Barnard <charl@pondermatic.ee.up.ac.za> wrote:
>>
>>My problem is that the server takes extremely long to respond, and
>>quite often doesn't respond at all. Sometimes (usually shortly after
>>previous attempts, the server responds instantaneously ! 
>
>Don't use inetd to start bootpd.  Run it in standalone mode.
>The CMU version, at least, supports a -s switch to make bootpd run
>as a daemon.  Try it, you'll like it.

Agreed.  Standalone operation will likely solve many of your problems.
If your config file is large, it takes a long time to start up the
server.

However, an apparently related problem is that a lot of the DOS/Mac
client software isn't very forgiving of "slow" BOOTP servers.  It
seems to be fairly common to fire off a half-dozen requests at
1-second intervals and give up if an "acceptable" reponse isn't
received.  Some packages apparently check the sequence number because
they ignore responses from previous requests.  That means the response
must come back in under 1 second.  (I haven't verified this, but some
clients have logged the behavior.)  For a SLIP line, the 1-second
turnaround requirement is pretty marginal.

-dpm

-- 
 David P. Maynard, Carnegie Mellon University & Dependable Solutions
 USMail: 14312 Richard Walker Blvd, Austin, TX 78728-6862
 EMail: dpm@depend.com,  Tel: +1 512 251 8122,  Fax: +1 512 251 8308
--

-----------[000272][next][prev][last][first]----------------------------------------------------
Date:      14 Jun 1994 07:59:37 GMT
From:      visser@convex.com (Lance Visser)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP ports

In <CrC9Dw.GsD@pica.army.mil> prodrig@gundam.batdd (Paul) writes:

>Hello;

+>	I'm hoping someone can answer a couple of basic questions, or help me to get started on the right track by letting me know where some of this information can be obtained.  What I'm trying to do is connect a vax to a sparc station and use TCP for data transfer. Thank you very much in advance. 

	Go pick up a book on socket programming (or Unix network programing).
You could also read the bind(2) and connect(2) man pages on the sparc.

	IF the vax is running ULTRIX, there should be documentation or
man pages for sockets.  If the vax is running VMS or something else,
then I would suggest looking at any documentation the vax has for clues.

+>1. When establishing a TCP connection, how does one determine what the port numbers will be in use on both machines?

	The bind() and connect() system calls determine what ports should
be used.  If you dont pick a local port, tcp will assign one for you.

	The "server" side of the connection is usually bound to a port
you know so that the client can find it.  The client can either specifically
bind to a local port or let tcp assign it a default port at random.
	The client establishes the connection with the server via the
connect() system call.  In the connect syscall is specified the server
"port" you wish to connect to.



+>2. When transfering data between a vax and a sparc station, will the data be transfered in a pre-determined format such as binary or ASCII, or will both users have to determine which format will be used in advance.

	TCP is a byte stream protocol.  There is no pre-determined format
You are pushing a stream of 8-bit bytes from one side to the other.  Binary
and ascii are FTP concepts put on top of tcp.


-----------[000273][next][prev][last][first]----------------------------------------------------
Date:      14 Jun 1994 08:27:57 GMT
From:      i.ellery@uea.ac.uk (Ian Ellery)
To:        comp.protocols.tcp-ip
Subject:   Re: NIS <----> PCNFS problem !

In article <1994Jun10.201135.13478@lauca.usach.cl>, jprado@lauca.usach.cl (Jorge Andres Prado Troncoso) says:

>        We are running PCNFS 5.0 under Ultrix 4.3 (DEC System 5000/240)
>and yellow page (yp).
>        All works fine, but in Windows 3.1, pc-nfs' network services
>(telnetw, ftpw and others) only use the NIS map (Hostmap) and doesn't
>resolve in the name server host.

Either wait for 5.1 which is finally supposed to do this, or get your NIS
hosts map to 'fail over' to the DNS. PCNFS still looks up hostnames in
the NIS, but if it is not in your local hosts map, NIS will send out a DNS 
request and get the hostname. You need to add a '-d' flag somewhere
in the NIS makefile - sorry been a while and I can't see a manual.

    hope this helps,
               Ian
----
Ian Ellery, Computer Centre, UEA, Norwich, Norfolk, NR4 7TJ,  UK

-----------[000274][next][prev][last][first]----------------------------------------------------
Date:      14 Jun 1994 20:20:14 -0700
From:      dcrane@crl.com (David Crane)
To:        comp.security.misc,comp.protocols.tcp-ip
Subject:   Re: Query: trusted routers

Ran Atkinson (atkinson@sundance.itd.nrl.navy.mil) wrote:
: In article <2tk9jp$auh@gabriel.resudox.net> sharris@resudox.net (Sandy Harris) writes:
: >Are there any packet filtering IP routers evaluated for
: >interesting security levels, American B's or some other country's
: >standard?
 
:   I understand that Advanced Computer Communications Systems (ACC
: Systems) has a fairly new product named "Stealth" which is targeted at
: an Orange Book/Red Book B3 level.  ACC Systems has indicated that they
: are submitting it to NCSC for formal evaluation.  I'm pretty sure that
: final evaluation is not yet complete.  You might contact them directly
: for more information.  They have an office somewhere near Columbia,
: Maryland, USA.  The product is real -- they showed one in DC late last
: week at the AFCEA tradeshow.  It implements most normal routing
: protocols.
 
:   To my knowledge that is the only router designed for formal
: evaluation under both Orange Book and Red Book criteria.  Its also the
: only B3-targetted router I know about.  I would guess that they'll get
: a fair amount of business if they price it reasonably.

It's my understanding that the essential problem with routers is that 
they are easily spoofed.  What does one do to a router to make it really 
effective as a security wall?  They aren't bright enough to question what
they receive.

-----------[000275][next][prev][last][first]----------------------------------------------------
Date:      Tue, 14 Jun 1994 11:25:52 GMT
From:      steven@unipalm.co.uk (Steven Vincent)
To:        comp.protocols.tcp-ip
Subject:   Re: FTP PCTCP ---> HP1200C Jet Direct?

temp@sneezy.cc.utexas.edu (Lee Thomas) writes:

>Hi,
 
>I just bought an HP 1200C color printer with an ethernet card (Jet Direct).
>I need to print to it from an IBM RS/6000 using TCP/IP and PC's with FTP's 
>PCTCP software.  Does  anyone have any ideas or specific instructions on how
>to get either system to print to the HP 1200C using TCP/IP?  Please E-mail
>me if you have a solution or ideas.


For PC/TCP there are two options at least!

Depending on the jet direct card in use PC/TCP might be able to use the
LPR protocol to talk to it directly. (This is for Jet Direct cards that
support lpr/lpd functions).

Alternativly "Iprint -b 9100 <filename>" with the IP address of the Card
set as the Imagen-print-server in pctcp.ini often works. This is brute
force no spooling.


Be carefull using lots of PC's direct to the Jet Direct cards as they
will not spool the jobs and let the PC's go. Its far better to send the
jobs to a central queue on the RS/6000 from which a single stream feeds
to the printer. Configuring the AIX for LPR/LPD is fairly straight forward
via Smit, otherwise speak to IBM.

>Thanks!
 
>-Lee
 
>---------------------------------------------------------------------------
>Lee Thomas                              Voice: (512)322-6386
>Systems Analyst                           FAX: (512)322-6350
>City of Austin Electric Utility      Internet: temp@ccwf.cc.utexas.edu
>---------------------------------------------------------------------------

-----------[000276][next][prev][last][first]----------------------------------------------------
Date:      14 Jun 1994 11:36:17 GMT
From:      charl@pondermatic.ee.up.ac.za (Charl Barnard)
To:        comp.protocols.tcp-ip
Subject:   bootp server response times

Hi,

I am trying to use bootp with all the networked DOS-type PC's running
CUTCP on our segment. As a bootp server, I use an RS/6000 340, as it
also does some bootp serving for dataless clients.

My problem is that the server takes extremely long to respond, and
quite often doesn't respond at all. Sometimes (usually shortly after
previous attempts, the server responds instantaneously ! 

I have monitored the request broadcasts, and the PC's seem to 
broadcasting the bootp-requests
correctly. Further, I can see that the inetd actually does start
bootpd on the server, and a file bootpd.dump is created. The only
thing it doesn't do, is respond !

I tried using a Linux box as server, with identical results.

Is CUTCP the problem here ? Can anyone suggest s better way to debug ?
Or is the bootpd source available somewhere ?

Any suggestions would be appreciated.

Charl Barnard
(charl@ford.ee.up.ac.za)






-----------[000277][next][prev][last][first]----------------------------------------------------
Date:      14 Jun 1994 12:02:49 GMT
From:      tudball@lis.pitt.edu (A. Bruce McDonald)
To:        comp.protocols.tcp-ip
Subject:   Re: ICMP Redirect THEN Host Unreachable?

Barry Margolin (barmar@think.com) wrote:
: In article <3928@wcc.oz.au> tom@wcc.oz.au (Tom Evans) writes:
: >H1 sends a packet (an ICMP Ping reply) to H2, but via R1 (its default gateway).
: >R1 forwards the packet via R2 to H2, and sends an ICMP Redirect to H1. Fine.
: >Then R1 sends an ICMP Host Unreachable to H1 for the same packet. Not fine.

I have seen the same thing with an AGS+.


: Seems wrong to me.  Host Unreachable should only be sent if the router has
: no route to the destination.  If it can send a redirect for the destination
: then it obviously thinks it's reachable.
: -- 
: Barry Margolin
: System Manager, Thinking Machines Corp.
 
: barmar@think.com          {uunet,harvard}!think!barmar

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

A. Bruce McDonald
tudball@icarus.lis.pitt.edu
University of Pittsburgh				"All Good Things..."

Work Phone: (412) 624-9499

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

-----------[000278][next][prev][last][first]----------------------------------------------------
Date:      14 Jun 1994 12:45:44 GMT
From:      SPENCER@alpha.salem.ge.com (Andy Spencer)
To:        comp.protocols.tcp-ip,comp.protocols.nfs
Subject:   NFS Buffer size & MTU for enet/fddi


 This problem may be related to the version of NFS that our O/S (LynxOS) is
 using, or the rev of the firmware in our router, but all in all I believe 
 it is probably a basic issue.  Here is our situation:

 +----------+                                          +-----------+
 | Novell   |    Fiber (FDDI)   +--------+  Ethernet   |  UNIX     |
 |NFS Server|-------------------| Router |-------------| NFS Client|
 +----------+                   +--------+             +-----------+
 
  What we see it that nfs transfers from the Novell NFS server to the UNIX
  client often die.  The client side (unfsio) is set for 10 2second retries
  but can be made to work if the nfs_rdsize is dropped to 1024 or below.
  Local (on the same ethernet) transfers work fine at larger buffer sizes.

  Watching the packets on the ethernet shows nfs (udp) packets of 1200 to
  1500 byte packets consistently cause failure, but droping the rdsize to
  512 somehow regulates the link so that packets on the wire are 600 or
  700 bytes long and don't seem to cause problems.  I strongly suspect it
  has something to do with the MTU of the different links, but don't under-
  stand how changing the rdsize regulates the flow differently if it is
  over the router rather than locally on the ethernet.

  Any help would be appreciated!


Andy Spencer                                      GE Drive Systems
AESpencer@salem.ge.com                            1501 Roanoke Blvd./Rm 287
(703) 387-7361  (Voice)                           Salem, VA  24153
(703) 387-8651  (FAX)

-----------[000279][next][prev][last][first]----------------------------------------------------
Date:      Tue, 14 Jun 1994 13:02:01 GMT
From:      youki-k@is.aist-nara.ac.jp (Youki Kadobayashi)
To:        comp.protocols.tcp-ip
Subject:   Routing protocol simulator?

Are there any simulation tool for routing protocols?  (specifically OSPF?)
How do OSPF folks know that the protocol operates properly?

--
	// Youki Kadobayashi <youki-k@is.aist-nara.ac.jp>
	// Graduate School of Information Science
	// Nara Institute of Science and Technology, Japan

-----------[000280][next][prev][last][first]----------------------------------------------------
Date:      14 Jun 1994 13:36:01 GMT
From:      grpjl@iastate.edu (Paul J Lustgraaf)
To:        comp.protocols.tcp-ip
Subject:   Re: bootp server response times

In article <CHARL.94Jun14133617@pondermatic.ee.up.ac.za>,
Charl Barnard <charl@pondermatic.ee.up.ac.za> wrote:
>
>I am trying to use bootp with all the networked DOS-type PC's running
>CUTCP on our segment. As a bootp server, I use an RS/6000 340, as it
>also does some bootp serving for dataless clients.
>
>My problem is that the server takes extremely long to respond, and
>quite often doesn't respond at all. Sometimes (usually shortly after
>previous attempts, the server responds instantaneously ! 
>
>I have monitored the request broadcasts, and the PC's seem to 
>broadcasting the bootp-requests
>correctly. Further, I can see that the inetd actually does start
>bootpd on the server, and a file bootpd.dump is created. The only
>thing it doesn't do, is respond !
>

Don't use inetd to start bootpd.  Run it in standalone mode.
The CMU version, at least, supports a -s switch to make bootpd run
as a daemon.  Try it, you'll like it.

-- 
Paul Lustgraaf             "It's easier to apologize than to get permission."
Network Specialist                                      Grace Hopper
Iowa State University Computation Center                    grpjl@iastate.edu
Ames, IA  50011                                                  515-294-0324

-----------[000281][next][prev][last][first]----------------------------------------------------
Date:      Tue, 14 Jun 1994 13:41:01 GMT
From:      abell@velveeta.apdev.cs.mci.com (Andrew_Bell)
To:        comp.protocols.tcp-ip
Subject:   Read returns zero even when RST received.

Some postings have gone across here saying that if a read is pending when
the RST is received from a remote side, then the read will return -1 and
errno == ECONNRESET.  If there is a bunch of stuff in the receive queue
and you are reading along happily, I don't get a hint of a problem until
the queue is empty.  This is fine.  When I have emptied the queue, I just
get a result of 0 from my read, indicating a disconnect, but not
necessarily an aborted connection.

Is there anyway I can be sure I have gotten an aborted connection
instead of just a close one?  BTW, running AIX 3.2.5 on both sides.

Andrew Bell
MCI Communications
abell@chong.nms.cs.mci.com

-----------[000282][next][prev][last][first]----------------------------------------------------
Date:      14 Jun 1994 13:55:19 GMT
From:      anilg@cs.tamu.edu (Anil Kumar Reddy Gurijala)
To:        comp.protocols.tcp-ip
Subject:   Question on tcp protocol

Hi folks,
	 Under what circumstances a tcp layer packs two different data segments
	 from upperlayer into a single packet? i.e. if I use send(a) and send(b)
	 in two different instructions, is it possible that tcp layer packs both
	 of them in a single packets and sends them to remote host?

anil gurijala
anilg@cs.tamu.edu

-----------[000283][next][prev][last][first]----------------------------------------------------
Date:      Tue, 14 Jun 1994 17:01:49 GMT
From:      donp@novell.com (don provan)
To:        comp.protocols.tcp-ip
Subject:   Re: Question on tcp protocol

In article <2tkcs7$rgu@news.tamu.edu> anilg@cs.tamu.edu (Anil Kumar Reddy Gurijala) writes:
> Under what circumstances a tcp layer packs two different data segments
> from upperlayer into a single packet? i.e. if I use send(a) and send(b)
> in two different instructions, is it possible that tcp layer packs both
> of them in a single packets and sends them to remote host?

When does TCP ignore send boundaries? Whenever it wants! TCP provides
a reliable byte stream of data. While each byte sent will be delivered
in order and intact, TCP makes no attempt at all to maintain the
original grouping of the bytes. To maintain the grouping, you'll need
to have your own mechanism in the application protocol.

						don provan
						donp@novell.com

-----------[000284][next][prev][last][first]----------------------------------------------------
Date:      Tue, 14 Jun 1994 18:43:13 GMT
From:      gnn@netcom.com (George Neville-Neil)
To:        comp.protocols.tcp-ip
Subject:   Re: Question on tcp protocol

anilg@cs.tamu.edu (Anil Kumar Reddy Gurijala) writes:

>	 Under what circumstances a tcp layer packs two different data segments
>	 from upperlayer into a single packet? i.e. if I use send(a) and send(b)
>	 in two different instructions, is it possible that tcp layer packs both
>	 of them in a single packets and sends them to remote host?

If I understand your question correctly you are asking about where the data
from a particular call to send(2) on a TCP socket winds up.  TCP is a stream
protocol and will pack, or segment data, independantly of calls to send.  
If you want a packet oriented protocol you should look at UDP, or you can place
your own makers in the stream of a TCP connection.

Hope this helps.

Later,
George

-- 
gnn@netcom.com

Gentlemen, I will not have you fighting in the War Room.
					--- The President in Dr. Strangelove

-----------[000285][next][prev][last][first]----------------------------------------------------
Date:      14 Jun 1994 19:03:30 GMT
From:      karthik@informix.com (Karthikeyan Guruswamy)
To:        comp.os.ms-windows.programmer.win32,comp.protocols.tcp-ip
Subject:   How does Windows NT work on the internet ?

Hi,
This is something I really want to know. How does Windows NT
work on the internet ? Can I have two Windows NT machines
across the internet and can share resources just like the way
I can do it on my local network ? I saw something like NETBIOS
encapsulated with TCP/IP during the installation. Does it work ?
I am very sure that if it is talking NETBIOS, there is no way
the 'packets' can get past the standard routers. Has someone
thought about this ? Also, can someone enlighten me about 
DHCP ?

Karthik
  

-----------[000286][next][prev][last][first]----------------------------------------------------
Date:      14 Jun 1994 19:53:58 GMT
From:      sklower@oboe.CS.Berkeley.EDU (Keith Sklower)
To:        comp.protocols.tcp-ip
Subject:   Re: Multiple IP addrs for same hardware interface?

In article <1994Jun2.034930.24757@relay.nswc.navy.mil>,
Chuck Smoko - E81 <csmoko@relay.nswc.navy.mil> wrote:
>In article <1994Jun1.135707.10535@cherokee.nsuok.edu> landin@cherokee.nsuok.edu (Mark C. Landin) writes:
>>
>>So how did you get around it? I'm going to do the hardware shuffle in a 
>>month or two and would like any helpful anecdotes from people who've
>>done it.
>
>I have some code allows the multiple addresses per interface.
>... code (included), but I have ported it Sunos.
>
I've also done it.  Code supporting this has been distributed by
Berkeley since NetII.  The syntax is

	ifconfig if0 inet alias <rest of the command line is the same>

If you have two IP address from the same subnet as calculated by the
netmask on the same interface there is a minor bug in some of the
earlier versions in that you have to do a  route add host <2nd address>
127.1 to be able to send stuff to that address from the machine
itself.  Receiving from the outside works.

It is also supported in OSF/1.


-----------[000287][next][prev][last][first]----------------------------------------------------
Date:      Tue, 14 Jun 1994 21:27:33 GMT
From:      haggis@netcom.com (John R. Haggis)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP ports

In article <CrC9Dw.GsD@pica.army.mil> prodrig@gundam.batdd (Paul) writes:
>        I'm hoping someone can answer a couple of basic questions, or help me 
>to get started on the right track by letting me know where some of this 
>information can be obtained.  What I'm trying to do is connect a vax to a 
>sparc station and use TCP for data transfer. Thank you very much in advance. 

I read Lance's reply to you, and I'm worried you'll get confused if you're new 
to this.

Bottom line is:  Barring any pecularities on the VAX end, it should be pretty 
easy once you get them networked.  Hopefully, you'll be using ULTRIX or some 
kind of UNIX clone on the VAX.  This is the overview:

a.  get the machines physically networked (cables and any requried boxes).
b.  get the network drivers running (ifconfig, route, etc.).
c.  as part of b., make sure you know the IP addresses you assign them.
d.  "ping" each machine from the other to make sure they're talking.

At this point, the machines will be "talking" on TCP/IP.  To transfer data, 
you have two basic choices:

A.  Use a high level application, like ftp, to transfer the data.
B.  Write your own software using TCP Sockets.  (what Lance was talking about).
C.  one other:  use NFS to mount a drive from one computer on the other.  Then 
you can just copy files.

You seem to be leaning toward writing your own software with sockets?  
(Otherwise, why are you talking about "ports"?)  I don't recommend this if 
you're new to this, unless your application demands automatic data transfer.  
Let me know.

>1. When establishing a TCP connection, how does one determine what the port numbers will be in use on both machines?

The ports for standard applications, like FTP, Telnet, etc. are predetermined 
for Unix systems.  For your own custom program, you can choose any arbitrary 
port number, as long as both sides (sender and receiver) agree on the same 
one, and it doesn't conflict with any standard port number usage.  Look in 
your manual, and in etc\services or some such file for the standard ports 
defined on that machine.  There should also be something in sockets 
docmuentation about typical port numbers for use in custom programs.

>2. When transfering data between a vax and a sparc station, will the data be transfered in a pre-determined format such as binary or ASCII, or will both users have to determine which format will be used in advance.

If you use a high-level application, like ftp, it has settings in it for how 
to transfer the files' data.  If you write your own software, you can use any 
format you like.  TCP/IP just transfers packets of numbers.  It doesn't care 
what they are.  Likewise, Sockets (which run just above tcp) don't care what 
you send;  they just send streams of numbers.  It's your application that must 
make some sense out of it.

Beware VAX implementation peculiarities of these things.  We're still laboring 
under some backwards, draconian conventions DEC foisted on us in the early 
days pertaining to 7-bit values here and there...  If you're using Unix 
variants you shouldn't have to worry, though.

Have fun.

- JohnR  (haggis@netcom.com)





-----------[000288][next][prev][last][first]----------------------------------------------------
Date:      15 Jun 1994 09:36:59 -0700
From:      rdervan@crl.com (Richard Dervan)
To:        comp.protocols.tcp-ip
Subject:   MacTCP problems

I'm having a problem getting the MacTCP that comes with the Macintosh
Internet Tour Guide up adn running.  Every time I try to enter the
IP address, it comes back and tells me that it is an invalid address
and that I need to go into the MacTCP control panel and set the IP address.

Also, does anyone know where I can pick up a copy of the docs via
FTP or someway?

Thanks,
-Richard

-- 
---------------------------------------------------------------------------
Richard Dervan - VMS System Manager               rdervan@crl.com
Information America                               70007.6230@compuserve.com
Atlanta, GA                                       Go Braves!  Chop Chop!

-----------[000289][next][prev][last][first]----------------------------------------------------
Date:      14 Jun 1994 22:24:13 GMT
From:      chris@jbasp.demon.co.uk (Chris Bradshaw)
To:        comp.protocols.tcp-ip
Subject:   [Q] Any good books on network routing???

Greetings Netters...
I was wondering if anyone reading this could recommend any good books (or
free documentation on the internet) which deal with configuring and 
administrating routing in TCP/IP networks. I already have a few books which
deal with the more technical aspects of the various routing protocols (i.e.
what each byte of each packet represents etc.). I am really looking for 
something which shows how to configure routing in different situations using
something like gated with the latest protocols and subnetting techniques (i.e.
RIPv1, RIPv2, OSPF, multicasting etc......I don't suppose O'Reilly & Assoc. 
have a 'gated' book on the way?) Any and all replies much appreciated. Thanx 
in advance.

--

 Chris Bradshaw
 ----------------------------------------------------------------------------
 JBA Software Products Ltd.,  |   Internet:   chris@jbasp.demon.co.uk
 Eagle House,                 |    
 Studley,                     |   Voice:      (0527) 854525
 Warwickshire B80 7EN,        |   FAX:        (0527) 857146   
 England.                     | 
 ----------------------------------------------------------------------------  

-----------[000290][next][prev][last][first]----------------------------------------------------
Date:      Wed, 15 Jun 1994 00:44:49 GMT
From:      atkinson@sundance.itd.nrl.navy.mil (Ran Atkinson)
To:        comp.security.misc,comp.protocols.tcp-ip
Subject:   Re: Query: trusted routers

In article <2tk9jp$auh@gabriel.resudox.net> sharris@resudox.net (Sandy Harris) writes:
>Are there any packet filtering IP routers evaluated for
>interesting security levels, American B's or some other country's
>standard?

  I understand that Advanced Computer Communications Systems (ACC
Systems) has a fairly new product named "Stealth" which is targeted at
an Orange Book/Red Book B3 level.  ACC Systems has indicated that they
are submitting it to NCSC for formal evaluation.  I'm pretty sure that
final evaluation is not yet complete.  You might contact them directly
for more information.  They have an office somewhere near Columbia,
Maryland, USA.  The product is real -- they showed one in DC late last
week at the AFCEA tradeshow.  It implements most normal routing
protocols.

  To my knowledge that is the only router designed for formal
evaluation under both Orange Book and Red Book criteria.  Its also the
only B3-targetted router I know about.  I would guess that they'll get
a fair amount of business if they price it reasonably.

Ran
atkinson@itd.nrl.navy.mil


-----------[000291][next][prev][last][first]----------------------------------------------------
Date:      Wed, 15 Jun 1994 09:05:00 -0500
From:      Bill.Beers@f240.n379.z1.fidonet.org (Bill Beers)
To:        comp.protocols.tcp-ip
Subject:   Re: Is IP source routing a bad idea?

 BP> bparker@pilot.njin.net (Bruce Parker) wrote: 
 BP> 
 BP> Bhagwat and Perkins (Mobile and Location-Independent Computing 
 BP> Symposium), Johnson (CMU TR), and Rekhter and Perkins (Internet draft 
 BP> "Loose Source Routing for Mobile Hosts") use LSR to allow mobile hosts 
 BP> to retain the same IP address while moving through the internet. 

Is there an RFC associated with LSR?  While I don't have hosts moving thru THE Internet, I will have pen computers moving from base station to base station. Our current configuration has the base station acting as an IP router.  My recommendation based on only having a small number of 
Pen Computers floating around was to find a base station that would act as a mac bridge capable of filtering out unwanted traffic.  However, sounds like LSR, from what's said above, might be an alternative.  Does anyone implement LSR commercially yet? 



-----------[000292][next][prev][last][first]----------------------------------------------------
Date:      Wed, 15 Jun 1994 01:39:06 GMT
From:      marstein@netcom.com (Martin Stein)
To:        comp.sys.mac.misc,comp.sys.mac.wanted,netcom.software.mac,comp.sys.mac.comm,comp.protocols.tcp-ip
Subject:   Sun RPC on Mac?


I am looking for a Sun RPC library for the Macintosh OS. Did
anyone ever run across something like that? I would appreciate any
hints.

Thank you

Martin
(marstein@netcom.com)
-- 

----------------------------------------
Martin Stein
Ixos Software GmbH, Munich, Germany
SAP America Inc, Foster City, CA
Email:
martin.stein@ixos.de
marstein@netcom.com
100031.2333@CompuServe.COM


-----------[000293][next][prev][last][first]----------------------------------------------------
Date:      15 Jun 1994 08:56:26 GMT
From:      charl@pondermatic.ee.up.ac.za (Charl Barnard)
To:        comp.protocols.tcp-ip
Subject:   Re: bootp server response times

In article <2tkmsv$1v9@edwin.bga.com> dpm@bga.com (David P. Maynard) writes:

   Path: inet.up.ac.za!ee.und.ac.za!psgrain!charnel.ecst.csuchico.edu!yeshua.marcam.com!MathWorks.Com!europa.eng.gtefsd.com!howland.reston.ans.net!gatech!udel!news2.sprintlink.net!news.sprintlink.net!bga.com!bga.com!nobody
   From: dpm@bga.com (David P. Maynard)
   Newsgroups: comp.protocols.tcp-ip
   Date: 14 Jun 1994 11:46:23 -0500
   Organization: Real/Time Communications - Bob Gustwick and Associates
   Lines: 32
   References: <CHARL.94Jun14133617@pondermatic.ee.up.ac.za> <2tkbo1$nms@news.iastate.edu>
   NNTP-Posting-Host: edwin.bga.com

   Paul J Lustgraaf <grpjl@iastate.edu> wrote:

   >However, an apparently related problem is that a lot of the DOS/Mac
   >client software isn't very forgiving of "slow" BOOTP servers.  It
   >seems to be fairly common to fire off a half-dozen requests at
   >1-second intervals and give up if an "acceptable" reponse isn't
   >received.  Some packages apparently check the sequence number because
   >they ignore responses from previous requests.  That means the response
   >must come back in under 1 second.  (I haven't verified this, but some
   >clients have logged the behavior.)  For a SLIP line, the 1-second
   >turnaround requirement is pretty marginal.

Thanks for the suggestion; unfortunately running bootpd in server mode
still doesn't solve the problem. The first request always seems to get
lost, and after that, response is ok.

-Charl

-----------[000294][next][prev][last][first]----------------------------------------------------
Date:      15 Jun 1994 21:31:59 -0700
From:      r_daems@pinyon.libre.com (Robert Daems)
To:        comp.protocols.tcp-ip
Subject:   OS/2 TCP/IP and windows ?

I am trying to get Windows to add, access Network files using tcpip.
I have installed winsock for tcpip (IBM TCPIP 2.0) and mount several 
disks on start up.  The disks are available under OS/2, but under Windows
It doesn't know it has a network.

What do I need to do to get the windows to "See" an TCPIP network? 



-----------[000295][next][prev][last][first]----------------------------------------------------
Date:      Wed, 15 Jun 94 18:20:26 -0500
From:      Peter Chapman <bankrupt@delphi.com>
To:        comp.protocols.tcp-ip
Subject:   Re: Connecting the PC to the Internet

You connected your PC to the Internet, and people can now ftp from your
machine?  I don't want mere access, I also want to set my PC up as a server.
Thanks!

-----------[000296][next][prev][last][first]----------------------------------------------------
Date:      Wed, 15 Jun 1994 10:12:38 GMT
From:      ccadda@beluga.upe.ac.za (Daryl Anderson)
To:        comp.protocols.tcp-ip
Subject:   Re: BOOTP and NCSA Telnet

In article <2ti41q$l9u@blue.weeg.uiowa.edu> gpalmer@blue.weeg.uiowa.edu (Gary Palmer) writes:
>From: gpalmer@blue.weeg.uiowa.edu (Gary Palmer)
>Subject: BOOTP and NCSA Telnet
>Date: 13 Jun 1994 12:12:26 -0500
>Keywords: BOOTP NCSA TELNET
 
>I am having trouble in getting the myip=BOOTP to work with the latest
>release of NCSA Telnet, 2.3.07.
 
>It seems that the FTP client works fine with this parameter, but if
>I don't specifiy an exact ip address with myip=, Telnet will eventually
>come back with an error that it cannot communicate with a BOOTP
>server.
 
>Again, I think I have the server working, because it satisifies FTP,
>and it satisifies other TCP/IP software that I've been working with,
>like WINSOCK, but NSCA Telnet 2.3.07 it does not.
 
>Has anyone come across this problem?

Yes, I had this problem with 2.3.07.

I am currently working on the NCSA source.
So far I have fixed the BOOTP.  It was caused by a buggy implementation of
UDP in the NCSA kernel.  I rewrote the UDP implementation.
There is also a problem connecting to Solaris 2.X hosts.  The recognition
of fragmented/do not fragment TCP datagrams was buggy.

This version is now working successfully on our campus.

I have added LPD, fixed RCP and FTP.
There are other subtle bugs in the kernel which I am currently tuning.

I do not read this news group regularly, so if you want further
correspondance please email me.

Regards
Daryl

+--------------------------------------------------------------------+
 Daryl Anderson                     Internet: ccadda@beluga.upe.ac.za
 Network Consultant                      Tel: +27 41 5042321
 University of Port Elizabeth            Fax: +27 41 5042574

  "A program that works first time contains a more subtle bug" - DLS
+--------------------------------------------------------------------+

-----------[000297][next][prev][last][first]----------------------------------------------------
Date:      Wed, 15 Jun 1994 14:19:40 GMT
From:      richlove@netcom.com (Rich Love)
To:        comp.protocols.tcp-ip
Subject:   Mac Plus and TCP

Several people have reported problems trying to make a Mac Plus work with
MacTCP. Has anyone out there had this problem and if so is there a solution
to it? Here are the posts I copied from the Mac Communications newsgroup:


> In Article <2tagab$amp@io.qcc.sk.ca>, marc@qcc.sk.ca (Marc St-Jean) wrote:
> >I have MacTCP installed on a number of machines (including a Classic
> >running 7.1) and everything runs well.
> >
> >However I can't get it to work with a Mac Plus running 6.0.7. The
> >manual states that the minimum requirements should be a Plus with
> >6.0.5. I've tried both Network Installers 1.3.2 and 1.4.3. I've tried
> >reinstalling the system, etc.
> >
> >I should include some details:
> >- we are running MacTCP over LocalTalk
> >- the MacIP gateway is in another zone
> >
> >Has any run into this situation and if so what is the fix? (Other than
> >throwing away the Plus :-)
> 
> ==========================================
> I have a customer in the Seattle area with the same problem and would also
> like an answer to this question. The TCP/IP manual says it is supposed to
> work with a Mac Plus.
-----------------------------

   I have been having the similar problems. I have tried two or three
versions of TCP/IP as well as diffrent versions of AppleTalk. All to no
avail. The TCP/IP driver seems to boot up fine but when I try to ping any
other machine on my net I get timeout errors.
   I am guessing that there may specific design flaws with a Mac Plus that
will prevent it from running TCP/IP, even though the manual says it should
work.
   I am attempting to connect the plus over AppleTalk to a Shiva fastPath
and then to my IP gateway. Nothing I have tried works.  Any Help would be
appreciated.

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


-- Rich Love                                     Carnation Software, Inc.

| MacToPic and SBMac - Macintosh to Host connectivity and file transfer  |
| for PICK, uniVerse, unix, System Builder and other host systems.       |
| Viewpoint, Wyse 50, VT101 and Prism emulations included.               |
| Demo available for download at ftp.netcom.com in pub/carnation         |
| Home page at file://ftp.netcom.com/pub/carnation/HT.Carn.Home.html     |      
| Phone (206) 333-4288                   Internet:  richlove@netcom.com  |

-----------[000298][next][prev][last][first]----------------------------------------------------
Date:      15 Jun 1994 15:31:47 GMT
From:      kannan@cs.ualberta.ca (Kannan Thiruvengadam)
To:        comp.protocols.tcp-ip
Subject:   RTP Code Available ?

Hi,

RTP (Realtime Transport Protocol) is (as the name suggests) meant for
Realtime applications. It works on Multicast IP. 

If any of you know any way of getting hold of the code (which must have 
developed by IETF AVT, please post/mail the contact address. Thanks.

- Kannan
--
615, General Services Building, University of Alberta, Edmonton
CANADA T6G 2H1
---------------------------------------------------------------------------
		What is life ? An opportunity to live.

-----------[000299][next][prev][last][first]----------------------------------------------------
Date:      Wed, 15 Jun 1994 16:06:20 GMT
From:      art@acc.com (Art Berggreen)
To:        comp.protocols.tcp-ip
Subject:   Re: Question on tcp protocol

In article <2tkcs7$rgu@news.tamu.edu> anilg@cs.tamu.edu (Anil Kumar Reddy Gurijala) writes:
>	 Under what circumstances a tcp layer packs two different data segments
>	 from upperlayer into a single packet? i.e. if I use send(a) and send(b)
>	 in two different instructions, is it possible that tcp layer packs both
>	 of them in a single packets and sends them to remote host?

Sure, if send(a) is smaller than the current TCP segment size then some, or all, of
the data in send(b) could be sent in the same segment as data from send(a).  This
is likely to happen if the TCP window is closed when the two send()s are done.
TCP is a BYTE STREAM protocol which makes no guarantees about the relationship
of user buffer boudaries and what is in the TCP segments.  The send() just copies
the data into a kernel buffer.  If the TCP window is open, the data is likely to
be sent immediately.  If the TCP window is closed, the data is held waiting for
the window to reopen.  If send(b) occurs while data from send(a) is still pending,
the new data is just added to the kernel buffer.  Eventually, the kernel would
block the send() system call if the kernel buffer allotment is filled.  Conversly,
recv() will attempt to copy data from the kernel's receive buffer to the user's
buffer.  If less data is available than the users buffer size, the recv() can
complete indicating a partial buffer.  Where in the data stream this recv()
completed may not have any relationship to the send()s at the other end.

Hope this helps,
Art


-----------[000300][next][prev][last][first]----------------------------------------------------
Date:      Wed, 15 Jun 1994 16:10:26 GMT
From:      edleslie@elearn.edu.yorku.ca (Ed  Leslie)
To:        comp.protocols.tcp-ip
Subject:   Re: Mac Plus and TCP

Rich Love (richlove@netcom.com) wrote:
: Several people have reported problems trying to make a Mac Plus work with
: MacTCP. Has anyone out there had this problem and if so is there a solution
: to it? 

A shot in the dark: is the Mac PLUS one of the ones which does not have the
capability of hardware handshake because DTR does not come out to the modem
plug? There are several Macs like that, and if you are running MacTCP you
are *very* likely using a high speed modem with data compression and are
configured for hardware handshake.

Did I hit anything?  :-)

Ed   

-----------[000301][next][prev][last][first]----------------------------------------------------
Date:      15 Jun 1994 09:38:19 +0400
From:      Mark Orlov <mark@mcs.spb.su>
To:        comp.protocols.tcp-ip
Subject:   [Q]: Can't send mail via SMTP


1) UNIX box with SVR4 can't send mail via SMTP.
After /etc/rc2.d/S88smtpd run the SMTP demon is created with normal
Helohost:
         smtpd -H node.domain

But in the /var/spool/smtpq/LOG file the log information is

 smtpd  trasport <tcp> opened on fd <5> address <0.0.0.0.0.25>

Netstat -a gives

             *.smtp      LISTEN

Machine receives mail OK, but can't send it. In the LOG file the lines
are

  smtp     Can't allocate for client: System error:

And lines in /var/spool/smtpq/*/E.*  are

        Invalid argument

All other TCP/IP based applications work correctly. DNS is running.

2) Another UNIX box with the same configuration  works fine.

LOG file contains

 smtpd  transport <tcp> opened on fd <5> address <193.125.130.35.0.25>

Netstat -a gives
               nodename.smtpd   LISTEN

When the receiver is down the LOG file contains

   smtp         t_connect failed: An event requires attention


What can be done to fix the problems in the first case?

--


 Best Regards,

   Mark Orlov,
                      
   ICL / Marine Computer Systems JV Co.
   St.Petersburg, Russia
   Voice: +7 (812) 5683952 
   X.400: (ICL OfficePower)  M.Orlov BRA0104


-----------[000302][next][prev][last][first]----------------------------------------------------
Date:      15 Jun 1994 16:23:54 GMT
From:      vince@dropzone.vti.com (Vince Fleming)
To:        comp.protocols.tcp-ip,comp.sys.ncr
Subject:   Re: How to tear down a TCP over X.25 connection?

Nigel Harwood (nigel@coles.com.au) wrote:

: Questions:	(about X.25)
 
: 1/ Is there a way for the host/remote end to tear down the connection after
:    completion?
 
: 2/ Is there a way to cause the TCP/IP timeout to be something more reasonable
:    for my circumstances such as 10 seconds.

The TCP/IP waits a min to allow any other traffic to pick up. The overhead
in creating the X.25 connection is "sufficient" to keep it up a while.

Are you running X.25 on the 3450 or are you using a Router? The cisco routers
allow you to set this value (if I remember correctly)

-Vince


-----------[000303][next][prev][last][first]----------------------------------------------------
Date:      15 Jun 1994 17:06:53 GMT
From:      ove@yoyo.neu.sgi.com (Ove Hansen)
To:        comp.protocols.tcp-ip,comp.sys.ibm.pc.hardware.comm,comp.os.linux.help
Subject:   X.25 to IP or directly into PC running Linux

I'm looking for a protocol translator or anything else which will allow
people to connect to a LAN or directly to a PC running Linux, over X.25.
Does anyone know of any cheap-ish protocol translators, or X.25 cards
for the PC, with either a Linux driver or DOS packet driver?

Thanks in advance,
-- 
Ove Hansen 

-----------[000304][next][prev][last][first]----------------------------------------------------
Date:      15 Jun 1994 18:53:10 GMT
From:      barmar@think.com (Barry Margolin)
To:        comp.protocols.tcp-ip
Subject:   Re: Stop me before I kill again (TCP vs UDP)

In article <2ta4he$o3v@crchh81b.bnr.ca> dawkins@bnr.ca writes:
>What I said: "If you're going to keep the same application-level
>interface, which is connectionless, you might as well use UDP."
 ...
>	The applications already run timers and sequence numbers,
>	because of the connectionless interface to the MUX software.

Is there a way to configure the timers?  When running over a reliable
transport you can set high timeouts, so retransmissions usually won't
occur.  The sequence numbers can stay in -- they'll just be redundant
overhead.

>	The developers planned to MUX all conversations over a single
>	TCP connection, if they used TCP. I was concerned about
>	applications which sent large numbers of packets back-to-back
>	causing other applications sending relatively time-critical
>	"query/response" exchanges to be flow controlled.

If the receiver can't keep up with the data, you're likely to get packet
drops with UDP, so the application layer would have retransmitted anyway,
and your "time critical" packets wouldn't have arrived in a timely fashion.
Consider that your raw interface driver performs essentially the same
function as the MUX server.  As long as the MUX forwards the data to the
application processes quickly, you shouldn't have much backlog.

>	The classic "large number of clients per service" scenerio
>	applies. I did not want to support, potentially, hundreds of
>	clients using TCP for (most often) application-level datagram
>	exchanges anyway.

The usual justification for not using TCP for datagram exchanges is the
connection setup/teardown overhead.  But since you'd be multiplexing all
the conversations over a single connection, that problem is alleviated.

One point in favor of using UDP is that it probably simplifies the
implementation a bit.  The TCP MUX implementation will have to handle the
case of the connection going down transparently to the applications
(although since they have their own retransmission mechanism, they
shouldn't find it too difficult to deal with, unless you take my suggestion
of setting the timeouts real high).
-- 
Barry Margolin
System Manager, Thinking Machines Corp.

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

-----------[000305][next][prev][last][first]----------------------------------------------------
Date:      15 Jun 94 23:56:28
From:      billw@glare.cisco.com (William )
To:        comp.protocols.tcp-ip
Subject:   Re: Question on tcp protocol

Furthermore, some TCPs will repacketize re-transmissions.  So even if
the data is sent originally as two packets with 64 bytes in each one,
if there needs to be a retransmission, you may get one retransmission
with 128 bytes of data...

BillW
cisco

-----------[000306][next][prev][last][first]----------------------------------------------------
Date:      16 Jun 94 00:01:29
From:      billw@glare.cisco.com (William )
To:        comp.protocols.tcp-ip
Subject:   Re: SLIP via terminal server?

First suggestion - lots of "terminal servers" these days support SLIP
directly, so you might not even need to connect to the sun first.

Next, IF your terminal server is 8-bit, 256 character clean - no escape
characters, no flowcontrol, no nothing - then SOME unix systems will allow
you to run SLIP on a pty rather than a physical COM port.  I'm sorry, but
I don't remember whether SUNOS is one of these.  (ie it's possible, but
it's implementation dependent.)

BillW
cisco

-----------[000307][next][prev][last][first]----------------------------------------------------
Date:      16 Jun 1994 07:14:16 -0700
From:      dcrane@crl.com (David Crane)
To:        comp.security.misc,comp.protocols.tcp-ip
Subject:   Re: Query: trusted routers

Paul Ferguson (paul@sprintlink.net) wrote:
: David Crane (dcrane@crl.com) wrote:
 
: > It's my understanding that the essential problem with routers is that 
: > they are easily spoofed.  What does one do to a router to make it really 
: > effective as a security wall?  They aren't bright enough to question what
: > they receive.
 
: Although a router cannot perform all of the functionality of a
: dual-homed, bastion firewall-gateway, some of the better routers
: have a great deal of security "built-in." For instance, the ability
: to packet-filter on source & destination addresses at the tcp port
: level and the ability to drop all IP source-routed packets.

How does that prevent spoofing?  Why can't somebody simply originate 
traffic with false packet headers?  I know it's difficult in a Unix 
environment, but not on a Macintosh.

"Firewalls" (Cheswick and Bellovin) makes a very strong case that NOTHING 
can prevent false information from passing a router and the best defence 
is a one-time password.  Then they give one example where even that can 
fail, though it requires complete control of a point in the Internet route.



-----------[000308][next][prev][last][first]----------------------------------------------------
Date:      15 Jun 1994 20:08:46 GMT
From:      schlumpf@matisse.uni-paderborn.de (Thomas Regin-Schubert)
To:        comp.protocols.tcp-ip
Subject:   TCP/IP over X.25 (Datex-P10H)

Helo world,

once upon alooooong ago I had a wish, I wanted to work at home.
Now my wish could become reality, the company I'm jobbing for get's 
a X.25 link. So I would like to drive 

	T C P / I P   over   X . 2 5  (D A T E X  P 10-H).

The following configuration is given:

		TCP/IP Network with Unix-Host and several MS-DOS Computers.
		The MS-DOS Computers are running a Winsocket in order
		to serve as an UNIX-Frontend under Windows.
		The charachteristics of the X.25 link: 9600bps, synchronous.

I would like to connect my Laptop over X.25 with the TCP/IP-Network for home-
working. My questions are: 
		
	on Host/Network-Side:
		- which software can route and correctly control the 
		  TCP/IP communication over X.25 if the host isn't able ?
		- which Hardware works with it (is an old PC enough or 
		  do we need expensive Unix-Hard-/Software) ?    
	on Laptop-Side: 
		- is my low-cost Highspeed-Modem able to work with X.25 ?
	  	- which packet-drivers/communication-software are available 
		  to provide a confortable, save communication (beware, the 
		  drivers must work with an winsocket).

Questions over questions but I think somebody can help me.

Thanks a lot,

		Thomas Regin-Schubert
		schlumpf@uni-paderborn.de   

		  
		
		

   



-----------[000309][next][prev][last][first]----------------------------------------------------
Date:      15 Jun 1994 20:21:59 GMT
From:      astein@nmrsg.biophys.upenn.edu (Alan Stein)
To:        comp.protocols.tcp-ip
Subject:   IP Packet Filtering

I am trying to implement a bridge on a linux box which would connect a subnet with my university's INET connection.  For starters, rather than a fully fledged firewall which might be overkill, I'd like to use the built-in abilities of unix to route packets.  However, to provide some tiny amount of efficiency, I'd like to screen out packets not intended for the network or packets not intended for typical ports.  
 
Can anyone point me toward a package like SGIs IPFILTERD or DECs SCREEND program which will allow bridging based on some simple rules (ALLOW/DENY according to source, dest, and port)?  Even better if this package is known to compile under Linux!
 
Thanks for all leads.
 
  Al
 

-----------[000310][next][prev][last][first]----------------------------------------------------
Date:      15 Jun 1994 20:32:53 GMT
From:      khweis@mvmpc9.ciw.uni-karlsruhe.de (Karl-Heinz Weiss)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc,comp.protocols.ppp,alt.winsock
Subject:   Announce: pre-release of SLIPLOGW (accesscontrol for SLIP)

Prerelease of SLIPLOGW, an access-controlprogram for your slipgate
------------------------------------------------------------------

SLIPLOGW replaces my SLIPLOG, an access- and remotecontrol-program
for any ibm pc gatesoftware which uses packetdrivers, especially 
the various compilations of ka9q/nos, like nos11c or jnos110b.

This version runs with windows now (thus the 'w') and has some other
useful advantages, like dial on demand, a bugfixed remotecontrol,
automatic reboot if program fails and so on. Installing more than one
sliplog (if you have more then one line) should work now without problems. 
You can switch back and forth from packetmode to terminalmode at any time,
by simply sending a break and relogin with a special password. This
works in enhanced mode of windows within a dosbox too! 

I'm still working on SLIPLOG and the final version will have a complete
new documentation and some installation examples, especially for windows-users.
I release this version, because there was a buggy (inofficial) version on
my server, named 'sliplogr'. My apologize for this. I hope 'sliplogw' will
be of more use for you ;-)

                   You may ftp it from:
        mvmpc9.ciw.uni-karlsruhe.de (129.13.118.9)
                 public/nos/sliplogw.zip  

If your GUI-ftp does'nt know the servertype 'ka9q/NOS' (ws_ftp does know ;-),
             try a commandline ftp or gopher on port 70!

Enjoy!
-------------------------------------------------------------------
K.H. Weiss            E-mail  : <khweis1@mvmhp.ciw.uni-karlsruhe.de>
Eulenweg 2            Phone   : (49)-608-2418
76536 Weingarten      Germany

-----------[000311][next][prev][last][first]----------------------------------------------------
Date:      Wed, 15 Jun 1994 20:55:24 GMT
From:      doug@siegfried.VF.GE.COM (Doug Hughes)
To:        comp.protocols.tcp-ip
Subject:   Re: NIS <----> PCNFS problem !

In article <2tjpmd$2ff@cpca3.uea.ac.uk>, i.ellery@uea.ac.uk (Ian Ellery) writes:
|> In article <1994Jun10.201135.13478@lauca.usach.cl>, jprado@lauca.usach.cl (Jorge Andres Prado Troncoso) says:
|> 
|> >        We are running PCNFS 5.0 under Ultrix 4.3 (DEC System 5000/240)
|> >and yellow page (yp).
|> >        All works fine, but in Windows 3.1, pc-nfs' network services
|> >(telnetw, ftpw and others) only use the NIS map (Hostmap) and doesn't
|> >resolve in the name server host.
|> 
|> Either wait for 5.1 which is finally supposed to do this, or get your NIS
|> hosts map to 'fail over' to the DNS. PCNFS still looks up hostnames in
|> the NIS, but if it is not in your local hosts map, NIS will send out a DNS 
|> request and get the hostname. You need to add a '-d' flag somewhere
|> in the NIS makefile - sorry been a while and I can't see a manual.
|> 
|>     hope this helps,
|>                Ian
|> ----
|> Ian Ellery, Computer Centre, UEA, Norwich, Norfolk, NR4 7TJ,  UK

I don't mean to be picky, but it's important. It's the "-b" flag
that must be set in the Makefile of the NIS master.
B=-b should be uncommented near the top of the Makefile and the
line below it that says B= should be commented out (put a # in front
of it).  You will then have to restart ypserv. (easiest way is to schedule
some down time and reboot)
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Doug Hughes              Internal Information Systems (NorthEast)   
System/Net Admin         Martin Marietta, Valley Forge, PA          
doug@vf.ge.com           doug@land.vf.ge.com                        
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
   "The light at the end of the tunnel is the headlamp of a train"  


-----------[000312][next][prev][last][first]----------------------------------------------------
Date:      Thu, 16 Jun 94 07:54:00 -0640
From:      john.will@dscmail.com (John Will)
To:        comp.protocols.tcp-ip
Subject:   Re: Connecting the PC to

B >You connected your PC to the Internet, and people can now ftp from your
B >machine?  I don't want mere access, I also want to set my PC up as a server.

WINQVT is an FTP server, though the security is a bit weak.  If you really
want to connect to the Internet as you describe, I'd consider Linux or
FreeBSD as my O/S.  You'll have real connectivity build-in.

-----------[000313][next][prev][last][first]----------------------------------------------------
Date:      Wed, 15 Jun 94 21:26:59 GMT
From:      thssaaf@iitmax.iit.edu (Abdulkader A. Al-Fantookh)
To:        comp.protocols.tcp-ip
Subject:   RTP and OSI95 ???

I just heard a bout two new transport protocols, namely RTP ( Real Time 
Protocol) and the OSI 95. I'm interested to read about them and probably do some
research on them.
Does anyone have information where I can get references regarding to any of
these two protocols?
Thanks,

 -Abdul

-----------[000314][next][prev][last][first]----------------------------------------------------
Date:      Wed, 15 Jun 1994 21:39:45 GMT
From:      mac@unison.com (Michael A. Casteel)
To:        comp.protocols.tcp-ip
Subject:   Re: Mac Plus and TCP

In <richlove.1122077620A@192.100.81.105> richlove@netcom.com (Rich Love) writes:

>[...stuff snipped...]
>   I am guessing that there may specific design flaws with a Mac Plus that
>will prevent it from running TCP/IP, even though the manual says it should
>work.
>   I am attempting to connect the plus over AppleTalk to a Shiva fastPath
>and then to my IP gateway. Nothing I have tried works.  Any Help would be
>appreciated.

I can confirm that it is possible to get MacTCP working over LocalTalk and
via Shiva FastPaths, we still do some of it here. I wouldn't say it was
simple configuring the FastPaths, though ;-).

I seem to recall that a problem we found on MacPluses (and some PBs) was an
inability to reliably bring up MacTCP over LocalTalk to a Shiva which was in 
another zone. Mind you, this was going through another Shiva and some 
IP routers to a remote zone (which had the IP network address we 
wanted). We don't have any problems with MacPluses, PBs etc. using
a Shiva in their local zone.

We have used (and continue to use) both Manual and Server IP address
assignment. We are now using MacTCP 2.0.4, although some Macs probably
haven't yet upgraded and are still on 1.0 or 1.1, whatever that last
one was. Seems to me there's some INIT or patch you're supposed to have
on the Pluses, though.
-- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Mike Casteel                      Unison Software, Inc.
mac@unison.com    		  675 Almanor Ave., Sunnyvale, CA
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

-----------[000315][next][prev][last][first]----------------------------------------------------
Date:      Wed, 15 Jun 1994 21:42:44 GMT
From:      hotopp@siam.bwi.wec.com (Dan Hotopp)
To:        comp.protocols.tcp-ip
Subject:   SLIP via terminal server?

Is it possible to somehow get a SLIP server to run via a telnet session?
Where I work, we have a dozen 14.4baud modems connected to a 9600baud 
terminal server.  I can dial in and telnet to my account on a Sparc 10 
and was wondering if it's possible to use a SLIP server there to run
after I login.  Most of the time, I don't really need SLIP or PPP since 
it's faster to keep all of the files at work and not deal with the slow 
9600 link, but it would be nice to have the ability to use SLIP.

I looked at CSLIP, but it appeared to only utilize the COM port.  Also, it
requires root access to setup.  I'm a friend with the administrator and can
always get him to install things, but it'd be nice to check things out
first.  Cern's HTTP daemon has the ability to utilize ports such as 8001
so non-root users can set it up, and was wondering if such a beast exists
for a SLIP server or if what I want is even remotely (no pun intended)
possible.

So, my questions are... "Is it possible to start a SLIP server on a Sun
and connect via a terminal server"?  Also, is there a way to specify a
special telnet port other than a COM port.  

 _____                                                            _____
( ___ )----------------------------------------------------------( ___ )
 | / |          Dan Hotopp             Hotopp@siam.bwi.wec.com    | \ |
 | / |       A/M/I Engineering       (W) VAX: tron::"hotopp@siam" | \ |
 | / |  Westinghouse Electric Corp.      Phone:(410)765-2931      | \ |
 |___|      Baltimore, Maryland           Fax:(410)993-2581       |___|
(_____)----------------------------------------------------------(_____)

Anyone who hates Dogs and Kids Can't be All Bad.
		-- W. C. Fields

-----------[000316][next][prev][last][first]----------------------------------------------------
Date:      Thu, 16 Jun 94 09:11:02 PDT
From:      wadeware@halcyon.com
To:        comp.terminals,comp.protocols.tcp-ip,comp.os.ms-windows.networking.tcp-ip,bit.listserv.ibmtcp-l support@netmanage.com
Subject:   IBM 3270 emulation using TCP?


I know nothing about 3270 emulation but that is seems way too complicated.

Our small network in Seattle wants to do 3270 emulation with a machine in 
Dallas.

Question:  Using a leased line and routers, is there a way to achieve that 
connection and emulation using TCP/IP rather than installing a 3270 controller 
board in our server and connecting that way?  I use Chameleon TCP/IP for 
Windows, and see that it has a 3270 emulator....that where I got this bright 
idea....

Thanks for your time.
wadeware@halcyon.com

-----------[000317][next][prev][last][first]----------------------------------------------------
Date:      Thu, 16 Jun 1994 02:53:18 GMT
From:      richlove@netcom.com (Rich Love)
To:        comp.protocols.tcp-ip
Subject:   Re: Mac Plus and TCP

In Article <1994Jun15.213945.5396@unison.com>, mac@unison.com (Michael A.
Casteel) wrote:
>I can confirm that it is possible to get MacTCP working over LocalTalk and
>via Shiva FastPaths, we still do some of it here. I wouldn't say it was
>simple configuring the FastPaths, though ;-).
>
>I seem to recall that a problem we found on MacPluses (and some PBs) was an
>inability to reliably bring up MacTCP over LocalTalk to a Shiva which was in 
>another zone. Mind you, this was going through another Shiva and some 
>IP routers to a remote zone (which had the IP network address we 
>wanted). We don't have any problems with MacPluses, PBs etc. using
>a Shiva in their local zone.
>
>We have used (and continue to use) both Manual and Server IP address
>assignment. We are now using MacTCP 2.0.4, although some Macs probably
>haven't yet upgraded and are still on 1.0 or 1.1, whatever that last
>one was. Seems to me there's some INIT or patch you're supposed to have
>on the Pluses, though.

Yes, someone else mentioned that there was an INIT to make a Mac Plus work
with MacTCP 1.1 but they were not sure if it was required for 2.0.4.


-- Rich Love                                     Carnation Software, Inc.

| MacToPic and SBMac - Macintosh to Host connectivity and file transfer  |
| for PICK, uniVerse, unix, System Builder and other host systems.       |
| Viewpoint, Wyse 50, VT101 and Prism emulations included.               |
| Demo available for download at ftp.netcom.com in pub/carnation         |
| Home page at file://ftp.netcom.com/pub/carnation/HT.Carn.Home.html     |      
| Phone (206) 333-4288                   Internet:  richlove@netcom.com  |

-----------[000318][next][prev][last][first]----------------------------------------------------
Date:      Thu, 16 Jun 1994 02:54:36 GMT
From:      richlove@netcom.com (Rich Love)
To:        comp.protocols.tcp-ip
Subject:   Re: Mac Plus and TCP

In Article <CrG4xF.Bw0@newshub.ccs.yorku.ca>, edleslie@elearn.edu.yorku.ca
(Ed  Leslie) wrote:
>Rich Love (richlove@netcom.com) wrote:
>: Several people have reported problems trying to make a Mac Plus work with
>: MacTCP. Has anyone out there had this problem and if so is there a solution
>: to it? 
>
>A shot in the dark: is the Mac PLUS one of the ones which does not have the
>capability of hardware handshake because DTR does not come out to the modem
>plug? There are several Macs like that, and if you are running MacTCP you
>are *very* likely using a high speed modem with data compression and are
>configured for hardware handshake.
>
>Did I hit anything?  :-)
>
>Ed   
=================
Well, That would apply if the connection were going through a modem but it
is direct connect via Appletalk and then through a router into Ethernet.

-- Rich Love                                     Carnation Software, Inc.

| MacToPic and SBMac - Macintosh to Host connectivity and file transfer  |
| for PICK, uniVerse, unix, System Builder and other host systems.       |
| Viewpoint, Wyse 50, VT101 and Prism emulations included.               |
| Demo available for download at ftp.netcom.com in pub/carnation         |
| Home page at file://ftp.netcom.com/pub/carnation/HT.Carn.Home.html     |      
| Phone (206) 333-4288                   Internet:  richlove@netcom.com  |

-----------[000319][next][prev][last][first]----------------------------------------------------
Date:      Thu, 16 Jun 1994 04:10:38 GMT
From:      kyma@netcom.com (Matt Young)
To:        comp.protocols.tcp-ip
Subject:   Re: Tcp/IP and Ethernet performance per Query

ivo.drvaric@ext.uni-mb.si wrote:
: 	Hello !
 
: I have a problem that i can't solve by myself.
: I have to make a decision between two architectures.
: First is Client-Server with Ethernet and TCP/IP protocol
: ( where we plan Etherne in the house on twisted -pair, and on digital
:  leased lines (48Kb or 64Kb lines ) ).
: The second architecture is distribute environment with refreshment of 
: central
: database on some delta time intervals.


This is actually a very good thread.
To illustrate our problem with latency,
consider the problems that we are currently
having implementing distributed semantic
database. In a distributed semantic database 
environment the query moves over the data,
which involves moving the semantic p code
message from one data object across the link
to another related data object. Equivalent to
doing a table join across the network.

If the machines are dedicated semantic processors, 
then no context switch is required, each clause
of the query appearing as a thread which exists
in the machine until its termination echoes back
from its further propagations.  Using a new MIPS
processor from SGI, the semantic clause can be
brought up into semantic interpreter with the proper
stack pointer established within 15 - 20 microseconds.
This does not include the time for transport level
error checking.

The clauses tend to be from 30-300 bytes long, 
being composed of compiled p code.  To transfer 
a 300 byte message across a 100 mbps link, assuming
15% overhead, takes about 30 microsec, which matches
the thread latency.  Hence, we need to have TCP/IP 
processing occur in about 20-30 microseconds for 
everything to be well matched.

Since the query clause is likely to be re-propagated
within or without the machine, the reverse latencies
are also desirable.

This is actually a real handicap for deployment of
the new technology database.  Currently the closest
we have come to these numbers is the WAVE protocol,
being deployed across Internet by an international
university consortium.  They now use slow Sparc-4
machines, running Solaris, and thus must deal with
the context switching latencies.  This is acceptable
for Internet traversal times, but in medium grained
processing systems operating over low latency switched
FDDI, or ethernet switches the latency problems must
be improved.

Matt Young
KYMA



-----------[000320][next][prev][last][first]----------------------------------------------------
Date:      Thu, 16 Jun 1994 04:18:37 GMT
From:      kyma@netcom.com (Matt Young)
To:        comp.protocols.tcp-ip
Subject:   Re: Way for faster IPC than TCP/IP ?

Jon Kay (jkay@cs.ucsd.edu) wrote:

: adiwan@bbn.com (Arif Diwan) sez:
: > hzhou@cs.utk.edu (Honbo Zhou) writes:
: > >I would like to know if there is a way to do faster IPC between
 processes
: > >on different machines than TCP/IP. 
: > 
: > Why would you want to do that? You will probably not gain much over UDP
: > let alone RAW IP. I can get close to wire speed no loss thruput over
: > Ethernet or FDDI using the TCP/IP stack (UDP). The limiting factor is
: > your hardware (interface card + bus etc) and your OS.
 
: There is more than one kind of performance.  He may be interested in
: latency rather than max throughput.  



This is actually a very good thread.
To illustrate our problem with latency,
consider the problems that we are currently
having implementing distributed semantic
database. In a distributed semantic database 
environment the query moves over the data,
which involves moving the semantic p code
message from one data object across the link
to another related data object. Equivalent to
doing a table join across the network.

If the machines are dedicated semantic processors, 
then no context switch is required, each clause
of the query appearing as a thread which exists
in the machine until its termination echoes back
from its further propagations.  Using a new MIPS
processor from SGI, the semantic clause can be
brought up into semantic interpreter with the proper
stack pointer established within 15 - 20 microseconds.
This does not include the time for transport level
error checking.

The clauses tend to be from 30-300 bytes long, 
being composed of compiled p code.  To transfer 
a 300 byte message across a 100 mbps link, assuming
15% overhead, takes about 30 microsec, which matches
the thread latency.  Hence, we need to have TCP/IP 
processing occur in about 20-30 microseconds for 
everything to be well matched.

Since the query clause is likely to be re-propagated
within or without the machine, the reverse latencies
are also desirable.

This is actually a real handicap for deployment of
the new technology database.  Currently the closest
we have come to these numbers is the WAVE protocol,
being deployed across Internet by an international
university consortium.  They now use slow Sparc-4
machines, running Solaris, and thus must deal with
the context switching latencies.  This is acceptable
for Internet traversal times, but in medium grained
processing systems operating over low latency switched
FDDI, or ethernet switches the latency problems must
be improved.

Matt Young
KYMA



-----------[000321][next][prev][last][first]----------------------------------------------------
Date:      16 Jun 1994 18:13:15 -0700
From:      blarson@hsc.usc.edu (Robert A. Larson)
To:        comp.os.solaris,comp.protocols.tcp-ip
Subject:   routing ethernet to token ring with solaris 2.1

I've got a sparcstation LX running solaris 2.1 with the internal
ethernet connected to a router port through a hub, and a token ring
card hooked to a local 16 Mbps ring.  We have an 8-bit subnet, and
all the ethernet systems are in the *.*.*.129-254 range
and I used *.*.*.1-126 for the token ring, and told the sun the subnet
mask is 255.255.255.128 .  I can get a pc on the ring to connect to
the sun using ip, but can't connect to the rest of the world since
noone knows to send the packets to the sun.  When I try to set up
proxy arp using:
	arp -s <token-pc-ip> <sun-ethernet> pub
the sun can no longer communicate with the token ring pc.  The
external router is not in my control, I can't set up non-proxy
routing.

Do I need to do something besides enabling both intefaces to turn on
routing in solaris 2.1?

If I got another system to publish the proxy arp would this work?

Is there anything else I'm doing wrong?

(I'd also like to set up a ppp connection to my home system, which
would also need to be proxy-arped.)
-- 
Bob Larson (blars)	blarson@usc.edu			usc!blarson
	It [the Internet] scares any sane person.  -- Erik Fair
	It scares a few of the rest of us too.  -- Dave Crocker

-----------[000322][next][prev][last][first]----------------------------------------------------
Date:      16 Jun 94 19:26:14 -0600
From:      jnimis@mac.cc.macalstr.edu (Antoine)
To:        comp.protocols.tcp-ip
Subject:   International Telnet

I'm going to Australia for a conference and bringing a powerbook 520c with
modem.  I know I will be at a University (U of Tasmania) where there is a
mainframe from which I receive mail and to which I can send mail (@utas.edu.au)
My question is:  how can I telnet to my home mainframe (miamiu.acs.muohio.edu)
which is on the US Internet.  The address there isn't recognized by my telnet
attempts from here, so I'm assuming I'll have trouble heading the other way. 
What can I do?
	John

-----------[000323][next][prev][last][first]----------------------------------------------------
Date:      16 Jun 1994 10:29:17 GMT
From:      d.w.stevenson@strath.ac.uk (Dave Stevenson)
To:        comp.protocols.tcp-ip
Subject:   /dev/nit on NT?

Is there an equivalent facility on Windows NT to the Network Interface Tap /dev/nit.

I want to view all packets on an interface, including the MAC header.

Thanks.

---
Dave Stevenson 				d.w.stevenson@strath.ac.uk
Computer Centre Communications		Tel : 44 41-552 4400 ext 3461
University of Strathclyde
Glasgow, Scotland, U.K. 


-----------[000324][next][prev][last][first]----------------------------------------------------
Date:      Thu, 16 Jun 1994 11:28:59 GMT
From:      kaplanr@lehman.com (Roger Kaplan)
To:        comp.unix.programmer,comp.protocols.tcp-ip
Subject:   Help with UDP Broadcast

I have several questions about using UDP broadcast on
a machine's local subnet.  It seems this topic is barely
covered in "the literature".. other than a passing reference
to the SO_BROADCAST flag, the only documentation I have
found is in Sun's Advanced Sockets tutorial, and it's only
a few paragraphs (and not very clear)

Question 1:

What is the proper localaddr/localport and remoteaddr/remoteport
for a broadcast socket?  The Sun manual says to use
INADDR_ANY and assign a local port, but nothing about the
remoteaddr/remoteport.

I have been using (INADDR_ANY,myport,BCADDR,myport)
where BCADDR is the machine's bc address (usually x.y.z.0)
and myport is some high port# I've chosen.  This works
in some situations, and not in others, depending on if
I'm listening to the socket or writing to it.

If I'm listening to the socket, do I need to set the
remoteaddr/remoteport at all?  If I'm writing to the
socket, does it matter what my localport is?

So the question is, what is the proper setup?
-----
Question 2:

I am trying to set up a single socket to both listen for
broadcasts and send broadcasts.  I want to be able to
use connect() on socket init to register the 
remote (ie broadcast)address/port so
I can use readv/writev and not need to remember 
the address/port deep in the code.

I have written a test program which does this, then alternately
listens on the socket with a 10sec timeout and reports
when it gets a broadcast, and also broadcasts itself
every 10 secs.  I then start it up on two machines,
say m1 and m2.  m1 gets started a few seconds earlier than m2,
and therefore gets to send the first broadcast.  Note that
the first broadcast is sent at t=10, not t=0.

The behavior I am observing is seeing m2 receive m1's first
broadcast, but as soon as it sends a broadcast itself, it
no longer receives outside broadcasts.  m1 never receives broadcasts.

If I recycle just one of the programs, I get the same effect:
as soon as the process does its first write, it cant receive
any more broadcasts.

I have experimented with performing a connect in the loop
before each write, and it seems to make no difference.

If I switch to using sendto() or sendmsg() and specifying
the bc addr/port each time, it works fine.  But like I said,
I want to avoid doing this.

What is going on?  Is there some sort of interaction that
I'm not aware of?  Is it possible to read and write broadcasts
on the same socket, or do I need to use two?

BTW, the texts I'm using are Stevens, "UNIX Network Programming"
and Comer Vol 3.

Please email to me and I will summarize.

Thank you,
Roger Kaplan
kaplanr@lehman.com

--
Roger Kaplan          | "You don't tug on Superman's cape  
Lehman Brothers       |  You don't spit into the wind
kaplanr@lehman.com    |  You don't pull the mask off the ol' Lone Ranger
                      |  And you don't mess around with Jim" --Jim Croce

-----------[000325][next][prev][last][first]----------------------------------------------------
Date:      16 Jun 1994 12:23:20 GMT
From:      paul@sprintlink.net (Paul Ferguson)
To:        comp.security.misc,comp.protocols.tcp-ip
Subject:   Re: Query: trusted routers

David Crane (dcrane@crl.com) wrote:

> It's my understanding that the essential problem with routers is that 
> they are easily spoofed.  What does one do to a router to make it really 
> effective as a security wall?  They aren't bright enough to question what
> they receive.

Excuse me, but that's a common misconception.

Although a router cannot perform all of the functionality of a
dual-homed, bastion firewall-gateway, some of the better routers
have a great deal of security "built-in." For instance, the ability
to packet-filter on source & destination addresses at the tcp port
level and the ability to drop all IP source-routed packets.

Cheers,


_______________________________________________________________________________
Paul Ferguson                         
US Sprint 
Managed Network Engineering                        tel: 703.904.2437 
Herndon, Virginia  USA                        internet: paul@hawk.sprintmrn.com

-----------[000326][next][prev][last][first]----------------------------------------------------
Date:      Thu, 16 Jun 1994 19:23:55
From:      brad@bootp (Brad Heaton)
To:        comp.protocols.tcp-ip
Subject:   What hardware is needed for T1

Sorry if this is the wrong place for this but I need to know what is involved 
if where I work gets a T1 line to the internet.  What hardware is needed on 
our end, approx cost, etc.

Thanks


-----------[000327][next][prev][last][first]----------------------------------------------------
Date:      Thu, 16 Jun 94 22:46:22 -0500
From:      baldwinl@delphi.com
To:        comp.protocols.tcp-ip
Subject:   S  l   o     w    P     a       c         k           e           t s

I believe were having TCP performance issues over high-latency links
(e.g. U.S. to Uk and/or Hong Kong).  If I understand correctly you
should set your TCP window sizes large enough to match the amount of
data it takes to fill a link between two such locations.  For example,
if the latency to the UK is 3 seconds, then you need to have a Window
to hold the amount of data segments you could transmit in 3 seconds.
 
My question is what kinds of latencys have people measured and what
window sizes have you used for those links?
 
For example,
 
Link		Speed		Latency		Using Window
--------		----------	--------	------------
NY to London	256K		3s		10000?
 
 
 
(we-re using 4000 byte windows on the above link, which I know
is not enough)
 

-----------[000328][next][prev][last][first]----------------------------------------------------
Date:      Thu, 16 Jun 1994 15:45:50 GMT
From:      evansmp@mb52112.aston.ac.uk (Mark Evans)
To:        comp.protocols.tcp-ip
Subject:   Re: Telnet response time after packet drop?

Ran Atkinson (atkinson@sundance.itd.nrl.navy.mil) wrote:

: Yes.  The "Path MTU Discovery" technique documented in a
: standards-track RFC can often be helpful in such circumstances.
: However, if one or more of the critical components is badly enough
: implemented to drop legal packets, that same component is not likely
: to be implementing Path MTU Discovery.  Hence, Path MTU Discovery
: doesn't always help.  The bug you describe is in the hub/repeater,
: which might not even be implementing IP or ICMP.
 
:   If you can manually set the MTU size on the host interfaces, you
: might be able to work around it.  This is not demonstrating that IPX
: is better; IPX is just getting lucky.

Something to do with many IPX implimentations using an MTU of 576, me thinks.

Were as IP often used a larger MTU.


-----------[000329][next][prev][last][first]----------------------------------------------------
Date:      Thu, 16 Jun 1994 17:08:44 GMT
From:      rstevens@noao.edu (W. Richard Stevens)
To:        comp.unix.programmer,comp.protocols.tcp-ip
Subject:   Re: Help with UDP Broadcast

> What is the proper localaddr/localport and remoteaddr/remoteport
> for a broadcast socket?  The Sun manual says to use
> INADDR_ANY and assign a local port, but nothing about the
> remoteaddr/remoteport.

First, do *NOT* use connect() with a UDP socket you'll broadcast on.
I won't go into the gory details of the kernel routines involved,
but believe me, it doesn't work as you'd expect.  (Once you do this
you can only receive datagrams from the broadcast IP address that
you connected to, but no one can bind that as their local IP address.)

The foreign IP address is whatever your network's broadcast address is,
normally the subnet-directed broadcast address of a locally attached
interface.  the foreign port is whatever port the listeners are listening
on.
 
	Rich Stevens

-----------[000330][next][prev][last][first]----------------------------------------------------
Date:      16 Jun 1994 17:38:12 GMT
From:      carlson@Xylogics.COM (James Carlson)
To:        comp.terminals,comp.protocols.tcp-ip,comp.os.ms-windows.networking.tcp-ip,bit.listserv.ibmtcp-l
Subject:   Re: IBM 3270 emulation using TCP?

In article <2tpu1q$aps@nwfocus.wa.com>, wadeware@halcyon.com writes:
|> 
|> I know nothing about 3270 emulation but that is seems way too complicated.
|> 
|> Our small network in Seattle wants to do 3270 emulation with a machine in 
|> Dallas.
|> 
|> Question:  Using a leased line and routers, is there a way to achieve that 
|> connection and emulation using TCP/IP rather than installing a 3270 controller 
|> board in our server and connecting that way?  I use Chameleon TCP/IP for 
|> Windows, and see that it has a 3270 emulator....that where I got this bright 
|> idea....

Sure -- it's called tn3270.

You'll need to have a protocol converter somewhere at the other site
which knows tn3270 protocol.  Give OpenConnect Systems, Inc, a call at
+1 214 484-5200 or drop them a line at support@oc.com.

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

-----------[000331][next][prev][last][first]----------------------------------------------------
Date:      16 Jun 1994 18:38:08 GMT
From:      paul@sprintlink.net (Paul Ferguson)
To:        comp.security.misc,comp.protocols.tcp-ip
Subject:   Re: Query: trusted routers

David Crane (dcrane@crl.com) wrote:

> How does that prevent spoofing?  Why can't somebody simply originate 
> traffic with false packet headers?  I know it's difficult in a Unix 
> environment, but not on a Macintosh.
>
> "Firewalls" (Cheswick and Bellovin) makes a very strong case that NOTHING 
> can prevent false information from passing a router and the best defence 
> is a one-time password.  Then they give one example where even that can 
> fail, though it requires complete control of a point in the Internet route.

I didn't say it "prevented," I did say, however that many routers
have a good deal of security already built-in, when used properly.

There is no such thing as 100% security. If this is what you are trying
to achieve, then disconnect your network from the Internet immediately.

,-)  <smiley, for the humor-impaired>


Cheers,

_______________________________________________________________________________
Paul Ferguson                         
US Sprint 
Managed Network Engineering                        tel: 703.904.2437 
Herndon, Virginia  USA                        internet: paul@hawk.sprintmrn.com

-----------[000332][next][prev][last][first]----------------------------------------------------
Date:      17 Jun 1994 01:38:14 -0400
From:      arlie@thepoint.com (Arlie Davis)
To:        comp.protocols.tcp-ip
Subject:   How to limit bandwidth usage?

Forgive me if this is common knowledge, heresy, or just plain annoying,
but I need to know how to limit the bandwidth usage of a segment of
my network.  I have read all the FAQs I could find for 
comp.protocols.tcp-ip, and have not found anything relevant.

I want to be able to limit bandwidth because the more bandwidth my 
network uses (between it and my Internet provider), the more I pay for it.
I pay for the number of channels used (at *all*, not average) per day,
so if someone starts 12 FTP sessions and causes a usage spike at midnight,
I might have to pay for quite a bit more bandwidth than was actually used.

If I don't get any replies or pointers, I'm going to try my hand at 
implementing just such a beast on a Linux box with two Ethernet cards.
Because of the nature of the machine, it would also make an ideal 
firewall -- it's between Internet and my main network, and it is already 
forwarding IP.

Are there any commercial implementations out there that can do either 
just bandwidth limiting and/or firewalling?  I want a system that will 
allow bandwidth to *gradually* increase over time, if there is consistent 
demand for it.  It want it to smooth out usage spikes.

While I could probably hack this together on a Linux machine, I don't 
like the idea of trusting *all my Internet traffic* to a machine that I'm 
hacking on -- I would rather invest in a proven product.

Any replies (at all!) are welcome.  Specifically, experiences with 
existing products, advice on what to avoid and what to consider (any 
why), and pointers to any information (commercial or public) on Internet 
is welcome.

Thank you for your time.


-- 
-- Arlie Davis <arlie@thepoint.com>  | The Point: Inexpensive Internet access:
-- System and network administrator  | (812)246-8032: 32 lines, all 28.8K Hayes 
-- Linux: PCs are finally useful.    | $20/month flat rate -- call or mail me.

-----------[000333][next][prev][last][first]----------------------------------------------------
Date:      16 Jun 1994 20:03:25 GMT
From:      adiwan@siacbbn.com (Arif Diwan (BBN))
To:        comp.security.misc,comp.protocols.tcp-ip
Subject:   Re: Query: trusted routers

In article <2tq66h$11t@news.sprintlink.net>,
	paul@sprintlink.net (Paul Ferguson) writes:
  P.Ferguson|>     David Crane (dcrane@crl.com) wrote:
...
  I didn't say it "prevented," I did say, however that many routers
  have a good deal of security already built-in, when used properly.

  There is no such thing as 100% security. If this is what you are trying
  to achieve, then disconnect your network from the Internet immediately.
...
<<<

  You should also suggest: disconnect from reality as well!!! :)

-- 

				-- Arif Diwan (adiwan@bbn.com)
						617-873-6274

-----------[000334][next][prev][last][first]----------------------------------------------------
Date:      Fri, 17 Jun 1994 09:54:32 -0800
From:      owen@hodes.com (Owen Crowley)
To:        comp.protocols.tcp-ip
Subject:   Re: MacTCP problems

In article <2tnanb$hva@crl2.crl.com>, rdervan@crl.com (Richard Dervan)
wrote:

> I'm having a problem getting the MacTCP that comes with the Macintosh
> Internet Tour Guide up adn running.  Every time I try to enter the
> IP address, it comes back and tells me that it is an invalid address
> and that I need to go into the MacTCP control panel and set the IP address.

When you get this message, are you entering the IP address into MacTCP or
something else?  Is your MacTCP set to obtain addresses dynamically from a
server?  Are you sure that the IP address has a valid format?

Another thought: trash MacTCP prefs and DNR -- they might be corrupt. 
MacTCP will re-create them on restart.  (The MacTCP DNR is seen by the
system as a control panel, but MacTCP creates it in the system folder.)

Yet another thought:  Make sure that your MacTCP is version 2.0.4, or at
least 2.0.2, which can be upgraded to 2.0.4 by a freely available patch. 
If you are planning to run Mosaic, you should have 2.0.4 to avoid memory
leaks.

Owen

-----------[000335][next][prev][last][first]----------------------------------------------------
Date:      17 Jun 94 01:41:31
From:      billw@glare.cisco.com (William )
To:        comp.protocols.tcp-ip
Subject:   Re: S  l   o     w    P     a       c         k           e           t s


Note that if you have well behaved, "slow start" TCPs, you can use
"infinity" as your window size.  The slow start code will adapt the
"congestion window" to meet the characteristics of the actual network.

With "vanilla" tcps, "infinity" is only 65535 bytes, and link
delay*bandwidth products are commonly available can exceed this, thereby
limiting the throughput of a single connection to less than the bandwidth
available.  (Which may be OK - usually someone else will be using the extra
available bandwidth.)

There is a "TCP large window option" that solves this issue.  But it's not
very widely implemented.  I don't even think "Slow Start" TCPs are widely
implemented, despite having been "required" since 1989...

BillW
cisco


-----------[000336][next][prev][last][first]----------------------------------------------------
Date:      Thu, 16 Jun 1994 23:40:30 GMT
From:      marstein@netcom.com (Martin Stein)
To:        comp.sys.mac.misc,comp.sys.mac.wanted,netcom.software.mac,comp.sys.mac.comm,comp.protocols.tcp-ip
Subject:   Re: Sun RPC on Mac?

Garry Hornbuckle (garryh@seeding.apple.com) wrote:

: Check out a company called NobelNet, in Southboro MA. They are on the net
: as 'noblent.com'.


and trentmd@stu.beloit.edu (Michael Trent) writes:

: I am working on one, even as we speak. I don't know when I'll have it
: finished (probably next fall). My twist on the product is to provide not
: only the libraries, but also the source for everything, libraries, RPCGEN,
: everything - uploaded to sumex.
 
: When I wrote SUN asking for permission, I got a reply that mentioned there
: were a couple ports already in existance (I think maybe commercially?), but
: none of them provided source code.

Thats all, so far, ...


I talked to noblenet (508-460-8222) They really have a library for
the Mac (and OS/2 and NT and Unixens), but it is still in
beta-state. The person I talked to said, that it is already very
stable. Price is $4995 for one developer seat + 15% maintainance
cost (support, upgrade, ...) They are going to send a demo-version
for free.


Martin
-- 

----------------------------------------
Martin Stein
Ixos Software GmbH, Munich, Germany
SAP America Inc, Foster City, CA
Email:
martin.stein@ixos.de
marstein@netcom.com
100031.2333@CompuServe.COM


-----------[000337][next][prev][last][first]----------------------------------------------------
Date:      17 Jun 1994 12:50:35 -0700
From:      lstowell@pyrnova.mis.pyramid.com (Lon Stowell)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP/IP over X.25

In article <2tsp3r$2ft@news.uni-paderborn.de> schlumpf@tritta.uni-paderborn.de (Thomas Regin-Schubert) writes:
>
>Hello,
>
>I`m searching for a cheap solution to 
>connect two TCP/IP networks over X.25.
>
>
>
>Somebody told me I should drive X.29 over X.25. What does this mean
>and how can I reach this ?					   .

  It means they don't know what they are talking about.  X.29 is the
  command and data transfer protocol for ASYNC pads and hosts.   

  Admittedly you COULD run tcp/ip over SLIP and run that over an X.29
  like connection over X.25 if you have masochistic or goldbergian
  tendencies.

  You may want to check with router vendors to see if theirs can run
  over a public X.25 packet network.  Most offer sync interfaces, but
  whether they would run over a packet PDN only that vendor would
  know.

  The other answer depends on what operating systems and vendors you
  have available to you.  If you have unix with sync adapter ports,
  X.25, and tcp/ip, most vendors offer the "glue" layer to map IP to
  X.25 along with configuration utilities to create mappings between
  host IP addresses and X.121 addresses.  I know SCO Unix offers such
  a feature for PC clones.  Unix vendors with both the OS and hardware
  all offer it to my knowledge, as does IBM on MVS.   

  This software uses the X.25 Protocol ID of 0xCC in the Call Request
  packets, takes care of virtual circuit management, etc. etc. 
  I have yet to find any serious interoperability problems that
  weren't a simple configuration issue.

  Someone may have pointers to an FTP site for the CSNET white papers
  of a few years back, I only have hardcopy.  Also the RFC which is
  a model of incompleteness.


-----------[000338][next][prev][last][first]----------------------------------------------------
Date:      17 Jun 1994 10:08:04 -0400
From:      ddj@gradient.gradient.com (Dave Johnson)
To:        comp.unix.programmer,comp.protocols.tcp-ip
Subject:   Re: Help with UDP Broadcast

net@cs.tu-berlin.de (Oliver Laumann) writes:

>Christian Callsen <chris@iesd.auc.dk> wrote:
>> Actually, it would be great for all of us broadcast programmers, if
>> you showed us the "correct way" of determining this address...
 
>I have posted a C function to determine the local interfaces' broadcast
>addresses to comp.unix.programmers just seven days ago.  Here's another
>copy of it.  Perhaps someone should write a FAQ for comp.unix.programmers
>containing, among other things, the below program, plus one that shows
>how to use mmap(), and, of course, a program that demonstrates use of
>the dreaded xterm `slave mode'...
>-----------------------------------------------------------------------------
>/* Loop through the machine's list of network interfaces and print the
> * name and broadcast address of each interface.
> */
>#include <sys/types.h>
>#include <sys/socket.h>
>#include <sys/ioctl.h>
>#include <netinet/in.h>
>#include <net/if.h>
>#include <arpa/inet.h>
 
>main(ac, av) char **av; {
>    struct sockaddr_in sin;
>    struct ifconf ifc;
>    struct ifreq ifs[10];
>    int s, i, n;
 
>    if ((s = socket(AF_INET, SOCK_DGRAM, 0)) == -1) {
>	perror("socket"); return 1;
>    }
>    ifc.ifc_len = sizeof(ifs);
>    ifc.ifc_req = ifs;
>    if (ioctl(s, SIOCGIFCONF, &ifc) == -1) {
>	perror("ioctl SIOCGIFCONF"); return 1;
>    }
>    for (n = ifc.ifc_len / sizeof(struct ifreq), i = 0; n > 0; n--, i++)  {
>	if (ioctl(s, SIOCGIFBRDADDR, (char *)&ifs[i]) != -1) {
>	    bcopy((char *)&ifs[i].ifr_addr, (char *)&sin, sizeof(sin));
>	    printf("%s:\t%s\n", ifs[i].ifr_name, inet_ntoa(sin.sin_addr));
>	}
>    }
 return 0;
>}


Note that this code will fail on machines that have split the
(short) sin_family into (char) sin_family and (char) sin_len fields.

This includes OSF/1, AIX 3.x (added but not mandatory) and 4.x, and
4.4BSD.  The return from SIOCGIFCONF is now a list of variable sized
chunks that always start with at least an ifreq structure, but may be
longer for families that need more room for an address.  Also there
are machines that return entries for other address families than AF_INET
(AF_LINK is being used for hardware addresses).  This code will
need a little work on SVR4 machines with Streams ioctl and /dev/udp 
interfaces.  You may also want to skip interfaces that aren't up or
don't support broadcasting.  Some SVR4 networking packages (TWG TCP on NCR)
add an extra length field on the front of the return from SIOCGIFCONF.

	Dave Johnson
	Gradient Technologies, Inc.
	ddj@gradient.com

New example (tried on AIX, OSF1/AXP and SunOS 4.1.3):
-----------------------------------------------------
/* Loop through the machine's list of network interfaces and print the
 * name and broadcast address of each interface.
 */
#include <sys/types.h>
#include <sys/socket.h>
#include <sys/ioctl.h>
#include <netinet/in.h>
#include <net/if.h>
#include <arpa/inet.h>

main(ac, av) char **av; {
    struct sockaddr_in sin;
    struct ifconf ifc;
    struct ifreq *ifr;
    char   buf[1024];
    char   *bp;
    char   *limit;
    int s, i, n;
    int sa_len;

    if ((s = socket(AF_INET, SOCK_DGRAM, 0)) == -1) {
	perror("socket"); return 1;
    }
    ifc.ifc_len = sizeof(buf);
    ifc.ifc_req = (struct ifreq *) buf;
    if (ioctl(s, SIOCGIFCONF, &ifc) == -1) {
	perror("ioctl SIOCGIFCONF"); return 1;
    }
    bp = buf;
    limit = bp + ifc.ifc_len;
    while (bp < limit) {
        ifr = (struct ifreq *) bp;
	sa_len = sizeof (struct sockaddr);
#if defined(_SOCKADDR_LEN) || defined(_AIX)
	if (ifr->ifr_addr.sa_len > sa_len)
	    sa_len = ifr->ifr_addr.sa_len;
#endif	/* _SOCKADDR_LEN */
	bp += sizeof(ifr->ifr_name) + sa_len;

	if (ifr->ifr_addr.sa_family != AF_INET)
	    continue;

	if (ioctl(s, SIOCGIFBRDADDR, (char *) ifr) != -1) {
	    bcopy((char *) &ifr->ifr_addr, (char *)&sin, sizeof(sin));
	    printf("%s:\t%s\n",  ifr->ifr_name, inet_ntoa(sin.sin_addr));
	}
    }
 return 0;
}

-----------[000339][next][prev][last][first]----------------------------------------------------
Date:      17 Jun 1994 05:03:34 GMT
From:      bass@cais.cais.com (Tim Bass)
To:        comp.protocols.tcp-ip,comp.sys.ibm.pc.hardware.comm,comp.os.linux.help
Subject:   Re: X.25 to IP or directly into PC running Linux

Ove Hansen (ove@yoyo.neu.sgi.com) wrote:
: I'm looking for a protocol translator or anything else which will allow
: people to connect to a LAN or directly to a PC running Linux, over X.25.
: Does anyone know of any cheap-ish protocol translators, or X.25 cards
: for the PC, with either a Linux driver or DOS packet driver?
 
: Thanks in advance,
: -- 
: Ove Hansen 

Sangoma makes a card for the PC that does x.25, frame relay, HDLC, etc.
The drivers are for SCO, but the people their are willing to work with
me to port the drivers to Linux.  Nice folks too, so far.

I haven't seen the card yet, so I can't comment on how well it works.


-----------[000340][next][prev][last][first]----------------------------------------------------
Date:      17 Jun 1994 06:01:51 GMT
From:      tli@cisco.com (Tony Li)
To:        comp.protocols.tcp-ip
Subject:   Re: S  l   o     w    P     a       c         k           e           t s

In article <R0zSAeO.baldwinl@delphi.com> baldwinl@delphi.com writes:
    I believe were having TCP performance issues over high-latency links
    (e.g. U.S. to Uk and/or Hong Kong).  If I understand correctly you
    should set your TCP window sizes large enough to match the amount of
    data it takes to fill a link between two such locations.  For example,
    if the latency to the UK is 3 seconds, then you need to have a Window
    to hold the amount of data segments you could transmit in 3 seconds.
     
    Link		Speed		Latency		Using Window
    --------		----------	--------	------------
    NY to London	256K		3s		10000?

You actually want a window big enough so that you can transmit for a full
round trip time and a bit more.  So if the round trip time is 3s, you want
at least:

256Kbits/second * 3 seconds = 768Kbits = 96Kbytes

Unfortunately, the largest window that you can use with MOST TCP's is 64k.
You would have to go to the RFC 1323 TCP extension to get optimal
performance.  

Tony



-----------[000341][next][prev][last][first]----------------------------------------------------
Date:      Fri, 17 Jun 1994 07:17:43 GMT
From:      tru@kddnews.kddlabs.co.jp (Tohru Asami)
To:        comp.protocols.tcp-ip
Subject:   AF_UNIX & AF_INET Domains


I'm writing several interprocess communication programs right now.
Writing such programs, I have found the following technical
problems are uncertain. Suppose there are two processes A and
B communicating with each other via stream connection.

1. If I choose AF_UNIX domain, the socket name can be given as
   a path name. In that case, how are data passed from A to B?
   Even in this case, it will be a bad idea to send data via
   a physical filesystem. I suppose the followings:
   Process A -write--> Some area in the main memory -read---> Process B

   Is this the way for current UNIX systems such as SVR4 or 4.3BSD to
   use?

2. If I choose AF_INET domain for the interprocess communication
   between 2 processes A and B on the SAME machine. The protocol
   stack will be:
   Process A                    Process B
   Socket          --write--->  Socket
   TCP             --write--->  TCP
   IP              --write--->  IP
   I/O Driver      --write--->  I/O Driver
   Ethernet        --write--->  Ethernet

   There can be several possible layers to loop the data physically
   back to Process B. It will be a bad idea for the machine to send 
   the data for itself via an Ethernet cable. 

If someone can teach me how to transfer such data between the processes
on the same machine, please let me know.

Thanks in advance.

Tohru Asami

--
Network Engineering Support Group, KDD R&D Labs.
2-1-15 Ohara Kamifukuoka-shi, Saitama 356, Japan
Phone: +81 492 66 7890, FAX: +81 492 66 7510, E-Mail: tru@kddlabs.co.jp
KDD = an international telecommunication company in Japan

-----------[000342][next][prev][last][first]----------------------------------------------------
Date:      17 Jun 1994 08:04:21 GMT
From:      chris@iesd.auc.dk (Christian Callsen)
To:        comp.unix.programmer,comp.protocols.tcp-ip
Subject:   Re: Help with UDP Broadcast

>>>>> "W" == W Richard Stevens <rstevens@noao.edu> writes:
 
>> What is the proper localaddr/localport and remoteaddr/remoteport
>> for a broadcast socket?  The Sun manual says to use INADDR_ANY and
>> assign a local port, but nothing about the remoteaddr/remoteport.

W> First, do *NOT* use connect() with a UDP socket you'll broadcast
W> on.  I won't go into the gory details of the kernel routines
W> involved, but believe me, it doesn't work as you'd expect.  (Once
W> you do this you can only receive datagrams from the broadcast IP
W> address that you connected to, but no one can bind that as their
W> local IP address.)

W> The foreign IP address is whatever your network's broadcast address
W> is, normally the subnet-directed broadcast address of a locally
W> attached interface.  the foreign port is whatever port the
W> listeners are listening on.
 
W> 	Rich Stevens

Actually, it would be great for all of us broadcast programmers, if
you showed us the "correct way" of determining this address... In your
otherwise *EXCELLENT* book this is missing... is it too system
dependent?

Also, some more words on handling ASYNCH I/O (SIGIO facility),
possibly combined with select/poll? would be great. I eventually
figured it out by myself, but it took a lot of time... 

Otherwise, thanks for a great book!

-Chris
--
"The solution used to be to ask everyone on the net. But then he graduated.."
   __               | Christian J. Callsen  [ chris@iesd.auc.dk ]
  /  ) /            | Department of Mathematics and Computer Science,
 /    /_  __  o _   | Frederik Bajers Vej 7E, Aalborg University
(__/ / /_/ (_<_/_)_ | 9220 Aalborg 0st, DENMARK {Sm:^>le and be Happy Today!}

-----------[000343][next][prev][last][first]----------------------------------------------------
Date:      17 Jun 1994 10:20:33 GMT
From:      sdas@sh.bel.alcatel.be (Sanjay Dasgupta SH33 9639)
To:        comp.unix.programmer,comp.protocols.tcp-ip
Subject:   Encore : Re: Help with UDP Broadcast

>>>>> "W" == W Richard Stevens <rstevens@noao.edu> writes:

  { Text deleted }

>> Actually, it would be great for all of us broadcast programmers, if
>> you showed us the "correct way" of determining this address... In your
>> otherwise *EXCELLENT* book this is missing... is it too system
>> dependent?

I have a broadcast program that works on the VAX 
(VMS + MULTINET library) but fails when moved to 
a UNIX machine.  I've tried changing almost 
everything -- without results.

It's time some authoritative info became available. 


Thanks in advance





-----------[000344][next][prev][last][first]----------------------------------------------------
Date:      17 Jun 1994 17:10:55 -0400
From:      li@news.cs.columbia.edu (Zhe Li)
To:        comp.unix.programmer,comp.protocols.tcp-ip
Subject:   RPC Challenge -- pipelining



Hi Gurus:

I am in the process of designing an RPC procedure which scans a file
with typical size of 200MB+ upon client requests. One design is to let
the procedure returns 8K result data per-call (similar to NFS).
Because of the synchronous RPC nature, the client has to do something
like the following pseudo code:

	char	result[8192];
	while ((result = rpc_call(fileName, thisPageNum, ...)) != EOF)
	{
		result = rpc_call(fileName, nextPageNum++, ...);
	} 

Each iteration has to send a request, wait for the 8K result sent back
across the network, then send the next request (two-way msg
delays). Significant sequential delays are introduced if the client
wants to scan the whole file.

What I really want to have is for the client to make a single RPC call
and get all 200MB+ data back. If using sockets, the client can send a
request, then repeatedly read from the connected TCP socket. This way
only one request is needed for 200MB+ data.

Any hints on how I could achieve the same thing using RPC? Will
threaded clients or servers help? (maybe 200MB/8K = 25K threads
needed?)


Regards,

/Jay Li
Dept. of Computer Science
Columbia University

PS: please email to li@cs.columbia.edu. I will post a summary if there
are enough interests.

-----------[000345][next][prev][last][first]----------------------------------------------------
Date:      17 Jun 1994 10:35:10 GMT
From:      net@cs.tu-berlin.de (Oliver Laumann)
To:        comp.unix.programmer,comp.protocols.tcp-ip
Subject:   Re: Help with UDP Broadcast

Christian Callsen <chris@iesd.auc.dk> wrote:
> Actually, it would be great for all of us broadcast programmers, if
> you showed us the "correct way" of determining this address...

I have posted a C function to determine the local interfaces' broadcast
addresses to comp.unix.programmers just seven days ago.  Here's another
copy of it.  Perhaps someone should write a FAQ for comp.unix.programmers
containing, among other things, the below program, plus one that shows
how to use mmap(), and, of course, a program that demonstrates use of
the dreaded xterm `slave mode'...

-----------------------------------------------------------------------------
/* Loop through the machine's list of network interfaces and print the
 * name and broadcast address of each interface.
 */
#include <sys/types.h>
#include <sys/socket.h>
#include <sys/ioctl.h>
#include <netinet/in.h>
#include <net/if.h>
#include <arpa/inet.h>

main(ac, av) char **av; {
    struct sockaddr_in sin;
    struct ifconf ifc;
    struct ifreq ifs[10];
    int s, i, n;

    if ((s = socket(AF_INET, SOCK_DGRAM, 0)) == -1) {
	perror("socket"); return 1;
    }
    ifc.ifc_len = sizeof(ifs);
    ifc.ifc_req = ifs;
    if (ioctl(s, SIOCGIFCONF, &ifc) == -1) {
	perror("ioctl SIOCGIFCONF"); return 1;
    }
    for (n = ifc.ifc_len / sizeof(struct ifreq), i = 0; n > 0; n--, i++)  {
	if (ioctl(s, SIOCGIFBRDADDR, (char *)&ifs[i]) != -1) {
	    bcopy((char *)&ifs[i].ifr_addr, (char *)&sin, sizeof(sin));
	    printf("%s:\t%s\n", ifs[i].ifr_name, inet_ntoa(sin.sin_addr));
	}
    }
 return 0;
}

-----------[000346][next][prev][last][first]----------------------------------------------------
Date:      17 Jun 1994 13:01:36 GMT
From:      mcla@btzp16 (CLAEYS Marc)
To:        comp.protocols.tcp-ip
Subject:   Intelligent TCP/IP analyser



	Hello internet,

	I am looking for an (intelligent) tcp ip analyser. It should
	accept tcp ip buffers and generate diagnostics, especially
	when things go wrong e.g. packets with wrong ack or seq
	numbers. Also packets out of order and the like info would
	be appreciated. 

	Any help, especially the one in source form, greatly
	appreciated.




--
An optimist is a colleague that is not well informed.

-----------[000347][next][prev][last][first]----------------------------------------------------
Date:      Fri, 17 Jun 1994 13:09:23 GMT
From:      rstevens@noao.edu (W. Richard Stevens)
To:        comp.unix.programmer,comp.protocols.tcp-ip
Subject:   Re: Help with UDP Broadcast

> > The foreign IP address is whatever your network's broadcast address
> > is, normally the subnet-directed broadcast address of a locally
> > attached interface.
>
> Actually, it would be great for all of us broadcast programmers, if
> you showed us the "correct way" of determining this address...

I'd recommend using the SIOCGIFCONF ioctl() to get the interface configuration
on the host.  That's how broadcast programs such as rwhod and routed do it.
Get the sources for one of these two and take the code.  You still have
to think how you want to handle things such as multiple broadcast-capable
interface on a given host (do you want the first? the last? all?).  Some
systems let you send to 255.255.255.255 and the kernel chooses the first
configured broadcast-capable interface for you, if that's what you want,
but you need to verify this works on your host.  Also be aware that you
can't call inet_addr() with "255.255.255.255" as the argument, since the
return value (all one bits) is the same as an error return.

	Rich Stevens

-----------[000348][next][prev][last][first]----------------------------------------------------
Date:      Fri, 17 Jun 1994 13:53:29 GMT
From:      tung@eespcb.ncku.edu.tw (Assistant)
To:        comp.protocols.tcp-ip
Subject:   tcpdump error?

I have got a tcpdump 2.21 source to be compiled in these days,
but when I execute it, it shows :

tcpdump: SIOCGIFCONF: : Operation not supported on socket

My os is sun os 4.1.2, what's the matter?

ps:I have successfully compile tcpdump 1.00 and execute without any problem
   but this time.....

thanks for your help.....

tung@eespcb.ncku.edu.tw



-----------[000349][next][prev][last][first]----------------------------------------------------
Date:      Fri, 17 Jun 94 14:19:20 GMT
From:      Valenzuela_Cesar/Mac@mm.ssd.lmsc.lockheed.com (Cesar Valenzuela)
To:        comp.protocols.tcp-ip
Subject:   RSH, REXEC, RPC source or implementation?

Does anyone have any source code or documentation on how to implement
the protocols for RSH or Rexec or RPC.  Any info on this subject
will be greatly appreciated.

Thanks.

The opinions and views listed within this posting does not reflect the
opinions and views of the company.

-----------[000350][next][prev][last][first]----------------------------------------------------
Date:      17 Jun 94 14:50:37 GMT
From:      yzarn@lhdsy1.lahabra.chevron.com (Philip Yzarn de Louraille)
To:        comp.security.misc,comp.protocols.tcp-ip
Subject:   Re: Query: trusted routers

In article <1993Jun16.160224@siacbbn.com> adiwan@siacbbn.com (Arif Diwan (BBN)) writes:
>In article <2tq66h$11t@news.sprintlink.net>,
>	paul@sprintlink.net (Paul Ferguson) writes:
>  P.Ferguson|>     David Crane (dcrane@crl.com) wrote:
>...
>  I didn't say it "prevented," I did say, however that many routers
>  have a good deal of security already built-in, when used properly.
>
>  There is no such thing as 100% security. If this is what you are trying
>  to achieve, then disconnect your network from the Internet immediately.
>...
><<<
>
>  You should also suggest: disconnect from reality as well!!! :)

Excuse me? Are you suggesting the Internet is "reality?" Me think you need
a life. The Internet is very useful, no doubt. But "reality"....????

-- 
  Philip Yzarn de Louraille                 Internet: yzarn@chevron.com
  UN*X Systems Specialist                   PROFS:    ZARN(SMTP)
  Chevron Information & Technology Co.      Tel: (310) 694-9232
  P.O. Box 446, La Habra, CA 90633          Fax: (310) 694-7709

-----------[000351][next][prev][last][first]----------------------------------------------------
Date:      17 Jun 1994 17:00:26 GMT
From:      barmar@think.com (Barry Margolin)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP ports

In article <CrC9Dw.GsD@pica.army.mil> prodrig@gundam.batdd.pica.army.mil writes:
>	I'm hoping someone can answer a couple of basic questions, or help
>me to get started on the right track by letting me know where some of this
>information can be obtained.

There are several good books; see the FAQ for a long list, but you should
probably start with something like "Internetworking with TCP/IP" by Comer
and Stevens.

>1. When establishing a TCP connection, how does one determine what the
>port numbers will be in use on both machines?

Usually there's a predefined (aka "well-known") port for the server (e.g.
TELNET always listens on port 21) and the client uses any unused port (the
API provides a way for the client application to let the system choose a
port when connecting to a server).

For examples of doing this on Unix, see "Unix Network Programming" by W.
Richard Stevens.

>2. When transfering data between a vax and a sparc station, will the data
>be transfered in a pre-determined format such as binary or ASCII, or will
>both users have to determine which format will be used in advance.

TCP just transfers octets (i.e. 8-bit bytes), and does no interpretation or
translation.  That's up to the application protocol.  There are
presentation protocols such as Sun's XDR (eXternal Data Representation) or
ISO's ASN.1/BER (Abstract Syntax Notation 1 / Basic Encoding Rules) which
provide facilities for handling data interchange between dissimilar
machines.  A simple mechanism for handling binary data is the use of
"network byte order"; many API's include the routines hton[sl]() and
ntoh[sl]() (Host TO Network [Short/Long] and Network TO Host [Short/Long])
that translate between local and network byte ordering.
-- 
Barry Margolin
System Manager, Thinking Machines Corp.

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

-----------[000352][next][prev][last][first]----------------------------------------------------
Date:      Fri, 17 Jun 1994 17:01:24 GMT
From:      steeds@syndesis.com
To:        comp.protocols.tcp-ip
Subject:   Are there any SNMP Class Libraries Available???

Hello:

I would like to know if there are any C++ class libraries available
for SNMP. I am particularly interested in SNMP libraries for
communications devices X.25, T1 etc.

Please e-mail me back.

Thankyou in advance.

steeds_b@syndesis.com



-- 
Bryan Steeds,Toronto,CANADA (steeds@syndesis.com)
                            (steeds@ecf.toronto.edu)

-----------[000353][next][prev][last][first]----------------------------------------------------
Date:      Fri, 17 Jun 1994 17:03:48 GMT
From:      art@acc.com (Art Berggreen)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP/IP over X.25 (Datex-P10H)

In article <2tnn4e$jb8@news.uni-paderborn.de> schlumpf@matisse.uni-paderborn.de (Thomas Regin-Schubert) writes:
>I would like to connect my Laptop over X.25 with the TCP/IP-Network for home-
>working. My questions are: 
>		
>	on Host/Network-Side:
>		- which software can route and correctly control the 
>		  TCP/IP communication over X.25 if the host isn't able ?
>		- which Hardware works with it (is an old PC enough or 
>		  do we need expensive Unix-Hard-/Software) ?    
>	on Laptop-Side: 
>		- is my low-cost Highspeed-Modem able to work with X.25 ?
>	  	- which packet-drivers/communication-software are available 
>		  to provide a confortable, save communication (beware, the 
>		  drivers must work with an winsocket).

Just a comment.  Looking at modems for setting up synchronous connections,
I've found that several of the really inexpensive modems don't support
synchronous operation.  Some even allow the commands to configure for it,
but apparently don't have the clock circuitry implemented.  Check your
manuals carefully, or check with the manufacturer (their tech support
people often are only familiar with asynch operation).

Art


-----------[000354][next][prev][last][first]----------------------------------------------------
Date:      17 Jun 1994 17:39:31 GMT
From:      schlumpf@tritta.uni-paderborn.de (Thomas Regin-Schubert)
To:        comp.protocols.tcp-ip
Subject:   Differences SLIP <---> PPP

Hello,

is there any person who could tell
me the main differences between PPP
and SLIP ?
I`m especially interested in the 
advantages/disadvantages.

Thanks

Thomas Regin-Schubert
schlumpf@uni-paderborn.de


-----------[000355][next][prev][last][first]----------------------------------------------------
Date:      17 Jun 1994 17:41:07 GMT
From:      carlson@Xylogics.COM (James Carlson)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP ports

In article <2tskraINNdbn@early-bird.think.com>, barmar@think.com (Barry Margolin) writes:
[...]
|> Usually there's a predefined (aka "well-known") port for the server (e.g.
|> TELNET always listens on port 21) and the client uses any unused port (the
[...]

Minor erratum:  TELNET listens on port 23.  Port 21 is for ftp control
connections.

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

-----------[000356][next][prev][last][first]----------------------------------------------------
Date:      17 Jun 1994 18:13:15 GMT
From:      schlumpf@tritta.uni-paderborn.de (Thomas Regin-Schubert)
To:        comp.protocols.tcp-ip
Subject:   TCP/IP over X.25

Hello,

I`m searching for a cheap solution to 
connect two TCP/IP networks over X.25.

Problems :	- Where can I find cheap X.25 Hard-/and Soft-
		  ware ?
		- Which Operating System is needed to use this
	 	  Soft-/Hardware ?
	
                                -------------------------
--------------------	        I (Personal) Computer   I
I  TCP/IP-NETWORK  I---TCP/IP---I with X.25 Hardware    I          
--------------------            I  ???????????????????  I
				-----------I-------------
					   I
                                           I
					  X.25
					   I
					   .


Somebody told me I should drive X.29 over X.25. What does this mean
and how can I reach this ?					   .
					   
Im thankful for all given help


Thomas Regin-Schubert
Student
schlumpf@uni-paderborn.de

-----------[000357][next][prev][last][first]----------------------------------------------------
Date:      Fri, 17 Jun 1994 18:44:14 GMT
From:      jas@talking.COM (Jim Shankland)
To:        comp.security.misc,comp.protocols.tcp-ip
Subject:   Re: Query: trusted routers

In article <2tq66h$11t@news.sprintlink.net> paul@hawksbill.sprintmrn.com writes:
>David Crane (dcrane@crl.com) wrote:
>> How does that prevent spoofing?  Why can't somebody simply originate 
>> traffic with false packet headers?  I know it's difficult in a Unix 
>> environment, but not on a Macintosh.
>>
>> "Firewalls" (Cheswick and Bellovin) makes a very strong case that NOTHING 
>> can prevent false information from passing a router and the best defence 
>> is a one-time password.  Then they give one example where even that can 
>> fail, though it requires complete control of a point in the Internet route.
>
>I didn't say it "prevented," I did say, however that many routers
>have a good deal of security already built-in, when used properly.

Here is one way in which a router can help prevent packet spoofing:
it can filter out packets coming in on an "impossible" interface,
given their source address.  For example, packets that purport
to originate at a host inside an organization can be dropped
if they come in from the organization's leased line to the Internet.
Such packets are either forged or are in a routing loop.

jas

-----------[000358][next][prev][last][first]----------------------------------------------------
Date:      17 Jun 1994 19:03:05 GMT
From:      dmore@gisws3.rtpnc.epa.gov (Duane More)
To:        comp.protocols.tcp-ip
Subject:   TLI vs. Sockets vs. XTI

I'm wondering if someone can enlighten me as to the "standardization"
of TCP/IP interfaces relative to APIs. There is the Berkeley Sockets 
interface which is one of those unofficial standards. The Transport
Layer Interface [TLI] which is a System V interface, and the X/Open
Transport Layer Interface. 

The basic question is, are these standards manifested in any of the
various FIPS/POSIX/IEEE/XPG-4/EIA/CCITT/ISO standards relative to
APIs for network programming. If so where? also, is TLI an SVID 
interface?

-- 
 ------------------------------------- --------------------------------------
| Duane N. More                       |  In Support of:                      |
| Martin Marrietta                    |    U.S. EPA                          |
| P.O. Box 14365, MD-4501-1B          |    National Data Processing Division |
| Research Triangle Park, NC  27709   |    GIS &                             |
| 919-541-3669                        |    UNIX                              |
| FAX 919-541-0028                    |    Technical Services                |
| dmore@gissv1.rtpnc.epa.gov          |                                      |
 ------------------------------------ ---------------------------------------

-----------[000359][next][prev][last][first]----------------------------------------------------
Date:      17 Jun 94 19:53:27 GMT
From:      nick@gftpd-mail.citicorp.com (Nick Devito)
To:        comp.protocols.tcp-ip
Subject:   TCP/IP Transltor Device


Can anyone Help!

Am looking for a TCP/IP address translator.  The device (gateway) if exists should be  able to accept a TCP/IP call request on the behalf of a destination host which has a different IP address; and then  forward it onto the new IP address assign to that host. In other words, it could/should act as a proxy between to the client and server machines.


Here's the challenge : 

I plan to change the TCP/IP address of  many of our existing  devices to a new  TCP/IP network address. In many cases I know who the end users are (clients), and therefore changing the client's code to reflect the new server address is easily. But unfortunately, I can't be sure that I've identified all the clients so I would like to implement an on-line contingency to service the client machines that I've missed.

Here's the scenario:

I have an existing IP address of  192.193.53.60 for Server-A, after the conversation,  its new IP address is 192.193.45.60.

As the address changes for Server-A, I also change my clients to reflect Server-A's new IP address. But I can't be sure I've identified all my clients and consequently the client's I've missed won't be able to reach Server-A.

Translator Features:

If I could add Server-A's old IP address 192.193.53.60 to this IP-Translor device,  and if it could accept the call on behalf of the host, and then  generate a new call to the new IP address of Server-A (192.193.45.60);  I could then guarantee that during my conversion, any  client I've failed to update  would still be  able to reach their destination. 


PS.  

I know that a Name Server would avoid this problem, but I have no guarantees that the client's refer to their server's (destination address)  using a host name and not the explicit IP address!  

-----------[000360][next][prev][last][first]----------------------------------------------------
Date:      Fri, 17 Jun 1994 11:59:00 +0800
From:      peter.lewis@info.curtin.edu.au (Peter N Lewis)
To:        comp.protocols.tcp-ip
Subject:   Re: MacTCP problems

In article <2tnanb$hva@crl2.crl.com>, rdervan@crl.com (Richard Dervan) wrote:

>I'm having a problem getting the MacTCP that comes with the Macintosh
>Internet Tour Guide up adn running.  Every time I try to enter the
>IP address, it comes back and tells me that it is an invalid address
>and that I need to go into the MacTCP control panel and set the IP address.

That's because you should have bought the Internet Starter Kit instead.

Grab MacTCP Watcher from amug.org:/pub/peterlewis, it includes some docs
by Eric Behr as well as my MacTCP testing program.

Enjoy,
   Peter.
_______________________________________________________________________
Peter N Lewis <peter.lewis@info.curtin.edu.au>       Ph: +61 9 368 2055

-----------[000361][next][prev][last][first]----------------------------------------------------
Date:      Sat, 18 Jun 94 10:24:43 -0500
From:      baldwinl@delphi.com
To:        comp.protocols.tcp-ip
Subject:   Re: S  l   o     w    P     a       c         k           e

William <billw@glare.cisco.com> writes:
 
>With "vanilla" tcps, "infinity" is only 65535 bytes, and link
>delay*bandwidth products are commonly available can exceed this, thereby
>limiting the throughput of a single connection to less than the bandwidth
>available.  (Which may be OK - usually someone else will be using the extra
>available bandwidth.)
 
Yes, I understand TCP window size limits.  What I was really trying to get
at is the actualy delay*bandwidth products for various types of
links.  I assume I can calculate this based on distance and bandwwidth.
Anyone know an exact formula?

-----------[000362][next][prev][last][first]----------------------------------------------------
Date:      Sat, 18 Jun 94 10:38:14 -0500
From:      Peter Chapman <bankrupt@delphi.com>
To:        comp.protocols.tcp-ip
Subject:   Re: Connecting the PC to

Re: Linus or FreeBSD, do you have any leads to a
distributor or other reseller?  Thanks!

-----------[000363][next][prev][last][first]----------------------------------------------------
Date:      Sat, 18 Jun 1994 09:16:15
From:      lnewby@unm.edu (Lewis Newby Jr.)
To:        comp.protocols.tcp-ip,alt.winsock
Subject:   Re: help with slip please

In article <1994Jun8.193955.23317@news.uta.edu> mccoll@cse.uta.edu (Roddy McColl) writes:
>From: mccoll@cse.uta.edu (Roddy McColl)
>Subject: help with slip please
>Summary: cannot get CSLIP 2.7 to work properly with Winsock
>Keywords: WinSock Cslip 2.7 Sparc 2 SunOS 4.1.1
>Date: Wed, 8 Jun 1994 19:39:55 GMT
 
>I find that under SLIP, I can only connect to the Sparc station
>providing the sliplogin, but I cannot connect to any other machine on
>the network, nor can I connect to the campus name server and get off campus.

I had this same problem and after playing around with route and eceverything I 
looked a little deeper into how machines communicate and I found that there 
had to be an ARP entry for the SLIP interface. I may be way offbase here but 
what I am running on is Trumpet Winsock internal SLIP to an IBM RS6000.

I used the manual arp setting feature to get the RS6000 running AIX 3.25 to 
recognize the packets bieing sent to the SLIP interface.

arp -s ether <SLIP machine name> <eternet address of the RS6000> pub

Once this was done the RS6000 would respond for the SLIP connection and then 
once the packets arrived it would decide where they should go.



>When I 
put the winsock trace on IP packets, I see the following for>connections to 
the Sparcstation (129.112.104.5) from the PC>(129.112.104.129) :-

>IP 129.112.104.129 -> 129.112.104.5 len 44 prot 6
>IP 129.112.104.5 -> 129.112.104.129 len 46 prot 6
 
>etc and I can launch WinQCT/Net telnet or ftp etc.
 
>But if I try to connect to other machines on the network which have IP
>addresses contained in the host tables of both Sparc and PC, I get the
>following trace :-
 
>IP 129.112.104.129 -> 129.112.104.1 len 44 prot 6
>IP 129.112.104.129 -> 129.112.104.1 len 44 prot 6
>IP 129.112.104.129 -> 129.112.104.1 len 44 prot 6
>IP 129.112.104.129 -> 129.112.104.1 len 44 prot 6
>.
>.
>.
 
>etc with never any reply back.
>I suspect that the problem is therefore with the slip running on the Sparc.
 
>Note that my winsock setup has the Gateway as 129.112.101.254 which is
>the campus Internet gateway, and the campus nameserver as
>129.112.101.112 which is the campus name server. This works fine for
>E-net connections.
 
>Following sliplogin, the slip.login script executes the following
>(found from echoing the execution to a disk file) :-
 
>slifconfig sl0 129.112.104.5 129.112.104.129 netmask 0xffff0000
>route -n delete default 129.112.104.129
>route -n add default 129.112.104.129 1
>route set default 129.112.104.129 mtu 552
 
>I wonder if there is no understood route for packets through the Slip
>server onto the network, or perhaps back from the network through the
>Slip server to the PC ?
 
>I have not set the Sparc up for dialing out, so there is no device cua0
>and there is no entry for such a device in my /etc/ttytab.
 
>Most suggestions gratefully received, and I will summarize responses
>to the net if necessary.
 
>Thanks
 
>       -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
>         Roddy McColl                     
>         Assistant Professor of Radiology
>         Radiology Imaging Center     
>         UT Southwestern Medical Center at Dallas
>         5323 Harry Hines Blvd
>         Dallas TX 75235-9058 
>         (214) 648-2910
>         (214) 648-4538 FAX            roddy@mri.swmed.EDU
>       -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-



Lew Newby Jr.                                   lnewby@unm.edu
UNIX/VMS Coordinator Backup                     Vice President
University of New Mexico - CIRT                 New Mexico Free-Net
Unless stated, my opinions are not those of the University of New Mexico

-----------[000364][next][prev][last][first]----------------------------------------------------
Date:      Sat, 18 Jun 1994 16:04:24 GMT
From:      vjs@calcite.rhyolite.com (Vernon Schryver)
To:        comp.unix.programmer,comp.protocols.tcp-ip
Subject:   Re: RPC Challenge -- pipelining

In article <CMM.0.90.2.771887452.li@ground.cs.columbia.edu> li@cs.columbia.edu writes:

> ...
>I am in the process of designing an RPC procedure which scans a file
>with typical size of 200MB+ upon client requests. One design is to let
>the procedure returns 8K result data per-call (similar to NFS).
> ...
 
>What I really want to have is for the client to make a single RPC call
>and get all 200MB+ data back. If using sockets, the client can send a
>request, then repeatedly read from the connected TCP socket. This way
>only one request is needed for 200MB+ data.
> ...

Without knowing which of the many flavors of remote procedure call are
being used, it's hard to guess the constraints.  Sun's RPC allows the
use of "batching" over TCP.  I don't remember what the per-call data
limit is, but I thought it was well over 8KByte.

This seems like the wrong way to attack such a problem.  Unless the
network is at least as fast as FDDI, the network will (or should be)
the bottleneck.  Sending 200MByte over an Ethernet will take at least
3-4 minutes no matter what optimizations are used.  Instead, why not
define a remote procedure that takes as arguments whatever is being
scanned for, and does the scanning on the server?

Besides being much faster and saving network bandwidth, this kind of
approach will probably save the CPU cycles on the server.  The server
will probably spend fewer cycles sifting the data than sending it,
assuming the scanning is simple.  Of course, one could have the server
do the simplest part of the scanning, and let the client do any really
fancy pattern matching.


Vernon Schryver    vjs@rhyolite.com

-----------[000365][next][prev][last][first]----------------------------------------------------
Date:      18 Jun 94 22:56:56
From:      billw@glare.cisco.com (William )
To:        comp.protocols.tcp-ip
Subject:   Re: S  l   o     w    P     a       c         k           e


    What I was really trying to get at is the actualy delay*bandwidth
    products for various types of links.  I assume I can calculate this
    based on distance and bandwwidth.  Anyone know an exact formula?

It's more difficult than that.  For terrestrial telco links, the actual
delay tends to be most dependant on things like the number of T-repeaters
in between the ends of cable, not to mention procesing time in the end
hosts, buffering and processing time in any routers between the endpoints,
the time spent doing "delayed ack", queuing delays, and so on.  The telco
you get your line from can probably tell you the end-to-end delay of the
line you are using (and may even guarantee a maximum delay, but the rest
is best measured.  A good tcp will let you look at what it has calculated
the smoothed round trip time to be, which is a better number than many.

At a rough estimate, I remember someone commenting that terrestrial T3
and satellite T1 links both had delay*bandwidth products exceeding the
normal TCP window...

BillW
cisco


-----------[000366][next][prev][last][first]----------------------------------------------------
Date:      18 Jun 1994 20:01:05 GMT
From:      visser@convex.com (Lance Visser)
To:        comp.unix.programmer,comp.protocols.tcp-ip
Subject:   Re: RPC Challenge -- pipelining

In <CMM.0.90.2.771887452.li@ground.cs.columbia.edu> li@news.cs.columbia.edu (Zhe Li) writes:



+>I am in the process of designing an RPC procedure which scans a file
+>with typical size of 200MB+ upon client requests. One design is to let
+>the procedure returns 8K result data per-call (similar to NFS).
+>Because of the synchronous RPC nature, the client has to do something
+>like the following pseudo code:

	Just as a suggestion, if your dealing with this size file,
its better to make a general scanner the RPC call and not transfer
the data at all. 
	The RPC call could pass a regular expression as a parameter
to some sort of scanning server on the host where the file lives.
This approach will be faster and take fewer cycles on both
client & server than scanning locally. 

	The only case where this would not work is if there is a huge
amount of local state needed to scan the file or you wanted a huge
percentage of the file moved to the local node anyway.




-----------[000367][next][prev][last][first]----------------------------------------------------
Date:      19 Jun 1994 01:36:22 GMT
From:      john@iastate.edu (John Hascall)
To:        comp.protocols.tcp-ip
Subject:   Re: Looking for Whois Client

Mark Stapleton <mark.stapleton@cld9.com> wrote:
}ML>I am looking for a Whois Client or Server application for Windows.
}ML>Hopefully freeware.  If anyone knows where I can ftp it from, it
}ML>would be greatly appreciated.
 
}Can't help you with freeware, but NetManage's Chameleon has it.

It's really not much of a protocol -- with RFC in hand, you
ought to be able to whip it out in under an hour (good 1st
TCP/IP project, BTW):

pooh.cc> telnet rs.internic.net 43
Trying 198.41.0.5...
Connected to rs.internic.net.
Escape character is '^]'.
JH28<CR>
<EOT>
Hascall, John (JH28)            john@IASTATE.EDU
   :
   :
Connection closed by foreign host.


John
-- 
John Hascall                   ``An ill-chosen word is the fool's messenger.''
Systems Software Engineer
Project Vincent
Iowa State University Computation Center  +  Ames, IA  50011  +  515/294-9551

-----------[000368][next][prev][last][first]----------------------------------------------------
Date:      19 Jun 1994 02:42:54 GMT
From:      visser@convex.com (Lance Visser)
To:        comp.protocols.tcp-ip
Subject:   Re: AF_UNIX & AF_INET Domains

In <CrJ5LJ.D7z@kddlab.kddlabs.co.jp> tru@kddnews.kddlabs.co.jp (Tohru Asami) writes:


+>I'm writing several interprocess communication programs right now.
+>Writing such programs, I have found the following technical
+>problems are uncertain. Suppose there are two processes A and
+>B communicating with each other via stream connection.

+>1. If I choose AF_UNIX domain, the socket name can be given as
+>   a path name. In that case, how are data passed from A to B?
+>   Even in this case, it will be a bad idea to send data via
+>   a physical filesystem. I suppose the followings:
+>   Process A -write--> Some area in the main memory -read---> Process B

	UNIX domain uses the file system namespace to establish 
connections.  It creates the file, but the file is little more than
a placeholder in the system.  The file does not have anything to
do with data transfer as best I remember.  The file system provides
an alternative connection namespace, that is all.



+>2. If I choose AF_INET domain for the interprocess communication
+>   between 2 processes A and B on the SAME machine. The protocol
+>   stack will be:
+>   Process A                    Process B
+>   Socket          --write--->  Socket
+>   TCP             --write--->  TCP
+>   IP              --write--->  IP
+>   I/O Driver      --write--->  I/O Driver
+>   Ethernet        --write--->  Ethernet

	

+>   There can be several possible layers to loop the data physically
+>   back to Process B. It will be a bad idea for the machine to send 
+>   the data for itself via an Ethernet cable. 

	Most systems dont ever transfer data by self-receive on an
interface.  IP detects that the request is to the local host and 
loops the packet back in software.

	The problem with this sort of loopback is that on many systems,
the MTU (maximum transmission unit) used by IP is somewhere around
1500 bytes.  This means if you send large amounts of data, it will
be fragmented and reassembled in the IP layer unnecessarily.


	The best way to do loopback IMO is to use AF_INET and the 
special loopback address 127.0.0.1.




-----------[000369][next][prev][last][first]----------------------------------------------------
Date:      Sun, 19 Jun 1994 21:42:31 -0800
From:      peak@halcyon.com (Paul K. Kim)
To:        comp.protocols.tcp-ip
Subject:   Weird MacTCP problem...

I run MacTCP 2.0.4 and Interslip 1.0.1 on my Powerbook 165c.
Somehow, whenever I quita program (any program) my TCP activates the
interslip and my computer starts dialing...
This has started recently and happens every so often.
I have replaced all concerned programs a few times; still happens...
Please mail any help.  Thank you.

-- 
Paul K. Kim
peak@halcyon.com

-----------[000370][next][prev][last][first]----------------------------------------------------
Date:      19 Jun 1994 20:14:41 -0400
From:      reh@cs.umd.edu (Richard Huddleston)
To:        comp.protocols.tcp-ip
Subject:   Petition against metered use of Internet

/* 
   This arrived in my mailbox yesterday, and after checking the articles 
   listing of this group to see if it it had made it here, I decided to 
   post it as a public-service announcement.

   If you agree with it, redistribute it appropriately. 

   If you disagree with it: please, no flames.  I'm just the messenger.

   I had to pull the attribution indicators out to defeat a Draconian 
   Pnews client; sorry about the impact to readability. 
*/ 

Date: Tue, 7 Jun 1994 12:07:19 -0700 (PDT)
From: James Ha <jcha@u.washington.edu>
Subject: ABSnet: Metered Use of Internet

Please note the following discussion regarding possible new charges for 
Internet use.

Subject: Metered Usage of the Internet: JSN

Please forgive the mass mailing, but I feel this is a subject
which is of great importance to anyone who benefits from the
bountiful resources of the Internet.
>
A very bad storm is brooding on the horizon.

In the future, you might have to pay a charge for every E-mail
message you send or receive, every Usenet article you read,
every kilobyte of data you transfer with ftp, every hypertext
link you follow with NCSA Mosaic or Gopher...

Hopefully this frightens you as much as it does me.
But it will happen, unless YOU do something about it.

Please read the attached, fill out the requested info, and
mail it back to mike@essential.org.  It also wouldn't hurt to
forward a copy of this to everyone you know on the Internet.
>
 Thanks for your support.
>
Craig Smith, <bcs@cs.tamu.eduor <craig@stat.tamu.edu>
Texas A&M University, Dept. of Computer Science
205 HRBB, 862-2084 (CPSC).   [PGP2 Public Key Available on Request]
---
>
TAXPAYER ASSETS PROJECT - INFORMATION POLICY NOTE
May 7, 1994

-    Request for signatures for a letter to NSF opposing metered
pricing of Internet usage

-    Please repost this request freely

The letter will be sent to Steve Wolff, the Director of
Networking and Communications for NSF.  The purpose of the letter
is to express a number of user concerns about the future of
Internet pricing.  NSF recently announced that is awarding five
key contracts to telephone companies to operate four Internet
"Network Access Points" (NAPs), and an NSF funded very high speed
backbone (vBNS).  There have been a number of indications that
the telephone companies operating the NAPs will seek permission
from NSF to price NAPs services according to some measure of
Internet usage.  The vBNS is expected to act as a testbed for new
Internet pricing and accounting schemes.  The letter expresses
the view that metered pricing of Internet usage should be
avoided, and that NSF should ensure that the free flow of
information through Internet listserves and file server sites is
preserved and enhanced.
>
Jamie Love, Taxpayer Assets Project (love@essential.org; but
unable to answer mail until May 15).  Until then, direct
inquires to Michael Ward.
>
If you are willing to sign the letter, send the following
information to Mike Ward of the Taxpayer Assets Project
(mike@essential.org, fax: 202/234-5176; voice: 202/387-8030;
P.O. Box 19367, Washington, DC 20036):

Names:    ___________________________
Title:    ___________________________   (Optional)
Affiliation:   ____________________________________
(for purposes of identification only)
Address:       ______________________________________
City; St, Zip  ________________________________
Email Address: _____________________________________
Voice:         __________________________________
for verification)
>
The letter follows:

Steve Wolff
Director
Division of Networking and Communications
National Science Foundation
4201 Wilson Blvd
Arlington, VA 22230
 
Dear Steve:
>
It is our understanding that the National Science Foundation
(NSF) and other federal agencies are developing a new
architecture for the Internet that will utilize four new Network
Access Points (NAPs), which have been described as the new
"cloverleaves" for the Internet.  You have indicated that NSF is
awarding contracts for four NAPs, which will be operated by
telephone companies (Pac Bell, S.F.; Ameritech, Chicago; Sprint,
NY; and MFS, Washington, DC).  We further understand that NSF has
selected MCI to operate its new very high speed backbone (vBNS)
facility.
>
There is broad public interest in the outcome of the negotiations
between NSF and the companies that will operate the NAPs and
vBNS.  We are writing to ask that NSF consider the following
objectives in its negotiations with these five firms:

PRICING.

We are concerned about the future pricing systems for Internet
access and usage.  Many users pay fixed rates for Internet
connections, often based upon the bandwidth of the connection,
and do not pay for network usage, such as the transfer of data
using email, ftp, Gopher or Mosaic.  It has been widely reported
on certain Internet discussion groups, such as com-priv, that the
operators of the NAPs are contemplating a system of usage based
pricing.

We are very concerned about any movement toward usage based
pricing on the Internet, and we are particularly concerned about
the future of the Internet Listserves, which allow broad
democratic discourse on a wide range of issues.  We believe that
the continued existence and enhancement of the Internet
discussion groups and distribution lists is so important that any
pricing scheme for the NAPs that would endanger or restrict their
use should be rejected by the NSF.

It is important for NSF to recognize that the Internet is more
than a network for scientific researchers or commercial
transactions.  It represents the most important new effort to
expand democracy into a wide range of human endeavors.  The open
communication and the free flow of information have make
government and private organizations more accountable, and
allowed citizens to organize and debate the widest range of
matters.  Federal policy should be directed at expanding public
access to the Internet, and it should reject efforts to introduce
pricing schemes for Internet usage that would mimic commercial
telephone networks or expensive private network services such as
MCI mail.

To put this into perspective, NSF officials must consider how any
pricing mechanisms will change the economics of hosting an
Internet electronic mail discussion groups and distribution
lists.  Many of these discussion groups and lists are very large,
such as Humanist, GIS-L, CNI-Copyright, PACS-L, CPSR-Announce or
Com-Priv.  It is not unusual for a popular Internet discussion
group to have several thousand members, and send out more than
100,000 email messages per day.  These discussion groups and
distribution lists are the backbones of democratic discourse on
the Internet, and it is doubtful that they would survive if
metered pricing of electronic mail is introduced on the Internet.

Usage based pricing would also introduce a wide range of problems
regarding the use of ftp, gopher and mosaic servers, since it
conceivable that the persons who provide "free" information on
servers would be asked to pay the costs of "sending" data to
persons who request data.  This would vastly increase the costs
of operating a server site, and would likely eliminate many
sources of data now "published" for free.

We are also concerned about the types of  accounting mechanisms
which may be developed or deployed to facilitate usage based
pricing schemes., which raise a number of concerns about personal
privacy.  Few Internet users are anxious to see a new system of
"surveillance" that will allow the government or private data
vendors to monitor and track individual usage of Information
obtained from Internet listserves or fileserves.

ANTI-COMPETITIVE PRACTICES

We are also concerned about the potential for anti-
competitive behavior by the firms that operate the NAPs.  Since
1991 there have been a number of criticisms of ANS pricing
practices, and concerns about issues such as price discrimination
or preferential treatment are likely to become more important as
the firms operating the NAPs become competitors of firms that
must connect to the NAPs.  We are particularly concerned about
the announcements by PAC-Bell and Ameritech that they will enter
the retail market for Internet services, since both firms were
selected by NSF to operate NAPs.  It is essential that the
contracts signed by NSF include the strongest possible measures
to insure that the operators of the NAPs do not unfairly
discriminate against unaffiliated companies.

Recommendations:

As the Internet moves from the realm of the research community to
a more vital part of the nation's information infrastructure, the
NSF must ensure that its decisions reflect the needs and values
of a much larger community.

1.   The NSF contracts with the NAPs operators will include
clauses that determine how the NAP services will be priced.
It is important that NSF disclose and receive comment on all
pricing proposals before they become final.  NSF should
create an online discussion list to facilitate public dialog
on the pricing proposals, and NSF should identify its
criteria for selecting a particular pricing mechanism,
addressing the issue of how the pricing system will impact
the Internet's role in facilitating democratic debate.

2.   NSF should create a consumer advisory board which would
include a broad cross section of consumer interests,
including independent network service providers (NSPs),
publishers of Internet discussion groups and distribution
lists, academic networks, librarians, citizen groups and
individual users.  This advisory board should review a
number of policy questions related to the operation of the
Internet, including questions such as the NAP pricing, NAP
operator disclosure of financial, technical and operational
data, systems of Internet accounting which are being tested
on the vBNS and other topics.

3.   NSF should solicit public comment, though an online
discussion group, of the types of safeguards against
anticompetitive behavior by the NAPs which should be
addressed in the NSF/NAPs contracts, and on issues such as
NAPs pricing and Internet accounting systems.

---------------------------------------------------------------------
TAP-INFO is an Internet Distribution List provided by the Taxpayer
Assets Project (TAP).  TAP was founded by Ralph Nader to monitor the
management of government property, including information systems and
data, government funded R&D, spectrum allocation and other government
assets.  TAP-INFO reports on TAP activities relating to federal
information policy.  tap-info is archived at ftp.cpsr.org;
gopher.cpsr.org and wais.cpsr.org

Subscription requests to tap-info to listserver@essential.org with
the message:  subscribe tap-info your name
---------------------------------------------------------------------
Taxpayer Assets Project; P.O. Box 19367, Washington, DC  20036
v. 202/387-8030; f. 202/234-5176; internet:  tap@essential.org
---------------------------------------------------------------------
-- 
ObIdentifier:	Richard Huddleston 
ObDisclaimer:	My opinions don't carry any official weight here 

"Only the enemy shows you where you are weak."  O.S.Card, _Ender's Game_ 

-----------[000371][next][prev][last][first]----------------------------------------------------
Date:      20 Jun 1994 03:14:31 -0500
From:      mweiss@nwk.cl.nec.co.jp (Michael J. Weiss)
To:        comp.os.ms-windows.networking.tcp-ip,comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject:   FTP client for MSDOS

Does anyone know of a shareware or freeware FTP client for DOS?

I have an Allied Telesis ethernet board.

Thanks,

--Mike


-----------[000372][next][prev][last][first]----------------------------------------------------
Date:      Mon, 20 Jun 1994 03:20:33
From:      emccoy@tra.com  (Earl E. McCoy)
To:        comp.protocols.tcp-ip
Subject:   TAXI


This may not be the right group for this question but I have run out
of local resources and my boss wants to know: What does TAXI stand
for (the 100Mbps/140Mbps FDDI interface). Thanks in advance. Earl

--
********************************************************************
Earl E. McCoy PhD				emccoy@tra.com
Senior Consultant				312-587-7323
Telecommunications Research Associates		usual disclaimer


-----------[000373][next][prev][last][first]----------------------------------------------------
Date:      Mon, 20 Jun 1994 07:05:45 GMT
From:      tru@kddnews.kddlabs.co.jp (Tohru Asami)
To:        comp.protocols.tcp-ip
Subject:   Re: AF_UNIX & AF_INET Domains


In <2u0bbe$mno@lovecraft.convex.com> visser@convex.com (Lance Visser) writes:
>+>1. If I choose AF_UNIX domain, the socket name can be given as
>+>   a path name. In that case, how are data passed from A to B?
>+>   Even in this case, it will be a bad idea to send data via
>+>   a physical filesystem. I suppose the followings:
>+>   Process A -write--> Some area in the main memory -read---> Process B
>
>	UNIX domain uses the file system namespace to establish 
>connections.  It creates the file, but the file is little more than
>a placeholder in the system.  The file does not have anything to
>do with data transfer as best I remember.  The file system provides
>an alternative connection namespace, that is all.
So AF_UNIX just means AF_INET with a local loopback (address 127.0.0.1),
doesn't it?

>	The best way to do loopback IMO is to use AF_INET and the 
>special loopback address 127.0.0.1.
This is the same comment that syklb@babylon.giss.nasa.gov (Ken Bell)
sent to me via E-mail:
>I don't know if this is what you're looking for, but there is a special
>interface that must be defined, called the local-loopback interface,
>with address (usually) 127.0.0.1.
>
>Anything written to the loopback address is required to NOT be placed
>on the ethernet, thus it is an efficient way to use AF_INET locally.
What I want to know is how data are passed from one process to
another via a LOCAL LOOPBACK. There are two choises to pass data from
one to another:

(1) Data written for 127.0.0.1 with TCP/UDP protocols are passed via
    some memory buffers shared among processes, physically using TCP/UDP
    protocols.
(2) Use only TCP/UDP port number and neglect all other protocol
    stuff to exchange data between processes. Data passing is physically
    made with hardware/OS specific mechanisms such as shared memory
    space, etc.

Are there any RFC's describing this kind of technical issues?

Thanks in advance.

Tohru Asami

--
Network Engineering Support Group, KDD R&D Labs.
2-1-15 Ohara Kamifukuoka-shi, Saitama 356, Japan
Phone: +81 492 66 7890, FAX: +81 492 66 7510, E-Mail: tru@kddlabs.co.jp
KDD = an international telecommunication company in Japan

-----------[000374][next][prev][last][first]----------------------------------------------------
Date:      20 Jun 1994 15:26:24 -0400
From:      L.J.W.Hendry@dcs.warwick.ac.uk (Leo Hendry)
To:        comp.unix.wizards,comp.unix.solaris,comp.protocols.tcp-ip
Subject:   Re: Implementing interrupts

In article <dcrowley.772121788@unix1.tcd.ie> Seoirse Crowley <dcrowley@unix1.tcd.ie> writes:
>I have been trying to build a client-server system to transfer packets across
>a network using UNIX. I initially thought that I could use a signal handler
>to signal a an incoming signal to wake up the client - I don't want to
>constantly poll the socket or use a waiting read().  However it seems this
>can't be done between machines, or at least I can't fingure ou how !!

Use select(2) to wait until your socket is ready for reading.  All example
socket code I have seen uses this.

Remember to re-enter select on interrupted system call and not to assume the
timeout is unchanged on exit.

- Leo

-----------[000375][next][prev][last][first]----------------------------------------------------
Date:      Mon, 20 Jun 1994 08:47:46 GMT
From:      terry@spcvxb.spc.edu (Terry Kennedy, Operations Mgr.)
To:        comp.protocols.tcp-ip
Subject:   Re: How to limit bandwidth usage?

In article <2trcs6$9vj@thepoint.com>, arlie@thepoint.com (Arlie Davis) writes:
> I want to be able to limit bandwidth because the more bandwidth my 
> network uses (between it and my Internet provider), the more I pay for it.
> I pay for the number of channels used (at *all*, not average) per day,
> so if someone starts 12 FTP sessions and causes a usage spike at midnight,
> I might have to pay for quite a bit more bandwidth than was actually used.

  This seems a bit odd - most providers that offer a discount for using less
than the connected bandwidth do so by averaging the bandwidth used. For ex-
ample, a T1 link with a service speed of 128Kb would be based on your average
usage of the link, not the peak usage.

  You seem to be connected via AlterNet, so I snarfed the AlterNet price list
from UUNET and in typical fashion, it doesn't discuss this at all - it doesn't
even describe the features of each of their services. Oh well.

  Anyway, a few things you could do:

  1) If the link is point-to-point T1 between you and Alternet, you could 
     switch to fractional T1 CSU's (if you aren't using them already) and
     configure them to use only the number of DS0's you're paying for. For
     example, if your agreement is for 128Kb, set the CSU's to feed only
     2 DS0's to the routers. That will hard-limit you to the speed you set.
     Drawbacks are the need for new CSU's if you don't already have frac-
     tinal units, coordinating this with the far end, and inability to go
     over the speed limit when you really want to.

  2) Get 2 routers and hook the serial ports of each back-to-back. Then set
     the clockrate on the serial port to whatever you want. Good if you hap-
     pen to have a stack of spare routers and the weird cable needed, bad if
     you don't (to do this with a pair of Cisco 2501's would cost about $5100
     at list price).

  3) Convert to a type of service that hard-limits you to some speed (for ex-
     ample, 56Kb or full T-1, or maybe Frame Relay with a CIR - although you
     can theoretically exceed your CIR and they may charge you for that).

  4) Switch to a provider that uses average bandwidth instead of peak, if your
     current provider really charges based on peak.

  Doing this on a PC will be tricky - you'll need to compute the offered bit
rate based on the size of the packets, and add the framing overhead for the
serial link. You may run into other problems as well. I'd try to deal with it
by limiting the actual serial speed or by fiddling with the politics first.
This assumes that you can't get your users to manage the bandwidth themselves.
That will be hard, anyway, as there isn't any real feedback to tell them when
they're over the limit.

	Terry Kennedy		  Operations Manager, Academic Computing
	terry@spcvxa.spc.edu	  St. Peter's College, Jersey City, NJ USA
        +1 201 915 9381 (voice)   +1 201 435-3662 (FAX)

-----------[000376][next][prev][last][first]----------------------------------------------------
Date:      20 Jun 1994 15:32:06 -0400
From:      syklb@babylon.giss.nasa.gov (Ken Bell)
To:        comp.protocols.tcp-ip
Subject:   Re: need ammo to use against bone-headed administrator

In article <sej.772128274@interaccess>,
Stephen Johnson <sej@psycfrnd.interaccess.com> wrote:
>Help!
>I've got a admin guy on one of my subnets that insists that he
>has 4 subnets available when he uses a subnet mask of 255.255.255.192
>I've explained/agrued with him until I'm blue in the face. Can anybody
>give me the RFC that spells this out in black and white? I need to
>beat him over the head with a RFC for a while.

Show him the section titled "Special Addresses" in RFC1060.

-- 
Ken Bell
syklb@nasagiss.giss.nasa.gov / syklb@nasagiss.bitnet / (212)-678-5545

-----------[000377][next][prev][last][first]----------------------------------------------------
Date:      20 Jun 94 15:28:46 MDT
From:      jrd@cc.usu.edu (Joe Doupnik)
To:        comp.protocols.tcp-ip
Subject:   Re: need ammo to use against bone-headed administrator

In article <sej.772128274@interaccess>, sej@psycfrnd.interaccess.com (Stephen Johnson) writes:
> Help!
> I've got a admin guy on one of my subnets that insists that he
> has 4 subnets available when he uses a subnet mask of 255.255.255.192
> I've explained/agrued with him until I'm blue in the face. Can anybody
> give me the RFC that spells this out in black and white? I need to
> beat him over the head with a RFC for a while.
> 
> Thanks
> Steve Johnson
-----------
	RFC1122.TXT
	Joe D. 

-----------[000378][next][prev][last][first]----------------------------------------------------
Date:      Mon, 20 Jun 1994 14:55:26
From:      bdbauer@dal.mobil.com (Blaine D. Bauer)
To:        comp.protocols.tcp-ip
Subject:   DNS & Sendmail

I'm a relative newcomer to the Internet, but it seems amazing to me how many 
locations are coming onto the internet considering how difficult it is to set 
up and use DNS & sendmail.  Frankly, I have to wonder how many of them are 
doing it very well.

Are there any tricks to the trade or perhaps automated tools that make DNS & 
sendmail (especially sendmail) less cumbersome?  If not, WHY NOT?

Cheers,
BDB

-----------[000379][next][prev][last][first]----------------------------------------------------
Date:      Mon, 20 Jun 94 11:24:00 GMT
From:      jwmanly@amherst.edu
To:        comp.protocols.tcp-ip
Subject:   Using routers as IP-filters?

Hello, everyone.

We at Amherst are looking to add one of the student dorms to our campus
ethernet, wherein the students would actually be able to connect their PCs
and MACs via Ethernet cards and actually become nodes on the Internet.

However, we want to try to protect ourselves as much as possible from 
inadvertant or deliberate IP snafus (such as a student bringing up their PC
with the same IP address as one of the Computer Center timesharing
systems).  The normal way to do this would be to subnet the local IP
network based on, say, the third octet of the address (we have a CLASS B
unsubnetted network.)

However, we do not wish to subnet if at all possible, because we would then
have to purchase quite a few routers.  What we would prefer to do is simply
use a router at the Ethernet entrance to the building as a kind of IP
bridge, but with some packet filtering.  That is, I want to be able to
configure a box, which has one interface for the building and one for the
backbone, such that it will throw away any IP packet it gets from the
building side that does not have the proper value in the third octet of the
source address.  Further, it should not pass any packets from the backbone
to the building unless the destination address has the correct value in the
third octet.  Basically, I want a bridge that functions at the IP layer 
instead of the MAC layer.

I am told that CISCO routers can do this -- they basically can be put into
bridging mode and still use their packet-filtering power, and I was
wondering if any other large vendors' offerings can as well, such as Xyplex
or Proteon.

If anyone knows whether any particular router can or can't do this kind of
thing (or has suggestions about other ways I might do the same thing or
reasons why my suggestion is a bad one), I would appreciate it.  Thanks.

-- John W. Manly  <JWMANLY@AMHERST.EDU> (System Manager -- Amherst College)


-----------[000380][next][prev][last][first]----------------------------------------------------
Date:      20 Jun 1994 19:51:36 -0500
From:      mweiss@nwk.cl.nec.co.jp (Michael J. Weiss)
To:        comp.os.ms-windows.networking.tcp-ip,comp.os.ms-windows.programmer.networks,comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject:   Simple Questions About Trumpet

Hi...

I have a few simple questions about Trumpet.


1) Is the Trumpet DLL a Windows Sockets Implementation?

2) Is it public domain?

3) Is the source code available?

4) Where can I get it ?  (please list a few places if possible)


Thanks a lot.

--Mike

-----------[000381][next][prev][last][first]----------------------------------------------------
Date:      Mon, 20 Jun 1994 12:37:00 GMT
From:      Birgitta.Lastow@ling.lu.se (Birgitta Lastow)
To:        comp.protocols.tcp-ip
Subject:   PC/TCP and printing on SUN SPARCprinter

Dear netters,
I've installed PC/TCP 2.3 on a 486, which was successful except from
the fact that it is not possible to print. When I try to print from the
PC using lpr I get the following error message: "Trying printer
sunprinter on server sun.ling.lu.se ... error on server: 115 un:
/usr/lib/lpd: Your host (130.245.135.172) does not have line printer
access". I don't understand what this means. I guess the problem is at
the SUN workstation, or what do you think? The host name (for the PC)
has been included in /etc/hosts. We are running Solaris 4.1.3 and
Newsprint 2.1 on the SUN workstation (LX).

I'm grateful for any hints. Please send answer by email, too.
(Birgitta.Lastow@ling.lu.se)

Thank you in advance,
Birgitta Lastow

-----------[000382][next][prev][last][first]----------------------------------------------------
Date:      20 Jun 1994 13:10:40 GMT
From:      john@iastate.edu (John Hascall)
To:        comp.protocols.tcp-ip
Subject:   Re: How to limit bandwidth usage?

Terry Kennedy, Operations Mgr. <terry@spcvxb.spc.edu> wrote:
}In article <2trcs6$9vj@thepoint.com>, arlie@thepoint.com (Arlie Davis) writes:
}> I want to be able to limit bandwidth because the more bandwidth my 
}> network uses (between it and my Internet provider), the more I pay for it.
}> I pay for the number of channels used (at *all*, not average) per day,
 
}  2) Get 2 routers and hook the serial ports of each back-to-back. Then set
}     the clockrate on the serial port to whatever you want. Good if you hap-
}     pen to have a stack of spare routers and the weird cable needed, bad if
}     you don't (to do this with a pair of Cisco 2501's would cost about $5100
}     at list price).
 
}  Doing this on a PC will be tricky - you'll need to compute the offered bit
}rate based on the size of the packets, and add the framing overhead for the
}serial link. You may run into other problems as well. I'd try to deal with it
}by limiting the actual serial speed or by fiddling with the politics first.

  Right, wouldn't the back-to-back via serial line trick work with PCs too?

     ---provider----[PC]...serial....[PC]----your net

  (presumably running PCroute or some such)

John
-- 
John Hascall                   ``An ill-chosen word is the fool's messenger.''
Systems Software Engineer
Project Vincent
Iowa State University Computation Center  +  Ames, IA  50011  +  515/294-9551

-----------[000383][next][prev][last][first]----------------------------------------------------
Date:      20 Jun 1994 13:21:59 GMT
From:      meessen@marina.in2p3.fr (Christophe Meessen)
To:        comp.protocols.tcp-ip
Subject:   Q: 3Com etherlinkIII packet driver for DOS ?

Hello, I can't find the packet driver on the installation
diskette. I need the packet driver to interface WINPKT and
the excellent Trumpet TCP/IP DLL.

Is there a internet accessible repository for such drivers ?

The dirver should be for the 3C509 card.

Thanks for any information.

-- 

Bien cordialement,

Ch. Meessen

-----------[000384][next][prev][last][first]----------------------------------------------------
Date:      Mon, 20 Jun 1994 13:35:52 GMT
From:      kurt@unirsvl.rsvl.unisys.com (Kurt Matthys )
To:        comp.protocols.tcp-ip
Subject:   Re: TLI vs. Sockets vs. XTI

In <2tss19$gn2@trixie.rtpnc.epa.gov> dmore@gisws3.rtpnc.epa.gov (Duane More) writes:

>I'm wondering if someone can enlighten me as to the "standardization"
>of TCP/IP interfaces relative to APIs. There is the Berkeley Sockets 
>interface which is one of those unofficial standards. The Transport
>Layer Interface [TLI] which is a System V interface, and the X/Open
>Transport Layer Interface. 
 
>The basic question is, are these standards manifested in any of the
>various FIPS/POSIX/IEEE/XPG-4/EIA/CCITT/ISO standards relative to
>APIs for network programming. If so where? also, is TLI an SVID 
>interface?

Yes, they are.  The IEEE POSIX 1003.1g (aka 1003.12) working group is currently
working on this.  The document attempts to standardize both TLI and a subset
of the BSD sockets calls.  The document is has been out for ballot twice and
is currently being updated for the next round in September.  For more
information send mail to the working group's mailing list at 
posix-net-ptp@nemo.ncsl.nist.gov

Kurt Matthys
kurt@rsvl.unisys.com


-----------[000385][next][prev][last][first]----------------------------------------------------
Date:      20 Jun 94 13:48:29 GMT
From:      merz@dk-vs.DE (Bruno Merz)
To:        comp.protocols.tcp-ip,comp.os.ms-windows.networking.tcp-ip
Subject:   Two processes reading from one socket

I'm using winsock.dll from ftp software for networking and I want to write
two processes which read and write to the same socket. It's obvious that at
a specific time only one of these two processes read or write from the socket.
Up to now my first process which calls WSAStartup(), socket(), connect() can
read and write from this socket. But the second process which tries to receive
data with recv() does not get any data whether he calls WSAStartup() or not.
I assume that there are dependendcies between socket and the current process
which makes it impossible two use sockets in my way.

I would appreciate any hints for my problem

best regards
bruno merz


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

Bruno Merz                        Tel.:   +49 7721 862690
Digital Kienzle                   Fax:    +49 7721 863210
Computersystems
Abt. 011                          e-mail: merz@kivax.UUCP
Postfach 78006                            ..!mcsun!unido!kivax!merz
78048 Villingen-Schwenningen              ..!uunet!unido!kivax!merz
Germany

-----------[000386][next][prev][last][first]----------------------------------------------------
Date:      Mon, 20 Jun 1994 14:05:13 GMT
From:      steve@ecf.toronto.edu (Steve Kotsopoulos)
To:        comp.protocols.tcp-ip,comp.security.unix
Subject:   Re: Is IP source routing a bad idea?

Casper H.S. Dik <casper@fwi.uva.nl> wrote:
>venu@voodoo.utcc.utk.edu (Nair Venugopal) writes:
>>2) Is there any situation, other than trouble shooting, where 
>>   the source routing option will be of use?
>
>Not many, though as work-around for temporary routing failures, it can
>be useful.  But even that is mostly under the heading of trouble
>shooting.

I have been told that the mbone software uses source routing.
If so, is there any way to filter source routes without breaking the mbone?
-- 
Steve Kotsopoulos  P.Eng.                         steve@ecf.toronto.edu
Systems Analyst,  Engineering Computing Facility, University of Toronto

-----------[000387][next][prev][last][first]----------------------------------------------------
Date:      21 Jun 1994 00:07:12 -0500
From:      mweiss@nwk.cl.nec.co.jp (Michael J. Weiss)
To:        comp.os.ms-windows.networking.tcp-ip,comp.os.ms-windows.programmer.networks,comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject:   Public Domain Winsock DLL

Author: mweiss@nwk.cl.nec.co.jp (Michael J. Weiss)
Subject: SOURCE CODE FOR WINSOCK DLL


Sorry about the overlap between this post and previous ones.
Thanks to all of you who have responded.

Here is the situation:

I am looking for a Winsock Implementation (DLL) for which the source is
available.  It must support a TCP/IP stack.

Ideally, it would be:

- available at no cost
- tested and bug-free
- fully winsock compliant
- in C rather than C++

So far, I have come across TCPMaster, NCSA Winsock, and Trumpet (thanks
to those generous individuals who responded to previous posts.)  I am trying to
map out the rest of my options.

I may consider DLLs that must be purchased, provided that I may purchase
a copy of the source code as well.

I am also willing to discuss/negotiate special arrangements with
shareware or commercial vendors, as this is for a research project and
not a commercial venture.

Please let me hear your thoughts on this matter.

Thanks again for your help.

--Michael Weiss			

-----------[000388][next][prev][last][first]----------------------------------------------------
Date:      20 Jun 94 16:04:34 GMT
From:      sej@psycfrnd.interaccess.com (Stephen Johnson)
To:        comp.protocols.tcp-ip
Subject:   need ammo to use against bone-headed administrator

Help!
I've got a admin guy on one of my subnets that insists that he
has 4 subnets available when he uses a subnet mask of 255.255.255.192
I've explained/agrued with him until I'm blue in the face. Can anybody
give me the RFC that spells this out in black and white? I need to
beat him over the head with a RFC for a while.

Thanks
Steve Johnson


-----------[000389][next][prev][last][first]----------------------------------------------------
Date:      20 Jun 1994 16:17:09 GMT
From:      nelson@crynwr.crynwr.com (Russell Nelson)
To:        comp.protocols.tcp-ip
Subject:   Re: Q: 3Com etherlinkIII packet driver for DOS ?

In article <2u455n$26e@ccpnws.in2p3.fr> meessen@marina.in2p3.fr (Christophe Meessen) writes:

   Hello, I can't find the packet driver on the installation
   diskette. I need the packet driver to interface WINPKT and
   the excellent Trumpet TCP/IP DLL.

   The dirver should be for the 3C509 card.

Look for 5x9pkt.exe on ftp.3com.com...

--
-russ <nelson@crynwr.com>      ftp.msen.com:pub/vendor/crynwr/crynwr.wav
Crynwr Software   | Crynwr Software sells packet driver support | ask4 PGP key
11 Grant St.      | +1 315 268 1925 (9201 FAX)    | Quakers do it in the light
Potsdam, NY 13676 | LPF member - ask me about the harm software patents do.

-----------[000390][next][prev][last][first]----------------------------------------------------
Date:      21 Jun 1994 01:34:30 -0500
From:      mweiss@nwk.cl.nec.co.jp (Michael J. Weiss)
To:        comp.os.ms-windows.networking.tcp-ip,comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject:   List of Winsock DLL Vendors

Does anyone knopw where I can get a list of Winsock Implementation
Vendors ?

Thanks,

--Mike

-----------[000391][next][prev][last][first]----------------------------------------------------
Date:      21 Jun 1994 05:10:05 -0700
From:      cgi@crl.com (Paul Smith)
To:        comp.protocols.tcp-ip
Subject:   Re: Implementing interrupts

Leo Hendry (L.J.W.Hendry@dcs.warwick.ac.uk) wrote:
: In article <dcrowley.772121788@unix1.tcd.ie> Seoirse Crowley <dcrowley@unix1.tcd.ie> writes:
: >I have been trying to build a client-server system to transfer packets across
: >a network using UNIX. I initially thought that I could use a signal handler
: >to signal a an incoming signal to wake up the client - I don't want to
: >constantly poll the socket or use a waiting read().  However it seems this
: >can't be done between machines, or at least I can't fingure ou how !!
 
: Use select(2) to wait until your socket is ready for reading.  All example
: socket code I have seen uses this.
 
: Remember to re-enter select on interrupted system call and not to assume the
: timeout is unchanged on exit.

Get any/all of the books by R. Stevens on; Advanced and or Network Programming.

All of your questions will be answered...  These books did it for me when I
had the SAME questions.  And Yes, install a SIGIO (SVR4.x only, SIGURG on 
BSD'ish systems) signal catcher and use poll (SVR4) or select (BSD'ish)
to find out which socket has input.  It is sufficient to just enble signals
on event, and use the reception of the SIGIO/SIGURG to indicate an inbound
packet.  Select/poll are typically used when more than one socket is being
read and you need to know which to post the read to.  Poll/select are not
associated with SIGIO/SIGURG these two facilities are independant and
can be used in conjunction or individually.  FYI beware of enabling
signals for S_OUTPUT.  I typically enable signals for:
S__INPUT | S_RD_NORM | S_RDBAND | S_HIPRI | S_ERROR | S_HANGUP
via ioctl(fd, I_SETSIG, ...) for SVR4



-----------[000392][next][prev][last][first]----------------------------------------------------
Date:      Mon, 20 Jun 1994 17:43:12 GMT
From:      cawilco@afterlife.ncsc.mil (Chris A. Wilcox)
To:        comp.protocols.tcp-ip
Subject:   Re: TAXI

In article <940620032033@news.tra.com>, Earl E. McCoy <emccoy@tra.com> wrote:
>
>This may not be the right group for this question but I have run out
>of local resources and my boss wants to know: What does TAXI stand
>for (the 100Mbps/140Mbps FDDI interface). Thanks in advance. Earl

If I'm not mistaken, it is the Transparant Asynchronous
Transmitter/Receiver Interface.
-- 
Chris Wilcox                |"You've been demoted from First Tiger to Tiger
Dept. of Defense            | bulk rate!"
cawilco@afterlife.ncsc.mil  |                                        Calvin
  The views represented here probably aren't held by the DoD. Get over it.

-----------[000393][next][prev][last][first]----------------------------------------------------
Date:      Mon, 20 Jun 1994 18:18:35 GMT
From:      abell@velveeta.apdev.cs.mci.com (Andrew_Bell)
To:        comp.protocols.tcp-ip
Subject:   Call to get socket protocol from fd?

Is there a call (BSD sockets) to get the protocol (SOCK_STREAM, SOCK_DGRAM,
SOCK_RAW, etc.) if given the file descriptor of a socket?

Andrew Bell
MCI Communications
abell@chong.nms.cs.mci.com

-----------[000394][next][prev][last][first]----------------------------------------------------
Date:      Mon, 20 Jun 1994 18:43:19 GMT
From:      abe@vic.cc.purdue.edu (Vic Abell)
To:        comp.protocols.tcp-ip
Subject:   Re: Call to get socket protocol from fd?

In article <CrpK6z.69s@sgi1.fnet.cs.mci.com> abell@velveeta.apdev.cs.mci.com (Andrew_Bell) writes:
>Is there a call (BSD sockets) to get the protocol (SOCK_STREAM, SOCK_DGRAM,
>SOCK_RAW, etc.) if given the file descriptor of a socket?

Try getsockopt(2).  You want to read SO_TYPE.

-----------[000395][next][prev][last][first]----------------------------------------------------
Date:      20 Jun 1994 18:58:39 GMT
From:      ganzhorn@cisco.com (Charles Ganzhorn)
To:        comp.protocols.tcp-ip
Subject:   Re: need ammo to use against bone-headed administrator

In article <sej.772128274@interaccess>, sej@psycfrnd.interaccess.com
(Stephen Johnson) wrote:
> 
> Help!
> I've got a admin guy on one of my subnets that insists that he
> has 4 subnets available when he uses a subnet mask of 255.255.255.192
> I've explained/agrued with him until I'm blue in the face. Can anybody
> give me the RFC that spells this out in black and white? I need to
> beat him over the head with a RFC for a while.

The reason you're having difficulty beating him up is that he's not wrong. 
If you were talking about a class C address, you are right but your use of
the term subnet and the mask you included implies you have given him a
class C sized piece of a class A or B in which case, he is correct.

Charles.

--
Charles Ganzhorn                        Email:  ganzhorn@cisco.com
Consulting Engineer                     
cisco Systems
One Appletree Square, Suite 1452        
8009 34th Avenue South                  Phone:  612-851-8310
Bloomington, MN  55425                  FAX:    612-851-8311

-----------[000396][next][prev][last][first]----------------------------------------------------
Date:      20 Jun 1994 19:19:13 GMT
From:      larsen@OES.ORST.EDU (Scott Larsen)
To:        comp.terminals,comp.protocols.tcp-ip,comp.os.ms-windows.networking.tcp-ip,bit.listserv.ibmtcp-l
Subject:   Re: IBM 3270 emulation using TCP?

In article <2tpu1q$aps@nwfocus.wa.com>,  <wadeware@halcyon.com> wrote:
>
> I know nothing about 3270 emulation but that is seems way too complicated.
>
> Our small network in Seattle wants to do 3270 emulation with a machine in
> Dallas.
>
> Question:  Using a leased line and routers, is there a way to achieve that
> connection and emulation using TCP/IP rather than installing a 3270 controller
> board in our server and connecting that way?  I use Chameleon TCP/IP for
> Windows, and see that it has a 3270 emulator....that where I got this bright
> idea....

1) Your 3270 based host/mainframe must understand TCP/IP.  This can be
	accomplished in many ways.  A common approach is to channel attach
	a front end processor that connects a TCP/IP data stream to a
	3270 data stream.

2) You need a PC/MAC/Workstation/whatever application to emulate a 327X
	terminal.  A winsock based 3270 program is available from
	ftp.ccs.queensu.ca:pub/msdos/tcpip/qws3270.zip.  The Chameleon
	327X emulator is a good one as well.  You have to pay quite a
	bit for it though... :)


Hope this helps...


Scott Larsen
larsen@oes.orst.edu                      UUCP: hplabs!hp-pcd!orstcs!larsen
--------------------------------------------------------------------------
"Those who can't write, write manuals."
		- anonymous

-----------[000397][next][prev][last][first]----------------------------------------------------
Date:      Tue, 21 Jun 94 01:00:31 GMT
From:      sridhar@sequent.com (Samudrala Sridhar)
To:        comp.protocols.tcp-ip
Subject:   TCP/IP Software on MS-DOS

Is there any public domain software which implements 
TCP/IP over NDIS driver in MS-DOS?

Thanks in Advance
-Sridhar

-----------[000398][next][prev][last][first]----------------------------------------------------
Date:      21 Jun 1994 03:19:57 GMT
From:      tcpdump@ee.lbl.gov (Craig Leres)
To:        comp.protocols.tcp-ip
Subject:   LBL TCPDUMP 3.0 and LIBPCAP 0.0 are now released

The latest release of tcpdump and initial release of libpcap are now
available:

    ftp://ftp.ee.lbl.gov/tcpdump.tar.Z
    ftp://ftp.ee.lbl.gov/libpcap.tar.Z

Note that you need both packages in order to build a working tcpdump.
When retrieving these compressed tarchives, don't forget to set binary
mode.

One main feature of this release is that the packet capture code has
been broken out into a separate library. This is also the first
release that supports Solaris.

We currently support the following hardware and operating system
combinations (this the RUNSON file from the libpcap package):

    machine         os                              packet filter
    -------         --                              -------------
    hp300           4.4BSD*, 4.3BSD Tahoe/Reno*     BPF
    sun3            SunOS 3*                        BPF, NIT
    sun3            SunOS 4                         BPF, STREAMS NIT
    sparc           SunOS 4                         BPF, STREAMS NIT
    sparc           SunOS 5                         DLPI
    Decstation      Ultrix 4                        packetfilter
    Alpha/AXP       OSF/1 v1.3*,v2.0                packetfilter
    IBM RT          4.3BSD*                         enet
    i386            BSD/386,NetBSD*,FreeBSD*        BPF
    SGI Indigo      IRIX 4                          snoop
    SGI Indigo      IRIX 5                          snoop
    IBM RT          AIX*                            BPF

    * These systems are supported but we currently do not have the resources
      to carry out testing in these environments (we suspect you'll run into
      problems under these systems -- please send us the patches if you fix any
      porting problems).

I've appended the new parts of the CHANGES files for both packages.

		Craig

------ libpcap/CHANGES

v0.0 Mon Jun 20 19:20:16 PDT 1994

- Initial release.

- Fixed bug with greater/less keywords, reported by Mark Andrews
  (mandrews@alias.com).

- Fix bug where '|' was defined as BPF_AND instead of BPF_OR, reported
  by Elan Amir (elan@leeb.cs.berkeley.edu).

- Machines with little-endian byte ordering are supported thanks to
  Jeff Mogul.

- Add hack for version 2.3 savefiles which don't have caplen and len
  swapped thanks to Vern Paxson.

- Added "&&" and "||" aliases for "and" and "or" thanks to Vern Paxson.

- Added length, inbound and outbound keywords.

------ tcpdump/CHANGES

v3.0 Mon Jun 20 19:23:27 PDT 1994

- Reorganize protocol dumpers to take const pointers to packets so they
  never change the contents (i.e., they used to do endian conversions
  in place).  Previously, whenever more than one pass was taken over
  the packet, the packet contents would be dumped incorrectly (i.e.,
  the output form -x would be wrong on little endian machines because
  the protocol dumpers would modify the data).  Thanks to Charles Hannum
  (mycroft@gnu.ai.mit.edu) for reporting this problem.

- Added support for decnet protocol dumping thanks to Jeff Mogul
  (mogul@pa.dec.com).

- Fix bug that caused length of packet to be incorrectly printed
  (off by ether header size) for unknown ethernet types thanks
  to Greg Miller (gmiller@kayak.mitre.org).

- Added support for IPX protocol dumping thanks to Brad Parker
  (brad@fcr.com).

- Added check to verify IP header checksum under -v thanks to
  Brad Parker (brad@fcr.com).

- Move packet capture code to new libpcap library (which is
  packaged separately).

- Prototype everything and assume an ansi compiler.

- print-arp.c: Print hardware ethernet addresses if they're not
  what we expect.

- print-bootp.c: Decode the cmu vendor field. Add RFC1497 tags.
  Many helpful suggestions from Gordon Ross (gwr@jericho.mc.com).

- print-fddi.c: Improvements. Thanks to Jeffrey Mogul
  (mogul@pa.dec.com).

- print-icmp.c: Byte swap netmask before printing. Thanks to
  Richard Stevens (rstevens@noao.edu). Print icmp type when unknown.

- print-ip.c: Print the inner ip datagram of ip-in-ip encapsulated packets.
  By default, only the inner packet is dumped, appended with the token
  "(encap)".  Under -v, both the inner and output packets are dumped
  (on the same line).  Note that the filter applies to the original packet,
  not the encapsulated packet.  So if you run tcpdump on a net with an
  IP Multicast tunnel, you cannot filter out the datagrams using the
  conventional syntax.  (You can filter away all the ip-in-ip traffic
  with "not ip proto 4".)

- print-nfs.c: Keep pending rpc's in circular table. Add generic
  nfs header and remove os dependences. Thanks to Jeffrey Mogul.

- print-ospf.c: Improvements. Thanks to Jeffrey Mogul.

- tcpdump.c: Add -T flag allows interpretation of "vat", "wb", "rpc"
  (sunrpc) and rtp packets. Added "inbound" and "outbound" keywords
  Add && and || operators

-----------[000399][next][prev][last][first]----------------------------------------------------
Date:      Tue, 21 Jun 94 16:43:00 -0640
From:      john.will@dscmail.com (John Will)
To:        comp.protocols.tcp-ip
Subject:   Re: Implementing interrup

D > Thanks to all who replied to my question about non-blocking/interrupt-
D >driven I/O.  Much of the advice was to use select(); however I don't actually
D >want my process to sleep, but to do other (useful!) stuff.

If you want real-time interrupt driven I/O, you have to get a bit trickier
than using the plain socket stuff.

D >It looks like SIGIO will work, although its a pity to have to muck around
D >with signals. Using this in conjunction with a second server-side process
D >to do non-blocking I/O seemed like a good suggestion.

This is one way of being trickier. :-)  OTOH, if you have other short tasks
that you can do and use select() occasionally to check if a new message
has come in, that also works.  I've done a couple of things that way.
You should tailor the solution to your requirements...

-----------[000400][next][prev][last][first]----------------------------------------------------
Date:      21 Jun 1994 14:56:05 -0500
From:      gpalmer@blue.weeg.uiowa.edu (Gary Palmer)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject:   Auto login with Telnet

Is there a way to create an automatic Telnet login into a Unix host?

I want to be able to create, say, an icon that will run a Windows
Telnet program and have it automatically attach to log in to a choosen
host and account.  I know you can set up the command line calling the
telnet program to connect to the host:

  c:\apps\trmptel.exe host.domain.dom

What would be nice is if you could do something like this:

  c:\apps\trmptel.exe host.domain.dom user

to log in as a user.  Or, I could see the posibility of creating a
special service on a normally unused port that, when connected to, would
automatically log into a predefined port:

  c:\apps\trumptel.exe host.domain.dom 2300

If anyone connects at port 23, the default telnet port, everything would be
normal.  Connect at 2300 and, if the system admin. set up a service there
to run telnetd but automatically log in, it would.

Does anyone know if this is possible? 

-----------[000401][next][prev][last][first]----------------------------------------------------
Date:      21 Jun 1994 16:22:59 -0500
From:      rew@moontarz.nuance.com (Ryan Waldron)
To:        comp.os.ms-windows.networking.tcp-ip,comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject:   Re: List of Winsock DLL Vendors

mweiss@nwk.cl.nec.co.jp (Michael J. Weiss) writes:
> Does anyone know where I can get a list of Winsock Implementation Vendors ?

ftp://sunsite.unc.edu/pub/micro/pc-stuff/ms-windows/winsock/vendor-list


-- 
Ryan Waldron     |||       rew@nuance.com       |||    ...!world!rew
The Software Tailors                            "Software that fits"
Consulting and Contract programming             Unix / Windows / DOS
       C / C++ / GUI / XVT / OWL / E-Mail & News setup & admin

-----------[000402][next][prev][last][first]----------------------------------------------------
Date:      21 Jun 94 16:08:11 CDT
From:      anh@kuhub.cc.ukans.edu
To:        comp.protocols.tcp-ip
Subject:   1 packet at a time



Hello everybody,

Suppose I had 4000 bytes to send and I use one sendto(s,buf,4000,0,addr,sz), will
buf be sent as one packet?

Is one sendto() call == 1 packet ? If not, is there a way to control the size of
UDP and TCP packets at all?

Thanks for all help.

Anh



-----------[000403][next][prev][last][first]----------------------------------------------------
Date:      21 Jun 1994 11:34:51 GMT
From:      Per.Weisteen@hda.hydro.com (Per Weisteen)
To:        comp.protocols.tcp-ip
Subject:   DHCP source somewhere ?

Has someone implemented and made available source code
for a UNIX based DHCP server yet ?

+---------------------------------------------------------------+
| Per Weisteen		Email: Per.Weisteen@hda.hydro.com   	|
| Norsk Hydro           Phone: +47 2273 8227                	|
| Norway                					|
 +---------------------------------------------------------------+

-----------[000404][next][prev][last][first]----------------------------------------------------
Date:      21 Jun 1994 12:47:16 GMT
From:      slama@ctron.com (Frederick G. Slama)
To:        comp.protocols.tcp-ip
Subject:   non-blocking connect/RPC


	Net,

	Has anyone out there had success in using RPC in an environment
	where target network devices might not exist? For example,
	when contacting a bogus address, clnt_create() will hang for a
	timeout period of about 75 seconds (on SunOs). At the sockets API
	level, I could mark the socket as non-blocking and to generate a SIGIO
	signal upon receipt of IO. However, the RPC interface insulates
	me from this. This makes things difficult.

	Any suggestions?

-Fred

-----------[000405][next][prev][last][first]----------------------------------------------------
Date:      Tue, 21 Jun 1994 13:12:51 GMT
From:      csylk@cspublic2 (Yoon Kimn)
To:        comp.protocols.tcp-ip,comp.sys.apple2.comm,comp.sys.mac.apps,comp.sys.mac.misc
Subject:   Network tools survey


First, I appologize if this is not the right newsgroup (and also cross posting).

I've been given a job of doing complete survey on tools such as eudora, fetch, etc.
      
My superiors want me to survey all softwares including public domain, freeware, share-
ware, as well as commercial products. The other stuff is rather easy to find, but the 
only commercial product I know of is TCP/IP CONNECT from the Intercon System.

Can someone tell me any commercial products (for Mac) out there?

Also I'll appreciate it very much if anybody can direct me to the right newsgroup or
mailing list to which a lot of those vendors join so that I can continue with the survey.

Thanks a million.



Yoon Kimn
City College of CUNY, NYC
email: yoon@cs-mail.engr.ccny.cuny.edu



-----------[000406][next][prev][last][first]----------------------------------------------------
Date:      21 Jun 94 14:40:57 GMT
From:      blaak@csri.toronto.edu (Raymond Blaak)
To:        comp.protocols.tcp-ip
Subject:   Re: need ammo to use against bone-headed administrator

jrd@cc.usu.edu (Joe Doupnik) writes:

>In article <sej.772128274@interaccess>, sej@psycfrnd.interaccess.com (Stephen Johnson) writes:
>> Help!
>> I've got a admin guy on one of my subnets that insists that he
>> has 4 subnets available when he uses a subnet mask of 255.255.255.192
>> I've explained/agrued with him until I'm blue in the face. Can anybody
>> give me the RFC that spells this out in black and white? I need to
>> beat him over the head with a RFC for a while.
>> 
>> Thanks
>> Steve Johnson
>-----------
>	RFC1122.TXT
>	Joe D.

Well, I would think that there would be 4 subnets available too. Would
someone care to explain to me why there aren't? Is it because of the
ambiguity between a broadcast over the 4th subnet and an all subnets
broadcast?

Cheers,
Ray Blaak
blaak@csri.toronto.edu


-----------[000407][next][prev][last][first]----------------------------------------------------
Date:      Tue, 21 Jun 1994 15:34:18 GMT
From:      ronf@phx.sectel.mot.com (Ron Feigen)
To:        comp.protocols.tcp-ip
Subject:   Re: Call to get socket protocol from fd?

getsockname fills in the sockaddr struct.


In article 69s@sgi1.fnet.cs.mci.com, abell@velveeta.apdev.cs.mci.com (Andrew_Bell) writes:
>Is there a call (BSD sockets) to get the protocol (SOCK_STREAM, SOCK_DGRAM,
>SOCK_RAW, etc.) if given the file descriptor of a socket?
>
>Andrew Bell
>MCI Communications
>abell@chong.nms.cs.mci.com





-----------[000408][next][prev][last][first]----------------------------------------------------
Date:      21 Jun 1994 15:59:24 GMT
From:      nhs@llnl.gov (Norman Samuelson)
To:        comp.os.ms-windows.networking.tcp-ip,comp.os.ms-windows.programmer.networks,comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject:   Re: Simple Questions About Trumpet

In article <9406210051.AA25621@ariake.nwk.cl.nec.co.jp> mweiss@nwk.cl.nec.co.jp (Michael J. Weiss) writes:
>Hi...
>
>I have a few simple questions about Trumpet.
>
>
>1) Is the Trumpet DLL a Windows Sockets Implementation?

Yes!

>2) Is it public domain?

No, it is shareware, with a $20 registration (and well worth it IMHO).

>3) Is the source code available?

I don't think so.

>4) Where can I get it ?  (please list a few places if possible)
>

You can get the executable and documentation, but not source, from:

ftp.cica.indiana.edu /pub/pc/win3/winsock/winsock.zip
ftp.cdrom.com /.5/cica/<something>
ftp.ncsa.uiuc.edu /PC/Mosaic/sockets/winsock.zip

I could not verify the ftp.cdrom.com path, their server was refusing
more logins.  There are lots of sites that mirror CICA, and any of them
will have winsock.zip.

- Norm -

-----------[000409][next][prev][last][first]----------------------------------------------------
Date:      21 Jun 1994 16:27:38 GMT
From:      netcon2@hpwin062.uksr.hp.com (Ian Spare)
To:        comp.protocols.tcp-ip
Subject:   Re: DNS & Sendmail

In article <bdbauer.53.000EECFD@dal.mobil.com>,
Blaine D. Bauer <bdbauer@dal.mobil.com> wrote:
>I'm a relative newcomer to the Internet, but it seems amazing to me how many 
>locations are coming onto the internet considering how difficult it is to set 
>up and use DNS & sendmail.  Frankly, I have to wonder how many of them are 
>doing it very well.

I think I confirm that it's not being done very well !!

>
>Are there any tricks to the trade or perhaps automated tools that make DNS & 
>sendmail (especially sendmail) less cumbersome?  If not, WHY NOT?

I'm sure this doesn't focus on the problem at all; the problem I frequently
come across is that people think a connection to the Internet means 
simply configuring a couple of utilities and away you go on the Information
Superhighway !!

I'm struggling to phrase my real point here without being too insulting
to people !!! It seems to me that to use an internet connection fully
and provide a service to internal customers it is beholden upon local
admins to understand the issues, tools and technologies.  
It seems that anyone capable of that should find DNS, sendmail et al pretty 
trivial. I'd think if an organisation doesn't have that resource then it has 
too buy it in or face the simple fact that the Internet is arena they can't 
play in. I think it's unreasonable to expect that something as potentially
beneficial as internet is going to be easy.

In the UK we have several Internet providers now (from none not very long ago!)
most provide a cheap (ie 10 sterling/mth) service for customers. At this price
companies appear to connect with little or no thought; it may be elitest but
I'm sure if cost more people would treat the commitment with the seriousness
it deserves.

It may be worth mentioning that O'Reilly have produced some excellent books
(Nutshell books) covering TCP/IP admin, sendmail and DNS etc.

I've had cause to think on this recently, I'm a contractor/consultant and I 
work in UNIX and internetworking things. I had thought that I might be able
to do a lot of work helping companies install Internet connections, since
they can link up for such a small amount I think they'll find my rates a 
bit much !!


Ian


-- 
--------------------------------------------------------------------------- 
Ian J Spare, HP UK Response Centre.  Internet - netcon2@hpwin062.uksr.hp.com   
                                     HP Desk  - Ian SPARE / AL8005/RC
                                     Tel.     - 0344 361834
    Hewlett-Packard Ltd,Cain Road,Bracknell,Berkshire, RG12 1HN
                ** Currently On Contract for HP **
--------------------------------------------------------------------------- 

-----------[000410][next][prev][last][first]----------------------------------------------------
Date:      Tue, 21 Jun 1994 16:43:43 GMT
From:      imp@boulder.parcplace.com (Warner Losh)
To:        comp.protocols.tcp-ip
Subject:   Re: need ammo to use against bone-headed administrator

In article <ganzhorn-200694135554@mojo.cisco.com> ganzhorn@cisco.com
(Charles Ganzhorn) writes: 
>The reason you're having difficulty beating him up is that he's not wrong. 
>If you were talking about a class C address, you are right but your use of
>the term subnet and the mask you included implies you have given him a
>class C sized piece of a class A or B in which case, he is correct.

Well, no, the original sys admin is wrong.  When you have two bits of
subnetting, you have two networks.  The "00" net and the "11" are
reserved.  This is assuming a class C network that is being divided.
A netmask of 255.255.255.192 gives you two networks.  The general
formula for networks is
	2^n - 2
so for two bits of subnet, you have
	2^2 - 2 == 2.

I don't have the RFC on it, but it is the subnetting RFC and it can be
found by grepping the rfc-index.  My rfc-index was removed
accidentally a while ago and I haven't needed a new one.

Warner


-- 
Warner Losh		imp@boulder.parcplace.COM	ParcPlace Boulder
"... but I can't promote you to "Prima Donna" unless you demonstrate a few
 more serious personality disorders"

-----------[000411][next][prev][last][first]----------------------------------------------------
Date:      Tue, 21 Jun 1994 17:01:44 GMT
From:      dcrowley@unix1.tcd.ie (Seoirse Crowley)
To:        comp.protocols.tcp-ip
Subject:   Re: Implementing interrupts

 Thanks to all who replied to my question about non-blocking/interrupt-
driven I/O.  Much of the advice was to use select(); however I don't actually
want my process to sleep, but to do other (useful!) stuff.

It looks like SIGIO will work, although its a pity to have to muck around
with signals. Using this in conjunction with a second server-side process
to do non-blocking I/O seemed like a good suggestion.


Anyway, thanks again for help & education :-) 
Dan.


-----------[000412][next][prev][last][first]----------------------------------------------------
Date:      21 Jun 1994 17:15:27 GMT
From:      D.Nash@utexas.edu (Donald L. Nash)
To:        comp.protocols.tcp-ip
Subject:   Re: need ammo to use against bone-headed administrator


In article <CrrAGv.CE7@boulder.parcplace.com>, imp@boulder.parcplace.com
(Warner Losh) writes:
>Well, no, the original sys admin is wrong.  When you have two bits of
>subnetting, you have two networks.  The "00" net and the "11" are
>reserved.  This is assuming a class C network that is being divided.
>A netmask of 255.255.255.192 gives you two networks.  The general
>formula for networks is
>	2^n - 2
>so for two bits of subnet, you have
>	2^2 - 2 == 2.

This is all correct.  Check RFC1122, Host Requirements: Communications
Layers, section 3.2.1.3.

                                ++Don Nash

Internet:  D.Nash@utexas.edu    The University of Texas System
THEnet:    THENIC::DON          Office of Telecommunication Services

-----------[000413][next][prev][last][first]----------------------------------------------------
Date:      Tue, 21 Jun 1994 17:54:38 GMT
From:      doug@siegfried.VF.GE.COM (Doug Hughes)
To:        comp.protocols.tcp-ip
Subject:   Re: RSH, REXEC, RPC source or implementation?

In article <Valenzuela_Cesar/Mac-170694071848@129.197.109.3>, Valenzuela_Cesar/Mac@mm.ssd.lmsc.lockheed.com (Cesar Valenzuela) writes:
|> Does anyone have any source code or documentation on how to implement
|> the protocols for RSH or Rexec or RPC.  Any info on this subject
|> will be greatly appreciated.
|> 
|> Thanks.
|> 
|> The opinions and views listed within this posting does not reflect the
|> opinions and views of the company.

yes, Stevens "Unix Network Programming" for one has the rsh source
code. From there it is easy to make the rexecd source code.  I did
it myself to repair some deficiencies in rexecd under 4.1.3.  The
complete sources from the book are available on ftp.uu.net in
one of those publications directories.
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Doug Hughes              Internal Information Systems (NorthEast)   
System/Net Admin         Martin Marietta, Valley Forge, PA          
doug@vf.ge.com           doug@land.vf.ge.com                        
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
   "The light at the end of the tunnel is the headlamp of a train"  


-----------[000414][next][prev][last][first]----------------------------------------------------
Date:      21 Jun 1994 14:52:35 +0200
From:      urlichs@smurf.noris.de (Matthias Urlichs)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP/IP Cleint/Server Timing Problem?

In comp.protocols.tcp-ip, article <1994Jun1.192251.16285@sed.psrw.com>,
  nebrich@sed.psrw.com (Mark A. Nebrich) writes:
> 
> The server is designed to notify connected clients when it (the server) dies.
> Each client has the responsibility to close server connections and try to 
> reconnect. Once the server is restarted, it accepts client re-connections.
> 
> The problem is that when the server dies and each client disconnects and
> immediately trys to reconnect, it connects to the dead server IP address.

Tell your server to close the socket which accepts connections before
notifying the clients, instead of afterwards (or indeed not at all).

-- 
Lawyers do it in their briefs.
-- 
Matthias Urlichs        \ XLink-POP Nürnberg  | EMail: urlichs@smurf.noris.de
Schleiermacherstraße 12  \  Unix+Linux+Mac    | Phone: ...please use email.
90491 Nürnberg (Germany)  \   Consulting+Networking+Programming+etc'ing     42

Click <A HREF="http://smurf.noris.de/~urlichs/finger">here</A>.

-----------[000415][next][prev][last][first]----------------------------------------------------
Date:      21 Jun 1994 18:33:17 GMT
From:      ganzhorn@cisco.com (Charles Ganzhorn)
To:        comp.protocols.tcp-ip
Subject:   Re: need ammo to use against bone-headed administrator

In article <CrrAGv.CE7@boulder.parcplace.com>, imp@boulder.parcplace.com
(Warner Losh) wrote:
> 
> In article <ganzhorn-200694135554@mojo.cisco.com> ganzhorn@cisco.com
> (Charles Ganzhorn) writes: 
> >The reason you're having difficulty beating him up is that he's not wrong. 
> >If you were talking about a class C address, you are right but your use of
> >the term subnet and the mask you included implies you have given him a
> >class C sized piece of a class A or B in which case, he is correct.
> 
> Well, no, the original sys admin is wrong.  When you have two bits of
> subnetting, you have two networks.  The "00" net and the "11" are
> reserved.  This is assuming a class C network that is being divided.
> A netmask of 255.255.255.192 gives you two networks.  The general
> formula for networks is
> 	2^n - 2
> so for two bits of subnet, you have
> 	2^2 - 2 == 2.
> 
> I don't have the RFC on it, but it is the subnetting RFC and it can be
> found by grepping the rfc-index.  My rfc-index was removed
> accidentally a while ago and I haven't needed a new one.

I guess I wasn't clear.  I agree for a class C.  The use of the term subnet
implied that the "bonehead" wanted to further subnet a subnet of a class A
or B which had been granted by the sysadmin who originated the posting.  In
this case, the rule about 00 and 11 doesn't apply.

Charles.

--
Charles Ganzhorn                        Email:  ganzhorn@cisco.com
Consulting Engineer                     
cisco Systems
One Appletree Square, Suite 1452        
8009 34th Avenue South                  Phone:  612-851-8310
Bloomington, MN  55425                  FAX:    612-851-8311

-----------[000416][next][prev][last][first]----------------------------------------------------
Date:      Tue, 21 Jun 1994 18:55:39 GMT
From:      add@philabs.philips.com (Aninda Dasgupta)
To:        comp.protocols.tcp-ip,comp.sys.sun.misc
Subject:   Reliable UDP Broadcasts?


Does anyone have any experience with "reliable UDP broadcasts?"
I am simulating a protocol using UDP broadcasts.  A node
on the network doesn't know of the existence or identity of the 
other nodes on the network.  Thus, if node A wishes to discover
who else is listening to its broadcasts on the subnet, it shouts
a 'grope' packet.  The reciepients of the grope packet reply 
back, again using broadcasts.

The problem I am facing is as follows:

Host B and C are listening for broadcasts on the subnet.  Node A
broadcasts a grope packet, which is received by both B and C.
Immediately, B and C decide to broadcast grope packets.  However, 
B does not hear C's broadcast.  Strangely enough, C can hear B's
broadcast.  I suspect that the UDP packets from C are being
dropped at B.  I guess that is part of the unreliability of the
UDP protocols.

If anyone has dealt with such a problem and built a reliability
layer over UDP broadcasts, I would like to hear from you.  Please
note that I cannot use end to end acknowledgements as the identity
of other nodes on the network are not known before the grope packets
are sent out.  Thus, C cannot expect to get an acknowledgement from
B as C does not know of B's existence.

If it matters, I am using Sparc IPX, with SunoS 4.1.2.

Thanks for any ideas/information you can give me.

Regards,

Aninda



-- 
Aninda DasGupta (add@philabs.philips.com) Ph:(914)945-6071 Fax:(914)945-6552
Philips Labs\n 345 Scarborough Rd\n  Briarcliff Manor\n NY 10510
"Err.., Phillips Petroleum gives you gas; fortunately Phillips Chemical
 makes antacid. Philips is with one "el", we make lightbulbs. And other shtuff"

-----------[000417][next][prev][last][first]----------------------------------------------------
Date:      Tue, 21 Jun 1994 19:01:34 GMT
From:      add@philabs.philips.com (Aninda Dasgupta)
To:        comp.protocols.tcp-ip,comp.sys.sun.misc
Subject:   Reliable UDP Broadcasts?


Does anyone have any experience with "reliable UDP broadcasts?"
I am simulating a protocol using UDP broadcasts.  A node
on the network doesn't know of the existence or identity of the 
other nodes on the network.  Thus, if node A wishes to discover
who else is listening to its broadcasts on the subnet, it shouts
a 'grope' packet.  The reciepients of the grope packet reply 
back, again using broadcasts.

The problem I am facing is as follows:

Host B and C are listening for broadcasts on the subnet.  Node A
broadcasts a grope packet, which is received by both B and C.
Immediately, B and C decide to broadcast grope packets.  However, 
B does not hear C's broadcast.  Strangely enough, C can hear B's
broadcast.  I suspect that the UDP packets from C are being
dropped at B.  I guess that is part of the unreliability of the
UDP protocols.

If anyone has dealt with such a problem and built a reliability
layer over UDP broadcasts, I would like to hear from you.  Please
note that I cannot use end to end acknowledgements as the identity
of other nodes on the network are not known before the grope packets
are sent out.  Thus, C cannot expect to get an acknowledgement from
B as C does not know of B's existence.

If it matters, I am using SunOS 4.1.2 on a Sparc IPX.

Thanks for any ideas/information you can give me.

Regards,

Aninda



-- 
Aninda DasGupta (add@philabs.philips.com) Ph:(914)945-6071 Fax:(914)945-6552
Philips Labs\n 345 Scarborough Rd\n  Briarcliff Manor\n NY 10510
"Err.., Phillips Petroleum gives you gas; fortunately Phillips Chemical
 makes antacid. Philips is with one "el", we make lightbulbs. And other shtuff"

-----------[000418][next][prev][last][first]----------------------------------------------------
Date:      Tue, 21 Jun 1994 19:37:53 +0000
From:      nikki@trmphrst.demon.co.uk (Nikki Locke)
To:        comp.os.ms-windows.networking.tcp-ip,comp.os.ms-windows.programmer.networks,comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject:   Re: Public Domain Winsock DLL

In article <9406210506.AA27520@ariake.nwk.cl.nec.co.jp> mweiss@nwk.cl.nec.co.jp (Michael J. Weiss) writes:
> I am looking for a Winsock Implementation (DLL) for which the source is
> available.  It must support a TCP/IP stack.
> 
> Ideally, it would be:
> 
> - available at no cost
> - tested and bug-free
> - fully winsock compliant

I don't believe I have seen a Winsock DLL which satisfies ONE of these
conditions, let alone all three at once ! 

-- 
Nikki Locke,Trumphurst Ltd.(PC & Unix consultancy) nikki@trmphrst.demon.co.uk
trmphrst.demon.co.uk is NOT affiliated with ANY other sites at demon.co.uk.

-----------[000419][next][prev][last][first]----------------------------------------------------
Date:      21 Jun 1994 16:34:25 +0200
From:      morten@haegar.allcon.net (Morten Jammer)
To:        comp.protocols.tcp-ip
Subject:   How to count packets on a network ?

Hi !

The system here is a DEC VAX 6000-420 machine and some Linux PCs.

How is it possible to count the IP packets on a network ?
Does anyone have a sample C-Listing ?

Im trying to write a simple accounting system to get statistic about
which IP number has sent how many packets to which IP adress.
Is it possible to get these informations while listening on a socket ?

I know, that some programms will give these Information like TCPDUMP or
ETHERFIND, but i need the Information, how to implement it
in C, without searching tons of sourcecode.

The main aim is to combine the PID of processes, which communicate
over a socket, with the portnumber the use.

Thanks in advance !


 






-----------[000420][next][prev][last][first]----------------------------------------------------
Date:      21 Jun 1994 19:56:13 GMT
From:      vsachdev@mason1.gmu.edu (Vineet Sachdev)
To:        comp.protocols.tcp-ip
Subject:   Info. on talk needed !!

I am trying to write a utility similar to talk, and am looking for any
help on the data formats used in sending data.  I am aware that the
underlying protocol is udp and the port information is available from
/etc/services.

Thanks in advance.
Vineet.


-----------[000421][next][prev][last][first]----------------------------------------------------
Date:      21 Jun 1994 19:59:20 GMT
From:      barmar@think.com (Barry Margolin)
To:        comp.protocols.tcp-ip
Subject:   Re: AF_UNIX & AF_INET Domains

In article <Crop1M.n25@kddlab.kddlabs.co.jp> tru@kddnews.kddlabs.co.jp (Tohru Asami) writes:
>So AF_UNIX just means AF_INET with a local loopback (address 127.0.0.1),
>doesn't it?

No.  Unix domain sockets don't use TCP/IP at all.  They usually use the
same internal kernel mechanisms as pipes.

>What I want to know is how data are passed from one process to
>another via a LOCAL LOOPBACK. There are two choises to pass data from
>one to another:
>
>(1) Data written for 127.0.0.1 with TCP/UDP protocols are passed via
>    some memory buffers shared among processes, physically using TCP/UDP
>    protocols.

Not quite.  It's done at the device driver level.  When IP writes something
to the loopback interface, the device driver simply moves the data into the
receive queue.  The normal processing of received data then causes it to go
back up the protocol stack.

>(2) Use only TCP/UDP port number and neglect all other protocol
>    stuff to exchange data between processes. Data passing is physically
>    made with hardware/OS specific mechanisms such as shared memory
>    space, etc.

This would not be right.  The loopback interface is required to behave just
like any other network interface.  If it only supported TCP and UDP then it
would not be like other interfaces.  It must support all IP facilities.

>Are there any RFC's describing this kind of technical issues?

Internal design of implementations is not usually the scope of RFC's --
RFC's are for communication protocols that affect interoperability of
systems (although there are some that describe how to implement efficient
implementations, since network protocol performance can affect other
systems).

-- 
Barry Margolin
System Manager, Thinking Machines Corp.

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

-----------[000422][next][prev][last][first]----------------------------------------------------
Date:      Tue, 21 Jun 1994 20:22:48 GMT
From:      doug@siegfried.VF.GE.COM (Doug Hughes)
To:        comp.sys.sun.admin,comp.protocols.tcp-ip
Subject:   RIP and very large internal internet


We have a huge internal internet and are seeing strange symptoms.
Has anybody seen problems with Sun workstations (running any version
of SunOS) losing routes randomly in large internets?  We seem
to be experiencing this even though we can see the routes being
advertised by the routers (using a sniffer, and a nit/dlpi custom
tool).  Sometimes the sun will pick up the route, sometimes it won't.
I cannot say whether it is sun specific or not, but the majority
of our systems are sun workstations currently.
  The number of routes is approximately 1500.  (admittedly, we
should be using something other than RIP, but because of the nature
of the network (subnetted class A on 255.255.252.0) and the diversity
of hosts (Mac, PC (many different protocol stacks), Sun, HP, Vax,
decstation... etc.. etc..) it is a prodigious undertaking to change.

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Doug Hughes              Internal Information Systems (NorthEast)   
System/Net Admin         Martin Marietta, Valley Forge, PA          
doug@vf.ge.com           doug@land.vf.ge.com                        
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
   "The light at the end of the tunnel is the headlamp of a train"  


-----------[000423][next][prev][last][first]----------------------------------------------------
Date:      21 Jun 1994 21:26:50 GMT
From:      dauns@andrews.edu (Frank Dauns)
To:        comp.protocols.tcp-ip
Subject:   ODI Gopher,news,etc clients

We are running the Pathway Access TCP/IP stack and Novell 3.12 and are
using ODI to share the card.    Are there any good gopher,news,etc..
clients that run on ODI (free or otherwise) without using shims ?  

I am familiar with the set of tools popmail, gopher etc with their own
internal TCP/IP stacks that run off the NCSA packet drivers but have
been unable to find the correct shims to run these on the above
configuration.  

Any information or pointers to information is appreciated.

Thanks

-- 
Frank Dauns                               Programmer/Support 
dauns@andrews.edu                         Lake Michigan College 

-----------[000424][next][prev][last][first]----------------------------------------------------
Date:      Tue, 21 Jun 1994 22:05:10 GMT
From:      nilesh@wuerl.wustl.edu (Nilesh R. Gohel)
To:        comp.protocols.tcp-ip,comp.networks.noctools.wanted,comp.protocols.dicom
Subject:   Wanted: TCP/IP network snooper based on SUNOS 5.x DLPI

We are designing a network snooping tool for a medical image communication
protocol known as DICOM (Digital Imaging and Communications in Medicine).
This protocol sits on top of TCP/IP in the protocol stack.

We are trying to develop the snooper in the SUNOS 5.x environment using
the Data Link Provider Interface (DLPI). If anyone is aware of the
whereabouts of inexpensive (most preferably free) source code for a
TCP/IP network snooper based on DLPI, such information would be highly
appreciated as a base for our project work. The tool is intended for
ethernet networks.

Thanks.

Nilesh R. Gohel

Research Assistant

Electronic Radiology Laboratory         Tel. (314) 362-6965
Mallinckrodt Institute of Radiology     Fax. (314) 362-6971
510 S. Kingshighway Blvd.
St. Louis, MO 63110                     E-mail: nilesh@wuerl.wustl.edu

-----------[000425][next][prev][last][first]----------------------------------------------------
Date:      Tue, 21 Jun 1994 23:20:43 GMT
From:      vjs@calcite.rhyolite.com (Vernon Schryver)
To:        comp.protocols.tcp-ip
Subject:   Re: RSH, REXEC, RPC source or implementation?

In article <1994Jun21.175438.11377@knight.vf.ge.com> doug@vf.ge.com writes:
>In article <Valenzuela_Cesar/Mac-170694071848@129.197.109.3>, Valenzuela_Cesar/Mac@mm.ssd.lmsc.lockheed.com (Cesar Valenzuela) writes:
>|> Does anyone have any source code or documentation on how to implement
>|> the protocols for RSH or Rexec or RPC.  Any info on this subject
>|> will be greatly appreciated.


>yes, Stevens "Unix Network Programming" for one has the rsh source
>code. From there it is easy to make the rexecd source code.  I did
>it myself to repair some deficiencies in rexecd under 4.1.3.  The
>complete sources from the book are available on ftp.uu.net in
>one of those publications directories.


While the Stevens book is by all accounts a great piece of work, why in
the world would anyone not go straight to the source of the source?
Why not use the freely available, freely redistributable source?  (Freely
redistributable provided you maintain the copyrights unlike a certain
large UNIX Source Lisense outfit.)

Look for rexec, rsh, rshd, rlogin, rlogind, telnet, telnetd, inetd, and
the rest in fine BSD source repositories everywhere.  It can be had on
several CDROMs from several outfits, including Walnut Creek (FreeBSD
and maybe Sprit) and O'Reilly (4.4BSD-Lite).  On the net, it can be
found as part of complete UNIX systems (plural).  See
comp.os.386bsd.announce for pointers to NetBSD and FreeBSD.

About 10 years ago Sun Microsystems tried to give away Sun RPC source.
It should be floating around the net somewhere.  Specifications for RPC
and XDR have been in informational RFC's for a long time.


Vernon Schryver    vjs@rhyolite.com

-----------[000426][next][prev][last][first]----------------------------------------------------
Date:      Wed, 22 Jun 1994 02:09:58 GMT
From:      vjs@calcite.rhyolite.com (Vernon Schryver)
To:        comp.protocols.tcp-ip
Subject:   Re: AF_UNIX & AF_INET Domains

In article <2u7gqoINN10a@early-bird.think.com> barmar@think.com (Barry Margolin) writes:
>In article <Crop1M.n25@kddlab.kddlabs.co.jp> tru@kddnews.kddlabs.co.jp (Tohru Asami) writes:
 
> ...
>>Are there any RFC's describing this kind of technical issues?
>
>Internal design of implementations is not usually the scope of RFC's --
>RFC's are for communication protocols that affect interoperability of
>systems (although there are some that describe how to implement efficient
>implementations, since network protocol performance can affect other
>systems).


True, except that AF_UNIX is a Berkeley creation, and the source for
both 4.*BSD AF_INET and AF_UNIX is widely available.

Remember, if you can choose only one kind of documentation, the source
is the one to pick.  Various verbal descriptions are easier to use and
understand, but invariably less complete.  The source is necessarily
complete.


Vernon Schryver    vjs@rhyolite.com

-----------[000427][next][prev][last][first]----------------------------------------------------
Date:      Wed, 22 Jun 1994 07:58:21
From:      clarkb@netstar.com (Clark Bremer)
To:        comp.protocols.tcp-ip
Subject:   Re: ODI Gopher,news,etc clients

In article <2u7luq$35o@orion.cc.andrews.edu> dauns@andrews.edu (Frank Dauns) writes:
>From: dauns@andrews.edu (Frank Dauns)
>Subject: ODI Gopher,news,etc clients
>Date: 21 Jun 1994 21:26:50 GMT
 
>We are running the Pathway Access TCP/IP stack and Novell 3.12 and are
>using ODI to share the card.    Are there any good gopher,news,etc..
>clients that run on ODI (free or otherwise) without using shims ?  
 
>I am familiar with the set of tools popmail, gopher etc with their own
>internal TCP/IP stacks that run off the NCSA packet drivers but have
>been unable to find the correct shims to run these on the above
>configuration.  

I think you're confusing some of your layers, but what you want in the end is 
a winsock comaptible interface to the IP stack (and eveything below it).  Once 
you have that, there are winsock versions of trumpet, gopher, mosaic, etc.

Since you have ODI drivers on the bottom, what you need to get is an IP stack 
that speaks ODI on the bottom, and winsock at the top.  I use FTP's PCTCP, 
which is really packet-driver style on the bottom, and proprietary on the top. 
They provided a 'shim' for the bottom called odipkt.com which - you guessed 
it - makes the ODI driver look like a packet driver to the stack.  On the top, 
they have another shim to give you winsock compatibility ( in this case it 
MUST be named winsock.dll).  You need to do something similar, as the defacto 
standard for windows IP apps is winsock.  Good luck, CB.
===========================================================================
          _  _               Clark Bremer     clarkb@netstar.com
         /  /_)              Software Engineer, NetStar Inc.
         \_/__)              10250 Valley View Road  MPLS, MN 55344

-----------[000428][next][prev][last][first]----------------------------------------------------
Date:      22 Jun 1994 09:51:34 -0400
From:      exe03309@char2.vnet.net (Jeff and Diana Kane)
To:        comp.protocols.tcp-ip
Subject:   Re: ODI Gopher,news,etc clients

Frank Dauns (dauns@andrews.edu) wrote:
: We are running the Pathway Access TCP/IP stack and Novell 3.12 and are
: using ODI to share the card.    Are there any good gopher,news,etc..
: clients that run on ODI (free or otherwise) without using shims ?  
 
: -- 
: Frank Dauns                               Programmer/Support 
: dauns@andrews.edu                         Lake Michigan College 

If you are using Pathway, you will need clients that use the Pathway 
TCP/IP stack and not ODI.  ODI is just a way of sharing the NIC with more 
than one protocol.  If you are using windows, you can get Pathway 3.0 and 
use Winsock.  It is available with 2.1, but is not very stable.  For 
those of you who have been asking how to use winsock with Pathway,...
Just make sure the Pathway directory is on your dos PATH= statement.  
Then when you start windows, it will find the Winsock.dll and use it.  
Make sure that if you have tested other packages that the one you want is 
the only one on your PATH= statement!
-Jeff

-- 
Jeff or Diana Kane             Perfect Computer Solutions
exe03309@vnet.net              414-238-9075
Network Consultants on the Information Super Highway!

-----------[000429][next][prev][last][first]----------------------------------------------------
Date:      21 Jun 1994 13:55:57 +0800
From:      snm@dublin.dcd.wa.gov.au (Sun Net Manager)
To:        comp.protocols.tcp-ip
Subject:   tn3270 for Solaris ?

Hi All

I am looking for a LOW COST TN3270 emulator for Solaris 2.3.  There are some
old PD emulators on the net which work fine under SunOs4, but Ive had problems
with using them under Solaris.

can someone point me in the right direction ?

Thanks

Jim

-----------[000430][next][prev][last][first]----------------------------------------------------
Date:      Wed, 22 Jun 1994 03:35:42 GMT
From:      scotto@crash.cts.com (Scott O'Connell)
To:        comp.protocols.tcp-ip
Subject:   source IP identification?

Is it possible to determine the source of a rlogin or telnet session from
a shell script?  I'd like to be able to set variables based on the origin
of the session.

Please e-mail to scotto@ipars.sds.com.  

Thanks in advance


-----------[000431][next][prev][last][first]----------------------------------------------------
Date:      22 Jun 1994 12:51:10 -0500
From:      les@MCS.COM (Leslie Mikesell)
To:        sco.tech.tcpip,comp.os.ms-windows.networking.tcp-ip,comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject:   Re: A Leaner TCP/IP For DOS ?

In article <1994Jun22.160322.16081@sco.com>,
Christopher J. Wood <chrisw@sco.COM> wrote:
>
>I am looking for a DOS implementation of TCP/IP
>that requires *AS LITTLE MEMORY AS POSSIBLE! *
>
>All my customer needs is tcp/ip -- no utils 
>(rlogin, ftp, snmp, etc.).

Depends on what you are doing.  The free WATTCP library might work
if you are writing your own program(s).  It is linked with your
program and requires only a packet driver interface.  So, when
you aren't running the program it doesn't take any dos memory.

Les Mikesell
  les@mcs.com

-----------[000432][next][prev][last][first]----------------------------------------------------
Date:      Wed, 22 Jun 1994 09:09:54 +0000
From:      Philc@hipstech.demon.co.uk (Phil Cramp)
To:        comp.dcom.lans.ethernet,comp.dcom.lans.misc,comp.misc,comp.protocols.tcp-ip,comp.sys.hp.hpux,comp.sys.hp.misc,comp.unix.misc
Subject:   Printing via GANDALF Terminal Servers

HI!

We have a customer who has installed an ethernet network based
around GANDALF terminal servers. They (and we!) would like to be
able to print information for them locally via these terminal 
servers. Their services are based on a Hewlett-Packard G60
Business Server.

Clearly, we need to be able to declare a remote printer, where
the remote host is one of the terminal servers and then replace
the interface script with either a 'C' program or a new script
that will initiate an outward connection to the terminal
server, then connect to a specific "port" on the terminal server
and deliver the print-out.

Does anyone know where we can obtain a replacement for the 
interface script, or have any idea on how we would go about
producing our own interface? All ideas/pointers gratefully
received - e-mail or post, I will try to summarise to all
groups this article appears in.

Thanks in advance.
-- 
Phil Cramp                          philc@hipstech.demon.co.uk
AT&T Istel Ltd., Redditch, UK
#include <std/disclaimer>
Plain .sig, not an original thought in my head...........

-----------[000433][next][prev][last][first]----------------------------------------------------
Date:      22 Jun 1994 16:59:52 -0400
From:      phoff@panix.com (Phil Hoff)
To:        comp.protocols.tcp-ip
Subject:   Re: need ammo to use against bone-headed administrator

>>> Help!
>>> I've got a admin guy on one of my subnets that insists that he
>>> has 4 subnets available when he uses a subnet mask of 255.255.255.192
>>> I've explained/agrued with him until I'm blue in the face. Can anybody
>>> give me the RFC that spells this out in black and white? I need to
>>> beat him over the head with a RFC for a while.
>>> 
>>> Thanks
>>> Steve Johnson
>>-----------
Merrill Lynch has about 2-3000 sun workstations, the corporate standard is a
subnet mask of 255.255.255.192. We divide the last octet into 4 subnets.

Regards,
Phil

-----------[000434][next][prev][last][first]----------------------------------------------------
Date:      22 Jun 1994 10:51:20 GMT
From:      leilabd@central.susx.ac.uk (Leila Burrell-Davis)
To:        comp.os.ms-windows.networking.tcp-ip,comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject:   Re: FTP client for MSDOS

Michael J. Weiss (mweiss@nwk.cl.nec.co.jp) wrote:
: Does anyone know of a shareware or freeware FTP client for DOS?

There's one with WATTCP and also I think with NCSA TCP and probably
with CUTCP. dorm.rutgers.edu is a good site for WATTCP and CUTCP. 

Leila
-- 
Leila Burrell-Davis, Computing Service, University of Sussex, Brighton, UK
Tel:   +44 273 678390              Fax:   +44 273 678470
Email: L.Burrell-Davis@susx.ac.uk

-----------[000435][next][prev][last][first]----------------------------------------------------
Date:      22 Jun 1994 11:22:59 GMT
From:      ppessi@snakemail.hut.fi (Pekka Pessi)
To:        comp.protocols.tcp-ip
Subject:   BOOTP client, SLIP and broadcasts?


	We are developing a BOOTP client for AmiTCP/IP, a free NET/2 derived
	TCP/IP stack for Amiga.  

	The problem is that many AmiTCP users want to use BOOTP with SLIP
	connections.  We want to find out our IP address, destination IP
	address (ie. the default router) and subnetmask with BOOTP. 
	
	We can not send undirected broadcasts (255.255.255.255) to
	point-to-point links since the IP code of NET/2 does not allow it.
	What is the reason for this limitation?  Would there be any
	catastrophic consequences if we allow the undirected broadcasts to
	p-2-p links?  The NET/2 code allows already sending a directed
	broadcast through a p-2-p link, as the p-2-p interfaces are not
	checked when directed broadcast addresses are verified.

	Is there anything else we should change, except allowing
	broadcasting to p-2-p links?

						Pekka Pessi

--
Pekka.Pessi@hut.fi

-----------[000436][next][prev][last][first]----------------------------------------------------
Date:      Wed, 22 Jun 1994 12:39:44 GMT
From:      smadja@techunix.technion.ac.il (Frank Smadja)
To:        comp.protocols.tcp-ip
Subject:   SLIP and SOLARIS help needed


I heard  that SLIP would not run on Solaris 2.3 is it true??
I only have a sparc running 2.3 and would like to get to the internet
through SLIP.

Thanks for answering.

Frank

-----------[000437][next][prev][last][first]----------------------------------------------------
Date:      Wed, 22 Jun 1994 12:59:10 GMT
From:      rstevens@noao.edu (W. Richard Stevens)
To:        comp.protocols.tcp-ip
Subject:   Re: 1 packet at a time

>Suppose I had 4000 bytes to send and I use one sendto(s,buf,4000,0,addr,sz), will
>buf be sent as one packet?

Depends on the network's MTU.  One sendto() is one IP datagram, but
one IP datagram may be multiple IP packets, if fragmentation occurs.

	Rich Stevens

-----------[000438][next][prev][last][first]----------------------------------------------------
Date:      22 Jun 1994 13:03:18 GMT
From:      bortz@cnam.cnam.fr (Stephane Bortzmeyer)
To:        comp.dcom.sys.cisco,comp.protocols.tcp-ip
Subject:   Authentification of users on dialup terminal servers

I'm investigating the problem of access control for dialup SLIP/PPP terminal 
servers like Cisco's 500CS, Livingston's PortMaster, Xylogics' Annex, etc.
Since these machines are connected to the (unsecure) telephone network, 
authentification of incoming users is a necessity.

Most terminal servers can have a local user base. This solution has several 
weaknesses:
- doesn't work if you have several servers
- doesn't allow you to reuse an existing base (/etc/passwd, Kerberos...)

The general solution to this problem is to have an authentification server, 
queried by the terminal server. You can then implement the politics you wish. 
BUT:

Livingston uses the Radius protocol (see the draft RFC in 
ftp://ftp.netcom.com/pub/livingston/radius), Annex has a different system, 
Access Control Protocol (ACP), quite similar in functionnalities, Cisco uses 
another one, TACACS (described in RFC 1492) and the Telebit Netblazer yet 
another one (based on the DNS).

Livingston has released the specification and the code to try to make its 
solution a standard (ACP seems proprietary, I'm not sure of the status of 
TACACS code and the DNS used by Telebit is non-proprietary, but I don't 
know the extent of modifications they made.)

Does anyone know what are the opinions of the other vendors? Did they 
announce any joint effort to make a standard? How did they react to 
Livingston's initiative?

(A standard would be useful for people with network access servers from 
different manufacturers but also for those who write extensions of 
authentification servers, so they could distribute them more widely.)

Did anyone study in deep the different protocols? Radius seems 
simpler and more powerful to me, also more secure since passwords 
are not send as clear text, but there are may be other facts I'm not 
aware of.

How does the different protocols compare when examining:
- security (how are passwords transmitted?)
- openess (are the specifications public?)
- availability of good implementations, with extensions like SecurID or
clear source code to implement your own modifications
- etc, etc

Stephane Bortzmeyer           Conservatoire National des Arts et Metiers	
bortzmeyer@cnam.fr            Laboratoire d'Informatique
                              292, rue Saint-Martin			
tel: +33 (1) 40 27 27 31      75141 Paris Cedex 03
fax: +33 (1) 40 27 27 72      France	

"C'est la nuit qu'il est beau de croire a la lumiere." E. Rostand

http://web.cnam.fr/personnes/bortzmeyer/home_page.dom

					
	

-----------[000439][next][prev][last][first]----------------------------------------------------
Date:      Wed, 22 Jun 1994 14:47:54 GMT
From:      gauthier@ug.cs.dal.ca (Paul Gauthier)
To:        comp.protocols.ppp,comp.protocols.tcp-ip
Subject:   How _should_ FTP react when a PPP link dies


Scenario: An FTP file transfer is occuring between two machines
(a Windows NT machine and some sort of UNIX box) which are
connected via a PPP link. The link is broken for some length of
time (aribitrarily long) and then reconnected.

Is there a well defined behavior for the FTP program, which it
should exhibit?

Will it:

   a) Kill the file transfer as soon as the PPP link dies
   b) Timeout after a while and kill the file transfer
   c) Just hang until the PPP link comes back up, and then resume
      where it left off

What if the PPP link goes down not because of a modem going offline,
but rather at the behest of the system administrator? Is there a
defined behavior in this case, and is it different?

I'm interested in behvaiors implied by the protocol standards, etc,
not really by a specific implimentation since I don't know what
flavours of UNIX will be involved.

The whole point of this disucssion, in case anyone cares, is to
find a good way to restart an FTP file transfer without having
to resend data which was already received by the other side.

If it will just hang and wait for the link to come back up and then
continue that would be wonderful. But if PPP link death propogates
a signal up the protocol stack letting everyone know its dead
causing the FTP client or server to abort, or if the transfer will
time out and abort, then this is not a viable solution. Any other
ideas?

PG
-- 
Paul Gauthier
gauthier@ug.cs.dal.ca
"Ready to climb?" ... "Does it *&^$ing look like I'm ready to climb?!"

-----------[000440][next][prev][last][first]----------------------------------------------------
Date:      22 Jun 1994 14:48:54 GMT
From:      justin@merle.acns.nwu.edu (Justin Newton)
To:        comp.protocols.tcp-ip
Subject:   Re: Info. on talk needed !!

In article <2u7gkt$qle@portal.gmu.edu>,
Vineet Sachdev <vsachdev@mason1.gmu.edu> wrote:
>I am trying to write a utility similar to talk, and am looking for any
>help on the data formats used in sending data.  I am aware that the
>underlying protocol is udp and the port information is available from
>/etc/services.
>
Uhm...
	Why not get one of the linux distributions and look at the source code
for talk and go from there?


-----------[000441][next][prev][last][first]----------------------------------------------------
Date:      22 Jun 1994 14:50:55 GMT
From:      achan@swm.metrotor.on.ca (Andrew Chan)
To:        comp.dcom.lans.ethernet,comp.dcom.lans.misc,comp.misc,comp.protocols.tcp-ip,comp.sys.hp.hpux,comp.sys.hp.misc,comp.unix.misc
Subject:   Re: Printing via GANDALF Terminal Servers

Phil Cramp (Philc@hipstech.demon.co.uk) wrote:
: HI!
 
: We have a customer who has installed an ethernet network based
: around GANDALF terminal servers. They (and we!) would like to be
: able to print information for them locally via these terminal 
: servers. Their services are based on a Hewlett-Packard G60
: Business Server.
 
: Clearly, we need to be able to declare a remote printer, where
: the remote host is one of the terminal servers and then replace
: the interface script with either a 'C' program or a new script
: that will initiate an outward connection to the terminal
: server, then connect to a specific "port" on the terminal server
: and deliver the print-out.
 
: Does anyone know where we can obtain a replacement for the 
: interface script, or have any idea on how we would go about
: producing our own interface? All ideas/pointers gratefully
: received - e-mail or post, I will try to summarise to all
: groups this article appears in.

  The Gandalf Terminal Server Modules we use are based on Datability
Terminal servers.  We received some code some time ago which allowed
printing off of the terminal server.  The code we received was not of the
highest quality, but it did work with a true Datability unit.
Unfortuantely, the software/hardware combination was unreliable on the
Gandalf units and we installed a seperate terminal/print server from
Lantronix to do our printing.

  The addresses given in the readme file may lead you to more up to date
code.  Try anon ftp to pluto.dss.com or email to techsupport@pluto.dss.com.

  Hope this helps.

Andrew


: Thanks in advance.
: -- 
: Phil Cramp                          philc@hipstech.demon.co.uk
: AT&T Istel Ltd., Redditch, UK
: #include <std/disclaimer>
: Plain .sig, not an original thought in my head...........

--
=============================================================================
Andrew Chan (achan@swm.metrotor.on.ca)                    Phone:    392-9653
Systems/Network Administrator - Metro Works / SWM         Fax:      392-4501
=============================================================================

-----------[000442][next][prev][last][first]----------------------------------------------------
Date:      22 Jun 1994 23:43:49 -0500
From:      mweiss@nwk.cl.nec.co.jp (Michael J. Weiss)
To:        comp.os.ms-windows.networking.tcp-ip,comp.os.ms-windows.programmer.networks,comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject:   no subject (file transmission)

As a starting point for some research I am doing, I am looking for a
Windows Sockets DLL with a TCP/IP stack written in C.  My work will
involve modifying this code to experiment with variants on the TCP/IP
protocol which support mobile a mobile computing environment.

I would greatly appreciate any advice you could offer as to how I
might reach this starting point in the easiest possible manner.
Below, I have listed my investigation into this issue thus far.  

Thank you in advance for any ideas or suggestions you might have.

I was able to find only two public domain DLLs with source available.

NCSA Winsock is not acceptable because based on what its README file
says, it is not very close to being Windows Sockets Compliant.

TCPMaster is in C++, which poses a problem for me, and is still being
beta tested.

I have solicited a few smaller vendors  in an effort to negotiate the
purchase of a single copy of source code to be used for research
purposes only by a single person on a single project, but this is a
long shot.


So, the two most likely scenarios are that I write the code myself, in
which case I would appreciate references to whatever info would help
me: RFCs, books, etc.

The other scenario is that I borrow large parts of other people's
code.  I am especially interested in finding public domain software
from which I can extract the code necessary to assemble portion(s) of
my goal, especially the TCP/IP stack, as I want to avoid this time
consuming task.



I would be very interested in hearing your thoughts on how I might get
to my starting point in as hassle-free a way as possible.

Thanks for your help.

Sincerely,

Michael Weiss



-----------[000443][next][prev][last][first]----------------------------------------------------
Date:      22 Jun 1994 15:35:05 GMT
From:      ppessi@snakemail.hut.fi (Pekka Pessi)
To:        comp.protocols.tcp-ip
Subject:   ARP on non-Ethernet networks


	What is the common practice in implementing the ARP on other than
	Ethernet hardware, e.g. Arcnet?  The original ARP document (RFC 826)
	defines the protocol type field as follows:

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

	This suggests that the protocol type is hardware specific, ie. one
	should use 2048 for IP in Ethernet and 240 for IP in Arcnet.

	However, this definition is refined by the Assigned numbers RFC
	(1060, 1340):

"   Protocol Type (pro)

      Use the same codes as listed in the section called "Ethernet
      Numbers of Interest" (all	hardware types use this	code set for the
      protocol type)."

	Is it common to use the Arcnet IP type (240) instead of the Ethernet
	IP type (2048, as required by RFC1340)?  Should the ARP
	implementation in Arcnet accept both protocol types (or three of
	them ;)?

						Pekka Pessi
--
Pekka.Pessi@hut.fi

-----------[000444][next][prev][last][first]----------------------------------------------------
Date:      Wed, 22 Jun 1994 15:39:00 GMT
From:      dag@tc.fluke.COM (David Gunderson)
To:        comp.os.ms-windows.networking.tcp-ip,comp.os.ms-windows.programmer.networks,comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject:   Re: Simple Questions About Trumpet

In article <9406210051.AA25621@ariake.nwk.cl.nec.co.jp> mweiss@nwk.cl.nec.co.jp (Michael J. Weiss) writes:
>Hi...
>
>I have a few simple questions about Trumpet.

I'm responding to this as a user and corporate reseller of an application
package that includes a licensed version of Trumpet.

>
>
>1) Is the Trumpet DLL a Windows Sockets Implementation?

Yes - it's as close to a complete implementation of V1.1 of the
WINSOCK specification as most implementations are right now.

>
>2) Is it public domain?

No - Trumpet International has always made it clear that the package
is available as shareware or via specific license agreements.

>
>3) Is the source code available?

No again - even those of us who have a specific bundling license with
Trumpet International have not been given access to the source code.

>
>4) Where can I get it ?  (please list a few places if possible)

Send email to peter@psychnet.psychol.utas.edu.au and he'll send you
a list of sources.

You can also reach Trumpet Software International via FAX or voice mail at
61-02-487049 in Australia. Their address is:

	Trumpet Software International
	GPO Box 1649
	Hobart Tasmania 7001
	Australia

ask for Peter Tattam (the author of the package) or Ian Jeanneret.

There are also several FTP servers with copies - since we don't generally
use these, I don't have the paths.

--David Gunderson


-----------[000445][next][prev][last][first]----------------------------------------------------
Date:      22 Jun 1994 16:01:19 GMT
From:      nhs@llnl.gov (Norman Samuelson)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject:   Re: Auto login with Telnet

In article <2u7gkl$js2@blue.weeg.uiowa.edu> gpalmer@blue.weeg.uiowa.edu (Gary Palmer) writes:
>Is there a way to create an automatic Telnet login into a Unix host?
>
>I want to be able to create, say, an icon that will run a Windows
>Telnet program and have it automatically attach to log in to a choosen
>host and account.

[some stuff deleted]

>Does anyone know if this is possible? 

What you are asking for is much easier with rlogin than telnet.

QVT/Net's telnet supports rlogin.  I have a couple of icons
setup that do rlogin to a couple of unix systems I use a lot.
With a .rhosts file on the unix machine to allow rlogin without
a password, I simply double click on the icon and I get a
window logged on to that machine.

It involves a little work in QVT/Net setting up a configuration
that uses rlogin, but the whole thing can be setup in a few
minutes.

I'll provide details if you are interested.

- Norm -

-----------[000446][next][prev][last][first]----------------------------------------------------
Date:      Wed, 22 Jun 1994 16:03:22 GMT
From:      chrisw@sco.COM (Christopher J. Wood)
To:        sco.tech.tcpip,comp.os.ms-windows.networking.tcp-ip,comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject:   A Leaner TCP/IP For DOS ?



Hi,

I am looking for a DOS implementation of TCP/IP
that requires *AS LITTLE MEMORY AS POSSIBLE! *

All my customer needs is tcp/ip -- no utils 
(rlogin, ftp, snmp, etc.).

Thanks!

Chris

-----------[000447][next][prev][last][first]----------------------------------------------------
Date:      22 Jun 1994 14:50:43 +0100
From:      robjan@rabo.nl (Rob Janssen)
To:        comp.protocols.tcp-ip,comp.sys.sun.misc
Subject:   Re: Reliable UDP Broadcasts?

In <1994Jun21.190134.11290@philabs.philips.com> add@philabs.philips.com (Aninda Dasgupta) writes:

:Does anyone have any experience with "reliable UDP broadcasts?"
:I am simulating a protocol using UDP broadcasts.  A node
:on the network doesn't know of the existence or identity of the 
:other nodes on the network.  Thus, if node A wishes to discover
:who else is listening to its broadcasts on the subnet, it shouts
:a 'grope' packet.  The reciepients of the grope packet reply 
:back, again using broadcasts.
 
:The problem I am facing is as follows:
 
:Host B and C are listening for broadcasts on the subnet.  Node A
:broadcasts a grope packet, which is received by both B and C.
:Immediately, B and C decide to broadcast grope packets.  However, 
:B does not hear C's broadcast.  Strangely enough, C can hear B's
:broadcast.  I suspect that the UDP packets from C are being
:dropped at B.  I guess that is part of the unreliability of the
:UDP protocols.

Maybe because of the "immediately"?
With such an algorithm, a single broadcast my a trigger a storm of
responses, some of which drown in collisions or queue overruns.
Best is to introduce some random delay between reception of the
packet and replying to it (or doing further broadcasts).

:If anyone has dealt with such a problem and built a reliability
:layer over UDP broadcasts, I would like to hear from you.  Please
:note that I cannot use end to end acknowledgements as the identity
:of other nodes on the network are not known before the grope packets
:are sent out.  Thus, C cannot expect to get an acknowledgement from
:B as C does not know of B's existence.

Protocols like this normally do a few retries to reduce the chance that
the response from some system is missed.  This cannot reduce the chance
to zero, however.

:Aninda DasGupta (add@philabs.philips.com) Ph:(914)945-6071 Fax:(914)945-6552
:Philips Labs\n 345 Scarborough Rd\n  Briarcliff Manor\n NY 10510
:"Err.., Phillips Petroleum gives you gas; fortunately Phillips Chemical
: makes antacid. Philips is with one "el", we make lightbulbs. And other shtuff"

Yes, I know about that company :-)

Rob

-----------[000448][next][prev][last][first]----------------------------------------------------
Date:      22 Jun 1994 16:35:39 GMT
From:      cgia@cgia.loc.gov (Chuck Gialloreto)
To:        comp.protocols.tcp-ip
Subject:   HLLAPI TN3270 over Winsock

Does anyone know if TN3270 software exists, that is both Winsock-compatible
and can also handle HLLAPI commands from application software?

----------------------------------------------------------
Chuck Gialloreto                    Library of Congress
Senior Systems Analyst          Information Technology Services
cgia@cgia.loc.gov                  101 Independence Ave.  S.E.
      202-707-9745                  LM-G51
fax: 202-707-0955                  Washington, D.C.  20540
----------------------------------------------------------


-----------[000449][next][prev][last][first]----------------------------------------------------
Date:      22 Jun 1994 17:21:57 GMT
From:      simha@tekelec.com (Ajay Simha)
To:        comp.protocols.tcp-ip
Subject:   TCP/IP sources.

Hi Netters,

I am interested in getting a source for TCP/IP preferably free
(may be the 4.3BSD source).  I want to get some feed back from
anyone experienced in porting of TCP/IP.  Preferably something
which is easy to port.

Also is it possible to have a client/server situation where one end
is talking sockets and the other end is talking something else, say
TLI/STREAMS?


I am concerned about performance so issues may be:

1. BSD vs System V implementations.
2. Sockets vs Streams.
3. UNIX/DOS/EMBEDDED issues.
3. Any other pointers for someone doing a port job.

Please mail any responses to simha@tekelec.com.

Thanks,

-ajay


-----------[000450][next][prev][last][first]----------------------------------------------------
Date:      22 Jun 1994 17:30:49 GMT
From:      buck@hebron.connected.com (Todd Sweetser)
To:        comp.terminals,comp.protocols.tcp-ip,comp.os.ms-windows.networking.tcp-ip,bit.listserv.ibmtcp-l
Subject:   Re: IBM 3270 emulation using TCP?

In article <2u4q3h$mm8@gaia.ucs.orst.edu>, larsen@OES.ORST.EDU (Scott Larsen) says:
>In article <2tpu1q$aps@nwfocus.wa.com>,  <wadeware@halcyon.com> wrote:
>> I know nothing about 3270 emulation but that is seems way too complicated.
>> Our small network in Seattle wants to do 3270 emulation with a machine in
>> Dallas.
>> Question:  Using a leased line and routers, is there a way to achieve that
>> connection and emulation using TCP/IP rather than installing a 3270 controller
>> board in our server and connecting that way?  I use Chameleon TCP/IP for
>> Windows, and see that it has a 3270 emulator....that where I got this bright
>> idea....
>
>1) Your 3270 based host/mainframe must understand TCP/IP.  This can be
>        accomplished in many ways.  A common approach is to channel attach
>        a front end processor that connects a TCP/IP data stream to a
>        3270 data stream.
>
>2) You need a PC/MAC/Workstation/whatever application to emulate a 327X
>        terminal.  A winsock based 3270 program is available from
>        ftp.ccs.queensu.ca:pub/msdos/tcpip/qws3270.zip.  The Chameleon
>        327X emulator is a good one as well.  You have to pay quite a
>        bit for it though... :)
>

[snip]

Attachmate's Extra! for Windows supports TN3270 (TCP/IP) connectivity as well.  
 Notice you are in Seattle, so are we.  Give our sales dept a call @ 1 800 426 6283 
to get a Demo disk and more info.....

Our product supports Winsock 1.1 compliant stacks as well as many non-winsock
stacks ...

Enjoy!

Todd









-----------[000451][next][prev][last][first]----------------------------------------------------
Date:      22 Jun 1994 18:42:53 GMT
From:      jtalvy@cantor.com (James Talvy)
To:        comp.protocols.tcp-ip,comp.unix.programmer
Subject:   TCP programming problem


I am having a problem with a client-server app that I am developing.  The
problem is that I have a TCP connection between the two of them and the
program gets into a state that the server is blocked trying to write to the
client and the client turns off his computer.  As a consequence, the server
sits on the write() system call forever.  I want to know why the server is
not notified with an error return that the client has broken the connection.

I would greatly appreciate any help that anyone can give me.

(P.S. I have already tried SO_KEEPALIVE to no avail)

                                                James

__________________________________________________________________________
Don't Pay Attention To The Police Box Flying By


-----------[000452][next][prev][last][first]----------------------------------------------------
Date:      23 Jun 1994 01:31:58 -0400
From:      jhawk@panix.com (John Hawkinson)
To:        comp.protocols.tcp-ip,comp.dcom.servers
Subject:   Re: Authentification of users on dialup terminal servers

In <2u9cqm$f1r@sheckley.cnam.fr> bortz@cnam.cnam.fr (Stephane Bortzmeyer) writes:

This is crossposted to comp.dcom.servers, rather than c.p.t-i exclusively...

>I'm investigating the problem of access control for dialup SLIP/PPP terminal 
>servers like Cisco's 500CS, Livingston's PortMaster, Xylogics' Annex, etc.
>Since these machines are connected to the (unsecure) telephone network, 
>authentification of incoming users is a necessity.
 
>Most terminal servers can have a local user base. This solution has several 
>weaknesses:
>- doesn't work if you have several servers
>- doesn't allow you to reuse an existing base (/etc/passwd, Kerberos...)
 
>The general solution to this problem is to have an authentification server, 
>queried by the terminal server. You can then implement the politics you wish. 
>BUT:
 
>Livingston uses the Radius protocol (see the draft RFC in 
>ftp://ftp.netcom.com/pub/livingston/radius), Annex has a different system, 
>Access Control Protocol (ACP), quite similar in functionnalities, Cisco uses 
>another one, TACACS (described in RFC 1492) and the Telebit Netblazer yet 
>another one (based on the DNS).
 
>Livingston has released the specification and the code to try to make its 
>solution a standard (ACP seems proprietary, I'm not sure of the status of 
>TACACS code and the DNS used by Telebit is non-proprietary, but I don't 
>know the extent of modifications they made.)

I know that RADIUS is also supported by Ascend products (which also
support TACACS); I recall that while RADIUS seemed to me to be
more secure than TACACS and ACP (since it uses a shared secret
between the clients and servers), I was kind of unhappy with
Livingston's server side of things (just like TACACS I supposed),
rather because though it was functional and all, I thought that
the configs could have been designed in a better fashion. We probably
would have done some work on this, and it may indeed have changed
as this was around November of 1993 when I last looked at this,
but we ended up dropping the Livingston routers (due to problems
we had with their firmware and software), so this became a dead
issue.

I've found TACACS to be fairly rough around the edges, particularly on
the server side. I haven't yet evaluated the new tacacsd that someone
announced on comp.dcom.sys.cisco last week, so I can't comment on
that.

We're using Xylogics' ACP stuff for our SLIP/PPP user authentication
and we're happy with it, but we're not doing anything overly complex.

At some point, however, we'd like to figure out how to integrate this 
with s/key, if possible. I believe it supports SecureID out of the
box.

It would probably be a good idea to look at the NASREQ WG of the IETF
(Network Access Server Requirements). As of June 13th, this was the
summary of info about them (note they produced a RADIUS IETF draft):

Note that despite the lack of a listed archive, mail to the list
appears to be availble from ftp://merit.edu/pub/nas-req-archive.
I don't have time to go through it, but perhaps someone would
care to and summarize (or a member of the WG for that matter...).

---cut
Network Access Server Requirements (nasreq)
-------------------------------------------
 
 Charter 
 
 Current status: active working group
 
 Chair(s):
     Allan Rubens  <acr@merit.edu>
     John Vollbrecht  <jrv@merit.edu>
 
 Security Area Director(s) 
     Jeffrey Schiller  <jis@mit.edu>
 
 Mailing lists: 
     General Discussion:nas-req@merit.edu
     To Subscribe:      nas-req-request@merit.edu
     Archive:           
 
Description of Working Group:
 

The Network Access Server Requirements Working Group has as its primary
goal, to identify functions and services that should be present in IP
Network Access Servers (NASs) and to specify the standards that
provide for these functions and services.  The term ``Network Access
Server'' is used instead of the more conventional term ``Terminal Server''
as it more accurately describes the functions of interest to this
group.  A ``Network Access Server'' is a device that provides for the
attachment of both traditional ``dumb terminals'' and terminal emulators
as well as workstations, PCs or routers utilizing a serial line
framing protocol such as PPP or SLIP.  A NAS is viewed as a device that
sits on the boundary of an IP network, providing serial line points of
attachment to the network.  A NAS is not necessarily a separate
physical entity; for example, a host system supporting serial line
attachments is viewed as providing NAS functionality and should abide
by NAS requirements.

This group will adopt (or define, if need be) a set of standard
protocols to meet the needs of organizations providing network access.
The immediate needs to be addressed by the group are in the areas of
authentication, authorization, and accounting. In general, this
group will select a set of existing standards as requirements for a
NAS.  If necessary, the group will identify areas of need where
Internet standards do not already exist and new standardization efforts
may be required.

Initially the group will independently investigate the two cases of
character and frame-oriented access to the NAS.  This investigation
will be aimed at determining what work is being done, or needs to be
done, in this and other working groups in order to be able to define
the set of NAS requirements.  While the ultimate goal of this group is
to produce a NAS requirements document, it may be necessary to define
standards as well.  This initial investigation will help determine what
the goals of this group need to be.  The group will also work with
appropriate working groups to define required NAS standards that fall
into the areas of these other groups.


 Internet-Drafts:

Posted Revised       I-D Title  <Filename>
------ ------- ------------------------------------------
 Apr 94 Jun 94  <draft-ietf-nasreq-radius-01.txt> 
                Remote Authentication Dial In User Service (RADIUS)            
---cut

--
John Hawkinson
jhawk@panix.com

-----------[000453][next][prev][last][first]----------------------------------------------------
Date:      23 Jun 1994 01:36:35 -0400
From:      jhawk@panix.com (John Hawkinson)
To:        comp.protocols.tcp-ip
Subject:   Re: Looking for Whois Client

In <2u07em$k50@news.iastate.edu> john@iastate.edu (John Hascall) writes:

>It's really not much of a protocol -- with RFC in hand, you
>ought to be able to whip it out in under an hour (good 1st
>TCP/IP project, BTW):

With _no_ RFC in hand, you mean. There is NO whois protocol, it's
just like finger...

>pooh.cc> telnet rs.internic.net 43
>Trying 198.41.0.5...
>Connected to rs.internic.net.
>Escape character is '^]'.
>JH28<CR>
><EOT>
>Hascall, John (JH28)            john@IASTATE.EDU
>   :
>   :
>Connection closed by foreign host.

--
John Hawkinson
jhawk@panix.com

-----------[000454][next][prev][last][first]----------------------------------------------------
Date:      23 Jun 1994 04:00:57 -0500
From:      mweiss@nwk.cl.nec.co.jp (Michael J. Weiss)
To:        comp.os.ms-windows.networking.tcp-ip,comp.os.ms-windows.programmer.networks,comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject:   Quickest Way to Arrive at Source For Winsock TCP/IP DLL

As a starting point for some research I am doing, I am looking for a
Windows Sockets DLL with a TCP/IP stack written in C.  My work will
involve modifying this code to experiment with variants on the TCP/IP
protocol which support mobile a mobile computing environment.

I would greatly appreciate any advice you could offer as to how I
might reach this starting point in the easiest possible manner.

I just conferred with my supervisor and here is the latest potential plan.

I will ftp the linux source code, extract the functions that handle BSD
Sockets and TCP/IP.  Make the modifications necessary to port them to
an IBM PC as a DLL, and modify the DLL to be Windows Sockets compliant,
yielding a Windows Sockets compliant TCP/IP DLL.

I don't have a good feel for the degree and difficulty of the
modifications involved in porting the code to the PC environment or in
making it Windows Sockets compliant.

I could really use your input on its feasibility and degree of difficulty,
especially as it compares with other potential approaches.


Below, I have listed my investigation into this issue thus far.  

Thank you in advance for any ideas or suggestions you might have.

I was able to find only two public domain DLLs with source available.

NCSA Winsock is not acceptable because based on what its README file
says, it is not very close to being Windows Sockets Compliant.

TCPMaster is in C++, which poses a problem for me, and is still being
beta tested.

I have solicited a few smaller vendors  in an effort to negotiate the
purchase of a single copy of source code to be used for research
purposes only by a single person on a single project, but this is a
long shot.


So, the two most likely scenarios are that I write the code myself, in
which case I would appreciate references to whatever info would help
me: RFCs, books, etc.

The other scenario is that I borrow large parts of other people's
code.  I am especially interested in finding public domain software
from which I can extract the code necessary to assemble portion(s) of
my goal, especially the TCP/IP stack, as I want to avoid this time
consuming task.

I would be very interested in hearing your thoughts on how I might get
to my starting point in as hassle-free a way as possible.

Thanks for your help.

Sincerely,

Michael Weiss



-----------[000455][next][prev][last][first]----------------------------------------------------
Date:      Wed, 22 Jun 1994 19:57:53 GMT
From:      art@acc.com (Art Berggreen)
To:        comp.protocols.tcp-ip
Subject:   Re: 1 packet at a time

In article <1994Jun21.160811.66273@kuhub.cc.ukans.edu> anh@kuhub.cc.ukans.edu writes:
>Suppose I had 4000 bytes to send and I use one sendto(s,buf,4000,0,addr,sz), will
>buf be sent as one packet?

Depends on the destination, the local network MTU and the current state of the
TCP window (if using TCP).

>Is one sendto() call == 1 packet ? If not, is there a way to control the size of
>UDP and TCP packets at all?

In general sendto() will not always correspond to 1 packet.  UDP packets will
get fragmented into local interface MTU sized packets, if the originating UDP
packet is larger.  TCP will negotiate TCP segment sizes based on whether the
destination is local or not, and path MTU if MTU discovery is supported.
As a user, one typically has no control over this.

Art


-----------[000456][next][prev][last][first]----------------------------------------------------
Date:      Wed, 22 Jun 1994 20:12:33 GMT
From:      billr@audi.optimation.co.nz (Bill Ryder)
To:        comp.terminals,comp.protocols.tcp-ip,comp.os.ms-windows.networking.tcp-ip,bit.listserv.ibmtcp-l
Subject:   Re: IBM 3270 emulation using TCP?

In article <2u4q3h$mm8@gaia.ucs.orst.edu> larsen@OES.ORST.EDU (Scott Larsen) writes:

> In article <2tpu1q$aps@nwfocus.wa.com>,  <wadeware@halcyon.com> wrote:
> >
> > I know nothing about 3270 emulation but that is seems way too complicated.
> >
> > Our small network in Seattle wants to do 3270 emulation with a machine in
> > Dallas.
> >
> > Question:  Using a leased line and routers, is there a way to achieve that
> > connection and emulation using TCP/IP rather than installing a 3270 controller
> > board in our server and connecting that way?  I use Chameleon TCP/IP for
> > Windows, and see that it has a 3270 emulator....that where I got this bright
> > idea....
> 
> 1) Your 3270 based host/mainframe must understand TCP/IP.  This can be
> 	accomplished in many ways.  A common approach is to channel attach
> 	a front end processor that connects a TCP/IP data stream to a
> 	3270 data stream.

The other way (and the one we usually use since it is usually MUCH
cheaper) is to install a small Sun - SS5 usually nowadays - very cheap -
with an HSI or Token ring card depending on free connections on the
FEP and SNA 3270/RJE software. The connection between the Sun and FEP
is SDLC (for the serial line) or LLC (?) for the Token ring. The Sun
then provides a TN3270 server to which you can attach your favorite PC
3270 software which supports TN3270.

This works VERY well.

Bill

-----------[000457][next][prev][last][first]----------------------------------------------------
Date:      Wed, 22 Jun 1994 20:42:10 GMT
From:      donp@novell.com (don provan)
To:        comp.protocols.tcp-ip
Subject:   Re: ARP on non-Ethernet networks

In article <PPESSI.94Jun22183505@lk-hp-19.hut.fi> <Pekka.Pessi@hut.fi> writes:
>	What is the common practice in implementing the ARP on other than
>	Ethernet hardware, e.g. Arcnet?
>...
>	Is it common to use the Arcnet IP type (240) instead of the Ethernet
>	IP type (2048, as required by RFC1340)?  Should the ARP
>	implementation in Arcnet accept both protocol types (or three of
>	them ;)?

The assigned numbers RFC takes precedence: always use the ethernet
protocol type in the ar$pro field of ARP packets, even when
transmitted the packets on Arcnet. The text to the contrary in RFC-826
can be considered obsolete.

						don provan
						donp@novell.com

-----------[000458][next][prev][last][first]----------------------------------------------------
Date:      Wed, 22 Jun 1994 20:58:06 GMT
From:      vjs@calcite.rhyolite.com (Vernon Schryver)
To:        comp.protocols.ppp,comp.protocols.tcp-ip
Subject:   Re: How _should_ FTP react when a PPP link dies

In article <Crszrw.A4I@cs.dal.ca> gauthier@ug.cs.dal.ca (Paul Gauthier) writes:
>
>Scenario: An FTP file transfer is occuring between two machines
>(a Windows NT machine and some sort of UNIX box) which are
>connected via a PPP link. The link is broken for some length of
>time (aribitrarily long) and then reconnected.
>
>Is there a well defined behavior for the FTP program, which it
>should exhibit?
>Will it:
>   a) Kill the file transfer as soon as the PPP link dies
>   b) Timeout after a while and kill the file transfer
>   c) Just hang until the PPP link comes back up, and then resume
>      where it left off

In general, in good systems, (b) or (c) depending on how long the
PPP link is dead and assuming the link comes up with the identical
IP addresses.

>What if the PPP link goes down not because of a modem going offline,
>but rather at the behest of the system administrator? Is there a
>defined behavior in this case, and is it different?

Unless the FTP client or server processes are terminated, or unless
routing is messed by the system administrator, no, there is no difference.

> ...
>If it will just hang and wait for the link to come back up and then
>continue that would be wonderful. But if PPP link death propogates
>a signal up the protocol stack letting everyone know its dead
>causing the FTP client or server to abort, or if the transfer will
>time out and abort, then this is not a viable solution. Any other
>ideas?

It is possible that while the link is kaput, either the FTP server or
client process or TCP protocol stacks might get host- or
network-unreachable indications, and that might cause either to kill
the TCP connection or the FTP transfer.  This is universally agreed
to be undesirable.


Vernon Schryver    vjs@rhyolite.com

-----------[000459][next][prev][last][first]----------------------------------------------------
Date:      22 Jun 1994 21:46:54 GMT
From:      Elliot_Jolesch@qmgate.cc.oberlin.edu (Elliot Jolesch)
To:        comp.protocols.tcp-ip
Subject:   Strange Telnet happenings

I have a TELNET situation I can't explain.  If someone on the net can
explain I would appreciate it.

Here is the situation.  

We have an Alpha PC running OSF on the network.  It is listed in our
nameserver.  We can TELNET to it from several computers on campus, (we
haven't tried all, but a good selection) including Macs, PCs, and
terminals.  

I have a Zenith PC 486/66 that cannot TELNET to the Alpha PC.  IT CAN 
TELNET to any other computer on campus!!  When we attempt to TELNET to
the Alpha the Zenith locks up.  It is running DOS 6.2 running 
Wollongong Pathway Access 2.0.  I can ping the Alpha from the Zenith
and that works, but I cannot TELNET....The PC hangs when I try and
I have to reboot it.  THIS ONLY HAPPENS WHEN TELNETTING TO THE ALPHA
PC.

Any ideas from any one will be greatly appreciated.

Elliot

========================================================================
====
Elliot C. Jolesch                 Elliot_Jolesch@qmgate.cc.oberlin.edu
Data Communications Manager              celliot@ocvaxa.cs.oberlin.edu 
  
Oberlin College                                 office: (216) 775-6930
Oberlin, OH

-----------[000460][next][prev][last][first]----------------------------------------------------
Date:      Thu, 23 Jun 94 10:00:33 -0700 (PDT)
From:      KCARPENT@mindlink.bc.ca (Ken Carpenter)
To:        comp.protocols.tcp-ip
Subject:   Re: socket <==> tli

In article <2uc7sv$232@getty.tekelec.com>, simha@tekelec.com (Ajay Simha)
writes:
>
> Msg-ID: <2uc7sv$232@getty.tekelec.com>
> Posted: 23 Jun 1994 14:57:35 GMT
>
> Org.  : Tekelec Inc.
>
> Hi Netters,
>
> Does anyone have experience with Client/Server situation where
> one is using TLI and the other is using Sockets?
>
> The reason I am asking is because I am involved in a port and
> may need to decide which interface I should provide if I had
> a choice.
>
> -ajay (simha@tekelec.com)
>


Well, it should not make any difference whether you use TLI or Sockets.
Both are just interface API's to the Transport Layer.  They do not add to,
or change the format of outgoing or incoming packets.  So a TLI server can
talk with a Sockets client.

It is really a matter of personal preference, and perhaps your companies
planned directions.  If you are heading towards OSI standards, TLI is the
choice.  If you are planning to stick with Internet standards, then Sockets
is probably a better choice.

BTW: I am also implementing a client/server system for our embedded systems
environment, and I am planning to use Sockets for the Transport interface.

Hope this helps.


Ken Carpenter
Network Group
Software Research & Development
Delta Controls Inc.

-----------[000461][next][prev][last][first]----------------------------------------------------
Date:      Wed, 22 Jun 1994 23:00:07 GMT
From:      bbosen@netcom.com (Bob Bosen)
To:        comp.protocols.tcp-ip
Subject:   Re: Authentification of users on dialup terminal servers

Stephane Bortzmeyer (bortz@cnam.cnam.fr) wrote:
: I'm investigating the problem of access control for dialup SLIP/PPP terminal 
: servers like Cisco's 500CS, Livingston's PortMaster, Xylogics' Annex, etc.
: Since these machines are connected to the (unsecure) telephone network, 
: authentification of incoming users is a necessity.

Me too.

: Most terminal servers can have a local user base. This solution has several 
: weaknesses:
: - doesn't work if you have several servers
: - doesn't allow you to reuse an existing base (/etc/passwd, Kerberos...)
 
: The general solution to this problem is to have an authentification server, 
: queried by the terminal server. You can then implement the politics you wish. 
: BUT:
 
: Livingston uses the Radius protocol (see the draft RFC in 
: ftp://ftp.netcom.com/pub/livingston/radius), Annex has a different system, 
: Access Control Protocol (ACP), quite similar in functionnalities, Cisco uses 
: another one, TACACS (described in RFC 1492) and the Telebit Netblazer yet 
: another one (based on the DNS).

These protocols are generally undergoing transitions, too. Advanced
features like truly non-replayable challenge/response authentication
have been recently added to draft versions of TACACS and Radius.
Perhaps to others as well. It's still a moving target.


: Livingston has released the specification and the code to try to make its 
: solution a standard (ACP seems proprietary, I'm not sure of the status of 
: TACACS code and the DNS used by Telebit is non-proprietary, but I don't 
: know the extent of modifications they made.)

Cisco has also released specifications and source code for TACACS.
Other independent software efforts have also resulted in release of
TACACS source code. Cisco remains a good contact for this stuff, as
it tends to migrate back to Cisco eventually....


: Does anyone know what are the opinions of the other vendors? Did they 
: announce any joint effort to make a standard? How did they react to 
: Livingston's initiative?

My company, Enigma Logic, manufactures authentication servers. We
have published an API that has been stable for several years now.
We have interfaced that API with TACACS and Radius, and we are most
anxious to interface with other popular access protocols. The world
would certainly be a nicer place if there was just _one_ such
standard, but so far that hasn't happenned.


: (A standard would be useful for people with network access servers from 
: different manufacturers but also for those who write extensions of 
: authentification servers, so they could distribute them more widely.)

Amen.


: Did anyone study in deep the different protocols? Radius seems 
: simpler and more powerful to me, also more secure since passwords 
: are not send as clear text, but there are may be other facts I'm not 
: aware of.

IMHO TACACS is simpler.


: How does the different protocols compare when examining:
: - security (how are passwords transmitted?)
Since our API assures non replayability (of authentication data
at least) and we encapsulate everything within our API and then
just transport it via these protocols, this was somewhat less
an issue for me.


: - openess (are the specifications public?)
WRT to TACACS and Radius, yes, both specifications seem to be
equally public and open.


: - availability of good implementations, with extensions like SecurID or

SafeWord is available for TACACS and Radius. We intend to support
others as they emerge with market influence.

(To see SafeWord and TACACS working together, you might want to
take a look at our anonymous ftp archive site. Just ftp to:

ftp.netcom.com

Then cd to:

/pub/bbosen/Enigma

and have a look around. Pay special attention to the various "read.me"
files in subdirectories.

From the tone of this posting, it sounds like you might be especially
interested in the animated tutorials for your VGA-equipped PC at:

/pub/bbosen/Enigma/Tutorials/VGA/Grasp/Cisco

and

/pub/bbosen/Enigma/Tutorials/VGA/Grasp/API

and

/pub/bbosen/Enigma/Tutorials/VGA/Grasp/Firewall


To see source code interfacing our published API with Cisco's
published TACACS server code, take a look at:

/pub/bbosen/Enigma/Cisco

Our Radius interface is in beta test right now. When it is fully
tested, I intend to make that source code available too, so
anybody with SafeWord running on any of several platforms can
secure an entire internet from a central location via combinations
of TACACS, Radius, native SafeWord, and SafeWord API customization
of individual applications. Since we support lots of different
ways to authenticate users, this allows quite a bit of unification
of an otherwise very ugly problem.



: clear source code to implement your own modifications
: - etc, etc


I _hope_ ours is pretty clear. We welcome your examination....



: Stephane Bortzmeyer           Conservatoire National des Arts et Metiers	
: bortzmeyer@cnam.fr            Laboratoire d'Informatique
:                               292, rue Saint-Martin			
: tel: +33 (1) 40 27 27 31      75141 Paris Cedex 03
: fax: +33 (1) 40 27 27 72      France	
 
: "C'est la nuit qu'il est beau de croire a la lumiere." E. Rostand
 
: http://web.cnam.fr/personnes/bortzmeyer/home_page.dom

Regards,

Bob Bosen

-- 

Bob Bosen
Enigma Logic Inc.
2151 Salvio St. #301
Concord, CA   94520
USA

Tel: +1 510 827-5707
Internet: bbosen@netcom.com
**************************************************************************
* "It wasn't me!!! Somebody must have captured my username/password!!!"  *
**************************************************************************

-----------[000462][next][prev][last][first]----------------------------------------------------
Date:      Wed, 22 Jun 1994 23:18:47 GMT
From:      larry@lia.com ((Larry Barnett x5474)~ABCDEFGHIJLMNOPQRSTUVWXYZ#HBI7695474)
To:        comp.protocols.tcp-ip,comp.software-eng,comp.sys.mac.programmer
Subject:   ONC RPCs for the Mac yet?

Almost two years ago, I posted a request for information
about ONC Remote Procedure Call implemenations available
on the Mac.  At that time, the only thing available was
a package called RPCTool by Netwise of Boulder, CO.  RPCtool
had the disadvantage that it was unable
to communicate with ONC RPC machines (i.e., you had to
run the Netwise software on your server too).

Has the situation changed since then?  I don't want to
buy RPCtool for every machine on my network.  Is RPCtool
compatible with ANY standard RPC implementation (DCE perhaps)?
Is anyone else in the game?  Thanks in advance for any light you
can shine my way.  I will post a summary if it seems
warranted.

Regards to all,

Larry Barnett

-----------[000463][next][prev][last][first]----------------------------------------------------
Date:      Thu, 23 Jun 1994 00:12:13 GMT
From:      atkinson@sundance.itd.nrl.navy.mil (Ran Atkinson)
To:        comp.sys.sun.admin,comp.protocols.tcp-ip
Subject:   Re: RIP and very large internal internet

In article <1994Jun21.202248.13573@knight.vf.ge.com> doug@vf.ge.com writes:
>
>We have a huge internal internet and are seeing strange symptoms.
>Has anybody seen problems with Sun workstations (running any version
>of SunOS) losing routes randomly in large internets?  We seem
>to be experiencing this even though we can see the routes being
>advertised by the routers (using a sniffer, and a nit/dlpi custom
>tool).  Sometimes the sun will pick up the route, sometimes it won't.
>I cannot say whether it is sun specific or not, but the majority
>of our systems are sun workstations currently.

  What you describe is highly unlikely to be a Sun problem.  In all
liklihood (based on the sketchy information provided) you are seeing
the well-understood slow convergence problems often seen when using
RIP on a large network. [Perlman92, pp.265-268 for more information].
The real answer is very likely to be migration away from RIP and
towards OSPFv2.

>  The number of routes is approximately 1500.  (admittedly, we
>should be using something other than RIP, but because of the nature
>of the network (subnetted class A on 255.255.252.0) and the diversity
>of hosts (Mac, PC (many different protocol stacks), Sun, HP, Vax,
>decstation... etc.. etc..) it is a prodigious undertaking to change.

There are some simple steps that can be undertaken incrementally to
start moving you away from RIP.  Some specific suggestions:

1) Configure all workstations with a default router (e.g. on SunOS 4.1.x,
  one creates a file /etc/defaultrouter that contains the IP address 
  of the default router for that workstation) or (better) configure 
  them to use ICMP Router Discovery (should work with modern routers,
  Solaris 2, and modern versions of SGI IRIX).  Macs will let you
  configure a default router using the MacTCP control panel.  I don't
  have any HPs or DECs handy, but I am pretty sure there is at least
  a way to configure a default router.

2) Once you've done (1) then ensure that the workstations do NOT run
   routed(8) or gated(8).  No single interface workstation should ever
   need to run a routing daemon.  Only run a routing daemon on a workstation
   if it has multiple interfaces AND you _intend_ for that workstation to
   be the router between the two connected networks.  If you have a choice,
   run OSPFv2 using gated(8).  You can get sources to gated(8) from
   ftp://gated.cornell.edu if you don't have it already.

3) Plan a move to OSPFv2 for interior routing and BGPv3 or BGPv4 for
   exterior routing.  In the pre-M&M days, you all were on net 3 and it
   was isolated from the rest of the world except at CR&D and at a couple
   of other sites.  If that is still so, only the externally connected
   sites need to worry about BGP.  OSPFv2 is implemented in gated(8) and
   is available now from all major router vendors (e.g. Cisco, Wellfleet, 
   Proteon).  OSPF is a link-state protocol rather than a distance-vector
   protocol and so converges faster and generally performs better than
   RIP, particularly in a large network.

4) Implement your OSPF migration plan.  Start with a few subnets that
   are nearby the support gang.  Once those are configured properly and
   the support gang are more familiar with OSPF configuration in routers
   and how to configure either a default router or ICMP Router Discovery,
   expand outwards and migrate more and more subnets over to OSPFv2.
   
  Sorry for the grim news, but you all are in a very deep hole and
digging out won't be easy, though it is certainly possible to do.

Ran
atkinson@itd.nrl.navy.mil

Radia Perlman, "INTERCONNECTIONS", Addison-Wesley, Reading, Mass, 1992.
ISBN = 0-201-56332-0.  Recommended for folks interested in routing.

-----------[000464][next][prev][last][first]----------------------------------------------------
Date:      23 Jun 1994 00:19:26 GMT
From:      mgleason@cse.unl.edu (Mike Gleason)
To:        comp.protocols.ppp,comp.protocols.tcp-ip
Subject:   Re: How _should_ FTP react when a PPP link dies

gauthier@ug.cs.dal.ca (Paul Gauthier) writes:

|The whole point of this disucssion, in case anyone cares, is to
|find a good way to restart an FTP file transfer without having
|to resend data which was already received by the other side.

If that's all you want to do then have a look at this from RFC 959:

  RESTART (REST)
		  
       The argument field represents the server marker at which file transfer
       is to be restarted. This command does not cause file transfer but
       skips over the file to the specified data checkpoint. This command
       shall be immediately followed by the appropriate FTP service command
       which shall cause file transfer to resume.

It's not too difficult to do, although the current version of ncftp doesn't
support it.  (I'm working on a rewrite, and don't want to add anything,
since I'd have to redo it for the new version.)

--
--mg                                        Mike Gleason <mgleason@cse.unl.edu>

-----------[000465][next][prev][last][first]----------------------------------------------------
Date:      23 Jun 1994 07:11:13 -0400
From:      alexis@panix.com (Alexis Rosen)
To:        comp.protocols.tcp-ip,comp.dcom.servers
Subject:   Re: Authentification of users on dialup terminal servers

jhawk@panix.com (John Hawkinson) writes:
>bortz@cnam.cnam.fr (Stephane Bortzmeyer) writes:
 
>>I'm investigating the problem of access control for dialup SLIP/PPP terminal 
>>servers like Cisco's 500CS, Livingston's PortMaster, Xylogics' Annex, etc.
 [...]
>>Most terminal servers can have a local user base. This solution has several 
>>weaknesses:
>>- doesn't work if you have several servers
>>- doesn't allow you to reuse an existing base (/etc/passwd, Kerberos...)

They can also encourage sloppy security by replicating passwords, etc.

[...]
>>Livingston uses the Radius protocol (see the draft RFC in 
>>ftp://ftp.netcom.com/pub/livingston/radius), Annex has a different system, 
>>Access Control Protocol (ACP), quite similar in functionnalities, Cisco uses 
>>another one, TACACS (described in RFC 1492) and the Telebit Netblazer yet 
>>another one (based on the DNS).

Actually, ACP is vastly more capable than RADIUS. I think it's also more
capable than TACACS, but I can't even remember what TACACS stands for exactly,
so don't take my word for it... :-)

Before some recent changes, there were a few extremely serious problems with
ACP. They generally involved one major idea: doing per-user command execution.
You can do this, for example, on a NetBlazer.

Fortunately, Xylogics recently added some new code to the ACP stuff and
you can now do anything you like with ACP- you can completely take over the
terminal server from it.

(It also appears that they've added an FTP server to the machine. Neat. It's
amazing what you learn by reading source. :-)

[...]

>I know that RADIUS is also supported by Ascend products (which also
>support TACACS); I recall that while RADIUS seemed to me to be
>more secure than TACACS and ACP (since it uses a shared secret
>between the clients and servers),

ACP doesn't? What's ACP_KEYS then?

> I was kind of unhappy with
>Livingston's server side of things (just like TACACS I supposed),
>rather because though it was functional and all, I thought that
>the configs could have been designed in a better fashion. We probably
>would have done some work on this, and it may indeed have changed
>as this was around November of 1993 when I last looked at this,
>but we ended up dropping the Livingston routers (due to problems
>we had with their firmware and software), so this became a dead
>issue.

[...]
>We're using Xylogics' ACP stuff for our SLIP/PPP user authentication
>and we're happy with it, but we're not doing anything overly complex.

I did the mods (which were actually few) and it worked well. The code is
pretty clean and not too difficult to follow, and there's lots of commenting
in the code, along with a dozen pages or more in the manual.

Now that the ability to generate random commands on a per-user basis exists,
I'm _really_ happy with it. It finally does what I wanted to do back when I
ditched the NetBlazer in Summer of '92. :-) (To be fair, it's had other
benefits in the meantime...)

One small problem- while the code is good, doing this sort of thing shouldn't
require code to be written. I think Xylogics will produce another data table
that gets read automatically by ACP, which doea this command-per-user thing
correctly. They probably just haven't had time to do this yet- the feature
is very new.

>At some point, however, we'd like to figure out how to integrate this 
>with s/key, if possible. I believe it supports SecureID out of the
>box.

That's actually easy, now. And it _does_ support SecureID as you say.

[Discussion of IETF drafts on NASes deleted]

---
Alexis Rosen   Owner/Sysadmin,
PANIX Public Access Unix & Internet, NYC.
alexis@panix.com

-----------[000466][next][prev][last][first]----------------------------------------------------
Date:      Thu, 23 Jun 1994 03:00:38 GMT
From:      dan@dpcsys.com (Dan Busarow)
To:        comp.protocols.tcp-ip,comp.software-eng,comp.sys.mac.programmer
Subject:   Re: ONC RPCs for the Mac yet?

(Larry Barnett x5474)~ABCDEFGHIJLMNOPQRSTUVWXYZ#HBI7695474 (larry@lia.com) wrote:
> Has the situation changed since then?  I don't want to
> buy RPCtool for every machine on my network.  Is RPCtool
> compatible with ANY standard RPC implementation (DCE perhaps)?

Not that I am aware of.

> Is anyone else in the game? 

Check out EZ-RPC from Noblenet.  I'm not sure if they have a Mac
port yet but I remember them saying it was in the works a few
months ago.

sales@noblenet.com

BTW, the code EZ-RPC generates is not only ONC it is readable.
One of the selling points they mention is that you can study
the generated code in order to understand RPC programming
better.

We're not even a customer, I just had an eval and was very impressed.
Ended up writing our RPCs by hand.

Dan
-- 
   Dan Busarow               dan@dpcsys.com                 uunet!cedb!dan
   DPC SYSTEMS                Monrovia, CA                  (818) 305-5733

-----------[000467][next][prev][last][first]----------------------------------------------------
Date:      Thu, 23 Jun 94 08:30:10 EST
From:      stein@gcomm.com
To:        comp.protocols.tcp-ip
Subject:   TCP/IP Software on MS-DOS


IS>Is there any public domain software which implements
IS>TCP/IP over NDIS driver in MS-DOS?

A good place to start might be to FTP into ftp.cac.psu.edu, change to
the /pub/dos/info directory and get tcpip.packages, a review of TCP/IP
packages for DOS.  I found out about this information in InfoWorld 5/94
I think.

-- Bob Stein, Galacticomm Inc.

-----------[000468][next][prev][last][first]----------------------------------------------------
Date:      Thu, 23 Jun 1994 05:30:51 GMT
From:      johns@rd.scitec.com.au (John Saunders)
To:        comp.protocols.tcp-ip
Subject:   Re: need ammo to use against bone-headed administrator

In article <2ua8o8$629@panix2.panix.com>, Phil Hoff (phoff@panix.com) did sayeth:
> >>> Help!
> >>> I've got a admin guy on one of my subnets that insists that he
> >>> has 4 subnets available when he uses a subnet mask of 255.255.255.192
> >>> I've explained/agrued with him until I'm blue in the face. Can anybody
> >>> give me the RFC that spells this out in black and white? I need to
> >>> beat him over the head with a RFC for a while.
 
> Merrill Lynch has about 2-3000 sun workstations, the corporate standard is a
> subnet mask of 255.255.255.192. We divide the last octet into 4 subnets.

I also beleive that 4 subnets are available. I think the limitation is in the
host part of the address i.e. you have 2 less than 64 host addresses available
because a host address of all 0's is the network and a host address of all 1's
is a broadcast. However for a subnet these extra bits are effectively part of
the network and and there is nothing special about 2 out of 26 bits being all
0's or all 1's. All 26 bits have to be all 0's or all 1's before the address
becomes special and should not be used.

P.S. The ideas above don't come from any RFC and can state off hand, just from
experience at setting up IP networks and writing some routing code.
-- 
+----------------------------------------------------------------------------+
| John SAUNDERS - AARnet johns@rd.scitec.com.au - #include <stddisclaimer.h> |
| SCITEC Communication Systems - Phone +61 2 428 9541 - Fax +61 2 418 6954   |
+----------------------------------------------------------------------------+

-----------[000469][next][prev][last][first]----------------------------------------------------
Date:      Thu, 23 Jun 1994 06:11:05 GMT
From:      albert@dn.itg.telecom.com.au (Albert Fu)
To:        comp.protocols.tcp-ip
Subject:   TCP retransmit mechanism

Should a TCP packet be re-transmitted using a fixed timeout?

I looked at a problem a while ago where a particular packet
did not get to the destination, and the sending host was 
retransmitting the packet using fixed timeout (nearly). 

The example on Page 41 of the TCP spec (RFC793), 

          RTO=min[UBOUND,max[LBOUND,(BETA*SRTT)]

shows that the timeout is fairly constant if the round trip 
delay does not vary much. The book by Douglas Comer on
"Internetworking with TCPIP") (Section 12.18 Karn's algorithm) 
indicates that the timeout is not fixed but increases with 
every re-transmit (new_timeout = gamma * timeout). 

Could someone please kindly explain how the timeout should
work. 

Thanks in anticipation.

Albert Fu
Telecom Australia
albert@netboss.dn.itg.telecom.com.au

-----------[000470][next][prev][last][first]----------------------------------------------------
Date:      22 Jun 1994 17:25:46 +0800
From:      snm@dublin.dcd.wa.gov.au (Sun Net Manager)
To:        comp.protocols.tcp-ip
Subject:   Dynamic BOOTP Server ?

Hi All

We have a bootp server NLM running on our novell server which dynamically
allocates IP addresses from a specified range.  The first time a client PC
puts out a Bootp request, the server gives that client the next free IP
address and notes the allocation in a host table for future reference.

This works really well, so I am now looking for a similar product for
use under Unix.  There are several bootp servers availanle, but they all
use static bootp tables.

So - does anyone know of source for a dynamic bootp server ?

Thanks

Jimm

-----------[000471][next][prev][last][first]----------------------------------------------------
Date:      Thu, 23 Jun 1994 09:41:21 GMT
From:      marten@ripe.net (Marten Terpstra)
To:        comp.protocols.tcp-ip
Subject:   Re: Looking for Whois Client

In <2ub713$8al@panix.com> jhawk@panix.com (John Hawkinson) writes:

>In <2u07em$k50@news.iastate.edu> john@iastate.edu (John Hascall) writes:
 
>>It's really not much of a protocol -- with RFC in hand, you
>>ought to be able to whip it out in under an hour (good 1st
>>TCP/IP project, BTW):
 
>With _no_ RFC in hand, you mean. There is NO whois protocol, it's
>just like finger...

Wrong:

--
Network Working Group                               K. Harrenstien (SRI)
Request for Comments: 954                                 M. Stahl (SRI)
Obsoletes:  RFC 812                                     E. Feinler (SRI)
                                                            October 1985

                             NICNAME/WHOIS


STATUS OF THIS MEMO

   This RFC is the official specification of the NICNAME/WHOIS protocol.
   This memo describes the protocol and the service.  This is an update
   of RFC 812.  Distribution of this memo is unlimited.
[etc]

-----

It does not say much, but still .....

-Marten

-----------[000472][next][prev][last][first]----------------------------------------------------
Date:      23 Jun 94 15:17:59
From:      zhao@crl.nmsu.edu (Z. Zhao)
To:        comp.protocols.tcp-ip.ibmpc,comp.sys.sun.admin,comp.dcom.modems,comp.protocols.ppp,comp.protocols.tcp-ip
Subject:   Cslip-2.7 & Trumpet-tcpman, are they friends?

I have installed cslip-2.7 on a sparc10/sunos4.1.3. I tried to use
trumpet-tcpman/slip to dial-slip-login the sparc. So far, I have got
no success. 

1. I put the phone # in login.cmd, when I start tcpman, it olny
   initializes the modem and noise, but doesn't really dial. I have to
   use "manual login" in the Dialler options.

2. After the 'login:' showing up, I tried login as user Slipper. But,
   the login will fail instantly. The signal says:
   	sliplogin: .... exit 1, login failed.

It seems I don't get the correct configuration on ether Cslip server
or tcpman-slip client, maybe both. If you have a similar system, or
similar experience, or know the secret to the success, please help me.

BTW, I am using a ZyXEL 1496+ modem on the sparc, ATT dataport 14.4 on
a pc. There is no problem for me to dialin from pc to sparc and tip out
(old tip or new tip coming with cslip-2.7) from sparc to anywhere.
But, for slip, where is the problem?


Regards,

ZiZi

-----------[000473][next][prev][last][first]----------------------------------------------------
Date:      23 Jun 1994 17:01:30 -0400
From:      brain@msen.com (Jim Brain)
To:        comp.protocols.tcp-ip,comp.protocols.ibm
Subject:   Problems with IBM OS/2 TCP/IP implementation

Aaaarrrggghhh, I am at my wits end.

I am trying to use IBM TCP/IP for OS/2.  Here is the deal.

I do the connection of the socket between process fine, but the sends are
skeweed.  I send 108 byte packet 5 times , but I receive one packet with
5*108 bytes in it.  I am using stream sockets with default bahavior.

I thought maybe I was misunderstanding stream, but a friend has the exact
same code running correctly.  Can anyone explain this problem????
I see a workaround in flushing the buffer after every send, but I can't
figure out how to do this.


--			      
Jim Brain, Embedded Systems Designer, Brain Innovations.
brain@msen.com  
Dabbling in VR, Old Commodore Computers, and Good Times!
"The above views DO reflect my employer, since I am my employer" - Jim Brain


-----------[000474][next][prev][last][first]----------------------------------------------------
Date:      23 Jun 94 11:41:06 GMT
From:      sej@flowbee.interaccess.com (Stephen Johnson)
To:        comp.protocols.tcp-ip
Subject:   Re: need ammo to use against bone-headed administrator

johns@rd.scitec.com.au (John Saunders) writes:

>In article <2ua8o8$629@panix2.panix.com>, Phil Hoff (phoff@panix.com) did sayeth:
>> >>> Help!
>> >>> I've got a admin guy on one of my subnets that insists that he
>> >>> has 4 subnets available when he uses a subnet mask of 255.255.255.192
>> >>> I've explained/agrued with him until I'm blue in the face. Can anybody
>> >>> give me the RFC that spells this out in black and white? I need to
>> >>> beat him over the head with a RFC for a while.
 
>> Merrill Lynch has about 2-3000 sun workstations, the corporate standard is a
>> subnet mask of 255.255.255.192. We divide the last octet into 4 subnets.
 
>I also beleive that 4 subnets are available. I think the limitation is in the
>host part of the address i.e. you have 2 less than 64 host addresses available
>because a host address of all 0's is the network and a host address of all 1's
>is a broadcast. However for a subnet these extra bits are effectively part of
>the network and and there is nothing special about 2 out of 26 bits being all
>0's or all 1's. All 26 bits have to be all 0's or all 1's before the address
>becomes special and should not be used.
 
>P.S. The ideas above don't come from any RFC and can state off hand, just from
>experience at setting up IP networks and writing some routing code.
>-- 

This information is gleened from several replies to my original post.
According to RFC 950 [Internet Standard Subnetting Procedure] and 
RFC 1122 [Requirements for Internet Hosts -- Communication layers]
subnet fields values of all zero bits or all ones bits are special
values and should not be used for actual subnets. A subnet field of
2 bits (255.255.255.192) has only 2 legal values according to these
RFC's.  I expect that the results of violating these standards are
implementation dependant, your mileage may vary (to quote Peter
Mockapetris).

-----------[000475][next][prev][last][first]----------------------------------------------------
Date:      Thu, 23 Jun 1994 12:31:46 GMT
From:      fenner@cmf.nrl.navy.mil (William C. Fenner)
To:        comp.protocols.tcp-ip
Subject:   Re: RIP and very large internal internet

In article <CrtpwD.21M@ra.nrl.navy.mil>,
Ran Atkinson <atkinson@sundance.itd.nrl.navy.mil> wrote:
>2) ... Only run a routing daemon on a workstation
>   if it has multiple interfaces AND you _intend_ for that workstation to
>   be the router between the two connected networks.

Depending on how complex your routing topology is, if a workstation has
multiple interfaces than it wants to at least listen to the routing
exchange.  We have several dual-homed hosts that would use much less
efficient routes if they weren't listening to the RIP exchanges and were
just using a default route.

  Bill
-- 
Bill Fenner                  fenner@cmf.nrl.navy.mil

-----------[000476][next][prev][last][first]----------------------------------------------------
Date:      23 Jun 1994 12:35:52 GMT
From:      lowsan@eng.umd.edu (Ching-Tien Tsai)
To:        comp.protocols.tcp-ip
Subject:   MBONE question, need help

Hi, 

I am new to MBONE and try to create a tunnel between two LANs, but have some
problems. My configuration is as follow:

1. I use SUN Sparcstation 10 running SunOS 5.2 as the "mrouted" machine at
   both LANs. I did not do any kernel modification.

2. The /etc/mrouted program is ftped from ftp.uoregon.edu under
   /pub/Solaris2.x/src/MBONE/Solaris2.x/binaries/mrouted 
   It is dated Apr. 26, 1994 with the size of 224184 bytes.

3. The contents of /etc/mrouted.conf are,

   tunnel 155.201.31.59 155.201.48.23 metric 1   # for 155.201.31.59 machine

   and 

   tunnel 155.201.48.23 155.201.31.59 metric 1   # for 155.201.48.23 machine

4. After I started the "mrouted" daemon and "sd" program on both machines, I
   tried to create a new session from one machine through "sd", but found the
   "sd" running on the machine at the other LAN did not receive this new 
   session message.

   I did try to broadcast to site, region, and world, but none of them worked.
   However, the other machines running "sd" at the same LAN did receive those
   new session message. And "mrouted" daemon was running at both "mrouted"
   machines. 

   Is there any good soul out there can tell me what is wrong? Thanks a lot!!  

   
Ching






-----------[000477][next][prev][last][first]----------------------------------------------------
Date:      23 Jun 1994 12:41:35 GMT
From:      simha@tekelec.com (Ajay Simha)
To:        comp.protocols.tcp-ip
Subject:   Re: Question on tcp protocol

In article <2tkcs7$rgu@news.tamu.edu> anilg@cs.tamu.edu (Anil Kumar Reddy Gurijala) writes:
>Hi folks,
>	 Under what circumstances a tcp layer packs two different data segments
>	 from upperlayer into a single packet? i.e. if I use send(a) and send(b)
>	 in two different instructions, is it possible that tcp layer packs both
>	 of them in a single packets and sends them to remote host?
>
>anil gurijala
>anilg@cs.tamu.edu

I was wondering if it possible to achieve this by setting the send buffer
size to the appropriate length using setsockopt().

-ajay



-----------[000478][next][prev][last][first]----------------------------------------------------
Date:      23 Jun 1994 13:20:09 GMT
From:      meyer@frostbite-falls.uoregon.edu (David M. Meyer 503/346-1747)
To:        comp.protocols.tcp-ip
Subject:   Re: MBONE question, need help


	Ching,

	One problem is that Solaris 2.2 (aka SunOS 5.2) only
	supports source-route encapsulation (tunnels). What you
	need is Erik Nordmark's modified /dev/kernel/ip (to do
	encapsulated tunnels) or upgrade to 2.3 (which I
	advise). This will be a problem when trying to talk to
	the outside world. From the README on   

	ftp.uoregon.edu:/pub/Solaris2.x/src/MBONE/Solaris2.x/Kernel/README


#
#       README
#
#       David M. Meyer 503/346-1747
#       meyer@cambium.uoregon.edu
#       Sun Nov 14 10:40:35 1993
#
#       $Header: $
#



        Note: The ip module here (ip, which goes in
        /dev/kernel/ip) is only needed for Solaris 2.2. Solaris 
        2.3 suports encapsulated tunnels as distributed.



	Good luck,


	Dave

-----------[000479][next][prev][last][first]----------------------------------------------------
Date:      Thu, 23 Jun 1994 13:33:02 GMT
From:      swel@bluecross.on.ca (Steve Welsh)
To:        comp.protocols.tcp-ip
Subject:   TN3270

I am looking for TN3270 s/w that will give me mod 4 emulation
while running in DOS. I have had no problem getting this
emulation in windows, but the emulators I've tested in DOS
only provide MOD 2 emulation, specifically FTP and Wollongong
tcp/ip s/w.

Any help would be greatly appreciated.

Thanks

Steve

-- 
Steve Welsh                     \\\///
swel@bluecross.on.ca           / @  @ \   __   __              ___          __
Telecommunications Specialist  |   j  |  [_   /    |_| \    /   |    /\  / / _
Ontario Blue Cross             | (---)|  __]  \__  | |  \/\/   _|_  /  \/  \_|

-----------[000480][next][prev][last][first]----------------------------------------------------
Date:      Thu, 23 Jun 1994 13:48:02 GMT
From:      jdallend@csir.co.za (Justin)
To:        comp.protocols.tcp-ip
Subject:   HELP - various scenarios

Hi

Sorry if this is the wrong group. I am in the bussiness of setting people up
for internet access.(I am new to this). And need help in the various possible
networks they might have. eg. Novell lan with MSMail etc. If anybody has this
information I would really appreciate you E-mailing me with it.

Thanks
Justin
jdallend@infocomp.csir.co.za
*****************************************************************************
*    E-mail : justin@csir.co.za    *                                        *
*    Voice  : +27 012 841-3308     *        .SIG file under construction    *    
*    FAX    : +27 012 841-4109     *                                        *
*****************************************************************************

-----------[000481][next][prev][last][first]----------------------------------------------------
Date:      Thu, 23 Jun 1994 14:05:21 GMT
From:      roy@issy.cnet.fr (Jean-Michel ROY)
To:        comp.protocols.tcp-ip
Subject:   proxy command with ftp

How use the proxy command in ftp to transfer data via a machine
with Internet access ?

I am working on SUN with SunOs and the man of the ftp command
is not detailed.

   _____________________________________________________________________
  /\           Centre National d'Etudes des Telecommunications          \
  \_|                                                                    |
    | Jean-Michel ROY              e-mail : Jean-Michel.Roy@issy.cnet.fr |
    | CNET PAA/TIM/IBT             tel    : +33 1 45 29 41 74            |
    | 38 rue du General Leclerc    fax    : +33 1 45 29 58 66            |
    | 92131 ISSY LES MOULINEAUX    piece  : 014 ID                       |
    | FRANCE                                                             |
    |   _________________________________________________________________|___
     \_/____________________________________________________________________/

-----------[000482][next][prev][last][first]----------------------------------------------------
Date:      23 Jun 1994 14:57:35 GMT
From:      simha@tekelec.com (Ajay Simha)
To:        comp.protocols.tcp-ip
Subject:   socket <==> tli

Hi Netters,

Does anyone have experience with Client/Server situation where
one is using TLI and the other is using Sockets?

The reason I am asking is because I am involved in a port and
may need to decide which interface I should provide if I had
a choice.

-ajay (simha@tekelec.com)


-----------[000483][next][prev][last][first]----------------------------------------------------
Date:      23 Jun 1994 15:16:04 GMT
From:      sean@oak.his.ucsf.edu
To:        comp.sys.sun.admin,comp.protocols.tcp-ip
Subject:   Re: RIP and very large internal internet

You may want to configure your routers to only listen to RIP updates
from adjacent routers, ignoring the updates that come from workstations
that are only echoing (possibly corrupted) copies of what they learned
from routers.

Sean McGrath - Voice: 510.653.8387
Email: sean@oak.his.ucsf.edu
Paper: 638 66th st, Oakland Ca, 94609

-----------[000484][next][prev][last][first]----------------------------------------------------
Date:      Thu, 23 Jun 1994 16:33:14 GMT
From:      albertk@cs.kun.nl (Albert Koppes)
To:        comp.protocols.tcp-ip
Subject:   ICMP redirect/dead gateway with VAXes and DECNIS routers

For a configuration of Digital equipment (
VAXstations 4000 and DECnis routers), we are looking
into the possibilities of using ICMP-redirect and
'dead gateway detection' to choose immediately
another route if one DECnis goes down, so the 
ongoing TCP sessions will not break.

We were planning the following:

A VAXstation has two static default routes, one for each router (A and B).
If A cannot deliver, it will do an ICMP redirect and the host will
use B. A dynamic route will be added. If A is really down, the
dead gateway detection should work, and the VAX should see that there
is another route, via B.

The VAXes are running UCX 2.0E, TCP/IP services for VMS.

Does anyone know some reference on the implementation
of 'dead gateway detection' (RFC1122 is rather vague about this). 
We have difficulties to determine if a VAx station is 
supporting this mechanism at all.

Thank you in advance


Frank Zeppenfeldt
EUMETSAT
albertk@zeus.cs.kun.nl
tel: +49 6151 950236
fax: +49 6151 950225


-----------[000485][next][prev][last][first]----------------------------------------------------
Date:      Thu, 23 Jun 1994 16:33:19 GMT
From:      donp@niaid.nih.gov (Don Preuss)
To:        comp.protocols.tcp-ip
Subject:   Re: Dynamic BOOTP Server ?

snm@dublin.dcd.wa.gov.au (Sun Net Manager) writes:
I wrote a dynamic bootp server (currently running on an RS/6000). It
provides for a pool of IP addresses to be allocated and then upon
hitting a high water mark (or by timer) will set out to recover addresses.

It's been up and running here for over a year, and has been very stable.

It's based on the CMU bootp code, so it'll also do regular static bootptab
files.

If interested, send me mail and I'll put it up for access.

donp
>Hi All
 
>We have a bootp server NLM running on our novell server which dynamically
>allocates IP addresses from a specified range.  The first time a client PC
>puts out a Bootp request, the server gives that client the next free IP
>address and notes the allocation in a host table for future reference.
 
>This works really well, so I am now looking for a similar product for
>use under Unix.  There are several bootp servers availanle, but they all
>use static bootp tables.
 
>So - does anyone know of source for a dynamic bootp server ?
 
>Thanks
 
>Jimm

-----------[000486][next][prev][last][first]----------------------------------------------------
Date:      23 Jun 94 21:46:47
From:      neeri@iis.ee.ethz.ch (Matthias Neeracher)
To:        comp.protocols.tcp-ip,comp.software-eng,comp.sys.mac.programmer
Subject:   Re: ONC RPCs for the Mac yet?

In article <Crtxp3.7n6@dpcsys.com>, dan@dpcsys.com (Dan Busarow) writes:
> Check out EZ-RPC from Noblenet.  I'm not sure if they have a Mac
> port yet but I remember them saying it was in the works a few
> months ago.
 
> sales@noblenet.com

According to a correspondent of mine, the Mac version is in beta right now.

Matthias

-----
Matthias Neeracher <neeri@iis.ee.ethz.ch> http://err.ethz.ch/members/neeri.html
  "Johannes Scotus Eriugena, the greatest European philosopher of the 9th
   century, said that if reason and authority conflict, reason should be
   given preference. And if that doesn't sound reasonable to you, you'll
   just have to accept it..."


-----------[000487][next][prev][last][first]----------------------------------------------------
Date:      Thu, 23 Jun 1994 16:58:23 GMT
From:      atul@berlioz.nsc.com (Atul P. Agarwal)
To:        comp.sys.novell,comp.dcom.lans.ethernet,comp.protocols.tcp-ip
Subject:   Looking for Information on Courses on Networking



      I am looking for feedback from netters on the networking
courses offered by the following
  
      1) American Institute
      2) Learning Tree International
      3) American Research Group, Inc
      4) Data Tech Institute

Needless to say, the prices for the courses are very steep. However, they
seem to provide the necessary hand on experience for someone who would
like to make a career change from development into network systems
engineering.

Are there any other courses which netters can suggest ? What else can
a person do to learn enough to be able to get into the area of 
network protocols, network design and internetworking.

Please email me your responses.

Thanks.
Atul Agarwal
( atul@lan.nsc.com ) 

-----------[000488][next][prev][last][first]----------------------------------------------------
Date:      Thu, 23 Jun 1994 18:20:02 GMT
From:      dastous@csrmtl.qc.bell.ca (Yves D"astous)
To:        comp.protocols.tcp-ip
Subject:   telnet option code

I try to find the meaning of the TELNET option code
25 (0x19). The only option i know about are:
0, 1, 3, and 24 (0x18).  

There is a RFC or something with a more complete list ?
And if this kind of list exist where (ftp site) I can take
one ???.


Thanks a lot

-- 
===========================================================
Yves D'Astous Bell Québec     |
CSR - Mezzanine               | Tel: (514) 391-9531
700 de la Gauchetière Ouest   | Fax: (514) 391-8660
Montréal, Québec              | Email: dastous@qc.bell.ca
H3B 4L1                       |
===========================================================

-----------[000489][next][prev][last][first]----------------------------------------------------
Date:      23 Jun 94 18:23:27 GMT
From:      steve@unidata.ucar.edu (Steve Emmerson)
To:        comp.unix.internals,comp.protocols.tcp-ip
Subject:   ensuring server-side RPC won't block

Hi,

Is there any way to ensure that a server-side svc_getreq() or
svc_getreqset() won't block because some portion (i.e. "segment")
of the RPC call is still outstanding?

Would the following on the client-side suffice?

    1.  Ensure that the size of all client-side RPC calls to the server
	are less than the TCP maximum transfer unit.

    2.  Ensure that the client-side RPC buffer is flushed after every
	client-side RPC call to the server.

Please respond by e-mail.  I'll summarize if there's interest.
--

Steve Emmerson        steve@unidata.ucar.edu        ...!ncar!unidata!steve

-----------[000490][next][prev][last][first]----------------------------------------------------
Date:      Thu, 23 Jun 1994 19:17:09 GMT
From:      morley@suncad.camosun.bc.ca (Mark Morley)
To:        comp.protocols.tcp-ip
Subject:   Advice on subnetting wanted...

Here's what I have: I've been allocated a subnet of a class B address.  My
                    network is 134.87.180.*  My domain name is IslandNet.com
                    I currently have a Sun and a NetBlazer on my network,
                    that's all.  The NetBlazer currently connects to the
                    internet on one of its ports.

Here's what I wanna do: Using a spare port on my NetBlazer, I want to connect
                        a remote lab of computers via a SLIP connection. 
                        I am going to put an old PC running PC Route in the
                        lab as a router, using a couple 28.8 modems for the
                        link.

I'd like the lab to be known under the domain name "lab.IslandNet.com",
although it wouldn't really matter if it had the same domain name.

Can I subnet the network I have been allocated?  Do I need to?  How would
I go about doing this?  Is it mostly just a matter of having the correct
netmasks?

Mark

-----------[000491][next][prev][last][first]----------------------------------------------------
Date:      23 Jun 1994 19:59:24 GMT
From:      vishwamber.yelsangikar.1@nd.edu (Vishwamber Yelsangikar)
To:        comp.protocols.tcp-ip
Subject:   RFC 1055 -SLIP

Where can I find RFC 1055 for SLIP.
Please e mail your replies to vish@nd.edu

Vishwamber Yelsangikar
Senior Network Engineer.
Notre Dame.

-----------[000492][next][prev][last][first]----------------------------------------------------
Date:      Thu, 23 Jun 1994 21:21:30 GMT
From:      jprado@lauca.usach.cl (Jorge Andres Prado Troncoso)
To:        comp.protocols.tcp-ip
Subject:   DOS's  socket libraries.


 Hi :

 	Does anybody know where may I find sources programs and socket's
  library ?.

	These sockets must be for DOS not for WINDOWS ( winsockt) and UNIX
       ( DOS client  and UNIX server).


      Thanks in advance.

                                     Jorge A. Prado T.

-----------[000493][next][prev][last][first]----------------------------------------------------
Date:      Thu, 23 Jun 94 21:24:04 GMT
From:      ftlofaro@unlv.edu (Frank Lofaro)
To:        comp.protocols.tcp-ip
Subject:   Re: telnet option code

In article <Crv49F.F6z@on.bell.ca> dastous@csrmtl.qc.bell.ca (Yves D"astous) writes:
>I try to find the meaning of the TELNET option code
>25 (0x19). The only option i know about are:
>0, 1, 3, and 24 (0x18).  
>
>There is a RFC or something with a more complete list ?
>And if this kind of list exist where (ftp site) I can take
>one ???.
>
>
>Thanks a lot
>

I'd like to find an RFC (or index to _all_ the telnet RFC's) myself.
The telnet source might be a good place to check.

Also, anyone know what option code number 2 was/is used for?



-----------[000494][next][prev][last][first]----------------------------------------------------
Date:      23 Jun 1994 21:41:24 GMT
From:      glenn@tiac.net (Glenn Freidet)
To:        comp.protocols.tcp-ip
Subject:   WFW with TCP/IP in DOS?

We currently use the Daytona 32-bit TCP/IP stack with WFW to 
access our UNIX machines.  The UNIX devices are shared on the 
net as LANMAN services, via Samba.  We require the same access 
from DOS, outside of Windows, but WFW DOS Add-On won't load the 
32-bit protocol.  MS confirmed this behavior.

We loaded the old real-mode TCP/IP stack, instead of the 32-bit 
version, and it worked in both Windows and DOS.  However, the 
system is much slower and requires too much conventional memory.

Is there any other stack, commercial or otherwise, which will 
allow us to connect to LANMAN services both in and out of 
Windows?

Is there any software, commercial or otherwise, which will 
allow us to create connections from DOS, but can also be 
loaded/unloaded from the command line?  If a product like this 
exists, we could unload it before going into Windows.

Please forgive the cross-posting.  We're really desperate for 
quick help with this problem.  Thanks.

-gf-

-----------[000495][next][prev][last][first]----------------------------------------------------
Date:      Thu, 23 Jun 1994 21:55:01 GMT
From:      rstevens@noao.edu (W. Richard Stevens)
To:        comp.protocols.tcp-ip
Subject:   Re: telnet option code

> I try to find the meaning of the TELNET option code
> 25 (0x19). The only option i know about are:
> 0, 1, 3, and 24 (0x18).  
> There is a RFC or something with a more complete list ?
> And if this kind of list exist where (ftp site) I can take ne ???.

You want the latest "Assigned Numbers" RFC.  It lists all these
types of magic numbers, complete with references to the defining
RFC.  I believe the most recent version of this is RFC 1340.

Send e-mail to rfc-info@isi.edu with the line

	help: ways_to_get_rfcs

for detailed instructions of various ways to get copies of RFCs.

	Rich Stevens

-----------[000496][next][prev][last][first]----------------------------------------------------
Date:      Thu, 23 Jun 1994 22:11:11 GMT
From:      asselin@vnet.ibm.com (Andre Asselin)
To:        comp.protocols.tcp-ip,comp.protocols.ibm
Subject:   Re: Problems with IBM OS/2 TCP/IP implementation

In <MlT2kmoZjSWQ064yn@msen.com>, brain@msen.com (Jim Brain) writes:
>I do the connection of the socket between process fine, but the sends are
>skeweed.  I send 108 byte packet 5 times , but I receive one packet with
>5*108 bytes in it.  I am using stream sockets with default bahavior.
>
>I thought maybe I was misunderstanding stream, but a friend has the exact
>same code running correctly.  Can anyone explain this problem????

Jim,
   TCP/IP is working correctly.  Stream sockets do not have any kind of
record boundaries in them-- they are just a stream of bytes.  You could
just as easily receive the data as 108 5 byte packets.

Andre Asselin                   VNET: ASSELIN at RALVM12
IBM OS/2 TCP/IP Development     Internet: asselin@vnet.ibm.com
Research Triangle Park, NC      


-----------[000497][next][prev][last][first]----------------------------------------------------
Date:      24 Jun 1994 10:37:29 -0700
From:      lstowell@pyrnova.mis.pyramid.com (Lon Stowell)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP retransmit mechanism

In article <albert.772351865@netboss> albert@dn.itg.telecom.com.au (Albert Fu) writes:
>
>Should a TCP packet be re-transmitted using a fixed timeout?
>
   No, nein, nyet, nicht.

   If you are a host, get RFC 1122 "Requirements for Hosts--Communications
   Layers".  It not only gives you some of the gory details, it has a
   VERY complete bibliography of other RFC's and technical papers. 

   The Comer internals book is another source of info.  

>I looked at a problem a while ago where a particular packet
>did not get to the destination, and the sending host was 
>retransmitting the packet using fixed timeout (nearly). 

   Wouldn't have been the DOS/VSE-VM version of tcp/ip would it?



-----------[000498][next][prev][last][first]----------------------------------------------------
Date:      Thu, 23 Jun 1994 23:11:37 GMT
From:      fred_s@netcom.com (Frederick Scott)
To:        comp.protocols.tcp-ip
Subject:   Re: need ammo to use against bone-headed administrator

sej@flowbee.interaccess.com (Stephen Johnson) writes: 

>johns@rd.scitec.com.au (John Saunders) writes:
>
>>I also beleive that 4 subnets are available. I think the limitation is in the
>>host part of the address i.e. you have 2 less than 64 host addresses available
>>because a host address of all 0's is the network and a host address of all 1's
>>is a broadcast. However for a subnet these extra bits are effectively part of
>>the network and and there is nothing special about 2 out of 26 bits being all
>>0's or all 1's. All 26 bits have to be all 0's or all 1's before the address
>>becomes special and should not be used.
>>
>>P.S. The ideas above don't come from any RFC and can state off hand, just from
>>experience at setting up IP networks and writing some routing code.
 
>This information is gleened from several replies to my original post.
>According to RFC 950 [Internet Standard Subnetting Procedure] and 
>RFC 1122 [Requirements for Internet Hosts -- Communication layers]
>subnet fields values of all zero bits or all ones bits are special
>values and should not be used for actual subnets. A subnet field of
>2 bits (255.255.255.192) has only 2 legal values according to these
>RFC's.  I expect that the results of violating these standards are
>implementation dependant, your mileage may vary (to quote Peter
>Mockapetris).

Could you cite chapter and verse on that?  (OK, I'll settle for section
and page number.)  This seems a bizarre requirement to me.  All ones or
all zeros in the host field implies broadcasts - but the the subnet field?!?
I wonder why the would wish to reserve those.  I'm not surprised you were met
with skepticism.

By the way, let's be a bit more specific here when posting about problems.
You completely neglected to mention you were talking about a subnet mask of
255.255.255.192 IN A CLASS C NETWORK.  I couldn't figure out what the heck
you were talking about because the same mask in a class A or B network will
give a whole lot more available subnets than 4, regardless of whether you
eliminate the all ones and all zeroes subnets or not.

Fred

-----------[000499][next][prev][last][first]----------------------------------------------------
Date:      24 Jun 1994 10:54:38 -0700
From:      marc@dumbcat.sf.ca.us (Marco S Hyman)
To:        comp.protocols.tcp-ip
Subject:   Re: need ammo to use against bone-headed administrator

In article <fred_sCrvHrD.Jq3@netcom.com>,
Frederick Scott <fred_s@netcom.com> wrote:
 > >This information is gleened from several replies to my original post.
 > >According to RFC 950 [Internet Standard Subnetting Procedure] and 
 > >RFC 1122 [Requirements for Internet Hosts -- Communication layers]
 > >subnet fields values of all zero bits or all ones bits are special
 > >values and should not be used for actual subnets. A subnet field of
 > >2 bits (255.255.255.192) has only 2 legal values according to these
 > >RFC's.  I expect that the results of violating these standards are
 > >implementation dependant, your mileage may vary (to quote Peter
 > >Mockapetris).
 > 
 > Could you cite chapter and verse on that?  (OK, I'll settle for section
 > and page number.)  This seems a bizarre requirement to me.  All ones or
 > all zeros in the host field implies broadcasts - but the the subnet field?!?
 > I wonder why the would wish to reserve those.  I'm not surprised you
 > were met with skepticism.

Check out RFC 1009, section 1.1.4, specifically the top of page 6

  "No subnet should be assigned the value of zero or -1 (all one bits)."

// marc
-- 
// marc@dumbcat.sf.ca.us or marc@ascend.com

-----------[000500][next][prev][last][first]----------------------------------------------------
Date:      24 Jun 1994 08:07:44 -0500
From:      mweiss@nwk.cl.nec.co.jp (Michael J. Weiss)
To:        comp.os.ms-windows.networking.tcp-ip,comp.os.ms-windows.programmer.networks,comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject:   NCSA Winsock

I just ftp'ed NCSA Winsock.

According to the accompanying README file, there are substantial
differences between it and a "Windoews Sockets Compliant" stack.  I
would like to know more specifically how substantial these differences
are.

If any of you have any insight into this matter, would you please share
it?

Also, does anyone know the email addresses of its creators ?

Thanks,

--Mike

-----------[000501][next][prev][last][first]----------------------------------------------------
Date:      24 Jun 1994 08:12:53 -0500
From:      mweiss@nwk.cl.nec.co.jp (Michael J. Weiss)
To:        comp.os.ms-windows.networking.tcp-ip,comp.os.ms-windows.programmer.networks,comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject:   Writing Winsock DLL (TCP/IP Stack) from Scratch

If I end up having to write a Winsock DLL (TCP/IP stack) from scratch,
what materials would help me?

Which RFCs do I need to get ?  Are there any books (I already have the
series by Comer/Stevens) that will help me ?

Thanks for your help.

--Mike

-----------[000502][next][prev][last][first]----------------------------------------------------
Date:      Fri, 24 Jun 94 02:30:13 GMT
From:      ftlofaro@unlv.edu (Frank Lofaro)
To:        comp.protocols.tcp-ip
Subject:   Re: telnet option code

In article <1994Jun23.215501.9057@noao.edu> rstevens@noao.edu (W. Richard Stevens) writes:
>> I try to find the meaning of the TELNET option code
>> 25 (0x19). The only option i know about are:
>> 0, 1, 3, and 24 (0x18).  
>> There is a RFC or something with a more complete list ?
>> And if this kind of list exist where (ftp site) I can take ne ???.
>
>You want the latest "Assigned Numbers" RFC.  It lists all these
>types of magic numbers, complete with references to the defining
>RFC.  I believe the most recent version of this is RFC 1340.
>
>Send e-mail to rfc-info@isi.edu with the line
>
>	help: ways_to_get_rfcs
>
>for detailed instructions of various ways to get copies of RFCs.
>
>	Rich Stevens

I lookef for and found telnet option 2 in that RFC. But I can't find 
the reference it refers to for information on it, it is not an rfc, but 
some kind of NIC document. This is the reference:

   [42]   DDN Protocol Handbook, "Telnet Reconnection Option",
          NIC 50005, December 1985.

How and where could I find it?


-----------[000503][next][prev][last][first]----------------------------------------------------
Date:      Fri, 24 Jun 1994 04:16:29 GMT
From:      thg@mare.lc.att.com (ND27005D0-T.GOLDSTEIN(AH0232)XXXX)
To:        comp.protocols.tcp-ip
Subject:   Is there a TCP/IP certification tool ?

Does anyone know of a TCP/IP protocol certification  tool
for a router ?. 
I called many of the major LAN instrument manufacturers 
and none had anything  even resembling a certification tool.

Without such a tool how does one make sure that a new router 
does not crash the network ?

-- 
	Thomas Goldstein
	
	AT&T Networks Systems 
	Warren, NJ 07059, USA
	Tel (908) 580-4660

-----------[000504][next][prev][last][first]----------------------------------------------------
Date:      Fri, 24 Jun 94 15:26:00 -0640
From:      john.will@dscmail.com (John Will)
To:        comp.protocols.tcp-ip
Subject:   Re: Problems with IBM OS/

B >Next question.  Since I do indeed need to make record boundaries, how would
B >I go about it?  I have been suggested the following :
B >
B >Process 1     process 2
B >
B >send(length)
B >send(data)     recv(length)
B >      recv(data)
B >      
B >But I noticed that there is always the possibility that 'length" bytes
B >may not be available for you to read YET.  How do sockets programs using
B >tcp get around this problem?

You either indeed send the length first, an alternate plan is to use
framing characters and escape them in the body of the message.  For 
instance, if you use <SOM> to start a message, and it appears in the
body of the message, you add one <SOM><SOM> replaces a single <SOM> in
the body of the message.  If you find a single <SOM>, it's the start
of a message.  A similar scheme for the end of the message with <EOT>...

-----------[000505][next][prev][last][first]----------------------------------------------------
Date:      24 Jun 1994 11:34:35 -0400
From:      brain@msen.com (Jim Brain)
To:        comp.protocols.tcp-ip,comp.protocols.ibm
Subject:   Re: Problems with IBM OS/2 TCP/IP implementation

In article <CrvEyn.6yxB@hawnews.watson.ibm.com>, Andre Asselin wrote:
> In <MlT2kmoZjSWQ064yn@msen.com>, brain@msen.com (Jim Brain) writes:
> >I do the connection of the socket between process fine, but the sends are
> >skeweed.  I send 108 byte packet 5 times , but I receive one packet with
> >5*108 bytes in it.  I am using stream sockets with default bahavior.
> >
> >I thought maybe I was misunderstanding stream, but a friend has the exact
> >same code running correctly.  Can anyone explain this problem????
> 
> Jim,
>    TCP/IP is working correctly.  Stream sockets do not have any kind of
> record boundaries in them-- they are just a stream of bytes.  You could
> just as easily receive the data as 108 5 byte packets.
> 
> Andre Asselin                   VNET: ASSELIN at RALVM12
> IBM OS/2 TCP/IP Development     Internet: asselin@vnet.ibm.com
> Research Triangle Park, NC      
> 

I'll be! Well, that was my quick synopsis, but I prayed it was untrue.
Next question.  Since I do indeed need to make record boundaries, how would
I go about it?  I have been suggested the following :

Process 1					process 2

send(length)
send(data)					recv(length)
						recv(data)
						
But I noticed that there is always the possibility that 'length" bytes
may not be available for you to read YET.  How do sockets programs using
tcp get around this problem?

(Don't worry, I am dragging out the sockets books as we speak, but I fear 
mine are not the best at dsescribing these little things.)


--
Jim Brain, Embedded Systems Designer, Brain Innovations.
brain@msen.com  
Dabbling in VR, Old Commodore Computers, and Good Times!
"The above views DO reflect my employer, since I am my employer" - Jim Brain


-----------[000506][next][prev][last][first]----------------------------------------------------
Date:      Fri, 24 Jun 1994 05:24:49 GMT
From:      ke4dpx@gregl.slip.iglou.com (Greg Law)
To:        comp.protocols.tcp-ip,comp.sys.sun.misc
Subject:   Re: Reliable UDP Broadcasts?

In article <1994Jun21.185539.11099@philabs.philips.com> add@philabs.philips.com (Aninda Dasgupta) writes:

>Does anyone have any experience with "reliable UDP broadcasts?"
>I am simulating a protocol using UDP broadcasts.  A node
>on the network doesn't know of the existence or identity of the 
>other nodes on the network.  Thus, if node A wishes to discover
>who else is listening to its broadcasts on the subnet, it shouts
>a 'grope' packet.  The reciepients of the grope packet reply 
>back, again using broadcasts.
 
>The problem I am facing is as follows:
 
>Host B and C are listening for broadcasts on the subnet.  Node A
>broadcasts a grope packet, which is received by both B and C.
>Immediately, B and C decide to broadcast grope packets.  However, 
>B does not hear C's broadcast.  Strangely enough, C can hear B's
>broadcast.  I suspect that the UDP packets from C are being
>dropped at B.  I guess that is part of the unreliability of the
>UDP protocols.
 
>If anyone has dealt with such a problem and built a reliability
>layer over UDP broadcasts, I would like to hear from you.  Please
>note that I cannot use end to end acknowledgements as the identity
>of other nodes on the network are not known before the grope packets
>are sent out.  Thus, C cannot expect to get an acknowledgement from
>B as C does not know of B's existence.

The general technique used in amateur radio to avoid packet collisions is to 
wait a random interval of time (up to a specified maximum) before sending or 
replying. While it doesn't guarantee collisions won't happen, it reduces the 
odds considerably.


-----------[000507][next][prev][last][first]----------------------------------------------------
Date:      Fri, 24 Jun 1994 11:24:10
From:      mikey@mcs.com (Mike Young)
To:        comp.os.ms-windows.networking.tcp-ip,comp.os.ms-windows.programmer.networks,comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject:   Re: Writing Winsock DLL (TCP/IP Stack) from Scratch

In article <9406240252.AA18447@ariake.nwk.cl.nec.co.jp> mweiss@nwk.cl.nec.co.jp (Michael J. Weiss) writes:
>From: mweiss@nwk.cl.nec.co.jp (Michael J. Weiss)
>Subject: Writing Winsock DLL (TCP/IP Stack) from Scratch
>Date: 24 Jun 1994 08:12:53 -0500
 
>If I end up having to write a Winsock DLL (TCP/IP stack) from scratch,
>what materials would help me?
 
>Which RFCs do I need to get ?  Are there any books (I already have the
>series by Comer/Stevens) that will help me ?
 
>Thanks for your help.
 
>--Mike

The RFC's won't be of much help to you; they define protocol at a higher level 
(usually). WinSock, as its name implies, is a library of BSD socket-like 
functions. You need the WinSock 1.1 specification from Microsoft.

Why would you want to do something like that???

Mike.

-----------[000508][next][prev][last][first]----------------------------------------------------
Date:      Fri, 24 Jun 1994 07:22:32 +0000
From:      proyse@peeras.demon.co.uk (Phil Royse)
To:        comp.protocols.tcp-ip
Subject:   Re: Authentification of users on dialup terminal servers

In article <bbosenCrtMK7.BGo@netcom.com> bbosen@netcom.com "Bob Bosen" writes:

>Stephane Bortzmeyer (bortz@cnam.cnam.fr) wrote:
>: I'm investigating the problem of access control for dialup SLIP/PPP terminal 
>: servers like Cisco's 500CS, Livingston's PortMaster, Xylogics' Annex, etc.
 
>These protocols are generally undergoing transitions, too. Advanced
>features like truly non-replayable challenge/response authentication
>have been recently added to draft versions of TACACS and Radius.
>Perhaps to others as well. It's still a moving target.

Bob,  I'm researching this field for a client in the UK.  I have 
downloaded some of your stuff from Enigma at netcom.com, including
the VGA demos and the .wri files on firewalls & the Cisco s/w.

Question:  is it necessary to have each client use a smart card
or other device to generate the one-time password?

We would like to have this authentication for remote dialin users
but we are happy to insist that they all must use PCs.  Therefore
we would like each user to identify him/herself to their local
PC with a password, then have the authentication client software
take over and authenticate (with an encrypted one-time p/wd) to
the server.

Which of your docs gives a more detailed functional spec. of
SafeWord and the other products?

>IMHO TACACS is simpler.

Yes, it appears to be, but doesn't it need an external device
or smart card?

>: How does the different protocols compare when examining:
>: - security (how are passwords transmitted?)
>Since our API assures non replayability (of authentication data
>at least) and we encapsulate everything within our API and then
>just transport it via these protocols, this was somewhat less
>an issue for me.

Where is this functionality described in more detail?

Phil
-- 

Phil Royse     Comms Consultant  |  PRA Consulting Ltd.
TUDOR HOUSE                      |
12 Woodside Road, Purley
Surrey  CR8 4LN (UK)  Tel: (+44) 81 645-9868   proyse@peeras.demon.co.uk

-----------[000509][next][prev][last][first]----------------------------------------------------
Date:      Fri, 24 Jun 1994 07:27:08 GMT
From:      pbs@zuunix.zuo.dec.com (Philip Shearer @ZUO-DC EBS-Team)
To:        comp.unix.programmer,comp.protocols.tcp-ip
Subject:   Re: Help with UDP Broadcast

rstevens@noao.edu (W. Richard Stevens) writes:
: but you need to verify this works on your host.  Also be aware that you
: can't call inet_addr() with "255.255.255.255" as the argument, since the
: return value (all one bits) is the same as an error return.
: 
: 	Rich Stevens

Which in SYSV and OSF1 manuals is specified as INADDR_NONE (-1)
despite the fact that the return is supposed to be of type unsigned int!

TTFN Philip

-----------[000510][next][prev][last][first]----------------------------------------------------
Date:      Fri, 24 Jun 1994 09:10:38 GMT
From:      tomw@netcom.com (Tom Walsh)
To:        rec.autos.marketplace,comp.protocols.tcp-ip,alt.winsock
Subject:   Internet Technical Survey ( less than a page )

This is a short questionaire to find out usage trends for various internet 
connectivity issues, If you have time please fill it out and E-mail to 
tomw@netcom.com ( no flames please! ). I will post a summary.

How do you currently connect to the internet: ( use an X to fill in field )
-------------------------------------------------------------------------------
Raw Serial ( TTY ):Slip:
PPP:
Direct Connection ( via ethernet or other "direct" meachanism ):
Other:
Don't know (??):

If you are not directly connected:
do you use an internet provider ( netcom, delphi... ):
do you use a bbs ( any bbs or america online, compuserve ... ):
are you a university student:
do you consider PPP or Slip Difficult to set up:

What kind of host machine do you use:
PC (windows):
Sun:
Other Unix Vendor:
Mac:
Other:

Do you read more than 10 news groups:
Do you use telnet:
Do you use Ftp:
Do you use a Gopher client:
Do you use a Wais client:
Do you use a www client ( like mosaic ):

If you never have used a mosaic like client do you think you might?:
do you know what the world wide web is:

If it was safe, would you use internet shopping or other "non-intrusive" ( you 
must ask ) services :

Do you see the Internet as a way to propagate published documents or other 
media:
-------------------------------------------------------------------------------
Thank You for your time I will post a summary if there is enough responses or 
you may ask me via E-mail ( in about a week or so ).




-----------[000511][next][prev][last][first]----------------------------------------------------
Date:      Fri, 24 Jun 1994 11:09:05 GMT
From:      cgee@ntuix.ntu.ac.sg (Ee Chong Gay)
To:        comp.protocols.tcp-ip
Subject:   Netstat figures in Ultrix (help !)


Hi, folks. I have a question here and I need some experts
out there to help...

You see, I executed the Netstat utility in DEC's Ultrix
ver4.2 and the results come out like this:

 input  (ln0)   output           input  (total)    output
packets errs  packets errs colls packets errs packets errs colls
 110153    0   38177     0    62  297808    0   176826   0    62
.
.
.
etc ...

Could someone outline what the "input" and the "output" specifically
means ?

Thanks in advance !!

Regards,
Thomas Ee
e-mail: cgee@ntu.ac.sg
.

-- 

Chong Gay, Ee (Thomas)
----------------------------------------------
|  Network Technolgy Research Centre  of the |

-----------[000512][next][prev][last][first]----------------------------------------------------
Date:      24 Jun 94 12:38:48 GMT
From:      sej@flowbee.interaccess.com (Stephen Johnson)
To:        comp.protocols.tcp-ip
Subject:   Re: need ammo to use against bone-headed administrator

>>This information is gleened from several replies to my original post.
>>According to RFC 950 [Internet Standard Subnetting Procedure] and 
>>RFC 1122 [Requirements for Internet Hosts -- Communication layers]
>>subnet fields values of all zero bits or all ones bits are special
>>values and should not be used for actual subnets. A subnet field of
>>2 bits (255.255.255.192) has only 2 legal values according to these
>>RFC's.  I expect that the results of violating these standards are
>>implementation dependant, your mileage may vary (to quote Peter
>>Mockapetris).
 
>Could you cite chapter and verse on that?  (OK, I'll settle for section
>and page number.)  This seems a bizarre requirement to me.  All ones or
>all zeros in the host field implies broadcasts - but the the subnet field?!?
>I wonder why the would wish to reserve those.  I'm not surprised you were met
>with skepticism.

RFC 950 Special Addresses section (page 6)

RFC 1122 section 3.2.1.3  (page 31)

Sorry about all the confusion. I should have stated that I was dealing 
with a class C address to begin with.  I have had this discusion so many
times that I forget that other people haven't.  

I dont think that there is anything bizarre about requiring non-zero 
subnet fields, the address 130.0.1.1 is not legal.  

By the way, thanks to all the folks that have made this problem of mine 
an interesting learning experience.

 

-----------[000513][next][prev][last][first]----------------------------------------------------
Date:      24 Jun 94 13:09:49 GMT
From:      werme@alingo.zk3.dec.com (Eric Werme)
To:        comp.protocols.tcp-ip,comp.protocols.ibm
Subject:   Re: Problems with IBM OS/2 TCP/IP implementation

brain@msen.com (Jim Brain) writes:

>Aaaarrrggghhh, I am at my wits end.
 
>I am trying to use IBM TCP/IP for OS/2.  Here is the deal.
 
>I do the connection of the socket between process fine, but the sends are
>skeweed.  I send 108 byte packet 5 times , but I receive one packet with
>5*108 bytes in it.  I am using stream sockets with default bahavior.

This is perfectly reasonable behaviour.  If record boundaries are important
to you, you'll have to use UDP and handle timeouts yourself.  Even if
your client sent five separate packets initially (which would be reather
inefficient), if it never received an ACK for the first data, I would
certainly hope it would retransmit all 5*108 bytes in a single packet.

Consider yourself lucky - you could have seen one packet with 1 byte,
then another with the rest.  That would also have been legal.

What you really want is SOCK_SEQPACKET, ala:

#define	SOCK_STREAM	1		/* stream socket */
#define	SOCK_DGRAM	2		/* datagram socket */
#define	SOCK_RAW	3		/* raw-protocol interface */
#define	SOCK_RDM	4		/* reliably-delivered message */
#define	SOCK_SEQPACKET	5		/* sequenced packet stream */

I think OSI supports that, TCP/IP doesn't, I guess because it's so easy
for an application to do itself.  For example, Sun RPC does that with
TCP connections.  You might want to borrow code from there.
-- 
Eric (Ric) Werme		| werme@zk3.dec.com
Digital Equipment Corp.		| This space intentionally left blank.

-----------[000514][next][prev][last][first]----------------------------------------------------
Date:      Fri, 24 Jun 1994 13:28:49 GMT
From:      athoren@irscscm.uucp (Allen Thoren)
To:        comp.protocols.tcp-ip
Subject:   SOCKETS?

I need to get as much info about sockets as possible???  Please be as basic
as you can.  Maybe a book that can be suggested as a good source of info.

Thanks.

-- 
     VIRGINIA               ,/\                   Allen L. Thoren
      IS FOR              ,/   `\/`'\   athoren%irscscm%media@uunet.uu.net or
      LOVERS          ,/\/          /           athoren@irscscm.UUCP   
                    ,/             <_          ._.  

-----------[000515][next][prev][last][first]----------------------------------------------------
Date:      Fri, 24 Jun 1994 13:32:38 GMT
From:      sar@prologic.com (Steve Rago)
To:        comp.protocols.tcp-ip
Subject:   Re: socket <==> tli

In article <2uc7sv$232@getty.tekelec.com> simha@tekelec.com (Ajay Simha) writes:
>Hi Netters,
>
>Does anyone have experience with Client/Server situation where
>one is using TLI and the other is using Sockets?
>
>The reason I am asking is because I am involved in a port and
>may need to decide which interface I should provide if I had
>a choice.

There's a fairly detailed comparison of the two interfaces in
my book, Unix System V Network Programming (Addison-Wesley,
ISBN 0-201-56318-5).  The bottom line is the two interfaces
provide similar functionality, but the socket interface is
simpler to use and the TLI is more flexible (read complicated).

When you say "which interface you should provide," I assume
you intend to port one or the other interfaces to your embedded
system.  If you're starting with any public-domain TCP/IP code,
then the logical answer is to use sockets, since most (possibly
all?) of the public-domain implementations are derived from the
BSD source.  O'Reilly has the BSD4.4-lite source code on CD-ROM
for about US$40.  (I picked up my copy at USENIX.)

Steve Rago
sar@prologic.com

-----------[000516][next][prev][last][first]----------------------------------------------------
Date:      Fri, 24 Jun 1994 14:14:19 GMT
From:      epr9q@kelvin.seas.Virginia.EDU (Eric Robins)
To:        comp.protocols.tcp-ip
Subject:   WinTel??

Where can I get WinTel from?? Is there an FTP site that has all kinds of stuff
for Trumpet??

Thanx,.
	Eric Robins

-- 

Women, you can't live with 'em; they can't pee standing up.


-----------[000517][next][prev][last][first]----------------------------------------------------
Date:      24 Jun 1994 21:56:17 -0400
From:      jhawk@panix.com (John Hawkinson)
To:        comp.protocols.tcp-ip
Subject:   Re: need ammo to use against bone-headed administrator

In <fred_sCrxB1F.DIo@netcom.com> fred_s@netcom.com (Frederick Scott) writes:

>Well, there's no reason for it that I can think of.  (Well, I guess I'll
>have to read the RFCs to find out.)  All ones and all zeros in host address
>implies an IP broadcast so you can't use them as node addresses.  But what
>on earth does all ones or all zeros in (just the) subnet field imply that
>would cause them to be reserved?
 
>And why do you say 130.0.1.1 is not legal?  Looks perfectly OK to me.
>(Now 130.0.0.0 or 130.0.255.255 could cause problems...)

The reason is that 130.0.0.0 with a mask of 255.255.255.0 represents
the all zero subnet. There are two interpretations of what that means:

	1) The network (all subnets) 130.0.0 thorugh 130.0.255.
	2) The network (one subnet) 130.0.0 (i.e. 130.0.0.0 - 130.0.0.255)

2) is explictly disallowed to remove the ambiguity.

This is not a hard and fast rule, and most code doesn't care.
Routers, however, tend to. On cisco routers you can make them
``not care'' by saying ``ip subnet-zero''.

--
John Hawkinson
jhawk@panix.com

-----------[000518][next][prev][last][first]----------------------------------------------------
Date:      24 Jun 1994 22:00:03 -0400
From:      jhawk@panix.com (John Hawkinson)
To:        comp.protocols.tcp-ip
Subject:   Re: Is there a TCP/IP certification tool ?

In <2ufiei$aqs@cronkite.cisco.com> tli@cisco.com (Tony Li) writes:

>In article <CrvvvH.23x@nntpa.cb.att.com> thg@mare.lc.att.com
>(ND27005D0-T.GOLDSTEIN(AH0232)XXXX) writes: 
>    Does anyone know of a TCP/IP protocol certification  tool
>    for a router ?. 

Yup. It's called the Internet.

>    I called many of the major LAN instrument manufacturers 
>    and none had anything  even resembling a certification tool.

They just weren't on the ball when you called...

>    Without such a tool how does one make sure that a new router 
>    does not crash the network ?
>    
>With such a tool, how does one make sure that a new router does not crash
>the network?

With such a tool, how does one make sure that a new router does crash the
network?
 
By never plugging it in, of course!

--
John Hawkinson
jhawk@panix.com

-----------[000519][next][prev][last][first]----------------------------------------------------
Date:      24 Jun 1994 16:04:43 GMT
From:      hansel@marvin.aero.org (Steve Hansel)
To:        comp.protocols.tcp-ip
Subject:   Ascii SLIP


I'm considering making modifications to CSLIP 2.7 to add an option to make it use only
7 bit ascii characters.   The purpose would be so that people could slip through stupid terminal
servers and over telnet sessions.  I would probably make this the LINK4 option.  Before I start, I was
wondering if the has been done already, or if anyone else is currently working on this.

At first glance, this doesn't look too hard.

Suggestions are welcome.  Anyone interested in testing this code, drop me a line. 

	Steve

-----------[000520][next][prev][last][first]----------------------------------------------------
Date:      24 Jun 1994 16:11:29 GMT
From:      cliffj@eng.umd.edu (Cliff Jones)
To:        comp.protocols.tcp-ip
Subject:   Find a node on an IP Address or net name of a node




-----------[000521][next][prev][last][first]----------------------------------------------------
Date:      24 Jun 1994 16:18:29 GMT
From:      dsg@blackbird.mitre.org (Dave Goldberg)
To:        comp.protocols.tcp-ip,comp.dcom.servers
Subject:   Re: Authentification of users on dialup terminal servers



>> At some point, however, we'd like to figure out how to integrate
>> this with s/key, if possible. I believe it supports SecureID out of
>> the box.
 
> That's actually easy, now. And it _does_ support SecureID as you
> say.

I just did this a couple of weeks ago, though I used the TIS authent
stuff as intermediary between the ACP and the s/key stuff.  I did it
for v.8.0.  It looks like they changed acp_policy.c enough in 8.0.8
that I may have to do some cut and paste to patch it into the right
places again, but I don't expect it to be any major trouble.

Dave Goldberg
Post: The Mitre Corporation MS B020 202 Burlington Rd. Bedford, MA 01730
Phone: 617-271-3887
Domain: dsg@mitre.org  UUCP: {your neighborhood}!linus!mdf!dsg 

-----------[000522][next][prev][last][first]----------------------------------------------------
Date:      Fri, 24 Jun 1994 18:43:50 GMT
From:      roberts@angelo.amd.com (Dave Roberts)
To:        comp.protocols.tcp-ip
Subject:   Re: TAXI

In article <1994Jun20.174312.15373@afterlife.ncsc.mil>,
Chris A. Wilcox <cawilco@afterlife.ncsc.mil> wrote:
>In article <940620032033@news.tra.com>, Earl E. McCoy <emccoy@tra.com> wrote:
>>
>>This may not be the right group for this question but I have run out
>>of local resources and my boss wants to know: What does TAXI stand
>>for (the 100Mbps/140Mbps FDDI interface). Thanks in advance. Earl
>
>If I'm not mistaken, it is the Transparant Asynchronous
>Transmitter/Receiver Interface.

Not that this belongs here, but TAXI, or more specifically TAXIchip,
is an AMD trade name for its high-speed asynchronous serial datacomm
products.  The acronym expansion is as Chris describes it above.  TAXI
really has nothing to do with FDDI (we've got a few other products
that do the necessary magic for FDDI).  TAXI has been used extensively
in various ATM implementations and has become a recognized physical
layer within the ATM community.

Dave Roberts
Advanced Micro Devices, Inc.
I/O and Network Products Division
david.roberts@amd.com


-----------[000523][next][prev][last][first]----------------------------------------------------
Date:      24 Jun 94 23:45:35
From:      billw@glare.cisco.com (William )
To:        comp.protocols.tcp-ip
Subject:   Re: Authentification of users on dialup terminal servers

It's either encouraging or depressing that with the current selection
of radius, tacacs, xylogics, and telebit protocols, there is no clear
customer concensus that any of these are good enough to settle on as
a standard...

BillW
cisco

-----------[000524][next][prev][last][first]----------------------------------------------------
Date:      24 Jun 1994 20:52:23 GMT
From:      09207psa@msu.edu (Peter M. Bamwoze)
To:        comp.protocols.tcp-ip
Subject:   Re: WinTel??

In article <CrwnJv.HpL@murdoch.acc.Virginia.EDU>, epr9q@kelvin.seas.Virginia.EDU (Eric Robins) says:
>
>Where can I get WinTel from?? Is there an FTP site that has all kinds of stuff
>for Trumpet??

You can find Trumpet stuff at  ftp.cica.indiana.edu (or its mirror sites). Retrieve
the file:
		/ftp/pub/pc/win3/winsock/winapps.zip

The NCSA Telnet for MS Windows (WinTel) is in the file:
		/ftp/pub/pc/win3/winsock/wintelb3.zip

Peter

-----------[000525][next][prev][last][first]----------------------------------------------------
Date:      24 Jun 1994 21:16:02 GMT
From:      tli@cisco.com (Tony Li)
To:        comp.protocols.tcp-ip
Subject:   Re: Is there a TCP/IP certification tool ?

In article <CrvvvH.23x@nntpa.cb.att.com> thg@mare.lc.att.com
(ND27005D0-T.GOLDSTEIN(AH0232)XXXX) writes: 
    Does anyone know of a TCP/IP protocol certification  tool
    for a router ?. 
    I called many of the major LAN instrument manufacturers 
    and none had anything  even resembling a certification tool.
    
    Without such a tool how does one make sure that a new router 
    does not crash the network ?
    
With such a tool, how does one make sure that a new router does not crash
the network?

0.5 ;-)

Tony


-----------[000526][next][prev][last][first]----------------------------------------------------
Date:      Fri, 24 Jun 1994 22:41:39 GMT
From:      fred_s@netcom.com (Frederick Scott)
To:        comp.protocols.tcp-ip
Subject:   Re: need ammo to use against bone-headed administrator

sej@flowbee.interaccess.com (Stephen Johnson) writes: 

>>>This information is gleened from several replies to my original post.
>>>According to RFC 950 [Internet Standard Subnetting Procedure] and 
>>>RFC 1122 [Requirements for Internet Hosts -- Communication layers]
>>>subnet fields values of all zero bits or all ones bits are special
>>>values and should not be used for actual subnets. A subnet field of
>>>2 bits (255.255.255.192) has only 2 legal values according to these
>>>RFC's.  I expect that the results of violating these standards are
>>>implementation dependant, your mileage may vary (to quote Peter
>>>Mockapetris).
 
>>This seems a bizarre requirement to me.  All ones or
>>all zeros in the host field implies broadcasts - but the the subnet field?!?
>>I wonder why the would wish to reserve those.  I'm not surprised you were met
>>with skepticism.
 
>I dont think that there is anything bizarre about requiring non-zero 
>subnet fields, the address 130.0.1.1 is not legal.  

Well, there's no reason for it that I can think of.  (Well, I guess I'll
have to read the RFCs to find out.)  All ones and all zeros in host address
implies an IP broadcast so you can't use them as node addresses.  But what
on earth does all ones or all zeros in (just the) subnet field imply that
would cause them to be reserved?

And why do you say 130.0.1.1 is not legal?  Looks perfectly OK to me.
(Now 130.0.0.0 or 130.0.255.255 could cause problems...)

Fred

-----------[000527][next][prev][last][first]----------------------------------------------------
Date:      24 Jun 1994 22:50:57 GMT
From:      leres@hot.ee.lbl.gov (Craig Leres)
To:        comp.protocols.tcp-ip
Subject:   Re: LBL TCPDUMP 3.0 and LIBPCAP 0.0 are now released

Two minor bugs have turned up that are worth mentioning. The first is
the streams nit under SunOS 4 and OSF/1. A number of people have found
that an uninitialized field can cause a "NIOCSFLAGS: Invalid argument"
error.

Also, FDDI support isn't turned on by default (but should be).

I've appended short context diffs for these problems (both should be
applied to libpcap).

As always please send any new bug reports to:

	libpcap@ee.lbl.gov
	tcpdump@ee.lbl.gov

Thanks.

		Craig

RCS file: RCS/pcap-snit.c,v
retrieving revision 1.32
diff -c -r1.32 pcap-snit.c
*** /tmp/,RCSt1a20330	Fri Jun 24 15:48:54 1994
--- pcap-snit.c	Thu Jun 23 13:51:18 1994
***************
*** 20,26 ****
   */
  #ifndef lint
  static  char rcsid[] =
!     "@(#)$Header: pcap-snit.c,v 1.32 94/02/10 23:03:22 leres Exp $ (LBL)";
  #endif
  
  /*
--- 20,26 ----
   */
  #ifndef lint
  static  char rcsid[] =
!     "@(#)$Header: pcap-snit.c,v 1.33 94/06/23 13:51:17 leres Exp $ (LBL)";
  #endif
  
  /*
***************
*** 167,172 ****
--- 167,173 ----
  	struct strioctl si;
  	struct timeval timeout;
  
+ 	si.ic_timout = INFTIM;
  	if (to_ms != 0) {
  		timeout.tv_sec = to_ms / 1000;
  		timeout.tv_usec = (to_ms * 1000) % 1000000;
***************
*** 184,190 ****
  	si.ic_cmd = NIOCSFLAGS;
  	si.ic_len = sizeof(flags);
  	si.ic_dp = (char *)&flags;
- 	si.ic_timout = INFTIM;
  	if (ioctl(fd, I_STR, (char *)&si) < 0) {
  		sprintf(ebuf, "NIOCSFLAGS: %s", pcap_strerror(errno));
  		return (-1);
--- 185,190 ----
RCS file: RCS/Makefile.in,v
retrieving revision 1.35
diff -c -r1.35 Makefile.in
*** /tmp/,RCSt1a20335	Fri Jun 24 15:49:04 1994
--- Makefile.in	Thu Jun 23 14:05:44 1994
***************
*** 17,23 ****
  #  WARRANTIES, INCLUDING, WITHOUT LIMITATION, THE IMPLIED WARRANTIES OF
  #  MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE.
  #
! # @(#) $Header: Makefile.in,v 1.35 94/06/16 20:55:58 leres Exp $ (LBL)
  
  #
  # Edit these paths.  INCLUDE_DIR is where the installed pcap
--- 17,23 ----
  #  WARRANTIES, INCLUDING, WITHOUT LIMITATION, THE IMPLIED WARRANTIES OF
  #  MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE.
  #
! # @(#) $Header: Makefile.in,v 1.36 94/06/23 14:05:11 leres Exp $ (LBL)
  
  #
  # Edit these paths.  INCLUDE_DIR is where the installed pcap
***************
*** 49,55 ****
  
  CCOPT = -O
  INCLUDES = -I.
! DEFINES = $(ETHERS_DEFINES) $(PCAP_DEFINES) $(OS_DEFINES)
  
  # Standard CFLAGS
  CFLAGS = $(CCOPT) $(DEFINES) $(INCLUDES)
--- 49,55 ----
  
  CCOPT = -O
  INCLUDES = -I.
! DEFINES = -DFDDI $(ETHERS_DEFINES) $(PCAP_DEFINES) $(OS_DEFINES)
  
  # Standard CFLAGS
  CFLAGS = $(CCOPT) $(DEFINES) $(INCLUDES)

-----------[000528][next][prev][last][first]----------------------------------------------------
Date:      Fri, 24 Jun 1994 23:40:44 GMT
From:      obelmar@usach.cl (Oscar A. Belmar Madrid)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject:   Re: Auto login with Telnet

: QVT/Net's telnet supports rlogin.  I have a couple of icons
: setup that do rlogin to a couple of unix systems I use a lot.
: With a .rhosts file on the unix machine to allow rlogin without
: a password, I simply double click on the icon and I get a
: window logged on to that machine.

 YEAH .. but i need the same .. but for DOS !!! ..

 Does anyone can help me ????



     thanks ....

_____________________________________________________________________________
 .__. _   .  .          __      Oscar Belmar Madrid --> MadMaX_ 
 |  | |_) |\/|         /  \     E-Mail : obelmar@toconao.usach.cl 
 |__| |__)|  |        /" (_)    Servicios de Computacion e Informatica
   _____             O_,'  \    _Universidad de Santiago de Chile
  /     |              )    \   \\     .  .   _    _    .  .   _  _  _
 |386sx |             /      \_  ))   /| /|  /_|  / \  /| /|  /_| \\//
 |______|__        __/ ./   /  \//   / |/ | /  | /_ / / |/ | /  | //\\ . . .
 |_____    |  ....(___/ \_._\   /          " I'm the Lost Boy "                 
_|_____>___|-<____>  (_/(_(____/______________________________________________


-----------[000529][next][prev][last][first]----------------------------------------------------
Date:      25 Jun 1994 00:25:15 GMT
From:      mre@teal.eng.sun.com (Mike Eisler)
To:        comp.protocols.tcp-ip,comp.sys.sun.misc
Cc:        
Subject:   Re: Reliable UDP Broadcasts?

I believe the algorithm Amoeba used to do reliable sequenced broadcasts
will accomplish what you want. Amoeba used a well-known node on the net
known as the "sequencer". Whenever ever an application on the node
wants to do a broadcast, it sends the request to the sequencer. When
the sequencer receives the request, it increments its sequence number
and broadcasts the message concatenated with the sequence number. Each
node on the network keeps track of the last sequence number it got from
the sequencer. If a node fails to receive a broadcasted message for
whatever reason, in can detect this the next time it receives
broadcasted message with a higher sequence number. For example if the
sequence number of the last broadcast it got was 7 and the next
received broadcast is sequence number 9, then the receiving node knows
that it missed packet # 8 from the sequencer. In that event, it sends a
message to the sequencer asking for the messages that it is missing.
The receiving nodes must take care to avoid processing the broadcasted
messages while there are gaps in the sequence numbers.

In article <1994Jun21.190134.11290@philabs.philips.com>,
Aninda Dasgupta <add@philabs.philips.com> wrote:
>
>Does anyone have any experience with "reliable UDP broadcasts?"
>I am simulating a protocol using UDP broadcasts.  A node
>on the network doesn't know of the existence or identity of the 
>other nodes on the network.  Thus, if node A wishes to discover
>who else is listening to its broadcasts on the subnet, it shouts
>a 'grope' packet.  The reciepients of the grope packet reply 
>back, again using broadcasts.
>
>The problem I am facing is as follows:
>
>Host B and C are listening for broadcasts on the subnet.  Node A
>broadcasts a grope packet, which is received by both B and C.
>Immediately, B and C decide to broadcast grope packets.  However, 
>B does not hear C's broadcast.  Strangely enough, C can hear B's
>broadcast.  I suspect that the UDP packets from C are being
>dropped at B.  I guess that is part of the unreliability of the
>UDP protocols.

The Amoeba protocol solves this because the next time B gets a broadcast
from any node, it will see a gap in the sequence number, and retrieve
C's message from the sequencer.

>If anyone has dealt with such a problem and built a reliability
>layer over UDP broadcasts, I would like to hear from you.  Please
>note that I cannot use end to end acknowledgements as the identity
>of other nodes on the network are not known before the grope packets
>are sent out.  Thus, C cannot expect to get an acknowledgement from
>B as C does not know of B's existence.

Again the amoeba protocol solves this, since neither the sender (node C
in your example), nor the sequencer requires acknowledgement of acks.

The paper I'm referring to:

	AN EFFICIENT RELIABLE BROADCAST PROTOCOL
was written by
	M. Frans Kaashoek
	Andrew S. Tanenbaum
	Susan Flynn Hummel
	Henri E. Bal
of 
	Vrije Universiteit
	Amsterdam, The Netherlands

and I'm pretty sure is available on the Internet somewhere.
It might have been published in Operating Systems Review in 1989.

>Aninda DasGupta (add@philabs.philips.com) Ph:(914)945-6071 Fax:(914)945-6552
>Philips Labs\n 345 Scarborough Rd\n  Briarcliff Manor\n NY 10510
-- 
	-Mike Eisler
	mre@Eng.Sun.Com

-----------[000530][next][prev][last][first]----------------------------------------------------
Date:      Sat, 25 Jun 94 02:58:05 GMT
From:      cmoore@osisys.brisnet.org.au (Charles Moore)
To:        comp.protocols.tcp-ip
Subject:   WINSOCK DNS


Has anyone been able to use winsock TCP/IP to support
DNS, in particular to Linix machines?

Any info would be appreciated.

thanks.

--
Charles_Moore___________________________________________________|   /-_|\   |
Email:cmoore@osisys.brisnet.org.au                              |  /     *  |
Brisbane, Queensland.                                           |  \_,-._/  |
AUSTRALIA.                                                      |       v   |
Work: cmoore@celsius.oz.au                                      |           |


-----------[000531][next][prev][last][first]----------------------------------------------------
Date:      Sat, 25 Jun 94 11:32:04 -0500
From:      baldwinl@delphi.com
To:        comp.protocols.tcp-ip
Subject:   Re: TCP retransmit mechanism

Albert Fu <albert@dn.itg.telecom.com.au> writes:
 
>Should a TCP packet be re-transmitted using a fixed timeout?
>
>I looked at a problem a while ago where a particular packet
>did not get to the destination, and the sending host was 
>retransmitting the packet using fixed timeout (nearly). 
>
>The example on Page 41 of the TCP spec (RFC793), 
>
>          RTO=min[UBOUND,max[LBOUND,(BETA*SRTT)]
 
But of course, all vendors implement TCP the same ..... NOT!
 
For example, IBM TCP/IP for OS/2 calculates an RTO similarly to the
formula you mentioned, HOWEVER THEY IMPOSE A MINIMUM VALUE OF 1000MS!
 
Due to timer resolution issues (e.g. 500ms resolution) actually
retransmission may be delayed 1500ms.  This doesn't cause a problem
for FTP, but Telnet users aren't too happy about waiting 1.5 seconds
for character echo when a packet is dropped in the network.
 

-----------[000532][next][prev][last][first]----------------------------------------------------
Date:      25 Jun 1994 13:58:47 -0400
From:      jhawk@panix.com (John Hawkinson)
To:        comp.protocols.tcp-ip
Subject:   Re: need ammo to use against bone-headed administrator

In <fred_sCryLzw.IA5@netcom.com> fred_s@netcom.com (Frederick Scott) writes:

>1) Which question are you answering above?  I ask two: "why are subnets of
>all-zeroes and all ones" illegal or "why is 130.0.1.1 illegal". 

It looks like I answered the first. I seem to have misread the second
as asking why 130.0.0.1 was illegal. To answer in a confused fashion:
130.0.1.1 is only illegal if subnet mask ranges from 255.255.128.0
through 255.255.254.0. It is legal once you hit 255.255.255.0 (class
C-sized subnets).

>Keep in mind that (I believe, correct me if I'm wrong) that the
>previous poster seemed to assert that 130.0.1.1 was illegal IN THE
>ABSENSE OF ANY SUBNET MASK and I was simply asking why.

It is my understanding that that poster was incorrect. You can _only_
have an all zero or all ones subnet field if you have a particular
netmask. This is because in the absense of a netmask, you never know
the subnet mask. You can make assumptions based on the class of the
address, but doing so is a bad idea because more and more often
you will be incorrect, particularly in a CIDR (Classless InterDomain
Routing) world.

>2) What does the assumption of any particular subnet mask have to do with
>anything?  The previous poster never mentioned one, other than the
>255.255.255.192 mask his sysadmin proposed to use.

See above. A netmask defines just what a the subnet field is set to,
so in the absense of a netmask you cannot know if your subnet field
is all zeroes, all ones, or none of the above.

>3) The first interpretation of "130.0.0.0 with a mask of 255.255.255.0"
>represents the all zero subnet", "The network (all subnets) 130.0.0 thorugh
>130.0.255." is pure and simply not correct.
 
>If you apply the mask to the address, you get only one subnet.

Correct, but not relevant. The zero subnet is intended to represent
all of the networks in that allocation (130.0) of a particular
mask. You cannot merely bitwise AND the mask and the address when
discussing the zero subnet. 

>In what sense do you refer to the other 255 possible subnets and what
>significance does it have?!?

The other 255 subnets are all of the subnets of 130.0 that can
possibly have that mask. That is what subnet zero of 130.0 (with
that mask) refers to, and that is why it is explicitly disallowed
from being used as a real network -- to avoid this ambiguity.

I'm not sure if this helps. This is confusing to think about, and while
I'm trying to be clear, I get the feeling that I'm being just as confusing.

>What I originally wanted to know was, by what reasoning was it necessary
>for the writers of the RFCs to specify that such subnets (all zeroes or
>all ones) should be illegal?


>For instance, all zeroes and all ones in the host address portion of
>the mask implies an IP broadcast and thus cannot be used as node
>addresses.

All zeroes does not necessarily imply a broadcast. Many hosts use
it as such, but the correct convention is all ones. :-)

>But there's no such thing as a "broadcast to all subnets in a net",
>so why should there be a concern with any IP addresses involving all
>the bits in the subnet mask being set to ones (or zeroes) in the
>absense of an all-ones or all-zeroes host address?

The all ones subnet refers to all subnetworks in the context of a
directed broadcast. To cite RFC1122 (page 29 and following, section
3.2.1.3, that being INTERNET LAYER PROTOCOLS/PROTOCOL
WALK-THROUGH/Internet Protocol -- IP/Addressing):
---cut
            We now summarize the important special cases for Class A, B,
            and C IP addresses, using the following notation for an IP
            address:

                { <Network-number>, <Host-number> }

            or
                { <Network-number>, <Subnet-number>, <Host-number> }

            and the notation "-1" for a field that contains all 1 bits.
[...]
            (f)  { <Network-number>, -1, -1 }

                 Directed broadcast to all subnets of the specified
                 subnetted network.  It MUST NOT be used as a source
                 address.
---cut

(Note that this same text (under (f)) appears verbatim in RFC1340 under
Special Addresses, page 4 and following)

It does not seem to mention the usage of the zero subnet, however
it does indicate that it is reserved:

---cut
            The <Network-number> is administratively assigned so that
            its value will be unique in the entire world.

            IP addresses are not permitted to have the value 0 or -1 for
            any of the <Host-number>, <Network-number>, or <Subnet-
            number> fields (except in the special cases listed above).
            This implies that each of these fields will be at least two
            bits long.

            For further discussion of broadcast addresses, see Section
            3.3.6.
---cut

(section 3.3.6 goes on to reiterate the differnt types
of broadcasts)

Furthermore, later discussion indicates that all hosts should
accept and recognize the non-standard broadcast address of 0 rather
than -1. In practice, however, it is my understanding that the 0
usually is taken to refer to the set of networks. Such usage is
never contained within a datagram, but is used by people when talking
to each others, and perhaps in configuring routers.

Page 9 of RFC 922, ``Broadcasting Internet Datagrams in the Presence
of Subnets'' (a not oft-cited RFC, but very useful) states:

---cut
7. Broadcast IP Addressing - Conventions
[...]
   If the use of "all ones" in a field of an IP address means
   "broadcast", using "all zeros" could be viewed as meaning
   "unspecified".  There is probably no reason for such addresses to
   appear anywhere but as the source address of an ICMP Information
   Request datagram.  However, as a notational convention, we refer to
   networks (as opposed to hosts) by using addresses with zero fields.
   For example, 36.0.0.0 means "network number 36" while 36.255.255.255
   means "all hosts on network number 36".
---cut

Lastly, RFC1219 does not address this specific issue, but seems to
be as good a general overview in one place as you'll get of
related issues.

'Seems like it's time for a new RFC -- ``Interpretation and Assignment
of subnet masks in a VLSM (Variable Length Subnet Masks) and CIDR
(Classless InterDomain Routing) world''. Actually, perhaps there's
an Internet Draft that's germane to this topic...

...Nope. A brief perusal of 1id-abstracts.txt shows no such thing, nor does
a scan of 1wg-charters.txt

I think I've said a mouthful here. Hopefully someone can interpret it.

Incidently, whoever started this thread is generating bad message-IDs:

	<sej.772128274@interaccess>

should be:

	<sej.772128274@interaccess.com>

--
John Hawkinson
jhawk@panix.com

-----------[000533][next][prev][last][first]----------------------------------------------------
Date:      25 Jun 1994 14:10:16 -0400
From:      jhawk@panix.com (John Hawkinson)
To:        comp.protocols.tcp-ip
Subject:   Re: need ammo to use against bone-headed administrator

In <2uhr8n$hk9@panix.com> jhawk@panix.com (John Hawkinson) writes:

>Page 9 of RFC 922, ``Broadcasting Internet Datagrams in the Presence
>of Subnets'' (a not oft-cited RFC, but very useful) states:
 
>---cut
>7. Broadcast IP Addressing - Conventions
>[...]
>   If the use of "all ones" in a field of an IP address means
>   "broadcast", using "all zeros" could be viewed as meaning
>   "unspecified".  There is probably no reason for such addresses to
>   appear anywhere but as the source address of an ICMP Information
>   Request datagram.  However, as a notational convention, we refer to
>   networks (as opposed to hosts) by using addresses with zero fields.
>   For example, 36.0.0.0 means "network number 36" while 36.255.255.255
>   means "all hosts on network number 36".
>---cut

Thus, like I said in my first post in this thread, it is relatively
safe to use the all zeroes subnet if you need to, but doing so should
be avoided.

--
John Hawkinson
jhawk@panix.com

-----------[000534][next][prev][last][first]----------------------------------------------------
Date:      Sat, 25 Jun 1994 15:35:55 GMT
From:      fred_s@netcom.com (Frederick Scott)
To:        comp.protocols.tcp-ip
Subject:   Re: need ammo to use against bone-headed administrator

jhawk@panix.com (John Hawkinson) writes: 

>In <fred_sCrxB1F.DIo@netcom.com> fred_s@netcom.com (Frederick Scott) writes:
>
>>Well, there's no reason for it that I can think of.  (Well, I guess I'll
>>have to read the RFCs to find out.)  All ones and all zeros in host address
>>implies an IP broadcast so you can't use them as node addresses.  But what
>>on earth does all ones or all zeros in (just the) subnet field imply that
>>would cause them to be reserved?
 
>>And why do you say 130.0.1.1 is not legal?  Looks perfectly OK to me.
>>(Now 130.0.0.0 or 130.0.255.255 could cause problems...)
>
>The reason is that 130.0.0.0 with a mask of 255.255.255.0 represents
>the all zero subnet. There are two interpretations of what that means:
>
>	1) The network (all subnets) 130.0.0 thorugh 130.0.255.
>	2) The network (one subnet) 130.0.0 (i.e. 130.0.0.0 - 130.0.0.255)
>
>2) is explictly disallowed to remove the ambiguity.

Please.  I don't intend this as a flame.  I may be very gratified to know about
the information in your post once I comprehend it.  But at present I cannot
make head or tail of it.  (Was anyone else as confused as I am???)  While I
may not be as well-versed on the details of the RFCs concerning subnets as I
should be, I have been a developer of IP network software for years and this
STILL doesn't make any sense to me.

Specifically:

1) Which question are you answering above?  I ask two: "why are subnets of
all-zeroes and all ones" illegal or "why is 130.0.1.1 illegal".  Keep in
mind that (I believe, correct me if I'm wrong) that the previous poster
seemed to assert that 130.0.1.1 was illegal IN THE ABSENSE OF ANY SUBNET
MASK and I was simply asking why.

2) What does the assumption of any particular subnet mask have to do with
anything?  The previous poster never mentioned one, other than the
255.255.255.192 mask his sysadmin proposed to use.

3) The first interpretation of "130.0.0.0 with a mask of 255.255.255.0"
represents the all zero subnet", "The network (all subnets) 130.0.0 thorugh
130.0.255." is pure and simply not correct.  If you apply the mask to
the address, you get only one subnet.  In what sense do you refer to the
other 255 possible subnets and what significance does it have?!?

It sounds to me as if you are trying to point out some ambiguity in the
legality of different subnets but your explanation has been totally lost
for lack of relevant details.  There seems no ambiguity that I can
perceive.

What I originally wanted to know was, by what reasoning was it necessary
for the writers of the RFCs to specify that such subnets (all zeroes or
all ones) should be illegal?  For instance, all zeroes and all ones in the
host address portion of the mask implies an IP broadcast and thus cannot
be used as node addresses.  But there's no such thing as a "broadcast to
all subnets in a net", so why should there be a concern with any IP
addresses involving all the bits in the subnet mask being set to ones (or
zeroes) in the absense of an all-ones or all-zeroes host address?

Fred

-----------[000535][next][prev][last][first]----------------------------------------------------
Date:      Sat, 25 Jun 1994 16:59:44 GMT
From:      ussw@netcom.com (Don Dunstan)
To:        comp.os.ms-windows.networking.tcp-ip,comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject:   Re: A Leaner TCP/IP For DOS ?

Christopher J. Wood (chrisw@sco.COM) wrote:


: Hi,
 
: I am looking for a DOS implementation of TCP/IP
: that requires *AS LITTLE MEMORY AS POSSIBLE! *
 
: All my customer needs is tcp/ip -- no utils 
: (rlogin, ftp, snmp, etc.).

The USNET implementation of TCP/IP from U S Software
takes about 20K bytes on an x86 or 68K target.  It
will run on DOS.

For more information call 503 641-8446 or email ussw@netcom.com

-----------[000536][next][prev][last][first]----------------------------------------------------
Date:      25 Jun 1994 20:41:13 GMT
From:      jgoldman@cpcug.digex.net (Jonathan Goldman)
To:        comp.protocols.tcp-ip
Subject:   Ports for WWW?

I'm trying to use Cello on a system with heavy filtering and would like 
to know what ports I need to permit in either direction.  I know I need 
telnet (23) and gopher (70) going out as well as > 1023 coming in.  What 
else is needed in either direction to run the WWW apps (HTTP, etc.)?

TIA,

Jonathan

-----------[000537][next][prev][last][first]----------------------------------------------------
Date:      Sat, 25 Jun 1994 21:09:31 GMT
From:      ddrg@superior.carleton.ca (Duncan Glendinning)
To:        comp.protocols.tcp-ip
Subject:   Re: TAXI

In <Crx012.DuB@amd.com> roberts@angelo.amd.com (Dave Roberts) writes:

>In article <1994Jun20.174312.15373@afterlife.ncsc.mil>,
>Chris A. Wilcox <cawilco@afterlife.ncsc.mil> wrote:
>>In article <940620032033@news.tra.com>, Earl E. McCoy <emccoy@tra.com> wrote:
>>>
>>>This may not be the right group for this question but I have run out
>>>of local resources and my boss wants to know: What does TAXI stand
>>>for (the 100Mbps/140Mbps FDDI interface). Thanks in advance. Earl
>>
>>If I'm not mistaken, it is the Transparant Asynchronous
>>Transmitter/Receiver Interface.
 
>Not that this belongs here, but TAXI, or more specifically TAXIchip,
>is an AMD trade name for its high-speed asynchronous serial datacomm
>products.  The acronym expansion is as Chris describes it above.  TAXI
>really has nothing to do with FDDI (we've got a few other products
>that do the necessary magic for FDDI).  TAXI has been used extensively
>in various ATM implementations and has become a recognized physical
>layer within the ATM community.

At 100 Mbps (TAXI 125 parts).  (The 140 Mbps variant is not a recognized PMD.)
-- 
Duncan Glendinning         ddrg@ccs.carleton.ca
Carleton University
Ottawa, Ontario
K1S 5B6

-----------[000538][next][prev][last][first]----------------------------------------------------
Date:      Sat, 25 Jun 1994 23:11:16 GMT
From:      mitch@cirrus.com (Mitch Wright)
To:        comp.os.ms-windows.networking.tcp-ip,comp.os.ms-windows.programmer.networks,comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject:   Re: Writing Winsock DLL (TCP/IP Stack) from Scratch

/* In <mikey.142.000B6775@mcs.com> mikey@mcs.com (Mike Young) writes: */

>>From: mweiss@nwk.cl.nec.co.jp (Michael J. Weiss)
>>Date: 24 Jun 1994 08:12:53 -0500
 
>>If I end up having to write a Winsock DLL (TCP/IP stack) from scratch,
>>what materials would help me?
 
>[...]
>Why would you want to do something like that???
>
Well, what if you want to slightly change the functionality so it can use
a proxy gateway like SOCKS?  That would be my #1 reason.

   ~mitch

-----------[000539][next][prev][last][first]----------------------------------------------------
Date:      26 Jun 94 03:43:46 GMT
From:      tom@wcc.oz.au (Tom Evans)
To:        comp.protocols.tcp-ip,comp.protocols.appletalk,comp.sys.mac.comm
Subject:   Re: Mac Plus and TCP

In article <richlove.1122077620A@192.100.81.105>, richlove@netcom.com (Rich Love) writes:
> Several people have reported problems trying to make a Mac Plus work with
> MacTCP. Has anyone out there had this problem and if so is there a solution
> to it? Here are the posts I copied from the Mac Communications newsgroup:

This is really old (1991) information, but may be relevant again.

> From: shoemake@apple.com (Mike Shoemaker)
> Newsgroups: comp.protocols.appletalk
> Subject: Re: conflict between MacTCP 1.1 and Appletalk 56
> Date: 17 Jan 92 01:11:07 GMT
 
> In article <1992Jan10.233517.25381@reed.edu>, mdunn@reed.edu (Marvin Dunn) writes:
> > Has anyone else had problems with MacTCP 1.1 and the new version of 
> > Appletalk 56 (as installed by CE Software's installer)??
> 
> Yes, this is the 'problem' with MacTCP 1.1 on MacPlus's running
> System 7 (which has AppleTalk 56).
> 
> Both the MacTCP 1.1 socket listener code and the lower levels of Appletalk
> v56 LocalTalk code each grew in code length in the critical path for packet
> delivery. The net result is MacTCP 1.1 doesn't always read in the packet
> soon enough to prevent an underrun error on the SCC chip causing a
> dropped packet.

Summary:
MacTCP 1.1 and System 7 with AppleTalk V56 wouldn't work on a Mac Plus
because of "code bloat" in V56 and the Plus being the slowest Macintosh..

An "unofficial patch" was released that fixed the problem. The fix was
supposedly included in MacTCP 1.1.1 (but I have a report of patched
1.1 working while 1.1.1 didn't).

Perhaps MacTCP 2.0.4 has bloat. Perhaps your AppleTalk 58.x.y has
bloat. Perhaps its a different problem. Back your Mac Plus to System
6.0.x (suggest 6.0.5) and pre-V56 AppleTalk and MacTCP 1.1.1 and see
if that works. You may have a hardware/gateway/config problem after all.

========================
Tom Evans  tom@wcc.oz.au
Webster Computer Corp P/L, 11 Glenvale Crescent Mulgrave, Melbourne 3170
Victoria, Australia 61-3-561-9999  FAX ...560-0067  A.C.N. 004 818 455

wcc@cup.portal.com, AppleLink: "WEBSTER.USA"
2109 O'Toole Avenue, Suite J. San Jose, CA 95131-1338 USA
1-408-954-8054  (800) 5 WEBSTE(R)  FAX 1-408-954-1832  

-----------[000540][next][prev][last][first]----------------------------------------------------
Date:      Sun, 26 Jun 94 04:50:35 GMT
From:      hal9001@panix.com (Robert A. Rosenberg)
To:        comp.protocols.tcp-ip,comp.sys.apple2.comm,comp.sys.mac.apps,comp.sys.mac.misc
Subject:   Re: Network tools survey

In Article <Crr0pG.332@ees1a0.engr.ccny.cuny.edu>, csylk@cspublic2 (Yoon
Kimn) wrote:
>
>First, I appologize if this is not the right newsgroup (and also cross
 posting).
>
>I've been given a job of doing complete survey on tools such as eudora, fetch,
 etc.
>      
>My superiors want me to survey all softwares including public domain, freeware,
 share-
>ware, as well as commercial products. The other stuff is rather easy to find,
 but the 
>only commercial product I know of is TCP/IP CONNECT from the Intercon System.
>
>Can someone tell me any commercial products (for Mac) out there?
>
>Also I'll appreciate it very much if anybody can direct me to the right
 newsgroup or
>mailing list to which a lot of those vendors join so that I can continue with
 the survey.
>
>Thanks a million.
>
>


There is also the VersaTerm Line which includes VersaTerm Link.
>
>Yoon Kimn
>City College of CUNY, NYC
>email: yoon@cs-mail.engr.ccny.cuny.edu
>
>

-----------[000541][next][prev][last][first]----------------------------------------------------
Date:      Sun, 26 Jun 1994 08:55:23 GMT
From:      tru@kddnews.kddlabs.co.jp (Tohru Asami)
To:        comp.protocols.tcp-ip
Subject:   Re: AF_UNIX & AF_INET Domains


Thanks a lot for many responses to my previus article. I summarize
all the responses as follows:

Suppose there are two processes A and B communicating with each other
via stream connection.

1. If I choose AF_UNIX domain, the socket name can be given as
   a path name. In that case, how are data passed from A to B?
   Even in this case, it will be a bad idea to send data via
   a physical filesystem. I suppose the followings:
   Process A -write--> Some area in the main memory -read---> Process B

visser@convex.com (Lance Visser) writes:
   UNIX domain uses the file system namespace to establish connections.
   It creates the file, but the file is little more than a placeholder
   in the system.  The file does not have anything to do with data
   transfer as best I remember.  The file system provides an
   alternative connection namespace, that is all.
barmar@think.com (Barry Margolin) writes:
   No.  Unix domain sockets don't use TCP/IP at all.  They usually use
   the same internal kernel mechanisms as pipes.
guy@netapp.com (Guy Harris) writes:
   No, it just means AF_UNIX - there's no Internet-protocol code
   involved when you send stuff over an AF_UNIX socket, there's just
   UNIX-domain-socket code (which, in all the flavors of UNIX I've seen,
   does not send data through the file system).
SUMMARY:
   Using the same internal kernel mechanisms as pipes, UNIX domain
   uses the file system namespace to establish connections.  It creates
   the file, but the file is little more than a placeholder in the
   system.  The file does not have anything to do with data transfer.
   The file system provides an alternative connection namespace, that
   is all. Unix domain sockets don't use TCP/IP at all.


2. If I choose AF_INET domain for the interprocess communication
   between 2 processes A and B on the SAME machine. The protocol
   stack will be:
   Process A                    Process B
   Socket          --write--->  Socket
   TCP             --write--->  TCP
   IP              --write--->  IP
   I/O Driver      --write--->  I/O Driver
   Ethernet        --write--->  Ethernet

   There can be several possible layers to loop the data physically
   back to Process B. 

visser@convex.com (Lance Visser) writes:
   Most systems dont ever transfer data by self-receive on an interface.
   IP detects that the request is to the local host and loops the packet
   back in software. The problem with this sort of loopback is that on
   many systems, the MTU (maximum transmission unit) used by IP is
   somewhere around 1500 bytes. This means if you send large amounts of
   data, it will be fragmented and reassembled in the IP layer
   unnecessarily. The best way to do loopback IMO is to use AF_INET and
   the special loopback address 127.0.0.1.

(1) Data written for 127.0.0.1 with TCP/UDP protocols are passed via
    some memory buffers shared among processes, physically using TCP/UDP
    protocols.

barmar@think.com (Barry Margolin) writes:
   Not quite.  It's done at the device driver level.  When IP writes
   something to the loopback interface, the device driver simply moves
   the data into the receive queue.  The normal processing of received
   data then causes it to go back up the protocol stack.
guy@netapp.com (Guy Harris) writes:
   Using AF_INET with the loopback address (127.0.0.1) works in the
   first way you list - i.e., it uses TCP or UDP protocols, and the
   data is passed, in the UNIX systems with which I'm familiar, via
   memory buffers in the kernel that (being in the kernel's address
   space) are shared between processes (either socket mbufs or STREAMS
   buffers, depending on whether the protocol code is running atop the
   BSD socket code or atop SV-style STREAMS).  It does not bypass the
   TCP or UDP protocol code.

(2) Use only TCP/UDP port number and neglect all other protocol
    stuff to exchange data between processes. Data passing is physically
    made with hardware/OS specific mechanisms such as shared memory
    space, etc.

barmar@think.com (Barry Margolin) writes:
    This would not be right.  The loopback interface is required to
    behave just like any other network interface.  If it only supported
    TCP and UDP then it would not be like other interfaces.  It must
    support all IP facilities.

SUMMARY:
   Most systems do not transfer data by self-receive on an interface.
   IP detects that the request is to the local host and loops the packet
   back in software.  If we use a normal internet address for loop
   back, on many systems, the MTU (maximum transmission unit) used by
   IP is somewhere around 1500 bytes. This means if you send large 
   amounts of data, it will be fragmented and reassembled in the IP
   layer unnecessarily.
But as for the packet fragmentation for the special loopback address
127.0.0.1, there are some diffrent comments. Lance Visser and Guy
Harris seem to think that a packet for 127.0.0.1 is not fragmented,
but others do not think so. Anybody who knows which is the real UNIX
implementation?

Tohru Asami

--
Network Engineering Support Group, KDD R&D Labs.
2-1-15 Ohara Kamifukuoka-shi, Saitama 356, Japan
Phone: +81 492 66 7890, FAX: +81 492 66 7510, E-Mail: tru@kddlabs.co.jp
KDD = an international telecommunication company in Japan

-----------[000542][next][prev][last][first]----------------------------------------------------
Date:      Sun, 26 Jun 94 10:31:21 DST
From:      anka@slama.pub.hr (Anka Novkovic)
To:        comp.protocols.tcp-ip,comp.unix.programmer
Subject:   Re: TCP programming problem

jtalvy@cantor.com (James Talvy) writes:

> 
> I am having a problem with a client-server app that I am developing.  The
> problem is that I have a TCP connection between the two of them and the
> program gets into a state that the server is blocked trying to write to the
> client and the client turns off his computer.  As a consequence, the server
> sits on the write() system call forever.  I want to know why the server is
> not notified with an error return that the client has broken the connection.
> (P.S. I have already tried SO_KEEPALIVE to no avail)              

    I had the same problem with ORACLE client server application
    (ORACLE/UNIX server didn't recognise when clients die and keep the
    daemon alive forewer - SQL*NET TCP/IP was the kind of connection) which
    I made a bit better setting TCPKEEPIDLE parameter to 1 instead of
    default 120 - after that the connection remains opened for few minutes
    and then close. I prefer it to be closed immediatelly, so if anyone has
    a better idea, please let me know too.
    (P.S. According to ORACLE people, this is UNIX-TCP/IP related problem)

        Anka


-----------[000543][next][prev][last][first]----------------------------------------------------
Date:      Sun, 26 Jun 1994 10:44:04 GMT
From:      king@reston.ans.net (Greg King)c
To:        comp.os.ms-windows.networking.tcp-ip,comp.os.ms-windows.programmer.networks,comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject:   Re: Writing Winsock DLL (TCP/IP Stack) from Scratch

In article <1994Jun25.231116.9771@cirrus.com>, mitch@cirrus.com (Mitch Wright) says:
>
>/* In <mikey.142.000B6775@mcs.com> mikey@mcs.com (Mike Young) writes: */
>
>>>From: mweiss@nwk.cl.nec.co.jp (Michael J. Weiss)
>>>Date: 24 Jun 1994 08:12:53 -0500
 
>>>If I end up having to write a Winsock DLL (TCP/IP stack) from scratch,
>>>what materials would help me?
 
>>[...]
>>Why would you want to do something like that???
>>
>Well, what if you want to slightly change the functionality so it can use
>a proxy gateway like SOCKS?  That would be my #1 reason.
>
>   ~mitch

FYI, Its my understanding that Peter Tattam has been working
on a socksified version of Trumpet Winsock and that it may be
in BETA now.  There was a post a while back to the firewalls
lists about a month ago.  Let me know if you need more info.

Regards,

Greg

BTW, I can think of other reasons such as maybe adding the
IP security protocol.

*********************************************************
Greg King, Advanced Network & Services (ANS)
king@reston.ans.net
*********************************************************

-----------[000544][next][prev][last][first]----------------------------------------------------
Date:      26 Jun 1994 19:05:50 -0500
From:      phil@zeus.fasttax.com (Phil Howard)
To:        comp.protocols.tcp-ip
Subject:   Re: need ammo to use against bone-headed administrator

fred_s@netcom.com (Frederick Scott) writes:

>1) Which question are you answering above?  I ask two: "why are subnets of
>all-zeroes and all ones" illegal or "why is 130.0.1.1 illegal".  Keep in
>mind that (I believe, correct me if I'm wrong) that the previous poster
>seemed to assert that 130.0.1.1 was illegal IN THE ABSENSE OF ANY SUBNET
>MASK and I was simply asking why.

As far as I can tell it avoids the abiguity of using all 0's in the host
part of the address (where subnetting is done) to identify the network,
and using all 0's in the subnetted host part of the address to identify
a fully qualified subnet.

36.0.0.0 would mean the whole class A network.  36.128.0.0 when used in
the context of a network would imply a subnet (the mask is needed to
know just what hosts are in a particular subnet).


>2) What does the assumption of any particular subnet mask have to do with
>anything?  The previous poster never mentioned one, other than the
>255.255.255.192 mask his sysadmin proposed to use.

Assuming class C, which later was indicated, this indicates that the
network was subdivided 4 ways, the first and last of which may be ambiguous
in many uses.  If the subnet was 255.255.255.240 then the number of subnets
would be all different.


>3) The first interpretation of "130.0.0.0 with a mask of 255.255.255.0"
>represents the all zero subnet", "The network (all subnets) 130.0.0 thorugh
>130.0.255." is pure and simply not correct.  If you apply the mask to
>the address, you get only one subnet.  In what sense do you refer to the
>other 255 possible subnets and what significance does it have?!?

Yes, when you apply the mask, there is a subnet.  The zero subnet would
have the same expression as the whole base network, in this case it would
be "130.0.0.0".  The problem is that you need to indicate if this is a
subnet, and there are places where you cannot.  By avoding the use of
the first (and last) subnets in a set of subnets you avoid the ambiguity.
For small sets this can lose a lot of addresses.


>It sounds to me as if you are trying to point out some ambiguity in the
>legality of different subnets but your explanation has been totally lost
>for lack of relevant details.  There seems no ambiguity that I can
>perceive.

If I do "route -net 130.0.0.0" am I refering to the whole network or am
I referring to a particular subnet and thus need to use a mask?


>What I originally wanted to know was, by what reasoning was it necessary
>for the writers of the RFCs to specify that such subnets (all zeroes or
>all ones) should be illegal?  For instance, all zeroes and all ones in the
>host address portion of the mask implies an IP broadcast and thus cannot
>be used as node addresses.  But there's no such thing as a "broadcast to
>all subnets in a net", so why should there be a concern with any IP
>addresses involving all the bits in the subnet mask being set to ones (or
>zeroes) in the absense of an all-ones or all-zeroes host address?

Your question is a good point and I answered based on experience and NOT
on reading the history of TCP/IP in the RFCs.  Real and accurate answers
may be there.  I don't know that there is any special meaning to the first
and last subnet as there is to the first and last host in a net or subnet.
But I do know from experience that assigning such a subnet gets you into
problems with some network routers which don't have very explicit ways to
specify exactly what you want.  Further, internal routing and other network
information may itself have these ambiguities.

-- 
Phil Howard KA9WGN      | The drive spec says the capacity is 600mb unformatted
Unix/Internet/Sys Admin | and 525mb formatted.  So where do I find an unformat
CLR/Fast-Tax            | utility?
phil@fasttax.com        |

-----------[000545][next][prev][last][first]----------------------------------------------------
Date:      26 Jun 1994 12:41:17 UT
From:      Erik Naggum <erik@naggum.no>
To:        comp.protocols.tcp-ip,comp.unix.programmer
Subject:   Re: TCP programming problem

[Anka Novkovic]

|   I had the same problem with ORACLE client server application
|   (ORACLE/UNIX server didn't recognise when clients die and keep the
|   daemon alive forewer - SQL*NET TCP/IP was the kind of connection) which
|   I made a bit better setting TCPKEEPIDLE parameter to 1 instead of
|   default 120 - after that the connection remains opened for few minutes
|   and then close. I prefer it to be closed immediatelly, so if anyone has
|   a better idea, please let me know too.
|   (P.S. According to ORACLE people, this is UNIX-TCP/IP related problem)

it appears from your previous articles that you run an SVR4 system, and are
largely unware that other systems exist.  now, System V implementations of
TCP/IP are somewhat inferior in performance compared to BSD-derived
implementations, so when you say "UNIX-TCP/IP" related, it really means
System V-related.  TCP/IP has several mechanisms to detect when clients
die.  if the client program dies, the connection should be shut down.  if
"client" is a machine, it should have forgotten the connection by the time
it comes back to life, and should send an RST in response to any non-SYN
packets on the relevant ports.  ORACLE's servers could easily have used the
keepalive mechanism to force this to happen.

isn't it typical that vendors engage in finger-pointing?

</Erik>
--
Erik Naggum <erik@naggum.no> <SGML@ifi.uio.no>       |  memento, terrigena
ISO 8652 Ada/ISO 8879 SGML/ISO 9899 C/ISO 10646 UCS  |  memento, vita brevis

ftp://ftp.ifi.uio.no/pub/SGML           wais://ftp.ifi.uio.no/comp.text.sgml

-----------[000546][next][prev][last][first]----------------------------------------------------
Date:      Sun, 26 Jun 1994 14:01:26 GMT
From:      mike@rayleigh.aftac.gov (Mike Black)
To:        comp.protocols.tcp-ip,comp.unix.programmer
Subject:   Re: TCP programming problem

In article <19940626.3272@naggum.no> Erik Naggum <erik@naggum.no> writes:
>TCP/IP has several mechanisms to detect when clients
>die.  if the client program dies, the connection should be shut down.  
>
>isn't it typical that vendors engage in finger-pointing?
>

If a tcp client machine "dies" (e.g. the user simply hits the on/off
switch) the server will have no way to tell that this has occurred
except by timeouts.  What will happen is the tcp buffer will start
filling and eventually will not be available for select() as the buffer
wil become full.  It is then up to the server to determine what to do,
i.e. wait or terminate.  

Oracle does have a timeout parameter.  Oracle was absolutely correct in 
that this is a TCP/IP related "problem".

TCP/IP has NOTHING in the underlying DEFAULT behaviour to ensure that
the connection you're talking to is still alive.  However, this is
generally a problem with any point-to-point communication.  If one side
rudely disconnects the only way the other side will know is by some
prearranged protocol.  This wasn't much of a problem until TCP got put
on DOS boxes where users are quite prone to either hit the power switch
or lock up the machine.


-- 
mike@rayleigh.aftac.gov

-----------[000547][next][prev][last][first]----------------------------------------------------
Date:      27 Jun 1994 01:02:20 -0500
From:      mweiss@nwk.cl.nec.co.jp (Michael J. Weiss)
To:        comp.os.ms-windows.networking.tcp-ip,comp.os.ms-windows.programmer.networks,comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject:   IS THIS FEASIBLE?

I was wondering if the following approach to arriving at a WINSOCK.DLL
with source is feasible:

I have heard that WATTCP is a public domain TCP/IP stack that works as a
TSR.  I remember someone mentioning to me (I am corresponding with a lot of
TCP/IP people lately) that a particular commercial package had a TSR
stack and their WINSOCK.DLL was just a shell which, for each winsock
call made to it, passes the appropriate commands onto the TSR.

Do you think I could implement such a scheme using WATTCP?
What would be involved and how difficult would it be/how long will it
take ?


Thanks for your help.

PS. I have a big meeting on wednesday night (Japan Time) concerning this
project, so prompt responses are especially appreciated.

--Mike

-----------[000548][next][prev][last][first]----------------------------------------------------
Date:      27 Jun 1994 01:05:33 -0500
From:      mweiss@nwk.cl.nec.co.jp (Michael J. Weiss)
To:        comp.os.ms-windows.networking.tcp-ip,comp.os.ms-windows.programmer.networks,comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject:   THE winsock??

I heard someone mention that soon Microsoft will be coming out with THE
definitive winsock specification and that winsock.dll will come with
windows?

Does anyone have anymore information on this topic?

Am I right in assuming that the source code for this winsock.dll will
not be available?

Thanks,

Mike

-----------[000549][next][prev][last][first]----------------------------------------------------
Date:      27 Jun 1994 00:32:17 -0400
From:      jhawk@panix.com (John Hawkinson)
To:        comp.protocols.tcp-ip
Subject:   Re: "standard" version of /etc/services ?

In <2uku9k$af0@news1.svc.portal.com> don_jackson@clark-comm.com (Donald Clark Jackson) writes:

>Hello:
 
>I run SunOS 4.1.3, when looking at my /etc/services I notice that
>there are lots of new services that do not appear here.  Is there an
>"official" list of ietf standard (& proposed standard) internet
>services that I could obtain (kind of like the hosts.txt file)?

Yes -- RFC1340, ``Assigned Numbers''.

--
John Hawkinson
jhawk@panix.com

-----------[000550][next][prev][last][first]----------------------------------------------------
Date:      Sun, 26 Jun 1994 18:26:33 GMT
From:      FLAVELL@cernvm.cern.ch (Alan J Flavell)
To:        comp.protocols.tcp-ip,comp.dcom.servers
Subject:   Q: PCROUTE by Vance Morrison

Could someone suggest, please, which group would be proper to ask
a question about PCROUTE by Vance Morrison?
 
The free version of this software is now quite old, but we have
had good results with it as an ethernet-ethernet IP-only router.
 
We now have a situation where it would be great to use its SLIP
feature to provide one SLIP port.  I.e we have the hardware already,
and the software price is right ;-)  We do not wish to use up an
entire (sub)network number for this SLIP line - there is a hint
in the documentation that one can avoid this, but the description
is a bit cryptic and I'm looking for someone to explain it in
detail (I've tried a number of variations on what it seems to be
saying, but none of them were actually successful).

-----------[000551][next][prev][last][first]----------------------------------------------------
Date:      Sun, 26 Jun 1994 19:12:18 GMT
From:      philip@cs.vu.nl (Philip Homburg)
To:        comp.protocols.tcp-ip,comp.sys.sun.misc
Subject:   Re: Reliable UDP Broadcasts?

In article <2ufthb$r4a@engnews2.Eng.Sun.COM> mre@teal.eng.sun.com (Mike Eisler) writes:
%Again the amoeba protocol solves this, since neither the sender (node C
%in your example), nor the sequencer requires acknowledgement of acks.
%
%The paper I'm referring to:
%
%	AN EFFICIENT RELIABLE BROADCAST PROTOCOL
%was written by
%	M. Frans Kaashoek
%	Andrew S. Tanenbaum
%	Susan Flynn Hummel
%	Henri E. Bal
%of 
%	Vrije Universiteit
%	Amsterdam, The Netherlands
%
%and I'm pretty sure is available on the Internet somewhere.
%It might have been published in Operating Systems Review in 1989.

Selected Amoeba papers are available in ftp.cs.vu.nl:/pub/amoeba/amoeba_papers.
group94.ps.Z gives a detailed description of the group protocol used in Amoeba.

-----------[000552][next][prev][last][first]----------------------------------------------------
Date:      Sun, 26 Jun 1994 20:09:32 GMT
From:      martineau@MacMartineau.ccr.hydro.qc.ca (Alain Martineau)
To:        comp.protocols.tcp-ip
Subject:   info request on IP multicasting

I am looking for sources of information on IP multicasting
protocols, routing and applications. Books and public documents.

Thank you

Alain Martineau
Hydro Quebec
amartineau@nccr.ccr.hydro.qc.ca

-----------[000553][next][prev][last][first]----------------------------------------------------
Date:      27 Jun 1994 08:24:29 -0700
From:      phil@lykos.netpart.com (Phil Trubey)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject:   Microsoft's Windows Internet Name Service?

Does anyone have some detailed info about Microsoft's new 
Windows Internet Name Service that they will be offering in their upcoming
TCP/IP products?  I remember reading somewhere that it was similar to DNS, but
not, in fact, DNS.  Does this mean that large sites that currently use DNS
will have to maintain two machine naming systems?

Thanks for any info,
-- 
Phil Trubey                 | Providing independent consulting in the 
NetPartners                 |   application of Internet technology.
E-mail: phil@netpart.com    |   Home Page: http://www.netpart.com/

-----------[000554][next][prev][last][first]----------------------------------------------------
Date:      26 Jun 1994 22:08:52 GMT
From:      don_jackson@clark-comm.com (Donald Clark Jackson)
To:        comp.protocols.tcp-ip
Subject:   "standard" version of /etc/services ?

Hello:

I run SunOS 4.1.3, when looking at my /etc/services I notice that there are lots of
new services that do not appear here.  Is there an "official" list of ietf standard (& proposed standard) internet services that I could obtain (kind of like the hosts.txt file)?

Don


-----------[000555][next][prev][last][first]----------------------------------------------------
Date:      Sun, 26 Jun 1994 23:10:00 GMT
From:      glenn@mips.bhpese.oz.au (Glenn McNally)
To:        comp.protocols.tcp-ip,comp.unix.programmer
Subject:   Re: TCP programming problem

anka@slama.pub.hr (Anka Novkovic) writes:

>jtalvy@cantor.com (James Talvy) writes:
 
>> 
>> I am having a problem with a client-server app that I am developing.  The
>> problem is that I have a TCP connection between the two of them and the
>> program gets into a state that the server is blocked trying to write to the
>> client and the client turns off his computer.  As a consequence, the server
>> sits on the write() system call forever.  I want to know why the server is
>> not notified with an error return that the client has broken the connection.
>> (P.S. I have already tried SO_KEEPALIVE to no avail)              
 
>    I had the same problem with ORACLE client server application
>    (ORACLE/UNIX server didn't recognise when clients die and keep the
>    daemon alive forewer - SQL*NET TCP/IP was the kind of connection) which
>    I made a bit better setting TCPKEEPIDLE parameter to 1 instead of
>    default 120 - after that the connection remains opened for few minutes
>    and then close. I prefer it to be closed immediatelly, so if anyone has
>    a better idea, please let me know too.
>    (P.S. According to ORACLE people, this is UNIX-TCP/IP related problem)
 
>        Anka

I have just developed some TCP stuff between UNIX and Windows 3.11 (Winsock)
and had the same problem. When the PC connection closed, the UNIX side did
not see it. I solved this by setting the SO_LINGER option on the PC side
to disconnect immediately. The UNIX side gets 'Connection Reset By Peer'.

glenn
-- 
Glenn McNALLY   BHP Information Technology, Newcastle, NSW, Australia.
INTERNET: glenn@bhpese.oz.au                      PHONE: +61 49 401695

-----------[000556][next][prev][last][first]----------------------------------------------------
Date:      27 Jun 1994 12:27:05 -0700
From:      jdw@cs.pdx.edu (Jeff Wandling)
To:        comp.protocols.tcp-ip
Subject:   Applications for multi-ethernet/homed addresses

Hey,  I know it's too early in the morning for something this deep, but
I'm in a pickle.

I neeed to know the feasibility of the following:

Does anyone know of a use for multiple IP addresses for the same machine?
Is this possible?  Is there a way to create pseduo ethernet interfaces (like 
what ppp does, but not exactly) and have each pseduo interface linked to each IP
address that has been 'multi-homed' to this one server.


Like, i'd do something ala:


(port list of pseduo ethernet addresses into kernel)

ifconfig fake0 123.1.2.3 , etc...
ifconfig fake1 123.1.2.4 , etc...

(then some how configure gated to inform the kernel of the following

accept connections to the fake IP as if it were a real machine. use
the corresponding fake ethernet device (the pseduo ethernet device) and the
hacked ethernet drivers in the kernel for that interface to do whatever.

Like, running a single server process listening to a specific port and the kernel (now aware of each pseduo interface) can route those packets (each with
an identifier of which IP they originally were destin'd for) to the server
process.



The alternative to doing this is harder to  explain, but probably not as
feasable.

That is, to do a seth-brundle-fly work and join named and this server process
at the hip.  when a request is made to the server's domain's DNS, queue up 
that request. then, when the server is actually connected to, then the 
server can ask the DNS server (named) "hey, who was the last guy from 
(client IP) to resolve one of these names)

Ok, I'm done fighing the line noise and low-bandwitdh.  If you know

1.  Any applications, papers, chapters, etc, (even URLs) of docs, lemme
know
2.  If you are interested in hearing more, drop me a line so I can get
off this damm news client and into a faster mail-shell.


ObDefinition:    Lag.  The time spent in line at the unemployment office
of your town after being fired from your job because you kicked the console tube of your terminal because the latency was so bad you had time for your newly
brewed cup of coffee to cool and drink between each keypress.


-- 
jeff wandling <jdw@cs.wwu.edu>

-----------[000557][next][prev][last][first]----------------------------------------------------
Date:      27 Jun 1994 01:35:26 GMT
From:      mjr@tis.com (Marcus J Ranum)
To:        comp.protocols.tcp-ip
Subject:   Re: Authentification of users on dialup terminal servers

>It's either encouraging or depressing that with the current selection
>of radius, tacacs, xylogics, and telebit protocols, there is no clear
>customer concensus that any of these are good enough to settle on as
>a standard...

	It's definitely discouraging! Worse, there's no standard
API -- if you want to add hooks to your code, you have to modify
it for each authentication system's client libraries, too. My
limited examination of the different protocols indicates that they
are all either a) insanely overcomplicated or b) rigged to work
with only one vendor's equipment. That's why the TIS Firewall
Toolkit uses this incredibly minimalist approach of passing back
and forth newline terminated strings. (How much more portable can
you *GET*?!)  It's too simple for any vendor to ever support it,
though, so don't worry. :)

mjr.

-----------[000558][next][prev][last][first]----------------------------------------------------
Date:      27 Jun 1994 03:28:31 GMT
From:      mwong@cs.ubc.ca (Marie Wong)
To:        comp.protocols.tcp-ip
Subject:   FAQ for newsgroup

Hello all, would somebody be kind enough to point me to where I can  get the FAQ for this
newsgroup? Please reply to <mwong@cs.ubc.ca>.

Thanks in advance,

Helene Wong.

-----------[000559][next][prev][last][first]----------------------------------------------------
Date:      27 Jun 1994 11:12:50 -0400
From:      jhawk@panix.com (John Hawkinson)
To:        comp.protocols.tcp-ip
Subject:   Re: Mobile*IP

In <2umo6i$b2p@adam.cs.tu-magdeburg.de> elkner@fichte.cs.tu-magdeburg.de (Jens Elkner) writes:

>Does anybody know, where I can get information about
>MOBILE*IP (scripts, rfc-drafts etc.) or where I can
>ftp some infos ???


Internet drafts are available from your favorite
draft repository (try ds.internic.net:/internet-drafts).
---cut	
IP Routing for Wireless/Mobile Hosts (mobileip)
-----------------------------------------------
 
 Charter 
 
 Current status: active working group
 
 Chair(s):
     Kannan Alagappan  <kannan@sejour.lkg.dec.com>
     Greg Minshall  <minshall@wc.novell.com>
 
 Routing Area Director(s) 
     Joel Halpern  <jhalpern@newbridge.com>
 
 Mailing lists: 
     General Discussion:mobile-ip@ossi.com
     To Subscribe:      mobile-ip-request@ossi.com
     Archive:           loki.ossi.com:/pub/mobile-ip/
 
Description of Working Group:
 
The Mobile IP Working Group is chartered to develop or adopt
architectures and protocols to support mobility within the Internet.
In the near-term, protocols for supporting transparent host ``roaming''
among different subnetworks and different media (e.g., LANs, dial-up
links, and wireless communication channels) shall be developed and
entered into the Internet standards track.  The work is expected to
consist mainly of new and/or revised protocols at the (inter)network
layer, but may also include proposed modifications to higher-layer
protocols (e.g., transport or directory).  However, it shall be a
requirement that the proposed solutions allow mobile hosts to
interoperate with existing Internet systems.

In the longer term, the group may address, to the extent not covered by the
mobile host solutions, other types of internet mobility, such as
mobile subnets (e.g., a local network within a vehicle), or mobile
clusters of subnets (e.g., a collection of hosts, routers, and subnets
within a large vehicle, like a ship or spacecraft, or a collection of
wireless, mobile routers that provide a dynamically changing internet
topology).

 Internet-Drafts:

Posted Revised       I-D Title  <Filename>
------ ------- ------------------------------------------
 Mar 94 May 94  <draft-ietf-mobileip-protocol-03.txt> 
                IP Mobility Support                                            
 
 Mar 94 New     <draft-ietf-mobileip-integrated-00.txt> 
                Integrated Mobility Extension                                  
 
 Mar 94 New     <draft-ietf-mobileip-addr-ext-00.txt> 
                Local Care-Of Address Extension                                
---cut

--
John Hawkinson
jhawk@panix.com

-----------[000560][next][prev][last][first]----------------------------------------------------
Date:      Mon, 27 Jun 1994 06:09:25 GMT
From:      al012@un.seqeb.gov.au ( ANTHONY LEE)
To:        comp.protocols.tcp-ip
Subject:   What signal when network failure ?


Dear all,

We have Data PABX (VCX 5000 with a VLAN card or MDX (for Australia))
that for various reason has to be resetted every morning at 2am.  This
unfortunately causes one of my program to fall over.  I am already
trapping SIGTERM, SIGQUIT, SIGBUS and SIGHUP but it seem whatever is
killing my program is sending a signal that I don't know about.  Has
anyone got any idea what a signal a network process receives when the
network fail ?

Thank you
Anthony

-- 
Anthony Lee				These are my opinions and not SEQEB.
SEQEB					
150 Charlotte Street			
Brisbane

-----------[000561][next][prev][last][first]----------------------------------------------------
Date:      27 Jun 94 07:02:59 GMT
From:      pmycheng@hk.net (Patrick Cheng)
To:        comp.protocols.tcp-ip
Subject:   on aix, using arp -a to get address

I have a daemon on AIX that checks the incoming IP address. It then looks
up a table to find the corresponding ethernet address that is associated
with that particular IP_address. This is for security purpose. Anyway, I
then issue the command :       
arp -a
and grep the actual ethernet address against the particular IP_address
that was sent to me. If the 2 ethernet addresses are the same, then we
would allow the connection to continue. My problem is, arp -a does not
always return the address all the time at the time of connection. Why
is that so ? Could some one please give me a hint ? Thanks. 

Patrick
.


-----------[000562][next][prev][last][first]----------------------------------------------------
Date:      27 Jun 1994 08:07:17 GMT
From:      hansen@jupiter.rz.Uni-Osnabrueck.DE (Hans Schligtenhorst)
To:        comp.protocols.tcp-ip
Subject:   DOS lpr and Linux lpd FIN_WAIT2  - Help needed


Hello *,

I've got problems setting up Linux as a print server for a connected DOS-box.
The connection is up (ping etc. works fine), a print job will be printed only
if it is the first after bootup for the linux-box. The DOS-box says, the
job is done and linux tells me with netstat, that the tcp-port has the
state FIN_WAIT2. Hmmmmmm   ?:-(

Any hints? I don't understand, why the printer prints, before the job is
completely finished. If there is a big theoretical background, don't tell,
I think, I will not understand, but I have to set the print server up. ;-)

Tx in advance.

BTW: Is there any lockd-port for linux? Where can I get it?

Hans Schligtenhorst
---
What is a .sign????????



-----------[000563][next][prev][last][first]----------------------------------------------------
Date:      27 Jun 1994 10:16:27 GMT
From:      seodu@soback.hana.nm.kr (Seodu Logic)
To:        comp.protocols.tcp-ip
Subject:   Anyone using SunLink/IR on SunOS4.1.3


I am trying to connect our LAN to Internet through a local network provider.  
They said we can connect to their gateway without a router using SunLink/IR.
But, the SunLink/IR they brought us to test the connection seems to be crashing
the portmap when the multiuser boot start.  Does anyone have experience in
using Sunlink/IR on SS10 with SunOS4.1.3? The one they brought us seems to
be a quite old version of SunLink. 

--
Choi Jaeseon                            


-----------[000564][next][prev][last][first]----------------------------------------------------
Date:      27 Jun 1994 10:16:27 GMT
From:      Francois.Manchon@sophia.inria.fr (Francois Manchon)
To:        comp.protocols.dicom,comp.protocols.ibm,comp.protocols.iso,comp.protocols.iso.x400,comp.protocols.misc,comp.protocols.nfs,comp.protocols.pcnet,comp.protocols.ppp,comp.protocols.snmp,comp.protocols.tcp-ip,comp.protocols.appletalk,comp.dcom.cell-relay,comp.dcom.isdn,comp.dcom.lans.ethernet,comp.dcom.lans.fddi,comp.dcom.lans.hyperchannel,comp.dcom.lans.token-ring
Subject:   Want papers on network performance evaluation

	Hello Netters !


First of all, sorry for posting to so many groups at once.  
I really could not find any well-suited group for this question.
PLEASE do not post a follow-up.  Reply to me by e-mail and I will post a summary
to comp.protocols.misc if people ask for it.

I am currently doing a survey of performance evaluation for corporate telecom networks.  
I am looking for articles or technical reports describing experiments or (preferably),
algorithms to evaluate the performances of a network under various load conditions.

Mathematical algorithms are preferred, though simulators might be of interest.
On-line measurements can be interesting too.

The protocols we are interested in are the following:

- Physical layer: voice/data multiplexers

- Link layer: HDLC/SDLC/LAPB/LAPD, PPP, 802.x (mostly Ethernet, Token-Ring and FDDI),
  Frame-Relay, ATM, ICMP, SMDS

- Network layer: X.25, SNA, IP, CBDS, RIPE, OSPF

- Transport layer: TCP, UDP, APPN, DECnet, ISO transport, IPX


Questions we try to answer are (among others):

- Impact of error recovery on performance (e.g., on packet transmission delay)

- Protocol overheads

- Traffic paterns occurring in real networks


Thanks in advance to all, and please remember to reply by e-mail.

Cheers,

-- 
	Francois MANCHON	<Francois.Manchon@sophia.inria.fr>
======================================================================
SIMULOG - Agence Sophia-Antipolis - Les Taissounieres HB2
Route des Dolines - 06560 VALBONNE - FRANCE
Tel: +33 93 65 25 46 - Fax: +33 93 65 25 57
......................................................................
  ``Puisque toutes ces choses nous depassent, 
    feignons d'en etre l'organisateur...'' -- Jean Cocteau

-----------[000565][next][prev][last][first]----------------------------------------------------
Date:      Mon, 27 Jun 1994 12:35:52 GMT
From:      doug@siegfried.VF.GE.COM (Doug Hughes)
To:        comp.sys.sun.admin,comp.protocols.tcp-ip
Subject:   Re: RIP and very large internal internet

In article <2uc8vk$pk3@agate.berkeley.edu>, sean@oak.his.ucsf.edu writes:
|> You may want to configure your routers to only listen to RIP updates
|> from adjacent routers, ignoring the updates that come from workstations
|> that are only echoing (possibly corrupted) copies of what they learned
|> from routers.
|> 
|> Sean McGrath - Voice: 510.653.8387
|> Email: sean@oak.his.ucsf.edu
|> Paper: 638 66th st, Oakland Ca, 94609

Actually, there are very very few hosts doing active routing
( < .01%)
The problem, as we have determined is related to several bugs in
the sun operating system.
1) There is an mbuf leak (fixed with a patch pre 4.1.3.U1)
2) there is a large performance penalty for going more than 600
routes in your routing table (admitted by sun)
3) we have a 1+ running 4.1.3_U1 B and it still loses routes.
Apparently the mbuf leak patch doesn't apply, I don't think.. But
other machines (IPC) don't have this problem.

In fact we have a sparc 2 running 4.1.1 (a relic) with MAXUSERS
still left at 8 running a GENERIC kernel and it doesn't have the
problem! Lots of questions, few answers...

adjusting MAXUSERS seems to have little effect.  Sun engeering
is working on a fix.
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Doug Hughes              Internal Information Systems (NorthEast)   
System/Net Admin         Martin Marietta, Valley Forge, PA          
doug@vf.ge.com           doug@land.vf.ge.com                        
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
   "The light at the end of the tunnel is the headlamp of a train"  


-----------[000566][next][prev][last][first]----------------------------------------------------
Date:      Mon, 27 Jun 94 21:01:33 PDT
From:      "Quinn Lanus" <qlanus@sigg.com>
To:        comp.protocols.tcp-ip
Subject:   Can one FTP w/out a shell?

I hope this is the correct newsgroup......

Simple question:  Why does a user need a shell to perform an FTP? 

I'd like to create a login ID that can FTP, but not have a traditional login.
 My environment is SunOS 4.1.3.blah.blah....., with NIS.  If a shell is
absolutely required, are there any "restricted" shells for SunOS?  

Thanks,

Quinn.

-----------[000567][next][prev][last][first]----------------------------------------------------
Date:      27 Jun 1994 14:37:06 GMT
From:      elkner@fichte.cs.tu-magdeburg.de (Jens Elkner)
To:        comp.protocols.tcp-ip
Subject:   Mobile*IP

Does anybody know, where I can get information about
MOBILE*IP (scripts, rfc-drafts etc.) or where I can
ftp some infos ???

Thanx,
Jens.

--
+--------------------------------------------------------------------------+
| Jens Elkner                   | Otto-von-Guericke-Universitaet Magdeburg |
|                               +==========================================|
| Am Uniplatz 5                     elkner@wotan.cs.tu-magdeburg.de        |
| WH 4   PF 310                     elkner@sunpool.cs.tu-magdeburg.de      |
| 39106 Magdeburg   GERMANY         elkner@next.cs.tu-magdeburg.de         |
+--------------------------------------------------------------------------+

-----------[000568][next][prev][last][first]----------------------------------------------------
Date:      Mon, 27 Jun 1994 18:26:42 +0000
From:      mickm@mickm.demon.co.uk (Michael B Morgan)
To:        comp.protocols.tcp-ip
Subject:   anonymous ftp setup

I am shortly moving to a job where I will be responsible for setting
up and managing an anon ftp server. My only previous experience is of
managing a purely internal network (ie. NO connections ever allowed
to the outside world).

My main concerns relate to the security implications of allowing
the world in to a machine on a previously /secure/ network. Any
and all advice would be much appreciated - particularly pointers
to any available documentation (on the net or published elsewhere).

I'd be grateful for replies by email.

Mick

-- 
Mick Morgan                             Home 'phone 0508-470938
CCTA ("Can't Change The Acronym")       Work 'phone 0603-694927
                                        Email mickm@mickm.demon.co.uk

-----------[000569][next][prev][last][first]----------------------------------------------------
Date:      27 Jun 1994 18:31:19 GMT
From:      iddasl@iddis.com (Alan Siping Liu)
To:        comp.protocols.tcp-ip
Subject:   IP Multicast

If you know how to use IP multicast on Solaris and where to find
the software, please give me some idea. I have seen it on Comer's
book, and even found a header file (igmp.h) on my machine. But I
couldn't find the library file. I checked just about all books
on communication in the local SoftPro bookstore and none of them
gives a platform specific explanation.

Thanks.
A. L.


-----------[000570][next][prev][last][first]----------------------------------------------------
Date:      27 Jun 94 20:19:40 WET
From:      bharat@ccvax.ucd.ie
To:        comp.protocols.misc,comp.protocols.tcp-ip,comp.sys.novell
Subject:   How to convert TCP/IP packet to IPX packet and visa-versa?

Hi, 

In my project I need to capture IP and IPX (Novell) packet and get 
the values of individual packet elements, e.g. source address, 
destination address, data, CRC, etc. Actually, I have to write a program 
which converts TCP/IP packets to IPX packets and visa-versa. 

I am using Solaris 2.1 on a Sparce workstation. I am also using Novell 
Netware 3.12 as a gateway between TCP/IP environment and IPX environment.

I am relatively new to this area and would like to know more 
about TCP/IP packets, IPX packets, and related stuff.
If you have any information which could be useful for me, do send 
it to me. 

Please send your replies by email.

Many thanks in advance,

- Bharat,


-----------[000571][next][prev][last][first]----------------------------------------------------
Date:      27 Jun 1994 21:12:04 GMT
From:      spp@bob.eecs.berkeley.edu (Steve Pope)
To:        comp.protocols.tcp-ip
Subject:   talk protocol -- need to work with ntalk aka newtalk

I have been told that, on some hosts, the "talk" protocol
has been replaced with the new talk protocol "ntalk".

Unfortunately, they do not seem to be compatible.  Further,
"ntalk" does not seem to be a standard thing with my 
SUN 4 systems.

Is "ntalk" available PD somehow?  Has it really displaced
"talk"?   

thanks for any advice.

Steve

-----------[000572][next][prev][last][first]----------------------------------------------------
Date:      28 Jun 1994 09:38:09 -0700
From:      jdw@cs.pdx.edu (Jeff Wandling)
To:        comp.protocols.tcp-ip
Subject:   Re: Applications for multi-ethernet/homed addresses

Oops, wrong mail address. 


Jeff Wandling <jdw@novx.com>
-- 
jeff wandling <jdw@cs.wwu.edu>

-----------[000573][next][prev][last][first]----------------------------------------------------
Date:      27 Jun 1994 22:30:59 GMT
From:      barmar@think.com (Barry Margolin)
To:        comp.protocols.tcp-ip
Subject:   Re: Ports for WWW?

In article <2ui4p9$dlb@news1.digex.net> jgoldman@cpcug.digex.net (Jonathan Goldman) writes:
>I'm trying to use Cello on a system with heavy filtering and would like 
>to know what ports I need to permit in either direction.  I know I need 
>telnet (23) and gopher (70) going out as well as > 1023 coming in.  What 
>else is needed in either direction to run the WWW apps (HTTP, etc.)?

The default HTTP port is 80, but servers run by unprivileged Unix users
must be on ports above 1023.  8000 and 8001 seem to be common, but I don't
think there's a general rule.

FTP uses port 21 going out and >1023 coming in.
-- 
Barry Margolin
System Manager, Thinking Machines Corp.

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

-----------[000574][next][prev][last][first]----------------------------------------------------
Date:      27 Jun 1994 23:12:52 -0000
From:      jpm@gin.pfm-mainz.de (Jan-Piet Mens)
To:        comp.protocols.tcp-ip
Subject:   Sun-RPCs & syslog() for Winsock ?

Hi,

I am looking for a Sun-RPC library (and a syslog()) implementation to run
on top of Winsock on MS-Windows 3.1. Is any such thing available ?

Thanks for pointers, etc.

	-JP
-- 
    __  _____   __  __ 
   |  ||  _  \ |  \/  |    Jan-Piet Mens                   Tel: +49-611-9518000
 __|  ||  ___/ |      |    Wilhelminenstrasse 20           Fax: +49-611-9518101
|_____||__|    |__||__|    D-65193 Wiesbaden               jpm@gin.PFM-Mainz.DE

-----------[000575][next][prev][last][first]----------------------------------------------------
Date:      Tue, 28 Jun 1994 02:09:23 GMT
From:      jparadis@courrier.usherb.ca (JParadis2)
To:        comp.protocols.tcp-ip
Subject:   How about a geographical locator !

As anybody have heard of the existence of a service that can give you
back the geographic site of an I.P. addresse or a D.N.S..
Exemple i'm in california and i would like to know the geographic
location of
the address 132.210.10.60 whit a client application i ask a host that
run the server application. And after the request the repply is "
Sherbrooke Quebec
Canada". Would be great ! Does this software client an server already
born !

-----------[000576][next][prev][last][first]----------------------------------------------------
Date:      28 Jun 1994 04:26:36 GMT
From:      spp@bob.eecs.berkeley.edu (Steve Pope)
To:        comp.protocols.tcp-ip
Subject:   Re: Can one FTP w/out a shell?

I'm not a UNIX whiz but two things occur to me that
could conceivably work.

(1) in the passwd file login shell field, put "/usr/ucb/ftp"
instead of "/bin/csh".

(2) put "exec /usr/ucb/ftp" at the end of your .cshrc.

Steve

-----------[000577][next][prev][last][first]----------------------------------------------------
Date:      Tue, 28 Jun 1994 04:45:36 GMT
From:      tvg@zeus.datasrv.co.il (T.V.G)
To:        comp.protocols.tcp-ip
Subject:   protocol analysis shareware

hello,

i'd much appreciate any pointers to shareware/public domain software
for tcp-ip protocol analysis, to run on DOS preferably (UNIX also
a possibility).

thanks

-----------[000578][next][prev][last][first]----------------------------------------------------
Date:      Tue, 28 Jun 1994 05:03:37 GMT
From:      giles@research.canon.oz.au
To:        comp.os.ms-windows.networking.tcp-ip,comp.os.ms-windows.programmer.networks,comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject:   Re: NCSA Winsock

In article <9406240429.AA19368@ariake.nwk.cl.nec.co.jp> mweiss@nwk.cl.nec.co.jp (Michael J. Weiss) writes:
>I just ftp'ed NCSA Winsock.
>
>According to the accompanying README file, there are substantial
>differences between it and a "Windoews Sockets Compliant" stack.  I
>would like to know more specifically how substantial these differences
>are.
>
>If any of you have any insight into this matter, would you please share
>it?
>
.....

Bits are missing. Specifically:

All the WSAAsync... calls are missing: WSAAsyncSelect() and WSAAsyncGetXByY()

They are the "hard part" of a Winsock implementation IMHO....

= Giles =                                    giles@research.canon.oz.au

-----------[000579][next][prev][last][first]----------------------------------------------------
Date:      Tue, 28 Jun 1994 10:05:01
From:      padgett@141.240.2.145 (Padgett 0sirius)
To:        comp.protocols.tcp-ip
Subject:   Re: protocol analysis shareware

In article <1994Jun28.044536.21657@news.datasrv.co.il> tvg@zeus.datasrv.co.il (T.V.G) writes:
>i'd much appreciate any pointers to shareware/public domain software
>for tcp-ip protocol analysis, to run on DOS preferably (UNIX also
>a possibility).

Might try The Beholder (MSDOS), might do what you want - not sure where
to get it, believe it came from .NL, but ARCHIE should know.

			A. Padgett Peterson, P.E.
                        Cybernetic Psychophysicist
			   We also walk dogs
	 	       PGP 2.4 Public Key Available

-----------[000580][next][prev][last][first]----------------------------------------------------
Date:      Tue, 28 Jun 1994 10:47:32
From:      Gregory_French@brown.edu (Greg French)
To:        comp.os.ms-windows.networking.tcp-ip,comp.os.ms-windows.programmer.networks,comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject:   Re: THE winsock??

>I heard someone mention that soon Microsoft will be coming out with THE
>definitive winsock specification and that winsock.dll will come with
>windows?

Microsoft has been (and still is) pretty good about working with other vendors 
regarding WinSock.  The current version of the spec (1.1) was put together by 
a group of over 25 companies, including Microdyne, Sun, HP, Silicon Graphics, 
IBM, Novell, 3Com, etc.  Almost every company that now sells a TCP/IP stack 
had a say too, including Spry, FTP, B&W, NetManage, Fronteir, Distinct, etc. 
For a full list, just download the spec and take a look at the credits.

Recently, a group has been assembled to work on WinSock 2.0.  It looks like 
Intel is leading the group (or at least running the mailing lists), and most 
of the WinSock 1.1 members are still involved.  Of course, Microsoft has the 
largest presence, but the number of companies involved is at least as big as 
before.

The big change/addition is expanding the spec to include other networks such 
as IPX/SPX and OSI based networks.

There is no mystery that both Chicago and Daytona will include a finished 
version of the TCP/IP stack that's now in beta.

Short term, I don't know if Chicago will include a fully compliant WinSock 2.0 
DLL right out of the gate.  It would be an incredible feat if they could get 
all that work done on time [Plus I have no idea where MS would get 
something like an OSI stack !!!]  But for us traditional TCP/IP users, a 
bundled WinSock 1.1 and stack will be what we're used to.  So, my guess is 
that the situation will be about the same as it is now:  3rd party vendors 
make a living by selling software that is better than what comes in the box 
with the OS.

Long Term, I don't think Microsoft's stack will put those other companies out 
of business though.  It looks like Chicago's eventually going to get a much 
improved general communications architecture.  So getting new network 
"drivers" might eventually become like getting new printer, screen or ODBC 
drivers now.  The most important network "drivers" will probably come with the 
OS, but even those will likely be contracted out to the company that knows 
that particular network inside and out [just like the PostScript printer 
driver that comes with Windows now is actually written by Adobe].

>Am I right in assuming that the source code for this winsock.dll will
>not be available?

I doubt it.  But the specification itself will be as open and collaborative as 
it's always been.

>Does anyone have anymore information on this topic?

For more information, check out Microsoft's WWW server: 
http://www.microsoft.com/winsock/ws20over.htm

Greg


-----------[000581][next][prev][last][first]----------------------------------------------------
Date:      28 Jun 1994 14:51:43 -0500
From:      mhuff@zilker.net (Matthew B. Huff)
To:        comp.dcom.isdn,comp.protocols.tcp-ip
Subject:   ISDN, Lan-to-Internet & TCP-IP

Located here in Austin, Texas, Southwestern Bell is making a gracious offer
of a one-time 89.00 hookup for an ISDN connection. However, they don't seem
to understand what someone wants one for.  We want to connect our LAN to the
Internet through ISDN rather than a 56k leased line. We are looking at a 
BlackBox ISDN V.35 interface. Has anyone had any experience with this?

Southwestern Bell is targeting the ISDN toward individuals as a way of 
telecommuting, rather than as an universal pipe.


-----------[000582][next][prev][last][first]----------------------------------------------------
Date:      Tue, 28 Jun 1994 10:56:37 GMT
From:      rstevens@noao.edu (W. Richard Stevens)
To:        comp.protocols.tcp-ip
Subject:   Re: IP Multicast

> If you know how to use IP multicast on Solaris and where to find
> the software, please give me some idea.

The only documentation I've seen is in the Solaris ip(7) man page: the
descriptions of the socket options: IP_{ADD|DROP}_MEMBERSHIP and the
IP_MULTICAST_{IF|TTL|LOOP}.  These are, of course, applied to a UDP
socket.  That's the complete programming interface.  You then need
to understand multicast addresses, multicast groups, etc.: my recent
book "TCP/IP Illustrated" talks about this, as does Comer Vol. I.

	Rich Stevens

-----------[000583][next][prev][last][first]----------------------------------------------------
Date:      Tue, 28 Jun 1994 12:29:50 GMT
From:      FLAVELL@cernvm.cern.ch (Alan J Flavell)
To:        comp.protocols.tcp-ip
Subject:   Re: info request on IP multicasting

In article <martineau-260694160157@macmartineau.ccr.hydro.qc.ca>
martineau@MacMartineau.ccr.hydro.qc.ca (Alain Martineau) writes:
 
>I am looking for sources of information on IP multicasting
>protocols, routing and applications. Books and public documents.
 
Just in case you're not already aware of it, mbone.faq
by anon.ftp from venera.isi.edu

-----------[000584][next][prev][last][first]----------------------------------------------------
Date:      28 Jun 94 13:54:06 GMT
From:      rtkao@remus.rutgers.edu (Richard Kao)
To:        comp.protocols.tcp-ip
Subject:   Re: SLIP via terminal server?

It is possilbe at Rutgers they have serveral dialups and all are
capable of providing slip services.  I don't know how they do it I
assume the terminal server being used must support slip connections.

-----------[000585][next][prev][last][first]----------------------------------------------------
Date:      28 Jun 94 13:57:54 GMT
From:      rtkao@remus.rutgers.edu (Richard Kao)
To:        comp.protocols.tcp-ip
Subject:   Re: HLLAPI TN3270 over Winsock

There are several commercial vendors...
Attachmate Extra For Windows
Wall Data's Rumba 3270 for Windows
DCA's IRMA Workstation for Windows
These are the more popular ones.

-----------[000586][next][prev][last][first]----------------------------------------------------
Date:      Tue, 28 Jun 1994 15:12:38 GMT
From:      ronf@phx.sectel.mot.com (Ron Feigen)
To:        comp.protocols.tcp-ip
Subject:   Re: Can one FTP w/out a shell?

I agree with #1 but if you use #2 make sure break is disabled.  You don't want
folks to ^C out of .cshrc and into csh.

In article al8@agate.berkeley.edu, spp@bob.eecs.berkeley.edu (Steve Pope) writes:
>I'm not a UNIX whiz but two things occur to me that
>could conceivably work.
>
>(1) in the passwd file login shell field, put "/usr/ucb/ftp"
>instead of "/bin/csh".
>
>(2) put "exec /usr/ucb/ftp" at the end of your .cshrc.
>
>Steve





-----------[000587][next][prev][last][first]----------------------------------------------------
Date:      Tue, 28 Jun 1994 16:30:32 GMT
From:      isaacson@wireless.gte.com
To:        comp.protocols.tcp-ip
Subject:   TCP/IP and CDPD


I am curious on how IP application developers would attack the problem of using 
IP over a slow link as found in CDPD's airlink and how would you make the 
application more efficient since CDPD will charge by the information and 
packets sent.

CDPD uses a 19.2Kbps speed between the mobile and the cell site.  This will 
obviously create timing problems.  What are the preferred methods of overcoming 
this problem?

If 1024 bytes of data cost $0.25 and each packet had a sur-charge of $0.0025, 
what would you do to make the application cost effective to use?

Thanks,

Steve Isaacson
GTE PCS
Mobile Data Group
isaacson@wireless.gte.com

-----------[000588][next][prev][last][first]----------------------------------------------------
Date:      28 Jun 1994 16:33:41 GMT
From:      leonard@telcom.arizona.edu (Aaron Leonard)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP/IP and CDPD


In article <netnewsCs40Kz.BBw@netcom.com>, isaacson@wireless.gte.com writes:
|
|I am curious on how IP application developers would attack the problem of using 
|IP over a slow link as found in CDPD's airlink and how would you make the 
|application more efficient since CDPD will charge by the information and 
|packets sent.
|
|CDPD uses a 19.2Kbps speed between the mobile and the cell site.  This will 
|obviously create timing problems.  What are the preferred methods of overcoming 
|this problem?

Why do you think it is "obvious" that TCP/IP will suffer "timing 
problems" over a 19.2Kbps link?  The University of Arizona's 
main Internet (then, CSnet) link worked just fine at 9600 for
many years.

TCP was designed to work over a range of speeds from 2400 bps up to
~1Gbps.

|If 1024 bytes of data cost $0.25 and each packet had a sur-charge of $0.0025, 
|what would you do to make the application cost effective to use?

Well, using VJ compression would certainly be a win, especially for
small packets.  And data compression, either modem-to-modem, IP-stack-
to-IP-stack, or application-to-application, sounds like a must here.

$250 a megabyte, eh?  <shudder>

Aaron

Aaron Leonard (AL104), <Leonard@Arizona.EDU>
University of Arizona Network Operations, Tucson AZ 85721
  \ Don't lock yourself into open systems. /


-----------[000589][next][prev][last][first]----------------------------------------------------
Date:      Tue, 28 Jun 1994 19:19:20 GMT
From:      brobbins@newbridge.com (Bert Robbins)
To:        comp.protocols.tcp-ip
Subject:   Checksum in SPARC Assembly

Looking for SPARC Assembly language code that does
IP checksums.

Thanks
Bert Robbins

-----------[000590][next][prev][last][first]----------------------------------------------------
Date:      28 Jun 1994 19:24:09 GMT
From:      feng@bigdog.engr.arizona.edu (Gene Feng)
To:        comp.protocols.tcp-ip
Subject:   Looking for PC/TCP 3.X

I heard that the new PCT/CP shareware program had come out.  I wonder if
anyone could tell me where it is (I have verson 2.1).  Thank you much.
--
+-------------------------------+-------------------------------+
|Gene Feng			|feng@crani.therm.arizona.edu	|
|Radiation Oncology		|feng@bigdog.engr.arizona.edu	|
|University Medical Center	|(602)626-7516			|
|Tucson, AZ 85724		|				|
+-------------------------------+-------------------------------+

-----------[000591][next][prev][last][first]----------------------------------------------------
Date:      Wed, 29 Jun 94 02:43:54 PDT
From:      fedor@interramp.com
To:        comp.protocols.tcp-ip,comp.dcom.isdn
Subject:   Re: ISDN, Lan-to-Internet & TCP-IP


In article <2upv0f$9n9@oak.zilker.net>, <mhuff@zilker.net> writes:
> Path: 
 interramp.com!psinntp!news.intercon.com!zilker.net!zilker.net!not-for-mail
> From: mhuff@zilker.net (Matthew B. Huff)
> Newsgroups: comp.dcom.isdn,comp.protocols.tcp-ip
> Subject: ISDN, Lan-to-Internet & TCP-IP
> Date: 28 Jun 1994 14:51:43 -0500
> Organization: Zilker Internet Park, Inc.
> Lines: 9
> Distribution: usa
> Message-ID: <2upv0f$9n9@oak.zilker.net>
> NNTP-Posting-Host: oak.zilker.net
> Xref: interramp.com comp.dcom.isdn:785 comp.protocols.tcp-ip:1000
> 
> Located here in Austin, Texas, Southwestern Bell is making a gracious offer
> of a one-time 89.00 hookup for an ISDN connection. However, they don't seem
> to understand what someone wants one for.  We want to connect our LAN to the
> Internet through ISDN rather than a 56k leased line. We are looking at a 
> BlackBox ISDN V.35 interface. Has anyone had any experience with this?
> 
> Southwestern Bell is targeting the ISDN toward individuals as a way of 
> telecommuting, rather than as an universal pipe.
> 

We've done some work with this and we actually have a service that is
designed to do this.  We principally work with the ascend PipeLine 50,
pipeline100 or Pipeline 400.  This box acts as an Internet Router with
ISDN BRI coming in and Ethernet coming out to your LAN.

The Cisco 2500 box with a BRI can also be an ISDN Internet Router. The 2500
gives you the option of a token ring interface for the LAN.

It depends on who you get internet service from, but for the LAN-ISDN
service from PSI, you need a router that does PPP over ISDN.  The PPP
must support PAP authentication among other things.  We have
certified the ascend and cisco product.

BTW, PSI does not have an ISDN presence in Austin yet.... hopefully soon.

send mail to info@psi.com if you have any questions...

Hope this helps...

Mark
PSI



-----------[000592][next][prev][last][first]----------------------------------------------------
Date:      Wed, 29 Jun 94 07:50:00 -0640
From:      john.will@dscmail.com (John Will)
To:        comp.protocols.tcp-ip
Subject:   Re: Applications for mult

J >Oops, wrong mail address. 
J >
J >Jeff Wandling <jdw@novx.com>
J >-- 
J >jeff wandling <jdw@cs.wwu.edu>

Which one? :-)

-----------[000593][next][prev][last][first]----------------------------------------------------
Date:      Tue, 28 Jun 1994 18:22:58 +0200
From:      Herbert.Hotz@alcatel.ch (Herbert Hotz)
To:        comp.os.ms-windows.networking.tcp-ip,comp.os.ms-windows.programmer.networks,comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject:   Re: THE winsock??

In article <Gregory_French.215.047DED0C@brown.edu> Gregory_French@brown.edu (Greg French) writes:

[snipsnap]

>Short term, I don't know if Chicago will include a fully compliant WinSock 2.0 
>DLL right out of the gate.  It would be an incredible feat if they could get 
>all that work done on time [Plus I have no idea where MS would get 
>something like an OSI stack !!!]  But for us traditional TCP/IP users, a 
>bundled WinSock 1.1 and stack will be what we're used to.  So, my guess is 
>that the situation will be about the same as it is now:  3rd party vendors 
>make a living by selling software that is better than what comes in the box 
>with the OS.

Regarding the OSI stack, I asked a Microsoft rep at the LA/94 developers  
conference and he stated, that MS bought/uses the Alcatel TITN OSI stack.
Don't remember his answer was in the context of WindowsNT or Chicago.

Herbert




Herbert Hotz (3.278) | Tel: +41-1-465 2249                 Fax: +41-1-465 3525 |
Alctatel STR AG      | INTERNET: Herbert.Hotz@alcatel.ch                       |
Friesenbergstr. 75   | X.25:     PSI%4795123920::H_HOTZ                        |
CH-8055 Zurich       | X.400:    C=ch ADMD=arcom PRMD=Alcatel S=Hotz G=Herbert |

-----------[000594][next][prev][last][first]----------------------------------------------------
Date:      Tue, 28 Jun 1994 22:03:33 GMT
From:      art@acc.com (Art Berggreen)
To:        comp.protocols.tcp-ip
Subject:   Re: need ammo to use against bone-headed administrator

In article <fred_sCryLzw.IA5@netcom.com> fred_s@netcom.com (Frederick Scott) writes:
>What I originally wanted to know was, by what reasoning was it necessary
>for the writers of the RFCs to specify that such subnets (all zeroes or
>all ones) should be illegal?  For instance, all zeroes and all ones in the
>host address portion of the mask implies an IP broadcast and thus cannot
>be used as node addresses.  But there's no such thing as a "broadcast to
>all subnets in a net", so why should there be a concern with any IP
>addresses involving all the bits in the subnet mask being set to ones (or
>zeroes) in the absense of an all-ones or all-zeroes host address?

From RFC1122:

      "3.3.6  Broadcasts

         Section 3.2.1.3 defined the four standard IP broadcast address
         forms:

           Limited Broadcast:  {-1, -1}

           Directed Broadcast:  {<Network-number>,-1}

           Subnet Directed Broadcast:
                              {<Network-number>,<Subnet-number>,-1}

           All-Subnets Directed Broadcast: {<Network-number>,-1,-1}"

All-Subnets Directed broadcasts are being deprecated in favor of IP
multicast, but were very much defined at the time RFC1122 was written.

Thus a Subnet Directed Broadcast to a subnet of all ones is not
distinguishable from an All-Subnets Directed Broadcast.

For those old systems that used all zeros for broadcast in IP addresses,
a similar argument can be made against the subnet of all zeros.

Also, for old routing protocols like RIP, a route to subnet zero
is not distinguishable from the route to the entire network number
(except possibly by context).

Art


-----------[000595][next][prev][last][first]----------------------------------------------------
Date:      Tue, 28 Jun 1994 22:47:37 GMT
From:      vjs@calcite.rhyolite.com (Vernon Schryver)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP/IP and CDPD

In article <netnewsCs40Kz.BBw@netcom.com> isaacson@wireless.gte.com writes:
>
>I am curious on how IP application developers would attack the problem of using 
>IP over a slow link as found in CDPD's airlink and how would you make the 
>application more efficient since CDPD will charge by the information and 
>packets sent.
>
>CDPD uses a 19.2Kbps speed between the mobile and the cell site.  This will 
>obviously create timing problems.  What are the preferred methods of
>overcoming
>this problem?

What timing problem is this?  (I'm one of many limited to a 14.4Kbit/sec
v.32bis PPP link to the outside world.)


>If 1024 bytes of data cost $0.25 and each packet had a sur-charge of $0.0025, 
>what would you do to make the application cost effective to use?

$0.25/KByte is about $30.00/minute of air time!

I'd look for a cheaper way to move the data.  It's hard to think of an
application that would be worth charges like that.  Maybe not even email,
in the modern age of MIME and x-headers bloat.  I doubt there's a lot
that can be done, and given even a little hope of competion from other
mobile media, not a lot of reason to worry about something that would
charge dollars/email message.

One might piggy back data onto SYN's or reduce the ratio of ACK's to
data in the mobile host, but there's no hope of changing 10's of
1,000,000's of TCP and SMTP implementations to reduce the number of
packets in a typical SMTP session.  Maybe some kind of POP to a tuned
mail server instead of delivering to a remote disk would help a little.



Vernon Schryver    vjs@rhyolite.com

-----------[000596][next][prev][last][first]----------------------------------------------------
Date:      29 Jun 1994 11:35:08 -0700
From:      ddean@opus.eng.sc.rolm.com (Drew Dean)
To:        comp.protocols.tcp-ip
Subject:   Re: AF_UNIX & AF_INET Domains

In article <Cs5HCn.IM1@cup.hp.com>, Ken Mintz <mintz@cup.hp.com> wrote:
>Tohru Asami (tru@kddnews.kddlabs.co.jp) wrote:
>> Using the same internal kernel mechanisms as pipes, UNIX domain
>> uses the file system namespace to establish connections.
>
>  On BSD systems (at least 4.3 and later), AF_UNIX does __not__ use the
>  "same mechanism as pipes" insofar as the code path through the kernel
>  is very different for pipes and AF_UNIX.  AF_UNIX reads and writes go
>  through the kernel socket interface.  (Pipes do not.)
>

"In UNIX systems prior to 4.2BSD, pipes are implemented using the filesystem;
when sockets were introduced in 4.2BSD, pipes were reimplemented as sockets."
Leffler, et al, _The Design and Implementation of the 4.3BSD UNIX Operating
System_, p. 30.

Checking BSD/386 1.1, in .../sys/kern/uipc_syscalls.c, version
7.24 (Berkeley) 6/3/91, (i.e. Net/2) this seems to be true, as the
implementation of pipe() calls socreate() twice, sets the type of the
file struct to DTYPE_SOCKET, and the f_ops field of the file struct to
&socketops.  Am I missing something here, other than it would be more
precise to say, "Pipes use the same internal kernel mechanisms as sockets"?


>> [Some] seem to think that a packet for 127.0.0.1 is not fragmented,
>> but others do not think so. Anybody who knows which is the real UNIX
>> implementation?
>
>  Perhaps this is implementation-dependent.  Not fragmenting loopback
>  packets would certainly be an interesting optimization.
>
>  [...]
>  (Of course, I suppose some implementations might set the loopback MTU to
>  64k, so that no fragmentation will occur.  But I have not seen that
>  myself.)

SGI uses an MTU of 32K (or thereabouts) on 127.0.0.1, at least as of
IRIX 4.0.5.  Probably helps performance a little -- they're the only
people I've seen goto the trouble of raising the MTU for localhost.

>-- Ken Mintz


-- 
Drew Dean               (408) 492-5524
ddean@robadome.com      ROLM, a Siemens company
Opinions expressed above are my own, not Siemens'.

-----------[000597][next][prev][last][first]----------------------------------------------------
Date:      29 Jun 1994 11:36:10 -0700
From:      guy@nova.netapp.com (Guy Harris)
To:        comp.protocols.tcp-ip
Subject:   Re: AF_UNIX & AF_INET Domains

>  On BSD systems (at least 4.3 and later), AF_UNIX does __not__ use the
>  "same mechanism as pipes" insofar as the code path through the kernel
>  is very different for pipes and AF_UNIX.  AF_UNIX reads and writes go
>  through the kernel socket interface.  (Pipes do not.)

Incorrect.  In BSD systems, including 4.3 and up to "Net-2" (I don't
have 4.4BSD source handy at present), pipes are constructed as socket
pairs, and I/O to pipes *DOES* go through the kernel socket interface.

>  However, broadcast packets are looped in the driver, below IP, at least
>  in some implementations.

Done by drivers for Ethernet adapters that can't hear their own
broadcasts (or by subroutines called by those drivers - in Net-2, for
example, it's done in "ether_output()" for devices whose drivers have
set the IFF_SIMPLEX flag, which means "I can't hear my own broadcasts").

-----------[000598][next][prev][last][first]----------------------------------------------------
Date:      29 Jun 1994 00:04:23 GMT
From:      rao@acsc.com (Rao Srinivasa)
To:        comp.protocols.tcpip,comp.protocols.nfs
Subject:   Your favorite Networks Magazine/Journal ...


Hi Netters,
	
		I am planning to subscribe to a Networking magazine/journal
	which features latest developments in UDP, TCP, IP protocols, 
	NFS servers and other Ethernet related News ...along with other
	networking news ....

	Do you have any advice ..?

	Thanks for your time ...

Rao..
	
	

-----------[000599][next][prev][last][first]----------------------------------------------------
Date:      29 Jun 1994 00:09:03 GMT
From:      rao@acsc.com (Rao Srinivasa)
To:        comp.protocols.tcp-ip
Subject:   Your favorite Networks Magazine/Journal ...

Hi Netters,
	
		I am planning to subscribe to a Networking magazine/journal
	which features latest developments in UDP, TCP, IP protocols, 
	NFS servers and other Ethernet related News ...along with other
	networking news ....

	Do you have any advice ..?

	Thanks for your time ...

Rao..
	

-----------[000600][next][prev][last][first]----------------------------------------------------
Date:      29 Jun 1994 01:15:05 GMT
From:      garryh@seeding.apple.com (Garry Hornbuckle)
To:        comp.protocols.tcp-ip
Subject:   Re: ONC RPCs for the Mac yet?

In article <1994Jun22.231847.2029@lia.com>, larry@lia.com ((Larry Barnett
x5474)~ABCDEFGHIJLMNOPQRSTUVWXYZ#HBI7695474) wrote:

> Has the situation changed since then?  I don't want to
> buy RPCtool for every machine on my network.  Is RPCtool
> compatible with ANY standard RPC implementation (DCE perhaps)?
> Is anyone else in the game?  Thanks in advance for any light you
> can shine my way.  I will post a summary if it seems
> warranted.
> 

Check out NobelNet in Southboro MA.

-----------------------------------------------------------------------
Garry Hornbuckle        Product Manager, Communications & Collaboration
-----------------------------------------------------------------------
"If I told you that I   | email      garryh@seeding.apple.com
 spoke only for myself  | applelink  HORNBUCKLE1
 would you believe me?" | fax        (408) 974-1211
-----------------------------------------------------------------------

-----------[000601][next][prev][last][first]----------------------------------------------------
Date:      Wed, 29 Jun 94 08:46:42 PDT
From:      kaherinedeforest@airdata.com
To:        misc.jobs.offered,comp.unix.solaris,comp.protocols.tcp-ip
Subject:   Seattle- Wireless Data/Billing Systems Mgr


McCaw Cellular Communication's Wireless Data Division 
is doing more than talking about a bright and boundary-free
communications future; we're delivering it. We developed a
break-through service called AirData, for transmitting data
over cellular networks.  Now we're looking for a Billing 
Systems Manager in our Kirkland, WA office to develop a
usage accounting and billing system.

Responsibilities:

* Development, installation, and operation of the Cellular 
Digital Packet Data usage accounting and billing system.
* Development, installation, and operation of the CDPD 
intercarrier usage accounting information exchange system.
* Training and development of usage accounting and billing 
operations staff.

Qualifications:

* A minimum of 5 years experience in real-time software 
development management.
* Strong knowledge of packet switching and router-based 
networking.
* Previous experience with accounting and billing systems 
development preferred.
* Undergraduate degree in CS or engineering.


Please send resume via the mode of your choice:
 
e-mail:   katherinedeforest@airdata.com 
fax:      (206)803-4001
us mail:  Katherine DeForest 
	  McCaw Cellular Communications, Inc.
          10230 NE Points Drive
	  Kirkland, WA  98033-7869 	  
No phone calls please

-----------[000602][next][prev][last][first]----------------------------------------------------
Date:      Wed, 29 Jun 1994 08:31:30
From:      karl@cavebear.com (Karl Auerbach)
To:        comp.dcom.isdn,comp.protocols.tcp-ip
Subject:   Re: ISDN, Lan-to-Internet & TCP-IP

In article <2upv0f$9n9@oak.zilker.net> mhuff@zilker.net (Matthew B. Huff) writes:
>From: mhuff@zilker.net (Matthew B. Huff)
>Subject: ISDN, Lan-to-Internet & TCP-IP
>Date: 28 Jun 1994 14:51:43 -0500
 
>Located here in Austin, Texas, Southwestern Bell is making a gracious offer
>of a one-time 89.00 hookup for an ISDN connection. However, they don't seem
>to understand what someone wants one for.  We want to connect our LAN to the
>Internet through ISDN rather than a 56k leased line. We are looking at a 
>BlackBox ISDN V.35 interface. Has anyone had any experience with this?

I'm using an ISDN link with Combinet boxes at either end.  I tend to run with 
both B channels on my BRI up all the time, and the Combinets do compression.

Overall, performance is quite acceptable until you hit big http files.   
Telnet/rlogin performance could be better, but I don't use those much.

I'm also using an ISDN setup with the B channels brought up/down as needed.
The connection delay isn't usually noticable unless you are looking.  And we
run most of the time with only one B channel active.

                --karl--


-----------[000603][next][prev][last][first]----------------------------------------------------
Date:      29 Jun 1994 10:48:30 -0400
From:      tomh@metrics.com (Tom Haapanen)
To:        news.announce.newgroups,news.groups,comp.protocols.tcp-ip,comp.os.ms-windows.networking.windows,comp.os.ms-windows.networking.tcp-ip
Subject:   RFD: comp.protocols.smb

                        REQUEST FOR DISCUSSION
                             on creating
                          comp.protocols.smb


RATIONALE
    There is currently no Usenet newsgroup for discussions about the use
    of the SMB networking protocol, or for discussions about SMB-based
    software packages.  This protocol is increasing in popularity and
    deserves a proper home.

    The SMB protocol is used by software such as Microsoft LAN Manager,
    IBM LAN Server, Windows for Workgroups, Windows NT and the upcoming
    new version of Windows, "Chicago."  It provides services for name
    services, disk sharing, printer sharing and browsing.  It can run on
    top of Netbeui, IPX/SPX, and, more importantly, TCP/IP, making it a
    versatile protocol with capabilities exceeding those of NFS.

    There is currently available a free (using the GNU Public License)
    implementation of and SMB server and client, Samba, developed by 
    Andrew Tridgell at the Australian National University in Canberra,
    Australia.  With the added availability of the free TCP/IP protocol
    stack (for Windows) and client software (for MS-DOS and OS/2) from
    Microsoft, SMB becomes a versatile yet inexpensive alternative to NFS
    for Unix/Windows/MS-DOS internetworking.

    There is now in existence a mailing list for Samba and SMB discussions,
    hosted at the Australian National University.  This mailing list has
    been growing in both membership and traffic, and the time has come to
    make the transition into a newsgroup.  Currently the mailing list has
    over 400 subscribers (not including those served by remote mail
    exploders), with increasingly heavy traffic.  The Samba ftp site also
    gets 200-400 connections per week.

PROPOSED CHARTER
    comp.protocols.smb (unmoderated)
        comp.protocols.smb is for discussions about the use of the SMB
        protocol, its applications and compatability, and for the
        discussions about SMB-based server and client software, such
        as Samba.

DISCUSSION AND VOTING
    The discussion period lasts for 21 days from the date in the header
    of this article.  All discussion should take place in news.groups.
    The group name in this proposal is subject to change, and if
    necessary, a second, revised RFD will be posted prior to the end
    of the discussion period.

    A CFV (Call for Votes) will be posted after the end of the discussion
    period.  The vote will be run by a neutral third party.

    This RFD attempts to fully comply with Usenet newsgroup creation
    guidelines set in "How to Create a New Usenet Newsgroup". Please
    refer to this document if you have questions about the process.
-- 
[ /tom haapanen -- tomh@metrics.com -- software metrics inc -- waterloo, ont ]
[ "the edsel is here to stay"                            -- henry ford, 1957 ]

-----------[000604][next][prev][last][first]----------------------------------------------------
Date:      29 Jun 1994 08:36:52 GMT
From:      eb@iunet.it (Enrico Badella)
To:        comp.protocols.tcp-ip
Subject:   Current version of tcpdump?

What is the current version of tcpdump? I poked around with archie and
could only find tcpdump-2.2.1. I'm sure that 1 or 2 weeks ago where was 
a posting announcing tcpdump-3.1, but I couldn't find it any more since here
all articles are expired after 3 days. Before posting I tried to find
a comp.protocols.tcpip FAQ but could only come up with the ibmpc version;
any pointers?

Thanks in advance.
eb


================================================================================
Enrico Badella					email  softstar@pol88a.polito.it
Soft*Star s.r.l.				       eb@vax.cnuce.cnr.it
Via Camburzano 9				phone  +39-11-746092
10143 Torino, Italy				fax    +39-11-746487

	People are strange
	When you're a stranger	(J. Morrison)
================================================================================

-----------[000605][next][prev][last][first]----------------------------------------------------
Date:      Wed, 29 Jun 1994 09:35:38 GMT
From:      zi@cli51jo.der.edf.fr (Zixiong Wang)
To:        comp.protocols.tcp-ip
Subject:   How do you get TCP/IP address by program ?

Hi,
	I must get my local host's address by program, I can 
of cause read in /etc/hosts, but I don't think it is the best 
way to do that.
	I'v tried gethostbyname(), which returns a hostname
and a pointer to an address, the hostname is always the same
than the one that I'v passed to the function, so not at all
informative. The Sun Solaris manual says that the address is
of form of in_addr, which can be manipulated by inet...
system calls, so I call inet_ntoa(), but what I get is
not my address:

struct hostent *ent = gethostbyname("cli51jo");
struct in_addr in;
memcpy(&in, ent->h_addr_list, sizeof(struct in_addr));
cout << inet_ntoa(in) << endl;

this code gives me:
0.3.104.252

while the good address is 130.98.16.56.

What's wrong ?

Thanks for any help.

Zixiong WANG
zi@cli51jo.der.edf.fr
Electricite de France

-----------[000606][next][prev][last][first]----------------------------------------------------
Date:      29 Jun 1994 20:29:19 -0600
From:      abelits@nyx10.cs.du.edu (Alexander Belits)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject:   Re: Auto login with Telnet

: : With a .rhosts file on the unix machine to allow rlogin without
: : a password, I simply double click on the icon and I get a
: : window logged on to that machine.

That configuration is a big security hole.
--

-----------[000607][next][prev][last][first]----------------------------------------------------
Date:      29 Jun 1994 18:56:21 -0500
From:      mweiss@nwk.cl.nec.co.jp (Michael J. Weiss)
To:        comp.os.ms-windows.networking.tcp-ip,comp.os.ms-windows.programmer.networks,comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject:   NCSA Winsock

I am looking for anyone who is working or has worked or has used NCSA
Winsock.  Also if anyone knows the email address of its creators, please
let me know.

Thanks,

--Mike

-----------[000608][next][prev][last][first]----------------------------------------------------
Date:      29 Jun 1994 19:20:25 -0500
From:      mweiss@nwk.cl.nec.co.jp (Michael J. Weiss)
To:        comp.os.ms-windows.networking.tcp-ip,comp.os.ms-windows.programmer.networks,comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject:   WATTCP for Windows

Sorry, I forgot to ask this in my last message.

Does anyone know anything about WATTCP for windows ?

Has anyone worked with it ?

--Mike

-----------[000609][next][prev][last][first]----------------------------------------------------
Date:      Wed, 29 Jun 1994 12:00:46 GMT
From:      pi92pob@pt.hk-r.se (PerOlof Bengtsson)
To:        comp.dcom.lans.ethernet,comp.dcom.lans.misc,comp.lang.c++,comp.protocols.tcp-ip,hk-r.info,swnet.sys.sun,swnet.unix
Subject:   Distributed groupcommunication

Hi.

I'm looking for papers, code, c++-class-libraries, anything about groupcommunication in tcp/ip or just about anything. Ptrs wanted

Thanks in advance...
    ____  ____ 
   / __ \/ __ \ ___________________________________________    
  / /_/ / / / / PerOlof PO Bengtsson        Villa Flora   
 / ____/ /_/ / Phone: +46 (0)457-26267      372 36 Ronneby  
/_/    \____/ e-mail: pi92pob@pt.hk-r.se    SWEDEN
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
http://jupiter.pt.hk-r.se/student/pi92pob/pi92pob.html



-----------[000610][next][prev][last][first]----------------------------------------------------
Date:      29 Jun 1994 12:59:21 GMT
From:      mgb722c@rs730.gsfc.nasa.gov (Myron Bradshaw)
To:        comp.protocols.tcpip,comp.protocols.nfs
Subject:   Re: Your favorite Networks Magazine/Journal ...

In <2uqdq7$8ti@acsc.com>, rao@acsc.com (Rao Srinivasa) writes:
>
>Hi Netters,
>	
>		I am planning to subscribe to a Networking magazine/journal
>	which features latest developments in UDP, TCP, IP protocols, 
>	NFS servers and other Ethernet related News ...along with other
>	networking news ....
>
>	Do you have any advice ..?
>
>	Thanks for your time ...
>
>Rao..
>	
>	
I have 2 suggestions:

Corporate Computing (Sorry; I dont have any info on this one) and
Network Computing (Subscriptions: (708)647-6834).

Both are excellent publications for any netter and often include
articles such as those you described.

*************************************************
*  Myron Bradshaw - Facility Manager                            *
*  Curtis Management Company, Inc.                               *
*  NASA/Goddard Space Flight Center                             *
*  Greenbelt, MD 20771                                                 *
*  E-Mail: mgb@meb6.gsfc.nasa.gov, or                            *
*            mgb722c@rs730.gsfc.nasa.gov                           *
*************************************************
*Jesus not only saves, He also frequently makes Backups.*
*************************************************
*  Stupid TV!! Be more funny!      - Homer Simpson          *
*************************************************


-----------[000611][next][prev][last][first]----------------------------------------------------
Date:      29 Jun 1994 13:28:34 GMT
From:      bertg@fwi.uva.nl (Bert Gijsbers)
To:        comp.unix.programmer,comp.protocols.tcp-ip
Subject:   Re: Help with UDP Broadcast

mintz@cup.hp.com (Ken Mintz) writes:

>     if ( (sin_addr = inet_addr(dot_addr)) == -1 &&
>          strcmp(dot_addr, "255.255.255.255")) != 0)
>        report_error();
 
>  That is, __if__ inet_addr returns -1, we merely need to also check to see
>  if the parameter is indeed "255...255" and, if so, accept the -1 as a
>  valid sin_addr.

Shouldn't we be testing for INADDR_NONE rather than -1?
Where INADDR_NONE is #defined as ((unsigned long)0xffffffff).
I'm also unsure about how this works on 64 bit CPUs.
Do they return (-1) or ((unsigned long)0xffffffff)?

>-- Ken Mintz

Bert Gijsbers

-----------[000612][next][prev][last][first]----------------------------------------------------
Date:      29 Jun 1994 14:53:07 GMT
From:      spitad@naomi.forthnet.gr (Vassilis Spitadakis)
To:        comp.protocols.tcp-ip
Subject:   Wanted: SLIP for MACs

 Hello from Greece,
   does anyone know which software implements SLIP or IP-over-PPP
   for MACintoshes ??

   I think MacTCP and Interslip are the answers.. but I do not know
   more about which versions are suitable, where to get the software
   or other solutions...

   We have a Cisco server (CS500) with asynchronous ports running IP over
   SLIP or PPP and a few people with Apple computers who want
   Internet connectivity.

many thanks,
 Vassilis Spitadakis

----------------------------------------
Vassilis Spitadakis
Network Operation Center - FORTH
e-mail: spitad@forthnet.gr
Dedalou 36 str.  
71110 Iraklion, Crete
GREECE
Tel. +81 229368, 221171, 229302
Fax  +81 229342 
----------------------------------------




-----------[000613][next][prev][last][first]----------------------------------------------------
Date:      Wed, 29 Jun 1994 15:05:58 GMT
From:      briley@encmail.encompass.com (Rob Briley)
To:        comp.protocols.tcp-ip
Subject:   FTP hangup

We have a customer who is transfering files via FTP between his system and ours.  Periodically the file transfer hangs.  The user connects to our system, sets it to binary mode and SEND's the file.  He gets a "started" message, and then sits there forever.  No errors, no nothing.  Our end shows the
connection.  A zero block file is created, and after an hour the link times out.  There are no errors on our end.  My network show no errors and the customer says that his network shows no errors.

We are in the process of checking MTU and Window size on the comm gear in case that is the problem.

Specifics.

Sending system:

	Tandam IPM version T9552C20_16NOV92_FTP_AAJ

Receiving system:

	VMS 5.5-2
	Wollongong 5.2

Files:

	ASCII
	Fixed length 512 byte records
	No carriage control
	File size varies, at least one failure happened on a 2k file.

Network:
	Two interconnected IP networks.  Both are CISCO based.

Note:

	There are no other known communications problems.

Thanks,

_______________________________________________________________

Robert Briley, Networks Manager
ENCOMPASS
briley@encmail.encompass.com


-----------[000614][next][prev][last][first]----------------------------------------------------
Date:      Wed, 29 Jun 1994 15:41:56 GMT
From:      j.d.stumbles@reading.ac.uk (John Stumbles)
To:        comp.protocols.tcp-ip
Subject:   Appletalk for PC??

Anyone know of software that allows a PC to speak Appletalk (over ethernet or 
perhaps phonenet with the appropriate card) in the direction of allowing the 
PC's resources (specifically printer) to be shared by the Macs ??

Any experience, ideas of costs etc gratefully recieved.

Email replies appreciated!


John Stumbles                                    j.d.stumbles@reading.ac.uk
Computer Services Centre                                        0734 318435
University of Reading        Whiteknights      Reading     RG6 2AF       UK
+-+-+-+-+-+-+-+-+-+-+-+-+-+

-----------[000615][next][prev][last][first]----------------------------------------------------
Date:      Wed, 29 Jun 1994 16:28:14 GMT
From:      dfitzgerald@fitzg.library.colostate.edu (Daniel C. FitzGerald)
To:        comp.infosystems.www,comp.protocols.tcp-ip
Subject:   HTTP Packets

OK, here's the deal..

I need to measure the impact of Mosaic use on my network, and I want to write 
a filter description for FTP's LANWatch to grab HTTP packets so I can get a 
look at how "chatty" Mosaic is.  I am using FTP's PCTCP Ebanyan kernel and 
WinSock on a Vines 5.52(5) NOS on Thin Ethernet (cheapernet :-) ).  What I 
need to know is how to make a filter description which will catch HTTP 
packets, does HTTP use TCP or UDP or niether?  Which byte do I look at to 
identify a http packet?


=========================================================================
Dan FitzGerald           | Network Support - A science of vague 
DFitzGerald@LTS@Libraries| assumptions, based on debatable figures,
danno@lamar.colostate.edu| taken from inconclusive experiments, performed
Phone: (303) 491-7102    | with instruments of problematical accuracy
                         | by persons of doubtful reliability and
                         | questionable mentality.
=========================================================================



-----------[000616][next][prev][last][first]----------------------------------------------------
Date:      29 Jun 1994 16:30:04 GMT
From:      smarcus@bbn.com (Scott Marcus)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP/IP and CDPD

In article <netnewsCs40Kz.BBw@netcom.com> you write:
>
>I am curious on how IP application developers would attack the problem of using 
>IP over a slow link as found in CDPD's airlink and how would you make the 
>application more efficient since CDPD will charge by the information and 
>packets sent.

The trick, in my opinion, is simply for your customers to choose their
applications wisely.  The alternative - the use of "tailored" 
applications - will also exist in the CDPD world, but will be less prevalent,
because it defeats one of CDPD's biggest advantages:  the ability to use
absolutely unmodified TCP/IP applications on fixed server systems (F-ESs).

As a simple example, consider e-mail.  E-mail is an obvious benefit for
the road warrier, because it doesn't require the recipient to be contiunously
logged on.  On your laptop, you could run a POP-style mailer that just
transfers the headers, or you could run a conventional SMTP e-mail handler
that transfers whole messages.  The POP mailer is a clear win - you only
pay to transfer the data you really want to see, based on the headers.

Excessive tailoring of the applications in ways that are specific to CDPD
is almost certainly counterproductive.


>CDPD uses a 19.2Kbps speed between the mobile and the cell site.  This will 
>obviously create timing problems.  What are the preferred methods of overcoming 
>this problem?

I agree with the previous posters.  There is no problem to overcome.


>If 1024 bytes of data cost $0.25 and each packet had a sur-charge of $0.0025, 
>what would you do to make the application cost effective to use?

Same as above.  The "best" packet is the one you don't have to send.
Avoid the use of overly "chatty" LAN-oriented applications.  Select ones
that are well suited to the bandwidth you have.

Also, choose TCP/IP implementations that are well implemented.  You may want
to revisit Dave Clark's old papers on window and acknowledgment strategies.
As a carrier, you don't want to be in the business of messing with the
TCP implementations of your customers; however, your customers could
benefit from understanding that they are better off with a TCP implementation
in their end systems that is intelligent about piggybacking acknowledgments
and dallying before acknowledging.  To the extent that you, the carrier,
implement value-added services, you will want to pay attention to the same.

Cheers,
-- Scott Marcus
Bolt Beranek and Newman Inc.  (BBN)



-----------[000617][next][prev][last][first]----------------------------------------------------
Date:      29 Jun 1994 16:32:18 GMT
From:      smarcus@bbn.com (Scott Marcus)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP/IP and CDPD

In article <2upjd5$gcv@news.CCIT.Arizona.EDU> you write:
>
>... (stuff deleted)
>
>|If 1024 bytes of data cost $0.25 and each packet had a sur-charge of $0.0025, 
>|what would you do to make the application cost effective to use?
>
>Well, using VJ compression would certainly be a win, especially for
>small packets.  And data compression, either modem-to-modem, IP-stack-
>to-IP-stack, or application-to-application, sounds like a must here.

The CDPD Spec includes a Subnetwork Dependent Convergence Layer (classic
OSI-ism, for those of you who aren't into such stuff) that includes VJ
compression, and an equivalent compression for CLNP NPDUs.  My reading
of the spec says that support for this is required; whether the equipment
now deploying fully supports compression, I couldn't say.  (CDPD Spec
Version 1, Section 404, and also the discussion of "CDPD Channel Stream",
Section 311)


>$250 a megabyte, eh?  <shudder>

I agree - this seems too high.

Cheers,
-- Scott Marcus, BBN


-----------[000618][next][prev][last][first]----------------------------------------------------
Date:      29 Jun 1994 16:54:32 GMT
From:      berke@panix.com (Wayne Berke)
To:        comp.protocols.tcp-ip
Subject:   Re: need ammo to use against bone-headed administrator

art@acc.com (Art Berggreen) writes:

> From RFC1122:
 
>       "3.3.6  Broadcasts
 
>          Section 3.2.1.3 defined the four standard IP broadcast address
>          forms:
 
>            Limited Broadcast:  {-1, -1}
 
>            Directed Broadcast:  {<Network-number>,-1}
 
>            Subnet Directed Broadcast:
>                               {<Network-number>,<Subnet-number>,-1}
 
>            All-Subnets Directed Broadcast: {<Network-number>,-1,-1}"
 
> All-Subnets Directed broadcasts are being deprecated in favor of IP
> multicast, but were very much defined at the time RFC1122 was written.
 
> Thus a Subnet Directed Broadcast to a subnet of all ones is not
> distinguishable from an All-Subnets Directed Broadcast.

As a practical matter though, would it be possible for routers inside
of <Network-number> to recognize the All-Subnets Directed Broadcast?
Note that this would require it to use the canonical mask for this one
type of address while using the subnet mask for all other addresses
within the network.
--
Wayne Berke
berke@panix.com

-----------[000619][next][prev][last][first]----------------------------------------------------
Date:      Wed, 29 Jun 1994 17:11:11 GMT
From:      gerco@cs.vu.nl (Ballintijn GC)
To:        comp.protocols.tcp-ip
Subject:   Q: How to know the writer died?

Hello,

	i have the following problem. I use a stream type socket to
connect a client and a server. The server writes info to the client.
If the server crashes, the client has to try to make a new connection.
To do this the client has to know the server died. But since he only
reads after a SIGIO (asynchronous), it wil never know when the server
died. The information,manuals and such are rather quiet on this subject,
so can anybody help me? I thought I would get a SIGIO if the server
died but it seems it only creates a SIGIO to flush the buffer or
something (certainly no read with 0 bytes read).

					Gerco.
-- 
+------------------------------+-----------------------------------+
|    GC Ballintijn             |     Oh, Fortuna, velut luna       |
|    Email: gerco@cs.vu.nl     |     Statu variabilis.....         |
+------------------------------+-----------------------------------+

-----------[000620][next][prev][last][first]----------------------------------------------------
Date:      29 Jun 1994 17:17:44 GMT
From:      jbrady@deepriver.East.Sun.COM (John Brady - SunNetworks Consultant)
To:        comp.protocols.tcp-ip
Subject:   CDPD Pricing [was: TCP/IP and CDPD]


>$250 a megabyte, eh?  <shudder>

Please note that the pricing example $0.25/Kb + $0.0025/Packet was exactly
that -- AN EXAMPLE.

If you are seriously considering CDPD for your application, talk to service
providers about pricing before making business decisions!

Due to CDPD's use of existing infrastructure, pricing should prove very
attractive compared to similar services like RAM (once the market stablizes).

-- John Brady

-----------[000621][next][prev][last][first]----------------------------------------------------
Date:      29 Jun 1994 17:44:48 GMT
From:      jbrady@deepriver.East.Sun.COM (John Brady - SunNetworks Consultant)
To:        comp.protocols.tcp-ip
Subject:   Re: HTTP Packets

In article 2E11A11D@fitzg.library.colostate.edu, dfitzgerald@fitzg.library.colostate.edu (Daniel C. FitzGerald) writes:
>OK, here's the deal..
>
>Which byte do I look at to identify a http packet?
>

HTTP is layered on top of TCP.  HTTP packets do not carry a byte that identifies
protocol.  Probaby the best way to measure traffic is by monitoring port
usage.  Any TCP packet with a source or destination port of 80 is HTTP.

-- John Brady

-----------[000622][next][prev][last][first]----------------------------------------------------
Date:      Wed, 29 Jun 1994 18:33:49 GMT
From:      collinrj@newton.ccs.tuns.ca (Robert J. Collins)
To:        comp.protocols.tcp-ip
Subject:   WINQVT/Net Display problems..

Has anyone had any problems with the display of WinQVT/Net version 3.97.
We are thinking about using the emulator to connect to our Unix systems,
however, we keep having things disappear from our screens when the window
is minimized and then maximized.  We can repaint the screen with a Ctrl-W
but we would like to solve the problems
.

Any ideas?

Thank you,

Paul Crane
Temporary e-mail: collinrj@newton.ccs.tuns.ca


-----------[000623][next][prev][last][first]----------------------------------------------------
Date:      Wed, 29 Jun 1994 19:37:01 GMT
From:      vjs@calcite.rhyolite.com (Vernon Schryver)
To:        comp.protocols.tcp-ip
Subject:   Re: AF_UNIX & AF_INET Domains

In article <Cs5HCn.IM1@cup.hp.com> mintz@cup.hp.com (Ken Mintz) writes:

> ...
>> [Some] seem to think that a packet for 127.0.0.1 is not fragmented,
>> but others do not think so. Anybody who knows which is the real UNIX
>> implementation?
>
>  Perhaps this is implementation-dependent.  Not fragmenting loopback
>  packets would certainly be an interesting optimization.
>
>  However, in BSD implementations I'm familiar with, IP does __not__ make a
>  special case for the loopback "interface".  IP calls the appropriate
>  "driver" anonymously through a function pointer.  Since the loopback
>  interface has an MTU, just like any other interface, IP __will__ (and must)
>  fragment large messages to accomodate larger-than-MTU UDP sends.
>
>  (Of course, I suppose some implementations might set the loopback MTU to
>  64k, so that no fragmentation will occur.  But I have not seen that
>  myself.)
> ...

Some versions of SGI's UNIX set the lo0 MTU to 32880.  I later reduced
it to only 8304 because a well known 3rd party network backup product
likes to use TCP (even locally), max sized windows, zillions of sockets,
and fill them all, exhausting the mbuf pool, that was at that time
limited to only 3MByte.

("only 3MByte" ... aint bloat grand?)

(Why those particular values?  They are of the form N*CLBYTES+M*MLEN.
Think of page flipping).


Vernon Schryver    vjs@rhyolite.com

-----------[000624][next][prev][last][first]----------------------------------------------------
Date:      Wed, 29 Jun 1994 19:47:11 GMT
From:      vjs@calcite.rhyolite.com (Vernon Schryver)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP/IP and CDPD

In article <2ur9o5$svb@sophia.inria.fr> fmanchon@zenon.inria.fr (Francois Manchon) writes:

> ...
>If you are alone, using rlogin or a similar low-bandwith interactive
>application, everything is fine.  The response time is very similar to what
>you get with a 19200 baud video terminal (anyone out there still using that ?
>we do !)  Even full-screen text editors or (simple) X-Window applications can
>be used.
>
>But... if one guy in the next office starts doing FTP,  or someone one the net
>sends you a big e-mail then the response time rises to 0.7-0.8 second.  You
>just cannot work when you have to wait that much to get what you type echoed
>on the screen.  A short performance modelling study quickly showed that you
>need at least 64 kbit/s to work in acceptable conditions.

64Kbit/sec is not enough if someone is pushing data, as I can testify
personally, since my 14.4 link to the rest of the world is only the 1st
hop of a chain that includes Ethernets, FDDI rings, and Frame Relay
links. 
  -if you use Cisco Routers with 56k lines which are not doing
      any kind of Type-Of-Service queuing (either because they are given
      TOS bits or because they are not cheating and looking at port
      numbers or packet sizes)
  -and if you are connecting hosts that use 60KByte TCP windows,
  -you will see interactive delays of up to 10 seconds with the default
    Cisco queue sizes.

On the other hand, if TOS queue does great things, especially for
keeping interactive traffic from being killed by FTP's on single-hop
14.4 PPP links.  If your PPP implementation doesn't have some kind of
TOS hack, get another one that does.


Vernon Schryver    vjs@rhyolite.com

-----------[000625][next][prev][last][first]----------------------------------------------------
Date:      29 Jun 1994 20:54:53 GMT
From:      barmar@think.com (Barry Margolin)
To:        comp.protocols.tcp-ip
Subject:   Re: Can one FTP w/out a shell?

In article <2uo125$e5q@sid.sigg.com> "Quinn Lanus" <qlanus@sigg.com> writes:
>Simple question:  Why does a user need a shell to perform an FTP? 

You need a shell to login to Unix and type commands.

>I'd like to create a login ID that can FTP, but not have a traditional login.
> My environment is SunOS 4.1.3.blah.blah....., with NIS.  If a shell is
>absolutely required, are there any "restricted" shells for SunOS?  

/usr/lib/rsh is the restricted Bourne shell (don't confuse this with
/usr/ucb/rsh, which is the remote shell).  It's not documented in the SunOS
man pages; see the book "Practical Unix Security" for information about it.
-- 
Barry Margolin
System Manager, Thinking Machines Corp.

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

-----------[000626][next][prev][last][first]----------------------------------------------------
Date:      29 Jun 1994 22:43:20 GMT
From:      smarcus@bbn.com (Scott Marcus)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP/IP and CDPD

>In article <2ur9o5$svb@sophia.inria.fr> fmanchon@zenon.inria.fr (Francois Manch
 on) writes:
>
>> ...
>>If you are alone, using rlogin or a similar low-bandwith interactive
>>application, everything is fine.  The response time is very similar to what
>>you get with a 19200 baud video terminal (anyone out there still using that ?
>>we do !)  Even full-screen text editors or (simple) X-Window applications can
>>be used.
>>
>>But... if one guy in the next office starts doing FTP,  or someone one the net
>>sends you a big e-mail then the response time rises to 0.7-0.8 second.  You
>>just cannot work when you have to wait that much to get what you type echoed
>>on the screen.  A short performance modelling study quickly showed that you
>>need at least 64 kbit/s to work in acceptable conditions.


With or without TOS enhancements, I have a hard time believing that a
normal telnet session is a good use of CDPD.  Even before we get to the
end-to-end delay issues, I just don't think that your most typical user
wants the kind of an interface that a normal telnet interface provides.

If you really need telnet, a simple optimization could help.  Most UNIX
systems want to set the telnet right away into full-duplex mode, where
every character is echoed immediately across the net.  The default
terminal in the telnet spec, however, is a half duplex device that
echoes locally and buffers until a line-terminating character, if memory
serves me right.  Most implementations will allow the user to set this
mode.

For a system like CDPD, this could greatly improve efficiency (and thus
reduce cost).  First, you avoid the byte-at-a-time echo.  Second, you
transmit multiple bytes in each packet, thus amortizing the cost of
the protocol headers over more data.

This is also better for the user, who isn't sitting around waiting for
his characters to be echoed back.  Note, BTW, that the airlink isn't the
only delay the user will see.  There are all the normal delays you would
see in any network, plus at least one packet forwarding from a device
called a Home MD-IS.

There is one obvious drawback to this, and for some users it would be
big to unacceptable:  some applications echo something back that is
unrelated to the character that the user typed.  If the customer is
really into playing rogue, or using the vi editor, you're smoked.
This is the wrong approach for that customer.

With all that said, I come back to my initial point:  I don't think
that the typical user of a service like CDPD really wants to log in
to a UNIX system.  I think that e-mail is a much more likely 
application.

Cheers,
-- Scott Marcus, BBN


-----------[000627][next][prev][last][first]----------------------------------------------------
Date:      30 Jun 94 11:51:00 -0500
From:      imhw400@indyvax.iupui.edu (Mark H. Wood)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP/IP and CDPD

> In article <netnewsCs40Kz.BBw@netcom.com>, isaacson@wireless.gte.com writes:
 [deletia]
>If 1024 bytes of data cost $0.25 and each packet had a sur-charge of $0.0025, 
>what would you do to make the application cost effective to use?

Start a competing service and drive the price down?  :-}
-- 
Mark H. Wood, Lead Systems Programmer    +1 317 274 0749   [@disclaimer@]
Internet:  MWOOD@INDYVAX.IUPUI.EDU       BITNET:  MWOOD@INDYVAX
"It's *better* than good -- it's CHEAP!" - Cosmo Spacely

-----------[000628][next][prev][last][first]----------------------------------------------------
Date:      30 Jun 1994 05:50:23 GMT
From:      crohrer@advtech.uswest.com (Chris Rohrer)
To:        comp.protocols.tcp-ip
Subject:   Max IP packet length and MTU

Hi all,

I'm trying to understand just what the relationship between maximum IP packet
size and MTU size really is.  My understanding is that according to the IP
RFC (791) the largest packet I could ever send on a network somewhere
would be 64k (actually 64k-1).  The packet length indicator only has
enough bits to indicate lengths up to that size.  My understanding of MTU
is that it is a data link layer parameter (Maximum Transmission Unit) and
is the largest payload that a frame can carry on a given network.  For
example, the MTU of Ethernet is 1500 bytes, or 1518 if you count the
header and CRC.

Would an MTU size of 1500 restrict the largest IP packet that I can send on 
an Ethernet to a length of 1500?  I believe the answer to be yes.  

My real question is more like this: Will "typical" host IP software obey
this 1500 byte restriction and tell its users (TCP, UDP and possibly other
entities) that THEIR maximum "block" size is of that same approximate
value (1500 minus the IP overhead)?  Or will this "typical" IP software
present a 64k-sized interface to its layer 4 users and take the initiative
to do real header-mediated IP fragmentation down to the 1500 byte size?

It had always been by understanding only routers would do fragmentation
and that hosts would just obey the MTU limitation on their local nets and
generate packets of the appropriate size with no IP fragmentation
indicated in the IP header.  And further, that the MTU limitation would be
"visible" to higher layers, well at least to layer 4.

I'm sure I have this wrong somewhere....

Thanks for any guidance,

Chris Rohrer

-----------[000629][next][prev][last][first]----------------------------------------------------
Date:      Thu, 30 Jun 1994 06:34:30 GMT
From:      hjb@netcom.com (squeedy)
To:        comp.protocols.tcp-ip
Subject:   Re: AF_UNIX & AF_INET Domains

Tohru Asami (tru@kddnews.kddlabs.co.jp) wrote:

: SUMMARY:
:    Using the same internal kernel mechanisms as pipes, UNIX domain
:    uses the file system namespace to establish connections.  It creates
:    the file, but the file is little more than a placeholder in the
:    system.  The file does not have anything to do with data transfer.
:    The file system provides an alternative connection namespace, that
:    is all. Unix domain sockets don't use TCP/IP at all.

my $.02,

there is at least one implementation of AF_UNIX that does not create a
file for UNIX sockets.  using a file for connection namespace is a
hack, and it is not required.  my implementation of AF_UNIX for SVR3.2
UNIX for motorola delta boxes rely on instantiations of a STREAM
within the kernel and the binding a STREAM to the socket is done
independently of the file system.  there are quite a few systems that
run this code out there still.

-- 
hwajin
PEACEFUL STAR

-----------[000630][next][prev][last][first]----------------------------------------------------
Date:      30 Jun 1994 06:47:46 GMT
From:      bq274@cleveland.Freenet.Edu (Andy J. Berkvam)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject:   Re: Microsoft's Windows Internet Name Service?


In a previous article, phil@lykos.netpart.com (Phil Trubey) says:

>Does anyone have some detailed info about Microsoft's new 
>Windows Internet Name Service that they will be offering in their upcoming
>TCP/IP products?  I remember reading somewhere that it was similar to DNS, but
>not, in fact, DNS.  Does this mean that large sites that currently use DNS
>will have to maintain two machine naming systems?
>
>Thanks for any info,

'lo

  As I understand it, another server will be required.  The Wolverine
TCP stack put out by Microsoft for WfW 3.11 uses it.

  Check out http://www.microsoft.com/wolverine.  There's some
information out there.  For more info, get the actual Wolverine release
and read the Windows Help file.  (No need to install, just unzip it and
load it into Windows Help.)  All sorts of good info on the new name
resolution, DHCP, etc.

Andy

-- 
Andy Berkvam                          |  Few are wholly dead:
U of Wisconsin - Stevens Point        |  Blow on a dead man's embers
Cleveland Freenet: bq274              |  And a live flame will start.
Internet: aberkvam@spbsd1.uwsp.edu    |