The 'Security Digest' Archives (TM)

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

ARCHIVE: TCP-IP Distribution List - Archives (1993)
DOCUMENT: TCP-IP Distribution List for December 1993 (465 messages, 264806 bytes)
SOURCE: http://securitydigest.org/exec/display?f=tcp-ip/archive/1993/12.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 Dec 93 00:09:32 GMT
From:      irving@sys.toronto.edu (Irving Reid)
To:        comp.protocols.tcp-ip,comp.security.unix
Subject:   TCP source routing and setsockopt(SO_DONTROUTE)

I've been trying to sort out the security issues involving TCP source
routing and host spoofing.  I've gone through Stevens' _Unix_Network_
_Programming_ and Comer's _Internetworking_with_TCP/IP_, and I'm still
not quite clear on how TCP should behave in the presence of a source
route.

I would like to make a network service safe from source routing attacks.
I know about DNS spoofing, and I can handle that; my concern is with remote
systems using source routing to get connections onto my network which have
the IP source addresses of trusted hosts.

The services we need to restrict are all TCP-based.

If an incoming TCP connection uses source-routed packets, will the reply
packets for that connection follow the (reversed) source route?  If not,
my life is easier; I just have to make sure I don't trust a TCP stream
that doesn't work in both directions.

I have also seen mention of using the SO_DONTROUTE socket option to
turn off source routing, but from reading the manual pages it's unclear
exactly what this is supposed to do.  The SO_DONTROUTE descriptions
sound more like it will ignore the kernel routing tables (ie, the
information maintained by routed(8) or gated(8); they don't mention
source routing.

Thanks beforehand,

 - irving (@sys.utoronto.ca, @platform.com) -

-----------[000001][next][prev][last][first]----------------------------------------------------
Date:      1 Dec 1993 00:36:20 GMT
From:      tli@cisco.com (Tony Li)
To:        comp.protocols.tcp-ip
Subject:   Re: Multiple Class B meshed Networks

In article <DTROP.4.0009C811@uxscosv1.asit.utah.gov>
DTROP@uxscosv1.asit.utah.gov (Dennis Trop) writes: 
    
    I need to implement two class B networks across a large state-wide
    network.  The requirements are such that we need to "mesh" the networks
    together.  We are using Frame Relay between alot of locations.  We are
    currently masking on 255.255.255.128 for the first network and
    255.255.255.192 for the second.  We want to use the second network for
    the small remote offices.
    
This will cause you great confusion.  I hope you're using OSPF.

    Do we need to implement a gateway between the two networks that are either 
    physically or logically separate?  Or do we use some sort of secondary 
    addresses on our routers?
    
Your routers should be able to cope with this.

    Our routers are ascom-Timeplex!
    
Hmm.....

Tony

-----------[000002][next][prev][last][first]----------------------------------------------------
Date:      1 Dec 1993 01:01:30 GMT
From:      lynchtk@wfu.edu (thomas kevi lynch)
To:        comp.protocols.tcp-ip
Subject:   Connect MacTCP nework to Internet by modem?


I was wondering if there are any programs out there that will allow me to 
connect a Mac network running MacTCP to a remote network over a 14.4 
serial modem connection.  I realize this would be somewhat slow and 
cumbersome, but it would enable some basic Internet interaction.  The 
local network consists of a bunch Mac SEs, SE/30s, and Classics running 
System 7.  The remote machine is a Sparc running SunOS 4.1.3.  I have
been unable to get any SLIP ports to compile on either end, but I think 
this is the right direction.  If anyone has any solutions, suggestions, 
ideas, or comments, I'd appreciate them.  Thanks,
							Tom
 


-----------[000003][next][prev][last][first]----------------------------------------------------
Date:      1 Dec 1993 16:22:24 -0800
From:      mark@telco-nac.com (Mark E. Ruedy)
To:        comp.protocols.tcp-ip
Subject:   Need Telnet for Mac

I believe there are some public domain packages for Telnet access from
Macs.  I have SPARC hosts and need to Telnet into them from Macs.

Which is the best to use and where can I find it?

Please reply via EMAIL

thanks
mark



-----------[000004][next][prev][last][first]----------------------------------------------------
Date:      1 Dec 93 03:24:56 GMT
From:      imam@yoko.rutgers.edu (Adil S. Imam)
To:        comp.protocols.tcp-ip
Subject:   Software Distribution Packages for TCP/IP Networks: Req. for Info.


Are there any software distribution packages for relatively large (or
even small) TCP/IP networks?  Any information about both public domain
and commercial packages would be greatly appreciated.

Thanks.

-Adil
-- 
Adil S. Imam				Dept. of Computer Science
+ 1 (908) 355-8590			Rutgers University
imam@paul.rutgers.edu			New Brunswick, NJ 08903

-----------[000005][next][prev][last][first]----------------------------------------------------
Date:      Wed, 1 Dec 1993 03:46:24 GMT
From:      newsham@wiliki.eng.hawaii.edu (Timothy Newsham)
To:        comp.protocols.tcp-ip,comp.security.unix
Subject:   Re: TCP source routing and setsockopt(SO_DONTROUTE)

In article <1993Nov30.190932.18574@jarvis.csri.toronto.edu> irving@sys.toronto.edu (Irving Reid) writes:
>
>If an incoming TCP connection uses source-routed packets, will the reply
>packets for that connection follow the (reversed) source route?  If not,
>my life is easier; I just have to make sure I don't trust a TCP stream
>that doesn't work in both directions.

There is no real "connection".  Return packets are routed normally
I believe, which means that they would take the normal path, not a
strange path taken by the packet they are responding to.  I dont believe
the kernel does anything with the routing path in the IP packet
it received (unless it needs to route it to the next hop).

As far as not trusting a TCP stream that doesn't work in both directions,
this one is really easy.  The handshaking that goes on to set up a
TCP "connection" pretty much insures that there is a two way connection.
The only way to set up a TCP connection with only 1 direction of data
flow is to guess at the sequence number of the remote host,  such an
attack is outlined in S. Bellovin's paper on the security of TCP/IP.

                                  Tim N.

> - irving (@sys.utoronto.ca, @platform.com) -
 

-----------[000006][next][prev][last][first]----------------------------------------------------
Date:      1 Dec 1993 12:46:47 -0500
From:      philp@universe.digex.net (Phil Perucci)
To:        comp.protocols.tcp-ip
Subject:   Specify specific reserved port?

hi,

  In the code fragment below, does anyone know how to specify a
SPECIFIC reserved port in the range 721-731 (or even a specific
port, for example 725)?  I just don't get it...

	int fd;

	} else if (port < 0) {
		resvport = IPPORT_RESERVED - 1; 
		if ( (fd = rresvport(&resvport)) < 0) {
			err_ret("tcp_open: can't get a reserved TCP port");
			return(-1);
		}
	}

code below included only for context

	/*
	 * Connect to the server.
	 */

	if (connect(fd, (struct sockaddr *) &tcp_srv_addr,
						sizeof(tcp_srv_addr)) < 0) {
		err_ret("tcp_open: can't connect to server");
		close(fd);
		return(-1);
	}

	return(fd);	/* all OK */
}



-- 
==============================================================================
 Phil Perucci             | "All postings are my own opinion - all comments
 Systems Programmer       |  are intended for research/educational purposes"
==============================================================================

-----------[000007][next][prev][last][first]----------------------------------------------------
Date:      1 Dec 93 11:19:48
From:      drw@zermelo.mit.edu (Dale R. Worley)
To:        comp.protocols.tcp-ip
Subject:   Re: Disabling character echo on a connection

In article <2dhqe5INNacv@life.ai.mit.edu> twilson@gnu.ai.mit.edu (Tom Wilson) writes:
   Is there a way to disable the automatic echoing of characters on a TCP
   connection?  I'm working on a program that uses passwords and I want to
   disable this during the typing of the password.

The TCP connection itself doesn't echo anything; the echos are being
done by the client or server programs at either end, or by the
terminal or pseudo-terminal drivers at either end.  You're going to
have to track down who's really doing the echoing and get it to stop.

Dale

Dale Worley		Dept. of Math., MIT		drw@math.mit.edu
--
Most loathsome events become humorous tales with the passage of time.
-- Jimmy Buffett, "Tales from Margaritaville"

-----------[000008][next][prev][last][first]----------------------------------------------------
Date:      Wed, 1 Dec 1993 07:19:58 GMT
From:      jmg@dxcoms.cern.ch (J.M. Gerard)
To:        comp.protocols.tcp-ip
Subject:   Trying to explain/avoid a type of broadcast storm


Having a large bridged ethernet we are very sensitive to any cause of
bursts of broadcast packets: most of these we can explain, even eliminate.

One problem, which the manufacturer(s) concerned seem unwilling, or
unable, to explain is due to systems, mostly Suns, issuing IP broadcasts
looking for various RPC programs, particularly NIS servers (RPC program
100004 version 2 process 2 is very frequent, but there are others such
as the 100026 shown below) via UDP port 111 (portmapper).

In the vast majority of cases these elicit very little reaction, apart
from the server actually being sought. However, in a few cases vast numbers
of systems seem to get interested for no reason whatsoever: they ARP
for the original Sun in order to reply: the Sun then ARPs for all the
answerers and lo and behold, we have a bunch of 1000 broadcasts or more
per second. The replying systems include, but are far from being confined
to, Suns.

On looking at a Sniffer trace, it seems that the packets which trigger
this are all interpreted as being without 4 bytes of authorization data.
This is an empirical observation: the actual details are shown below.
We have been asking for a reason for this behaviour for the past few
months: the answer is not forthcoming. I therefore pass the simple question
out to a wider audience, where I might get a quick and simple answer.
What is the Sniffer protocol analyser really saying, and why does this
lack of authorisation data apparently cause lots of systems to reply?

BTW, this is important to us because we have a nice piece of auto-blocking
software on site. Any system which issues a few hundred broadcasts in
less than 10 seconds gets blocked on the FDDI backbone. This tends to
happen quite often to Suns!

Packet trace :-


Top-level one-line description.

1892    0.0806  [128.141.2...[128.141.2..  PMAP C Call PROG=100026, VERS=1, PROC=2



Interpreted by a Sniffer

DLC:  Frame 1892 arrived at  16:13:00.0398; frame size is 154 (009A hex)
DLC:  Destination = BROADCAST FFFFFFFFFFFF, Broadcast
DLC:  Source      = Station Sun   18E2C6
DLC:  Ethertype  = 0800 (IP)

IP:   ----- IP Header -----
IP:   Version = 4, header length = 20 bytes
IP:   Type of service = 00
IP:         000. .... = routine
IP:         ...0 .... = normal delay
IP:         .... 0... = normal throughput
IP:         .... .0.. = normal reliability
IP:   Total length = 140 bytes
IP:   Identification = 31202
IP:   Flags = 4X
IP:   .1.. .... = don't fragment
IP:   ..0. .... = last fragment
IP:   Fragment offset = 0 bytes
IP:   Time to live = 1 seconds/hops
IP:   Protocol = 17 (UDP)
IP:   Header checksum = 10F5 (correct)
IP:   Source address = [128.141.xxx.xxx]
IP:   Destination address = [128.141.255.255]
IP:   No options

UDP:  ----- UDP Header -----
UDP:  Source port = 32769 (Sun RPC)
UDP:  Destination port = 111
UDP:  Length = 120
UDP:  Checksum = 5870 (correct)

RPC:  ----- SUN RPC header -----
RPC:  Transaction id = 751735013
RPC:  Type = 0 (Call)
RPC:  RPC version = 2
RPC:  Program = 100000 (Port mapper), version = 3
RPC:  Procedure = 5 (Indirect call routine)
RPC:  Credentials: authorization flavor = 1 (Unix)
RPC:   len = 32, stamp = 751561971
RPC:   machine = xxxxxxxxx
RPC:   uid = 0, gid = 0
RPC:   auth data too short by 4 byte(s)                        !!!!!!!!!!!
RPC:  Verifier: authorization flavor = 0 (Null)
RPC:  [Verifier: 0 byte(s) of authorization data]
RPC:  [Normal end of "SUN RPC header".]

PMAP: ----- SUN Port Map -----
PMAP: Proc = 5 (Indirect call routine)
PMAP: Program = 100026, version = 1, proc = 2
PMAP: [24 byte(s) of argument data]
PMAP: [Normal end of "SUN Port Map".]



0000  FF FF FF FF FF FF 08 00  20 18 E2 C6 08 00 45 00  ........ .....E.
0010  00 8C 79 E2 40 00 01 11  10 F5 80 8D xx xx 80 8D  ..y.@........o..
0020  FF FF 80 01 00 6F 00 78  58 70 2C CE 90 E5 00 00  .....o.xXp,.....
0030  00 00 00 00 00 02 00 01  86 A0 00 00 00 03 00 00  ................
0040  00 05 00 00 00 01 00 00  00 20 2C CB EC F3 00 00  ......... ,.....
0050
0060  down
0070  to
0080
0090  00 00 00 00 00 04 72 6F  6F 74                    ......root




-----------[000009][next][prev][last][first]----------------------------------------------------
Date:      Wed, 1 Dec 93 07:41:37 GMT
From:      ftlofaro@unlv.edu (Frank Lofaro)
To:        comp.protocols.tcp-ip
Subject:   Re: lpr/lpd port?

In article <2dh1c1$7n4@universe.digex.net> philp@universe.digex.net (Phil Perucci) writes:
>Could some kind soul shed some light on this...
>
>Is port 515 the only port involved with lpr/lpd?  I am trying to
>get an lpr client (specifically written for SVR3 systems - no lpd
>required!) working on my ancient dialect of Unix.  Everything
>seems OK until my lpr starts talking to the remote lpd.  Rather
>than the remote lpd sending me a '\0' initially in response to
>my "... \002" to begin a file transfer, I get "Improperly formed
>from address".
>
>When I "telnet IPADDRESS 515" to check permissions, I get the
>same nasty "Improperly formed from address".
>
>Is there a way to just telnet or ftp to a port on a remote lpd
>just to check permissions?
>
>Any help, comments, pointers, jests, flames or wise-cracks
>GREATLY appreciated.  I am really pulling my hair out on this one...
>

The lpd standard specifies the source port must be in a specific range.

The spec is in rfc1179.

The source port must be in the range 721 to 731, inclusive.

Your lpr client needs to be modified to bind to a port in that range 
(as root, since those are restricted ports) before the connect() call.

I hope this helps.


-----------[000010][next][prev][last][first]----------------------------------------------------
Date:      01 Dec 93 08:25:03 GMT
From:      jraja@snakemail.hut.fi (Jarno Tapio Rajahalme)
To:        comp.protocols.tcp-ip
Subject:   Re: looking for TCP/IP software

In article <CH9znq.C8z@sugar.NeoSoft.COM> fcis@NeoSoft.com (Farmer's Copper and Industrial Supply) writes:

>  We  are  looking  for  TCP/IP  software  that we can bundle with our
>DOS-based product to give it access to a NFS server running on a  UNIX
>system.  We  don't care too  much how it  is implemented; it  can be a
>TSR, a 'programmer's  toolkit', or a  DLL (assuming that  DLL does not
>have specificly need to have Windows present).

Is the usage of the NFS a must? If you are just copying files, rcp,
ftp or tftp might be better, simpler, cheaper etc. I'm not familiar
with the DOS based (t)ftp clients, but copying a remote file is not
really that hard.

Just checked the PC-NFS (SunSelect) manual, it has the rcp (Remote
CoPy), which should be able to do all you need.

	Jarno
-- 
-----------------------------------------------------------------------------
| Address: Jarno Rajahalme            | EMail:                              |
|          Servin Maijan tie 12 H 111 |   Jarno.Rajahalme@hut.fi            |
|          02150  ESPOO, FINLAND      | tel: +358 0 468 2891                |
-----------------------------------------------------------------------------

-----------[000011][next][prev][last][first]----------------------------------------------------
Date:      1 Dec 1993 10:08:05 GMT
From:      twilson@gnu.ai.mit.edu (Tom Wilson)
To:        comp.protocols.tcp-ip
Subject:   Disabling character echo on a connection


Is there a way to disable the automatic echoing of characters on a TCP
connection?  I'm working on a program that uses passwords and I want to
disable this during the typing of the password.

I've tried using ioctl() calls, but the only ones that I've found that would
do this work only on tty devices and not on sockets.  I also don't think
it would be appropriate to rewrite the inetd server to accomplish this.

Any information would be greatly appreciated.
Tom Wilson
twilson@gnu.ai.mit.edu
From: twilson@gnu.ai.mit.edu (Tom Wilson)
Newsgroups: comp.protocols.tcp-ip
Subject: 
Summary: 
Followup-To: 
Distribution: world
Organization: Free Software Foundation
Keywords: 

From: twilson@gnu.ai.mit.edu (Tom Wilson)
Newsgroups: comp.protocols.tcp-ip
Subject: Disabling character echo on a connection
Summary: 
Expires: 
Sender: 
Reply-To: twilson@gnu.ai.mit.edu.UUCP (Tom Wilson)
Followup-To: 
Distribution: 
Organization: Free Software Foundation
Keywords: echo disable help


Is there a way to disable the automatic echoing of characters on a TCP
connection?  I'm working on a program that uses passwords and I want to
disable this during the typing of the password.

I've tried using ioctl() calls, but the only ones that I've found that would
do this work only on tty devices and not on sockets.  I also don't think
it would be appropriate to rewrite the inetd server to accomplish this.
The program is running on a Un*x flavored machine.

Any information would be greatly appreciated.
Tom Wilson
twilson@gnu.ai.mit.edu



-----------[000012][next][prev][last][first]----------------------------------------------------
Date:      Wed, 1 Dec 1993 13:13:14 GMT
From:      alter@techunix.technion.ac.il (Alter Ilan)
To:        comp.protocols.tcp-ip
Subject:   3C509/accton/????

I had a standard which was SMC Ethernet Cards.	
Now as SMC stop producing the "old" card and start manufacturing the Ultra card which is not working proparly with PD, I am looking for a new standard:
I think on going into 3C509 or accton (ne2000) or something else.	
Any remarks (good or bad) on those two cards?  
Anyone has another recomandations?
                                                       Ilan Alter
                                                    Network Manager

-----------[000013][next][prev][last][first]----------------------------------------------------
Date:      Wed, 01 Dec 93 13:28:00 GMT
From:      marianne@kub.nl  (baliemedewerkers C.I.C )
To:        comp.protocols.tcp-ip
Subject:   Protocol definitions above tcp/ip

Hello guys,
My name is C. Bouhier. I'm looking for documentation which describs the 
various applications on top of tcp/ip. I mean the apps like FTP, TELNET etc.  
It is also not clear to me who defines the application protocols above the 
tcp/ip layers.
Thanks a lot for your help,
C. Bouhier.
Email: CIC@kub.nl
Tilburg Netherlands.

-----------[000014][next][prev][last][first]----------------------------------------------------
Date:      Wed, 1 Dec 1993 14:27:50 GMT
From:      jim@reptiles.org (Jim Mercer)
To:        comp.protocols.tcp-ip
Subject:   Re: Canonical KA9Q ftp site ?

In <CH4oru.At0@ra.nrl.navy.mil> atkinson@itd.itd.nrl.navy.mil (Ran Atkinson) writes:
>I'm looking for the canonical ftp site for the KA9Q TCP/IP package for DOS.
>I'm not looking for the various and sundry derivatives of KA9Q (e.g. KA9Q
>for Linux), only the regular KA9Q sources for DOS.

well, _the_ ka9q is found in ucsd.edu:/hamradio/packet/tcpip/ka9q.

however, there are a number of versions for DOS which have an untold number
of advantages/disadvantages compared to Phil Karn's version (KA9Q is Phil's
ham radio call sign).

in ucsd.edu:/hamradio/packet/tcpip you will find a number of directories
named after different people's call signs, which contain these versions.

-- 
[ Jim Mercer   Reptilian Research  merce@iguana.reptiles.org  +1 416 506-0654 ]
[      "'Tis better to clutch a glowing squid than curse the darkness."       ]
[                                                     Archie McPhee Catalog   ]

-----------[000015][next][prev][last][first]----------------------------------------------------
Date:      Wed, 1 Dec 1993 14:45:21 GMT
From:      jimc@jts.com (Jim Carroll )
To:        comp.dcom.lans.ethernet,comp.protocols.tcp-ip
Subject:   port number question

I've been trying to sleuth a bandwidth usage problem and have
come up with the following:

- during normal business hours, upwards of 96% of the traffic
is UDP;

- of this UDP traffic, the offending destination ports are:

	1. 1022
	2. 1021
	3. 1020

(sometimes 2 and 3 switch around, but 1 keeps top honours);

- there is no mention of any of these ports in /etc/services.

Would anybody have an idea what process(es) belong to these
ports?

Also, can anybody recommend a free utility available on the
Internet which:

- is similar in function to Delft U.'s Beholder/Gobbler, but
will run under SunOS (4.1.x);

- can be ASCII, but X/Motif preferred;

- can be similar to Sun's traffic tool, but will actually run
under X/Motif.

- can breakdown/filter traffic displays, display a frequency
bar chart, whatever.

SunOS 4.1.x functionality mandatory.  Will show interest
in Solaris 2.x versions.

I already have Curtin U's Etherman/Interman/Packetman, and
the DOS tool ETHLD103.ZIP.  It was between these two that I
was able to get this far.  Oh, some credit goes to nfswatch
and etherfind.

Thanks for any info.
-- 
Jim Carroll   | If Jim Morrison drove his van to Van Morrison's gym,
jimc@jts.com  | would Don Johnson use the john in Van Johnson's van?
              |   - Charles Fleischer

-----------[000016][next][prev][last][first]----------------------------------------------------
Date:      1 Dec 93 14:56:54 GMT
From:      lvandyke@balboa.eng.uci.edu (Lee Van Dyke)
To:        comp.protocols.tcp-ip
Subject:   What's the difference between IPPROTO_IP & IPPROTO_TCP for stream sockets?



Can anyone tell me what the difference is between:
#define IPPROTO_IP              0               /* dummy for IP */
#define IPPROTO_TCP             6               /* tcp */

The Unix Network Programming book only says that 0 is the typical value
used as the protocol argument for the socket system call. Does this
mean a reliable connection is established and data will be rebroadcast
if not received?


Thanks in advance,


--
Lee Van Dyke
      lvandyke@balboa.eng.uci.edu,
UUCP: infotec!Infotec.COM!lee@sunkist.West.Sun.COM

-----------[000017][next][prev][last][first]----------------------------------------------------
Date:      Wed, 1 Dec 1993 15:01:33 GMT
From:      alter@techunix.technion.ac.il (Alter Ilan)
To:        comp.protocols.tcp-ip
Subject:   Ethernet Controller on Parallel interface

I am looking for Ethernet adapter which is pluged to the parallel port.
I need it to work with PD.
I have been using the D-link adapter with was found to be good but the problem 
is that it has only one kind of connection (bnc/aui/10bast-T) on it.	

Is anyone using an adapter which fits my demands (has pd and 2 or more 
connections)?

                                                        Ilan Alter
                                                     Network Manager

-----------[000018][next][prev][last][first]----------------------------------------------------
Date:      1 Dec 93 12:29:02 +0200
From:      weissman@uctvax.uct.ac.za
To:        comp.protocols.tcp-ip
Subject:   dos version of TALK anywhere?

Hello,

I am trying to find a version of internet TALK which will run on dos machines.
Does anyone know where to find such a critter??

Avrohom Weissman
Weissman@uctvax.uct.ac.za
University of Cape Town   South Africa


-----------[000019][next][prev][last][first]----------------------------------------------------
Date:      Wed, 1 Dec 1993 16:44:07 GMT
From:      perlman@zeno.fit.edu (Marshal H. Perlman)
To:        comp.protocols.tcp-ip
Subject:   TN3270 FOR DOS

Does anyone have a copy of TN3270 that will run w/ NCSA's (or CUTCP's)
CONFIG.TEL???

It is sort of important!
-- 
  |o| Marshal Perlman                       Internet: perlman@cs.fit.edu |o|
  |o| Academic and Research Computing Services (ARCS)        IRC: Squawk |o|
  |o| Florida Institute of Technology                Private Pilot, ASEL |o|
  |o| Pager: 407/455-4809          Member: AOPA/AAAE/Goodyear Blimp Club |o|

-----------[000020][next][prev][last][first]----------------------------------------------------
Date:      1 Dec 1993 16:51:00 GMT
From:      wls@magrathea.csd.uwm.edu (Bill Stapleton)
To:        comp.protocols.tcp-ip
Subject:   Re: lpr/lpd port?

In article <1993Dec1.074137.3888@unlv.edu>, ftlofaro@unlv.edu (Frank Lofaro) writes:
> The lpd standard specifies the source port must be in a specific range.

There is no "lpd standard" per se.  The RFC appears to be a description
of a particular implementation.  Some of the stuff in that RFC I've never
actually seen in any LPD.  In particular, this is really bogus:

> The source port must be in the range 721 to 731, inclusive.

What most LPDs expect is simply a "privileged" port, usually just a port
less than 1024.  Of course with non-Unix machines, especially PCs, that
little security feature is now quite dated.

Unfortunately, now we're probably stuck with ports 721-731, since people are
undoubtedly writing to this spec.  Which means your perfectly good BSD "lpr"
client might not work with somebody's new "standard lpd".  Sigh.  Of course
if BSD had documented it better in the first place, somebody else wouldn't
have felt the need to come along and break it.  Double sigh.  I hate when
that happens...

--
Bill Stapleton
     wls@magrathea.csd.uwm.edu
     uwmcsd4!wls


-----------[000021][next][prev][last][first]----------------------------------------------------
Date:      Wed, 1 Dec 1993 17:19:07 GMT
From:      cricket@hpuecoz.nsr.hp.com (Cricket Liu)
To:        comp.protocols.tcp-ip
Subject:   Re: DNS - what RRs must the server return?

Arnt Gulbrandsen (agulbra@nvg.unit.no) wrote:
: I've noticed that when I do a nameserver query, I get some extra
: info which the server thinks I might need, e.g. when I ask for a
: CNAME or MX I also get the corresponding A record(s).  Is this
: behaviour part of the DNS protocol (and widely implemented) or is it
: just that the name servers around here try to be helpful?
 
: To put it another way, when I want to resolve an MX record to IP
: numbers, do I need code to do an extra query in case the MX query
: doesn't return the A's in the AR field?

Check out the parts of RFC1035 that discuss additional section processing
for each type of record.

--
cricket

cricket@hp.com / Hewlett-Packard Professional Services / Englewood, CO

-----------[000022][next][prev][last][first]----------------------------------------------------
Date:      1 Dec 93 17:57:35 GMT
From:      bill@melupl (Bill Fulton)
To:        comp.protocols.tcp-ip
Subject:   Re: ping: socket: permission denied

In article <CH3vG7.GLn@ewi.ch> wat@ewi.ch (Thomas Wacker) writes:
>>Jim Burnes (jburnes@csisun.uucp) wrote:
>>: I've never seen this error before.  I'm running SCO Unix with their
>>: TCP/IP package.  Telnet and ftp seem to run fine, but 'ping', 'rlogin',
>>: 'rcmd' (rsh) and rcp all respond with the same....
>>: (program name): socket: permission denied
>
>At least on our Sparc 1 (SunOS 4.1) ping must run setuid root!

Same is true on AIX. I presume this is because a ping requires access to raw
IP (to generate the ICMP msg), which requires root permission. If this is true,
I would expect the setuid to be the case on all systems.

-- 
Bill Fulton  -  Melita Intl.      |   Grab ..
   ..!dscatl!melupl!bill          |       the ..
OR bill@wafbox.gwinnett.com       |           reins

-----------[000023][next][prev][last][first]----------------------------------------------------
Date:      Wed, 1 Dec 1993 18:51:37 GMT
From:      ihsan@nmti.com (jaleel ihsan)
To:        comp.protocols.tcp-ip
Subject:   Re: The connect-connect syndrome - A bug or feature?

In article <2dghf0$dg8@usenet.INS.CWRU.Edu>, trier@slc6.ins.cwru.edu (Stephen C. Trier) writes:
> In article <1993Nov23.201520.4366@novell.com>,
> don provan <donp@novell.com> wrote:
> >I haven't been able to come up with any practical application of this
> >feature, but the spec requires that an implementation of TCP handle it
> >in a way that produces a single, usable connection.
> 
> After putting some thought into this, I decided the only reason for the
> feature is the "how else would you do it" argument.  I've managed to
> rationalize that I can't come up with any other behavior that makes
> much sense in the context of the rest of TCP.
> 
> The only application I've been able to think up is something where two
> machines sit and listen on port X.  When one needs to tell the other
> something, it opens a connection from port X to port X on the other
> machine.  Should the two machines try to open a connection
> simultaneously, it will open correctly.
> 
> I haven't been able to think of a good reason to use such a protocol,
> especially given the TIME-WAIT connection-reuse delay, but it seems
> like it would work.
> 

I have a very good reason for TCP connect-connect to work exactly the
way it is designed to.

I have a requirement (and lets not get into religous wars about having
such a requirement, believe me in my case it makes sence to have it)
to have a communication protocol between two system in which the two sides
have a "peer-to-peer" relationship, that's right "peer-to-peer" not
"client-server".

TCP connect-connect gives me the perfect solution I was looking for.

Hats off for the designers of TCP !

-----------[000024][next][prev][last][first]----------------------------------------------------
Date:      2 Dec 1993 09:23:06 -0800
From:      schmidt@net1.ics.uci.edu (Douglas C. Schmidt)
To:        comp.protocols.tcp-ip
Subject:   Re: A Good TCP/IP Book

In article <longyearCHE53H.Dwo@netcom.com>,
Alfred Longyear <longyear@netcom.com> wrote:
++ SVILLINSKI@macalstr.edu writes:
++ 
++ >I'm in need of a decent TCP/IP book.  I'm interested in learning more about 
++ >TCP/IP and I want to make sure that I get a book that will be really helpful.  
++ TCP/IP is like most anything else -- it means different things to different
++ people. Since you didn't specify what type of information that you want, here
++ is the my short list.

Another recent entry into the list of useful books on TCP/IP is
Richard Stevens latest:

	TCP/IP Illustrated Volume 1: the protocols
	W. Richard Stevens
	Addison-Wesley

This book is unique in that it utilizes "packet sniffer" tools (such
as tcpdump and snoop) to visually characterize the run-time behavior
of various protocols in the TCP/IP protocol suite (e.g., ARP, ICMP,
IP, UDP, TCP, SNMP, etc.).

I personally found the section on advanced features of TCP particular
enlightening since it illustrated the behavior of the fast retransmit
and slow start algorithms in a manner that is much more intuitive than
reading the relevant RFCs.

	Doug
-- 
Douglas C. Schmidt
Department of Information and Computer Science
University of California, Irvine
Irvine, CA 92717. Work #: (714) 856-4105; FAX #: (714) 856-4056

-----------[000025][next][prev][last][first]----------------------------------------------------
Date:      1 Dec 1993 20:17:32 GMT
From:      barmar@think.com (Barry Margolin)
To:        comp.protocols.tcp-ip
Subject:   Re: Disabling character echo on a connection

In article <2dhqe5INNacv@life.ai.mit.edu> twilson@gnu.ai.mit.edu.UUCP (Tom Wilson) writes:
>Is there a way to disable the automatic echoing of characters on a TCP
>connection?  I'm working on a program that uses passwords and I want to
>disable this during the typing of the password.
>
>I've tried using ioctl() calls, but the only ones that I've found that would
>do this work only on tty devices and not on sockets.  I also don't think
>it would be appropriate to rewrite the inetd server to accomplish this.

TCP doesn't do automatic echoing.  The only TCP-based protocol that
includes echoing support is TELNET.  A TELNET server can control the client
(and vice versa) by sending in-band option negotiations.  You can send IAC
DONT ECHO to turn off the client's local echoing.  See RFC 854 for the
TELNET specification, and RFC 857 for the ECHO option specification.

-- 
Barry Margolin
System Manager, Thinking Machines Corp.

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

-----------[000026][next][prev][last][first]----------------------------------------------------
Date:      2 Dec 1993 10:07:33 -0800
From:      bergan@balrog.horizon.com (Charles Bergan)
To:        comp.protocols.tcp-ip
Subject:   NCSA/TELNET on a mac problems (HELP!)

I am posting this for a friend, please reply directly to him at
tengel@aol.com

thanks,
charles

--------

Help! I am having trouble configuring NCSA/BYU Telnet 2.5 on my Macintosh
Q700 for a SLIP connection. I have read the entire manual and tried a large
number of possibilites without success. Most combinations result in a "Could
not initialize hardware level network driver" message. The Serial/SLIP check
box in the Open Connection dialog is always dimmed. The Session menu is
always dimmed. Can someone who has done this successfully share the contents
of their config.tel file, and any other relevant information? Thanks!

Tom Engel
tengel@aol.com



-----------[000027][next][prev][last][first]----------------------------------------------------
Date:      Wed, 1 Dec 1993 23:00:43 GMT
From:      miltonm@austin.ibm.com (Milton D. Miller II)
To:        comp.protocols.tcp-ip
Subject:   Re: The connect-connect syndrome - A bug or feature?


One reason for connect-connect to happen is when you have a symmetric
server protocol (eg conferencing brige) that uses a well known port to
both originate data to other clients and servers, and two of these 
servers are restarted "at the same time" and both are told they should
send data to the other.

milton
--
Milton Miller  KB5TKF  miltonm@austin.ibm.com
I never speak for IBM.

-----------[000028][next][prev][last][first]----------------------------------------------------
Date:      2 Dec 93 10:04:22 -0600
From:      heilja@cnsvax.uwec.edu
To:        comp.protocols.tcp-ip
Subject:   echo server, socket & connect problems


 Im try to set up an echo server between 2 networks,
 one of class b and the other of class c.  When I try
 to connect from one to another I receive a "connection refused"
 message.  The class b network is an alpha machine running OSF/1
 and the class c machine is Mac Quadra 700 running A/UX. I set up
 the socket connection using the AF_INET domain. Any help is
 appreciated.
 Thanks in advance,
 J.Heil

-----------[000029][next][prev][last][first]----------------------------------------------------
Date:      1 Dec 1993 23:19:02 +0100
From:      wietse@wzv.win.tue.nl (Wietse Venema)
To:        comp.protocols.tcp-ip,comp.security.unix
Subject:   Re: TCP source routing and setsockopt(SO_DONTROUTE)

irving@sys.toronto.edu (Irving Reid) writes:

>If an incoming TCP connection uses source-routed packets, will the reply
>packets for that connection follow the (reversed) source route?  If not,
>my life is easier; I just have to make sure I don't trust a TCP stream
>that doesn't work in both directions.

The source route is part of the state maintained in the kernel. Replies
follow the same path back. In my general-purpose daemon front-end
program (*) I have provisions for killing source-routing options, but
many UNIX kernels have bugs in the [gs]etsockopt() code.  Someone at
Berkeley forgot to lock some data structures, causing the kernel to
sometimes panic while dereferencing a null-pointer.

	Wietse

(*) ftp.win.tue.nl:/pub/security/tcp_wrappers_6.0.shar.Z

-----------[000030][next][prev][last][first]----------------------------------------------------
Date:      Thu, 2 Dec 1993 01:38:26 GMT
From:      becker@super.org (Donald J. Becker)
To:        comp.protocols.tcp-ip
Subject:   Re: Ethernet Controller on Parallel interface

In article <CHD32L.GJt@discus.technion.ac.il>,
Alter Ilan <alter@techunix.technion.ac.il> wrote:
>I am looking for Ethernet adapter which is pluged to the parallel port.
>I need it to work with PD.
>I have been using the D-link adapter with was found to be good but the problem 
>is that it has only one kind of connection (bnc/aui/10bast-T) on it.	

I've recently (last week) finished writing a Linux driver for the AT-Lan-Tec
pocket adaptor.  This adaptor appears to be OEMed by RealTek (Taiwan), and
AT-Lan-Tec is a direct importer.  I have reports that very similar products
are available Europe as well.

The adaptor is "normal size" for the product class, about 57mm wide, 22mm high
tapering to 15mm high at the DB25 connector, and 105mm long (120mm including
the BNC socket).  It's switchable between the RJ45 and BNC jacks with a small
slide switch positioned between the two: a very intuitive design.

It's powered by a lightweight 5V wall brick.  I measured an unconnected
quiescent power draw of 102ma for BNC and 84ma for 10baseT.  (Of course the
power draw while transmitting will be significantly higher.)  This is low
enough that you could buy or build a cable to take the 5V directly from the
keyboard port.

AT-Lan-Tec (1-301-948-7070) sells these adaptors for $149 (1-10) $129 (11+),
which is a very reasonable price for this product class.

I know the software package includes a packet driver, but I only ran it long
enough to verify that my driver was reading the correct station address.

Any questions.

-- 

Donald Becker					       becker@super.org
IDA Supercomputing Research Center
17100 Science Drive, Bowie MD 20715			   301-805-7482

-----------[000031][next][prev][last][first]----------------------------------------------------
Date:      2 Dec 1993 02:17:13 GMT
From:      socks@wam.umd.edu (Steve Shapero)
To:        comp.protocols.tcp-ip
Subject:   TCP/IP Routers for Mac WGS95

I am setting up my Mac to sit on the Internet and I need adivce on what
sort of routers work well with Macs.  The WGS95 just means that I am
running A/UX, which is Apple's implementation of Unix.  It is BSD4.2
with a lot of bonus things thrown in, more or less.  I plan on
purchasing a CSU/DSU unit as well, so the router must be able to talk
to this thing as well as my Mac.  I hope this is the correct place to
ask this.

Thanks in advance,

Steve

-----------[000032][next][prev][last][first]----------------------------------------------------
Date:      Thu, 2 Dec 93 02:32:57 GMT
From:      stuartf@sequent.com (Stuart Friedberg)
To:        comp.protocols.tcp-ip,comp.sys.sun
Cc:        stuartf
Subject:   Netid required in RPCBPROC_GETADDR call?

I'd like to know if the RPC port binding protocol version 3 has
a definite statement about where the netid for the RPCBPROC_GETADDR
function comes from.  The "reference implementation" is unclear.

1) Is the netid in the RPCB argument ignored, and the netid always
   taken implicitly from the transport that delivered the query?

2) Is the netid always taken explicitly from the RPCB argument?

3) Is the netid taken from the RPCB argument, unless NULL in which
   case the netid is taken from the delivery transport?

I'd prefer an authoritative answer from the spec, and not a reference to
the code.

This question arises from an rpcbind server that handles version
2 and 3 of the protocol using a single mapping list (and supports
version 2 registrations).  PMAPPROC_GETPORT requests are always
delivered over UDP, no matter which IP family protocol the requests
are for, and we want to make sure our way of dealing with this
(convert PMAP to RPCB and apply #2) is correct.

Stu Friedberg (stuartf@sequent.com)

-----------[000033][next][prev][last][first]----------------------------------------------------
Date:      2 Dec 1993 12:23:45 -0500
From:      barmar@think.com (Barry Margolin)
To:        comp.security.unix,comp.protocols.tcp-ip
Subject:   Re: TCP source routing and setsockopt(SO_DONTROUTE)

In article <CHC7tC.5ow@news.Hawaii.Edu> newsham@wiliki.eng.hawaii.edu (Timothy Newsham) writes:
>In article <1993Nov30.190932.18574@jarvis.csri.toronto.edu> irving@sys.toronto.edu (Irving Reid) writes:
>>If an incoming TCP connection uses source-routed packets, will the reply
>>packets for that connection follow the (reversed) source route?
 
>There is no real "connection".  Return packets are routed normally
>I believe, which means that they would take the normal path, not a
>strange path taken by the packet they are responding to.

From section 4.2.3.8 of RFC 1122:

	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.

Similarly, UDP must make a received source route available to the
application that reads the datagram, and it's supposed to use the reversed
route when sending any replies.

-----------[000034][next][prev][last][first]----------------------------------------------------
Date:      Thu, 2 Dec 1993 04:42:52 GMT
From:      longyear@netcom.com (Alfred Longyear)
To:        comp.protocols.tcp-ip
Subject:   Re: A Good TCP/IP Book

SVILLINSKI@macalstr.edu writes:

>I'm in need of a decent TCP/IP book.  I'm interested in learning more about 
>TCP/IP and I want to make sure that I get a book that will be really helpful.  
TCP/IP is like most anything else -- it means different things to different
people. Since you didn't specify what type of information that you want, here
is the my short list.

ADMINISTRATION
  How to setup and maintain a TCP/IP network

  Unix System Administration Handbook
  by Evi Nemeth, Garth Synder, Scott Seebass
  Prentice Hall

  TCP/IP handbook
  O'Rielly & Assoc.

  (Perhaps speciality books such as DNS&BIND from O'Rielly).

PROGRAMMING
  How to write programs which use TCP/IP networks

  UNIX Network Porgramming
  by W. Richard Stevens
  Prentice Hall

  Operating System Design, Volume II
  "Internetworking with XINU"
  by Douglas Comer
  Perntice Hall

TECHNICAL INFORMATION
  The format of the frames, addresses, etc.

  Besides the RFC documents

  Internetworking with TCP/IP
  by Douglas Comer
  Prentice Hall

Others may have different book lists. This is just the short list.

-----------[000035][next][prev][last][first]----------------------------------------------------
Date:      Thu, 2 Dec 1993 04:48:03 GMT
From:      longyear@netcom.com (Alfred Longyear)
To:        comp.protocols.tcp-ip
Subject:   Re: Protocol definitions above tcp/ip

marianne@kub.nl  (baliemedewerkers C.I.C ) writes:

>Hello guys,
>My name is C. Bouhier. I'm looking for documentation which describs the 
>various applications on top of tcp/ip. I mean the apps like FTP, TELNET etc.  
>It is also not clear to me who defines the application protocols above the 
>tcp/ip layers.

You will find what you wish in the RFC documents. The RFC documents are
available via anon. FTP from nisca.acs.hoio-state.edu:/pub/rfc, amoung
other places.

Get the index to the list and choose the appropriate item from the list.


-----------[000036][next][prev][last][first]----------------------------------------------------
Date:      Thu, 2 Dec 1993 05:46:06 GMT
From:      becker@super.org (Donald J. Becker)
To:        comp.protocols.tcp-ip
Subject:   Re: Ethernet Controller on Parallel interface

>In article <CHD32L.GJt@discus.technion.ac.il>,
>Alter Ilan <alter@techunix.technion.ac.il> wrote:
>>I am looking for Ethernet adapter which is pluged to the parallel port.
>>I need it to work with PD.
>>I have been using the D-link adapter with was found to be good but the problem 
>>is that it has only one kind of connection (bnc/aui/10bast-T) on it.	

In article <1993Dec2.013826.21730@super.org>,  I wrote...
>It's powered by a lightweight 5V wall brick.  I measured an unconnected
>quiescent power draw of 102ma for BNC and 84ma for 10baseT.  (Of course the
>power draw while transmitting will be significantly higher.)  This is low
>enough that you could buy or build a cable to take the 5V directly from the
>keyboard port.

Mmmm, I seem to be wrong about the "significantly higher" comment.  Once again
actual measurements screw up a perfectly good theory!

I hooked the pocket adaptor up to my home thinnet (yes, I do have a home
thicknet) and started FTPing a large file.  The power measurements were:
	idle, connected		99ma @ 5.1V
	active, connected	107ma @ 5.1V
This was measured using a Fluke 8026B true-RMS multimeter, so I'm pretty
confident the numbers are good.

I find these figures surprising low.  The lowest power bus-based adaptor I've
measured consumes 1.5W, and typical cards like the 3c501 and EtherExpress draw
a lot more.  With a little care, a battery-powered pocket adaptor could be
built.  (I have a "battery powered" April pocket modem that draws 350ma @ 9V
Yes, 350ma!  A battery doesn't last much beyond the login prompt.)

-- 

Donald Becker					       becker@super.org
IDA Supercomputing Research Center
17100 Science Drive, Bowie MD 20715			   301-805-7482

-----------[000037][next][prev][last][first]----------------------------------------------------
Date:      2 Dec 93 16:51:40 -0500
From:      harvey@indyvax.iupui.edu (James Harvey)
To:        comp.protocols.tcp-ip
Subject:   Re: RFC where ever you are

In article <BOB.93Dec2080736@roughy.MorningStar.Com>, bob@MorningStar.Com (Bob Sutterfield) writes:
> In article <19931202115243.marianne@dp0120.kub.nl> marianne@kub.nl  (baliemedewerkers C.I.C ) writes:
>    Could somebody tell me where i can find RFC on an FTP site somewhere.
>
> Try nic.ddn.mil:rfc/* or ftp.uu.net:inet/rfc/*.

In Europe try ftp.eu.net in /documents/rfc/*.  These are all stored in
Unix compressed format (rfc1500.txt.Z, etc.)
--
James Harvey    IUPUI OIT Technical Support -- VMS/Unix/Networks
harvey@iupui.edu  uucp:iugate!harvey  bitnet:harvey@indyvax
Disclaimer: These are my opinions, not those of Indiana University.

-----------[000038][next][prev][last][first]----------------------------------------------------
Date:      Thu, 2 Dec 1993 09:16:04 GMT
From:      john@starfire.mn.org (John Lind)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject:   inexpensive Frame Relay/IP routing

We are looking for an inexpensive solution to the Frame Relay/IP
routing problem.  A Cisco 3000 has GOT to be overkill for what we
need.  We just need a few hundred packets per second routed (though
perhaps many more than that recognized as not routable).  I have
heard rumors of a Frame Relay board for Suns, and I am hoping that
such things exist for ISA machines, as well.  An example of the
ideal would be to use an AT-class machine with a 3C503 and a Frame
Relay card and just let it route to its hearts content, but there
may be problems inherent in that approach which are not evident to
me at this superficial level of understanding.

We are looking for the piece that fits between the CSU/DSU (or the
wall jack, if you can manage it!) and the 10base?? IP network.

All leads, tips, etc., are appreciated.

Go ahead and post a reply, but mail tends to get to me much sooner,
and I am really trying to decide if this thing will go or not.
Newsgroups: comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject: looking for inexpensive Frame Relay/IP routing
Distribution: world

We are looking for an inexpensive solution to the Frame Relay/IP
routing problem.  A Cisco 3000 has GOT to be overkill for what we
need.  We just need a few hundred packets per second routed (though
perhaps many more than that recognized as not routable).  I have
heard rumors of a Frame Relay board for Suns, and I am hoping that
such things exist for ISA machines, as well.  An example of the
ideal would be to use an AT-class machine with a 3C503 and a Frame
Relay card and just let it route to its hearts content, but there
may be problems inherent in that approach which are not evident to
me at this superficial level of understanding.

We are looking for the piece that fits between the CSU/DSU (or the
wall jack, if you can manage it!) and the 10base?? IP network.

All leads, tips, etc., are appreciated.

Go ahead and post a reply, but mail tends to get to me much sooner,
and I am really trying to decide if this thing will go or not.
-- 
		   John Lind, Starfire Consulting Services
E-mail: john@starfire.MN.ORG		USnail: PO Box 17247, Mpls MN  55417

-----------[000039][next][prev][last][first]----------------------------------------------------
Date:      Thu, 02 Dec 93 10:52:00 GMT
From:      marianne@kub.nl  (baliemedewerkers C.I.C )
To:        comp.protocols.tcp-ip
Subject:   RFC where ever you are

Hello everybody,
Could somebody tell me where i can find RFC on an FTP site somewhere.
I already tried nisca.acs.hoio-state.edu, but this address could not
be resolved by our router. It is possible that the connection can be 
established  using the doted-decimal address. 
Should i contact internet directly ?
thanks a lot,
C.Y.C. Bouhier
Tilburg university Netherlands
Email: CIC&kub.nl
    

-----------[000040][next][prev][last][first]----------------------------------------------------
Date:      Thu, 02 Dec 1993 12:41:17 +0000
From:      cr@cs.strath.ac.uk (Chris Reid)
To:        comp.protocols.tcp-ip
Subject:   Re: RFC where ever you are

In article <19931202115243.marianne@dp0120.kub.nl>, marianne@kub.nl 
(baliemedewerkers C.I.C ) wrote:

> Hello everybody,
> Could somebody tell me where i can find RFC on an FTP site somewhere.
> I already tried nisca.acs.hoio-state.edu, but this address could not
> be resolved by our router. It is possible that the connection can be 

No wonder, it's wrong. It should be "nisca.acs.ohio-state.edu".
Since you are in Europe, it's usually better to use a European site.
Try 'archie' to obtain a list of rfc sites. For example, do this:

>telnet archie.doc.ic.ac.uk

archie> login as 'archie'
archie> prog rfc

Archie will return a list of sites that archive rfc documents.

Hope this helps.


Chris

+-----------------------------------------------------------------+
|Chris Reid                            e-mail: cr@cs.strath.ac.uk |
|Dept. Computer Science, Strathclyde University, Glasgow, Scotland|
 +-----------------------------------------------------------------+

-----------[000041][next][prev][last][first]----------------------------------------------------
Date:      2 Dec 1993 11:26:54 +0100
From:      swe@diogenes.informatik.tu-chemnitz.de (Steffen Weber)
To:        comp.protocols.tcp-ip
Subject:   TIMEOUTS for TCP/IP


In 1989 the CSNET asked the ITF for higher timeout values for TCP/IP.
I want to implement a dial-up-IP set and need higher timeout values as
30 seconds. 
How can I set this value ?

-----------[000042][next][prev][last][first]----------------------------------------------------
Date:      Thu, 2 Dec 1993 13:07:40 GMT
From:      bob@MorningStar.Com (Bob Sutterfield)
To:        comp.protocols.tcp-ip
Subject:   Re: RFC where ever you are

In article <19931202115243.marianne@dp0120.kub.nl> marianne@kub.nl  (baliemedewerkers C.I.C ) writes:
   Could somebody tell me where i can find RFC on an FTP site somewhere.

Try nic.ddn.mil:rfc/* or ftp.uu.net:inet/rfc/*.
--
Bob Sutterfield, Morning Star Technologies            +1 614 451 1883
1760 Zollinger Rd, Columbus Ohio USA, 43221-2856      +1 800 558 7827
bob@MorningStar.Com                                   +1 614 459 5054 (FAX)

-----------[000043][next][prev][last][first]----------------------------------------------------
Date:      Thu, 2 Dec 1993 13:39:06 GMT
From:      boersma@research.ptt.nl
To:        comp.protocols.tcp-ip
Subject:   buffersize TCP/IP router

Does anyone knows the buffersize of a TCP/IP router?
And does it have only one buffer or serveral smaller ones?
I suppose there are a lot of different kind of routers but
what is the most common one?
Anyone with some information for me?
Please email to

R.Boersma@research.ptt.nl

Thanks 



-----------[000044][next][prev][last][first]----------------------------------------------------
Date:      2 Dec 1993 22:43:57 -0500
From:      amir@pipeline.com (Amir Rosenblatt)
To:        comp.protocols.tcp-ip
Subject:   Re: Connect MacTCP nework to Internet by modem?

In article <2dgqda$dup@quad.wfunet.wfu.edu>,

thomas kevi lynch <lynchtk@wfu.edu> wrote:
>
>I was wondering if there are any programs out there that will allow me to 
>connect a Mac network running MacTCP to a remote network over a 14.4 
>serial modem connection.  I realize this would be somewhat slow and 
>cumbersome, but it would enable some basic Internet interaction.  The 
>local network consists of a bunch Mac SEs, SE/30s, and Classics running 
>System 7.  The remote machine is a Sparc running SunOS 4.1.3.  I have
>been unable to get any SLIP ports to compile on either end, but I think 
>this is the right direction.  If anyone has any solutions, suggestions, 
>ideas, or comments, I'd appreciate them.  Thanks,
>							Tom
> 

Here at the Pipeline, we use a Xylogics Annex III to run SLIP itself. It 
sits between the modem pool and our Sun (Sparc10) and takes care of SLIP 
for us.  
 
On the Mac end, for starters, try the demo of TCP Connect II by 
Intercon.  It's available for anonymous ftp at intercon.com in the /sales 
directory.  You have to e-mail them for the password, which will be good 
for a month.  They also make InterSlip, which is free and I hear is very 
good.  While I haven't been abnle to get it working, several other people 
here have and are very impressed with it.  You could also try using PPP.

	-Amir
 	I really need a .sig



-----------[000045][next][prev][last][first]----------------------------------------------------
Date:      2 Dec 1993 15:19:20 GMT
From:      ric@updike.sri.com (Richard Steinberger)
To:        comp.protocols.iso,comp.protocols.tcp-ip
Subject:   Looking fo Sync controller for SUN


        Can anyone help with this: I have a QBUS-based VAX with an
intelligent communications controller board.  Basically its an ACP 5100
from ACC Systems.  It "connects to [a] single bit-oriented synchronous
communication line at clock rates up to 300 kbits/sec.  The V.35
interface [I think that means T1] runs at 56 kbits/sec."  It provides
HDLC support for the VAX.

        What I would like to find is a card for SUNs (SBUS, probably, or an
external SCSI-attached device) that would provide similar capabilities.  It
would connect to some external hardware that is attached to a leased
Telephone line.  And hopefully we could run TCP/IP applications (like
telnet) over the line.  I'm told we need the synchronous capability because
that's what the T line expects/provides and that's what's used at the other
end.  (I'm not a telecom expert, sorry).

        If you know of any product(s) that might be appropriate, please
drop me a note.  Thanks in advance to all who reply.

regards,

        ric steinberger
        software engineer
        SRI International
        333 Ravenswood Ave.
        Menlo Park, CA 94025

        ric@updike.sri.com

Please reply to ric@updike.sri.com



-----------[000046][next][prev][last][first]----------------------------------------------------
Date:      2 Dec 93 15:24:43 GMT
From:      mvm@cbnewsb.cb.att.com (michael.v.murphy)
To:        comp.protocols.tcp-ip
Subject:   UUCP over tcp-ip


     Our system currently uses UUCP over tcp-ip on SUN Sparcs for daily
transfers of files between systems. The aspects of store and forward, reliable
delivery, and polling are some of the reasons we chose UUCP. 
I was wondering if anyone has used UUCP over tcp-ip on HP755 workstations?
(running HP 9.0 OS). We are getting indications from reps that it is not
possible. Also, assuming that UUCP is not possible, is there any other package
that we could use that allows for reliable delivery (uucp will 'retry later'),
and remote polling (for security purposes). Is ftp currently the most secure
method for file transfer? (vs rcp, what about NFS?).

							Mike Murphy
							mvmurphy@attmail.att.com

-----------[000047][next][prev][last][first]----------------------------------------------------
Date:      2 Dec 93 16:41:24 GMT
From:      marks@mpd.tandem.com (Mark Smith)
To:        comp.protocols.tcp-ip
Subject:   255 sockets

We have a problem here. Seems we cannot use and close more than 255 socket
connections on our SVR4 OS. If we open fewer than 255  socket connections,
everything works fine. But, whenever an application opens more than 255 sockets, upon
completion a great  number of sockets are left in the CLOSE_WAIT or FIN_WAIT_* state.

I believe this is a known problem.   Any ideas?

Thanks in advance.
Mark Smith
marks@mpd.tandem.com
512 244 8197

-----------[000048][next][prev][last][first]----------------------------------------------------
Date:      2 Dec 93 18:29:36 GMT
From:      harmon@craycomm.casemo ( Bob Harmon ( Eng. ))
To:        comp.protocols.tcp-ip
Subject:   Re: ping: socket: permission denied


In article <Dec01.175735.72297@melupl> bill@melupl (Bill Fulton) writes:
   In article <CH3vG7.GLn@ewi.ch> wat@ewi.ch (Thomas Wacker) writes:
   >>Jim Burnes (jburnes@csisun.uucp) wrote:
   >>: I've never seen this error before.  I'm running SCO Unix with their
   >>: TCP/IP package.  Telnet and ftp seem to run fine, but 'ping', 'rlogin',
   >>: 'rcmd' (rsh) and rcp all respond with the same....
   >>: (program name): socket: permission denied
   >
   >At least on our Sparc 1 (SunOS 4.1) ping must run setuid root!
>>>> Same is true on AIX. I presume this is because a ping requires access to

I guess when one 'Presumes' one makes a 'Pres' out of you and me, thats Cool.

Actually, this is because ping and rlogin and rcmd, lpd, ..... etcerta all
require that a port bewteen 0 and 1024 be used, These ports can only
be allocated by root for security, thus all applications which bind to
these ports must be setuid root.  You can check /etc/services for a list.
Check out the parallel lpd thread in this group for info on rresvport, etc.

-----------[000049][next][prev][last][first]----------------------------------------------------
Date:      2 Dec 1993 20:37:45 GMT
From:      tli@cisco.com (Tony Li)
To:        comp.protocols.tcp-ip
Subject:   Re: buffersize TCP/IP router

In article <1993Dec2.153906.1@research.ptt.nl> boersma@research.ptt.nl writes:
    I suppose there are a lot of different kind of routers but
    what is the most common one?

cisco

    Does anyone knows the buffersize of a TCP/IP router?
    And does it have only one buffer or serveral smaller ones?

I don't understand the question.  What is the size of the largest buffer?
It's tuneable.  How many buffers are there?  It depends on the model.  How
much memory is used for buffering?  It depends on the model.

Tony

-----------[000050][next][prev][last][first]----------------------------------------------------
Date:      2 Dec 1993 22:58:48 GMT
From:      hunenr@cis.corp.medtronic.com (Roger Hunen)
To:        comp.protocols.tcp-ip,comp.security.unix
Subject:   Re: TCP source routing and setsockopt(SO_DONTROUTE)

In article <CHC7tC.5ow@news.Hawaii.Edu> newsham@wiliki.eng.hawaii.edu (Timothy Newsham) writes:
#In article <1993Nov30.190932.18574@jarvis.csri.toronto.edu> irving@sys.toronto.edu (Irving Reid) writes:
#>
#>If an incoming TCP connection uses source-routed packets, will the reply
#>packets for that connection follow the (reversed) source route?  If not,
#>my life is easier; I just have to make sure I don't trust a TCP stream
#>that doesn't work in both directions.
#
#There is no real "connection".  Return packets are routed normally
#I believe, which means that they would take the normal path, not a
#strange path taken by the packet they are responding to.  I dont believe
#the kernel does anything with the routing path in the IP packet
#it received (unless it needs to route it to the next hop).

From RFC 793 (the TCP spec):

=>  TCP/Lower-Level Interface
=>
=>    [some stuff deleted]
=>
=>    If the lower level is IP (or other protocol that provides this
=>    feature) and source routing is used, the interface must allow the
=>    route information to be communicated.  This is especially important
=>    so that the source and destination addresses used in the TCP
=>    checksum be the originating source and ultimate destination. It is
=>    also important to preserve the return route to answer connection
=>    requests.

I think this says it all.

Regards,
-Roger

-----------[000051][next][prev][last][first]----------------------------------------------------
Date:      3 Dec 1993 01:06:51 GMT
From:      mogul@pa.dec.com (Jeffrey Mogul)
To:        comp.protocols.tcp-ip
Subject:   Should Dest. Unreachable cause TCP connect() to fail?

ICMP Destination Unreachable messages can be generated by transient
fluctuations in the network topology, and do not necessarily mean that
the destination is permanently unreachable.  RFC1122, in section 4.2.3.9
("ICMP Messages"), says:

            o    Destination Unreachable -- codes 0, 1, 5

[Codes 0, 1, 5 are UNREACH_NET, UNREACH_HOST, UNREACH_SRCFAIL, respectively]

                 Since these Unreachable messages indicate soft error
                 conditions, TCP MUST NOT abort the connection, and it
                 SHOULD make the information available to the
                 application.

                 DISCUSSION:
                      TCP could report the soft error condition directly
                      to the application layer with an upcall to the
                      ERROR_REPORT routine, or it could merely note the
                      message and report it to the application only when
                      and if the TCP connection times out.

We are trying to figure out what exactly this means, and/or what is the
right thing to do, in the context of the BSD socket programming interface.

It is quite clear that these "soft" destination unreachable messages
should not abort an established connection.  The TCP model is that once
a connection is established, then (come hell or high water) it stays
established until one of the endpoint applications decides to shut it
down, or until some fatal error occurs (keepalives are errors, I guess).
Moreover, operational experience has shown to many of us that an
implementation (such as 4.2BSD) that violates this rule causes
applications to fail unnecessarily.

The harder question is: what should connect() do if a "soft" destination 
unreachable message arrives before the TCP connection is properly
established?  (In a perfect world, the TCP layer would report a
soft error, via an upcall, without causing the connect() system call
to fail.  But the semantics of connect() do not provide such a solution;
connect() either succeeds or fails, with no way to indicate soft errors.)

In implementations based on 4.2BSD, connect() fails immediately when a
"soft" destination unreachable message is received.  (In 4.3BSD,
apparently, connect() ignores these messages, while in 4.4BSD it waits
to receive a few of them before failing.)  Failing the connect() in this
case is often useful, because the failure may be due to a permanent
condition, such a firewall router, and the user could be told right
away.

On the other hand, it might be viewed as incorrect: first, by a
strict reading of RFC1122 ("anything not permitted is forbidden");
second, because it could cause connection attempts to fail
unnecessarily, due to transient reachability problems.  However,
note that while aborting an established connection leaves no way
for the application to recover (because buffered data may be lost),
the application can easily recover from a failed attempt to establish
a connection: it simply tries again.

There are thus three possible approaches:
	(1) connect() always ignores "soft" unreachable messages.
	(2) connect() fails immediately on "soft" unreachable messages.
	(3) connect() ignores the first N-1 "soft" unreachable messages,
		and fails on the Nth such message.

I am hoping that the collected wisdom of the net can answer two questions:
    (a) which options (perhaps all) are consistent with RFC1122?
    (b) which option makes the most sense from a programmer's/user's point of
	view?

Thanks
-Jeff

-----------[000052][next][prev][last][first]----------------------------------------------------
Date:      3 Dec 1993 11:16:46 -0500
From:      shuford@cs.utk.edu (Richard Shuford)
To:        vmsnet.pdp-11,comp.protocols.tcp-ip,comp.sys.dec
Subject:   Re: TCP/IP for RSX

In article <1993Dec1.123942.522@homer.mentec.ie> barry@homer.mentec.ie writes:
>
> Can somebody e-mail me the name and telephone number of any company
> who supplies TCP/IP to run under RSX11-M or RSX11-M Plus.

    Process Software
    959 Concord Street
    Framingham, Massachusetts 01701  USA
    IDDD voice:  +1 508/879-6994
    WATS voice:     800/722-7770
    IDDD fax:    +1 508/879-0042

    Internet:    sales@process.com

Process Software sells the "TCPware" TCP/IP implementation for VAX/VMS,
AXP/OpenVMS, and the PDP-11 operating systems RSX, RT-11, IAS, and TSX.

Be advised that the PDP-11 products are rather bare-bones:  they perform
Telnet and FTP sufficiently, but they do not do such handy things as
respond to ICMP messages (ping).  (TCPware for VMS, however, provides a
fuller set of functions, including SLIP.)

There also exists a network newsgroup to discuss the Process Software
products:  "vmsnet.networks.tcp-ip.tcpware".  News feeds of the VMSnet
groups are widely available.

-- 
 ...Richard S. Shuford  |"He who oppresses the poor to increase his wealth and
 ...shuford@cs.utk.edu  | he who gives gifts to the rich--both come to poverty."
 ...Info-Stratus contact| Proverbs 22:16  NIV

-----------[000053][next][prev][last][first]----------------------------------------------------
Date:      3 Dec 93 08:21:39 EST
From:      longm@firnvx.firn.edu
To:        comp.protocols.tcp-ip
Subject:   Serial Line Analyzer?

Does anyone know where I can locate a Serial Line Protocol Analyzer?

I am looking for one that can break down PPP and decode the packets.  I
currently have a Sniffer for Token Ring/Ethernet but would also like to have
one for Serial Lines.

Please reply by e-mail thanks mike....
-- 
# Michael Long                     ______    __     _____        ____    __
# Fla. Info. Resource Network     |  ____|  |  |   |   _  \     |    \  |  |
# Sr. Systems Programmer          |  |_     |  |   |  |_|  |    |  |\ \ |  |
# Tallahassee, Florida            |   _|    |  |   |   __ <     |  | \ \|  |
# Florida State University        |  |      |  |   |  |  \ \    |  |  \ \  |
# e-mail : longm@firnvx.firn.edu  |__|    O |__| O |__|  |__| O |__|   \___| O

-----------[000054][next][prev][last][first]----------------------------------------------------
Date:      3 Dec 93 10:21:08
From:      plm@yankee.iscp.bellcore.com (Paul Mowatt)
To:        comp.protocols.tcp-ip
Subject:   Re: Protocol definitions above tcp/ip


Here is some info that might help. RFC's describe all the TCP/IP
based protocols.

RFCs can be obtained via FTP from NIS.NSF.NET, NISC.JVNC.NET, 
VENERA.ISI.EDU, WUARCHIVE.WUSTL.EDU, SRC.DOC.IC.AC.UK,
FTP.CONCERT.NET, FTP.NISC.SRI.COM, or NIC.DDN.MIL.

Details on obtaining RFCs via FTP or EMAIL may be obtained by sending
an EMAIL message to "rfc-info@ISI.EDU" with the message body 
"help: ways_to_get_rfcs".  For example:

        To: rfc-info@ISI.EDU
        Subject: getting rfcs

        help: ways_to_get_rfcs

Requests for special distribution should be addressed to either the
author of the RFC in question, or to NIC@NIC.DDN.MIL.  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.

Requests to be added to or deleted from this RFC-DIST distribution
list should be sent to RFC-REQUEST@NIC.DDN.MIL.

--
    _/_/_/_/  _/       _/_/   _/_/ 	   V-Mail: (908) 699-6947
   _/    _/  _/       _/  _/_/ _/	   E-Mail: plm@yankee.iscp.bellcore.com
  _/_/_/_/  _/       _/   _/  _/	   U-Mail: Bellcore, RRC 4D-356
 _/        _/       _/       _/                    444 Hoes Lane, Piscataway
_/aul     _/_/_/_/ _/owatt  _/                     NJ 08854

-----------[000055][next][prev][last][first]----------------------------------------------------
Date:      2 Dec 1993 12:38:03 +1100
From:      markd@bushwire.apana.org.au (Mark Delany)
To:        comp.protocols.tcp-ip
Subject:   Re: lpr/lpd port?

In comp.protocols.tcp-ip you write:

>Could some kind soul shed some light on this...
 
>my "... \002" to begin a file transfer, I get "Improperly formed
>from address".
 
>When I "telnet IPADDRESS 515" to check permissions, I get the
>same nasty "Improperly formed from address".

This is a weak form of security checking. What lpd does is check that
the caller is using a port below 1024 (IPPORT_RESERVED).

Your lpr will have to bind to a port below this value, preferably by
using the rresvport() library call if you have it.


-- 
Mark Delany                                    markd@bushwire.apana.org.au

-----------[000056][next][prev][last][first]----------------------------------------------------
Date:      Fri, 3 Dec 1993 07:04:16 GMT
From:      vjs@calcite.rhyolite.com (Vernon Schryver)
To:        comp.protocols.tcp-ip
Subject:   Re: UUCP over tcp-ip

In article <CHEyt8.8Bs@cbfsb.cb.att.com> mvm@cbnewsb.cb.att.com (michael.v.murphy) writes:
>
>     Our system currently uses UUCP over tcp-ip on SUN Sparcs for daily
>transfers of files between systems. The aspects of store and forward, reliable
>delivery, and polling are some of the reasons we chose UUCP. 
>I was wondering if anyone has used UUCP over tcp-ip on HP755 workstations?
>(running HP 9.0 OS). We are getting indications from reps that it is not
>possible. Also, assuming that UUCP is not possible, is there any other package
>that we could use that allows for reliable delivery (uucp will 'retry later'),
>and remote polling (for security purposes). Is ftp currently the most secure
>method for file transfer? (vs rcp, what about NFS?).


Besides the obvious scripts, perl programs, and C one could write,
`rdist` is available on many BSD-related systems, presumably including
HP systems.  If not, `rdist` should be easy to port from the widely
available source.  


Vernon Schryver    vjs@rhyolite.com

-----------[000057][next][prev][last][first]----------------------------------------------------
Date:      Fri, 3 Dec 1993 08:42:58 GMT
From:      igb@fulcrum.co.uk (Ian G Batten)
To:        comp.protocols.tcp-ip
Subject:   Re: Should Dest. Unreachable cause TCP connect() to fail?

In article <2dm3fb$5fn@usenet.pa.dec.com>,
Jeffrey Mogul <mogul@pa.dec.com> wrote:
>     (b) which option makes the most sense from a programmer's/user's point of
> 	view?


You could punt the issue to the application writers and provide an
interface via setsockopt to allow them to choose their favoured policy.
For some situations, I would argue, you would be fairly keen to fail and
move on: opening connections to SMTP ports when you have more than one
MX record in your hand, for example.  In fact, any situation where you
have multiple IP numbers (ie multiple A records) available would
probably fall into this category.

If the application could set the policy, you could, for example, have
ftp or telnet whiz through the available IP numbers for the destination
failing on ICMP dest unreachable and then go through them again ignoring
or allowing a few ICMP dest unreachables.

It's cowardly, in a sense, to force this issue onto the application.
You also need a sensible means to yield a default behaviour.  Whenever
I've handled Ultrix equipment I've been mightily impressed by the work
that had gone into /etc/svc.conf: that'd be the place to set the
default, perhaps.

ian



-----------[000058][next][prev][last][first]----------------------------------------------------
Date:      3 Dec 1993 08:43:33 GMT
From:      lein@kom.sietec.de (Herr Lein)
To:        comp.protocols.tcp-ip
Subject:   ARP requests from other IP networks

What is the correct behaviour of a system, which
receives an ARP request, directed to its own IP address,
but the IP address of the requesting system is not
in the IP network of the receiving system.

A lot of systems do reply the ARP, some others do not.

Is there a well defined "right or wrong", or is it left
to the implementer?

Remark:
The problem came up, when we moved from a class C net to a class B net
and were running two IP networks on the same wire.

Frank

--
Frank Lein
Sietec Systemtechnik GmbH & Co. OHG
Nonnendammalle 101
D-13629 Berlin
phone +49-30-386-27971
e-mail: lein@kom.sietec.de

-----------[000059][next][prev][last][first]----------------------------------------------------
Date:      Fri, 3 Dec 1993 13:46:09 GMT
From:      Pavel A. Gudz <pav@be.ugm.vaz.togliatti.su>
To:        comp.protocols.tcp-ip
Subject:   Re: A Good TCP/IP Book

   I'm interested too. My email dima@be.ugm.vaz.togliatti.su
 Thanks

 Dima






-----------[000060][next][prev][last][first]----------------------------------------------------
Date:      3 Dec 1993 13:55:21 +0100
From:      urlichs@smurf.sub.org (Matthias Urlichs)
To:        comp.protocols.tcp-ip
Subject:   Re: Quote of the day protocol

In comp.protocols.tcp-ip, article <tim.shaw.104.2CE8DEF6@ndm.ox.ac.uk>,
  tim.shaw@ndm.ox.ac.uk (Tim Shaw) writes:
> Does anyone have any information about how to implement the quote of the day 
> protocol ?
> 
I assume that it just spits out a quote and closes the connection.

Rather easy to implement; just make inetd execute /usr/games/fortune. ;-)

-- 
Examine what is said, not him who speaks.
-- 
Matthias Urlichs        \ XLink-POP Nürnberg   | EMail: urlichs@smurf.sub.org
Schleiermacherstraße 12  \  Unix+Linux+Mac     | Phone: ...please use email.
90491 Nürnberg (Germany)  \   Consulting+Networking+Programming+etc'ing      42

-----------[000061][next][prev][last][first]----------------------------------------------------
Date:      Fri, 3 Dec 1993 16:26:13 GMT
From:      oproque@scosysv (Pedro Miguel M R Marques)
To:        comp.protocols.tcp-ip
Subject:   Re: DNS - what RRs must the server return?

Arnt Gulbrandsen (agulbra@nvg.unit.no) wrote:
: I've noticed that when I do a nameserver query, I get some extra
: info which the server thinks I might need, e.g. when I ask for a
: CNAME or MX I also get the corresponding A record(s).  Is this
: behaviour part of the DNS protocol (and widely implemented) or is it
: just that the name servers around here try to be helpful?
 
: To put it another way, when I want to resolve an MX record to IP
: numbers, do I need code to do an extra query in case the MX query
: doesn't return the A's in the AR field?
 
: --Arnt
hint: rfc 883 explains all the NS transactions.
I've read it not very carrefully, but I think that when you issue a
Resource query the nameserver must send you the A records in the
aditional information field.
--
###############################################################################
Pedro Roque Marques				Centro de Calculo
Email:						Faculdade de Ciencias
Internet: oproque@scosysv.cc.fc.ul.pt		Universidade de Lisboa
bitnet:	  oproque at ptearn
###############################################################################

-----------[000062][next][prev][last][first]----------------------------------------------------
Date:      Fri, 3 Dec 1993 16:31:43 GMT
From:      dbikle@rahul.net (Dan Bikle)
To:        comp.sys.pyramid,comp.periphs.printers,comp.protocols.tcp-ip
Subject:   Remote Printing story

Hi there,


I'd like to hear any suggestions for getting my Pyramid to talk to
an HP LaserJet 4si with an ethernet interface.

If I had a SunOS box the solution is trivial: call HP and buy a set
of SunOS executables (source code not available).

Since I'm in a hurry, I got a widget called the "Pocket Print Server"
from Extended Systems in Boise Idaho.

The idea is simple: plug the Pocket Print Server into the HP parallel
port.  Then plug an ethernet 10 base t rj-connector into the
Pocket Print Server 10 base t hole.

The Pocket Print Server then emulates a remote host on my ethernet.

So, I put it in my hosts file.

Then the instructions tell me to fire up either bootp or rarpd on
the real host which then answers the Pocket Print Server when
it asks, "Who am I?".

So far so good except my dc/osx machine has no bootp nor rarpd.

When I called Pyramid support the tech told me, "You find those
things on Sun Workstations not Pyramid."  

He did offer one slender ray of hope.  He says bootp and rarpd are
public domain.

Could he be right?  Would you have a copy?  If you have only the
.c files will it take me more than a week to port them to dc/osx?

-Dan
-----------------------------
Daniel B. Bikle
Independent Oracle Consultant
dbikle@alumni.caltech.edu
415/854-9542
P.O. BOX 'D'
MENLO PARK CA 94026
-----------------------------







-- 
Dan Bikle <dbikle@rahul.net>

-----------[000063][next][prev][last][first]----------------------------------------------------
Date:      Fri, 3 Dec 1993 16:42:43 GMT
From:      thayne@unislc.slc.unisys.com (Thayne Forbes)
To:        comp.protocols.tcp-ip
Subject:   Re: Should Dest. Unreachable cause TCP connect() to fail?

Jeffrey Mogul (mogul@pa.dec.com) wrote:
: ICMP Destination Unreachable messages can be generated by transient
: fluctuations in the network topology, and do not necessarily mean that
: the destination is permanently unreachable.  RFC1122, in section 4.2.3.9
: ("ICMP Messages"), says:
 
:             o    Destination Unreachable -- codes 0, 1, 5
 
:                  Since these Unreachable messages indicate soft error
:                  conditions, TCP MUST NOT abort the connection, and it
:                  SHOULD make the information available to the
:                  application.
 
:                  DISCUSSION:
:                       TCP could report the soft error condition directly
:                       to the application layer with an upcall to the
:                       ERROR_REPORT routine, or it could merely note the
:                       message and report it to the application only when
:                       and if the TCP connection times out.
 
: The harder question is: what should connect() do if a "soft" destination 
: unreachable message arrives before the TCP connection is established?  
 
: There are thus three possible approaches:
: 	(1) connect() always ignores "soft" unreachable messages.
: 	(2) connect() fails immediately on "soft" unreachable messages.
: 	(3) connect() ignores the first N-1 "soft" unreachable messages,
: 		and fails on the Nth such message.
 
: I am hoping that the collected wisdom of the net can answer two questions:
:     (a) which options (perhaps all) are consistent with RFC1122?
:     (b) which option makes the most sense from a programmer's/user's point of
: 	view?

Well, since you asked for 'opinions' here is mine.  It seems clear to me
that a strict compliance to the RFC is not possible (as you noted), so
it is up to the application to conform to the spirit of the RFC.  To this
end, I think that 

(2) connect() fails immediately on "soft" unreachable messages 

is the correct solution, with the application doing whatever
retry it thinks is appropriate.  Obviously an application like telnet
would benefit from a few retrys (inasmuch as many outages are on the 
order of a few hundred milliseconds), but many applications cannot 
tolerate any outage, for instace time or daytime.

-- 
Thayne Forbes         thayne@unislc.slc.unisys.com
Unisys Unix Support Engineering,    Salt Lake City.
Phone: (801) 594-4448          Fax: (801) 594-3827

-----------[000064][next][prev][last][first]----------------------------------------------------
Date:      Fri, 3 Dec 1993 19:31:12 GMT
From:      klos@mv.mv.com (Patrick Klos)
To:        comp.protocols.tcp-ip
Subject:   Re: Serial Line Analyzer?

In article <1993Dec3.082139.1@firnvx.firn.edu>,  <longm@firnvx.firn.edu> wrote:
>Does anyone know where I can locate a Serial Line Protocol Analyzer?
>
>I am looking for one that can break down PPP and decode the packets.  I
>currently have a Sniffer for Token Ring/Ethernet but would also like to have
>one for Serial Lines.
>
>Please reply by e-mail thanks mike....
>-- 
># Michael Long                     ______    __     _____        ____    __
># Fla. Info. Resource Network     |  ____|  |  |   |   _  \     |    \  |  |
># Sr. Systems Programmer          |  |_     |  |   |  |_|  |    |  |\ \ |  |
># Tallahassee, Florida            |   _|    |  |   |   __ <     |  | \ \|  |
># Florida State University        |  |      |  |   |  |  \ \    |  |  \ \  |
># e-mail : longm@firnvx.firn.edu  |__|    O |__| O |__|  |__| O |__|   \___| O

We (Klos Technologies, Inc.) are about to release a product called SerialView
that will do exactly what you're looking for.  It will cost $399, and currently
uses COM1 and COM2 of a DOS-based PC to capture the frames.  It then decodes
the frames, recognizing several standard formats including LCP, IPCP, IPXCP,
PAP, TCP/UDP/IP, SNMP, and IPX/SPX/NCP.  And what SerialView can't decode, you
can easily write your own decoder for.  SerialView also has capture and display
filters, as well as symbolic support for node addresses, IP addresses and SNMP
object IDs.

If you're interested, send me email or call me at (603) 424-8300 so I can tell
you exactly what's up and when it will be available.  (anyone else who might
be interested is welcom to call as well)

Sincerely,

Patrick Klos
-- 
============================================================================
    Patrick Klos                           Internet: klos@mv.mv.com
    Klos Technologies, Inc.                Voice: (603) 424-8300
    604 Daniel Webster Highway             FAX:   (603) 424-9300
    Merrimack, New Hampshire  03054        BBS:   (603) 429-0032
============================================================================

-----------[000065][next][prev][last][first]----------------------------------------------------
Date:      Fri, 3 Dec 1993 19:31:20 GMT
From:      mark@alias.com (Mark Andrews)
To:        comp.protocols.tcp-ip
Subject:   Re: What's the difference between IPPROTO_IP & IPPROTO_TCP for stream sockets?

In <2CFCB0B6.13609@news.service.uci.edu> lvandyke@balboa.eng.uci.edu (Lee Van Dyke) writes:



>Can anyone tell me what the difference is between:
>#define IPPROTO_IP              0               /* dummy for IP */
>#define IPPROTO_TCP             6               /* tcp */
 
>The Unix Network Programming book only says that 0 is the typical value
>used as the protocol argument for the socket system call. Does this
>mean a reliable connection is established and data will be rebroadcast
>if not received?


>Thanks in advance,


>--
>Lee Van Dyke
>      lvandyke@balboa.eng.uci.edu,
>UUCP: infotec!Infotec.COM!lee@sunkist.West.Sun.COM

When making socket create calls:

    socket(domain, type, protocol number)

if the protocol number is 0 (i.e.: IPPROTO_IP), it means "use the default
protocol for that type of socket in that domain". In the case of a steam
type socket in the AF_INET domain, the protocol corresponds to IPPROTO_TCP
(tcp) which will retransmit (you can only broadcast on SOCK_DGRAM or udp
sockets) any data that the recipient of the data does not receive.

-----------[000066][next][prev][last][first]----------------------------------------------------
Date:      Fri, 3 Dec 1993 19:33:39 GMT
From:      cooker@ci.ua.pt (Fernando Cozinheiro)
To:        comp.protocols.tcp-ip
Subject:   Domain Name Servers

I have heard some references abou two different Name Servers: Domain Name
Servers and IEN-116. We have an old terminal server that includes on its
specifications the support of the Domain Name Service... But I don't know
which name service.

Now I'm asking you about the following:
1. What are the differences of both?

2. How can I implement one Name Server, using IEN-116 standard? (I suppose
   that IEN-116 isn't the same as Domain Name Service. I have running one
   Domain Name Service.

Thanks in advance.
Cheers.

--
Fernando Cozinheiro

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Universidade de Aveiro        Phone: +351 34 25085 * Ext. 2254 (before 6 p.m.)
Centro de Informatica                +351 34 381265 (after 6 p.m.)
3800 Aveiro                   Fax:   +351 34 28600
Portugal                      Email: cooker@ci.ua.pt


-----------[000067][next][prev][last][first]----------------------------------------------------
Date:      3 Dec 1993 21:07:02 GMT
From:      Enrico Talin <etalin1@ithaca.edu>
To:        comp.protocols.tcp-ip
Subject:   Wanted: ISDN card for the Mac

Hi there,
I am desperately looking for an adress or a telephone number of a
manufacturer, retailer of ISDN NuBus Cards for the mac.
Please mail me any information you might have.

Thank you in advance for your help,

Enrico

E-mail: etalin1@ithaca.edu

tel 607-256-4890

-----------[000068][next][prev][last][first]----------------------------------------------------
Date:      Fri, 3 Dec 1993 21:19:32 GMT
From:      rmiller@netcom.com (Robert Miller)
To:        comp.protocols.tcp-ip,comp.protocols.appletalk
Subject:   Sockets type interface for MacTCP?

Does anyone know if MacTCP supports any Berkley or Windows type sockets
interface? Or any other TCP programmers interface.

I am looking for any tech info on MacTCP on this subject, also any sample
code.

You can contact me by e-mail rmiller@netcom.com

Thanks
Rob.



-----------[000069][next][prev][last][first]----------------------------------------------------
Date:      3 Dec 1993 21:23:59 GMT
From:      peter.gregory@mccaw.com (Peter Gregory)
To:        comp.protocols.tcp-ip
Subject:   Re: Socket address reuse

In article 16316@nz.dialogic.com, manningc@nz.dialogic.com (Charles Manning) writes:
>
>I see that the TCP/IP sockets model allows for socket address reuse by
>specifying the SO_REUSEADDR socket option.
>
>The documentation I have does not really specify how much this buys. Asd
>I understand things, this should allow more than one process to bind the
>address to a socket.
>
>so_val = 1;
>error = setsockopt(socket_fd,SOL_SOCKET,&so_val,sizeof(so_val);
>
>I have tried putting this code in before and after the bind.
>
>The call succeeds, but the second bind attempt always fails.

While I don't know the entire context of your situation, I can say that while
you can open another socket on the same port, one can only do so if the entire
5-tuple socket description is unique.

See "UNIX Network Programming" (Stevens, Prentice-Hall), pg. 211.

--

Pete Gregory   peter.gregory@mccaw.com      |  "It may be rice wine to you,
Senior Consultant. ASIX, Inc., Seattle, WA  |  but it's sake to me."
on-site at Wireless Data Division, McCaw Cellular Communications, Kirkland, WA


-----------[000070][next][prev][last][first]----------------------------------------------------
Date:      3 DEC 93 23:45:01 GMT
From:      mrl@pfc.mit.edu (Mark London)
To:        comp.protocols.tcp-ip
Subject:   Filtering BOOTP requests?

We have a bridge connecting our network to another one, and we would like to
set it up to filter BOOTP requests.  Is this possible?  Does anyone know the
multicast address, if there is one?  Thanks.

Mark London
MRL@PFC.MIT.EDU

-----------[000071][next][prev][last][first]----------------------------------------------------
Date:      Sat, 4 Dec 1993 01:33:29 GMT
From:      jonathan@CS.Stanford.EDU (Jonathan Stone)
To:        comp.protocols.tcp-ip
Subject:   Re: New version of traceroute anywhere?

I prefer the version containing the comment:

 *
 * I've hacked up a round-trip-route version of this that works by
 * sending a loose-source-routed udp datagram through the destination
 * back to yourself.  Unfortunately, SO many gateways botch source
 * routing, the thing is almost worthless.  Maybe one day...
 *
 *  -- Van Jacobson (van@helios.ee.lbl.gov)
 *     Tue Dec 20 03:50:13 PST 1988
 *

Two years later, LSRR was much more widely available; perhaps
partly due to its being used to encapsulate IP multicast traffic.
In any case, the `newer' traceroute is available from ftp.ee.lbl.gov:
    ftp> dir trace*
    200 PORT command successful.
    150 Opening ASCII mode data connection for /bin/ls.
    -rw-r--r--  1 van      staff       22567 Apr  3  1990 traceroute.tar.Z
    226 Transfer complete.

Use archie to find a copy of traceroute.tar.Z with the same
size nearest you.

-----------[000072][next][prev][last][first]----------------------------------------------------
Date:      Sat, 4 Dec 93 01:59:05 GMT
From:      manningc@nz.dialogic.com (Charles Manning)
To:        comp.protocols.tcp-ip
Subject:   Socket address reuse

A plea for help...

I see that the TCP/IP sockets model allows for socket address reuse by
specifying the SO_REUSEADDR socket option.

The documentation I have does not really specify how much this buys. Asd
I understand things, this should allow more than one process to bind the
address to a socket.

I have tried this thus:


so_val = 1;
error = setsockopt(socket_fd,SOL_SOCKET,&so_val,sizeof(so_val);

I have tried putting this code in before and after the bind.

The call succeeds, but the second bind attempt always fails.

This is running under SCO Unix if this makes a difference.

Thanx

Charles



-- 
--------------------------------------------------------------------------
Charles Manning         Internet: manningc@nz.dialogic.com
Dialogic (New Zealand)  Phone:    (+64) 9 3021831  Fax: (+64) 9 3021793
---------------  When all else fails, find a scapegoat -------------------

-----------[000073][next][prev][last][first]----------------------------------------------------
Date:      4 Dec 1993 07:05:56 GMT
From:      pustule@cats.ucsc.edu (Thaddeus H. Wood)
To:        comp.protocols.tcp-ip
Subject:   Crazy-whack telnet question!


Greetings.  I would like to be able to communicate to a machine's
telnet port 23, but without having to deal with the IAC characters
or negotiation.  Is there a way to tell the remote telnet program
to just speak to me in plain old text mode?  In effect, I would 
like to bypass all of the extraneous features in telnet, and just
talk to the port.

Any info would be appreciated.  And if clarifacations are needed,
please do not hesitate to e-mail.

Thanks much.

-- 
 Thaddeus H. Wood  715 Washington St. Suite D  Santa Cruz, CA  95060
  pustule@cats.ucsc.edu -- +1 408.423.8733 -- pustule@gorn.echo.com
             "At the prompt, please type 'kill -HUP $$'"

-----------[000074][next][prev][last][first]----------------------------------------------------
Date:      4 Dec 93 15:53:14
From:      drw@runge.mit.edu (Dale R. Worley)
To:        comp.protocols.tcp-ip
Subject:   Re: DNS - what RRs must the server return?

   : To put it another way, when I want to resolve an MX record to IP
   : numbers, do I need code to do an extra query in case the MX query
   : doesn't return the A's in the AR field?

The usual advice is to be strictly conforming in what one generates,
but liberal in accepting what other generate.  In this case, code to
do the extra query in case the server doesn't remember to give you the
A records.

Dale

Dale Worley		Dept. of Math., MIT		drw@math.mit.edu
--
Sometimes you're the windshield.
Sometimes you're the bug.
-- Dire Straits

-----------[000075][next][prev][last][first]----------------------------------------------------
Date:      4 Dec 93 15:57:08
From:      drw@runge.mit.edu (Dale R. Worley)
To:        comp.protocols.tcp-ip
Subject:   Dark fiber

Does anyone know of an Internet service provider who is renting dark
optical fibers and doing their own interfacing on the ends?  It seems
like this is an ideal way to get bandwidth -- as you need more
bandwidth, the bandwidth of the interface electronics can be upgraded,
with no further money going to the telcos.

Dale

Dale Worley		Dept. of Math., MIT		drw@math.mit.edu
--
Britannus (shocked):  Caesar, this is not proper.
Theodotus (outraged):  How?
Caesar (recovering his self-possession):  Pardon him, Theodotus; he is
     a barbarian, and thinks that the customs of his tribe and island
     are the laws of nature.
-- "Caesar and Cleopatra", act II, by George Bernard Shaw

-----------[000076][next][prev][last][first]----------------------------------------------------
Date:      5 Dec 1993 02:51:56 -0800
From:      skl@Connectivity.com (Samuel Lam)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject:   Re: inexpensive Frame Relay/IP routing

In article <1993Dec2.091604.1133@starfire.mn.org>, john@starfire.mn.org
 (John Lind) wrote:
>We are looking for an inexpensive solution to the Frame Relay/IP
>routing problem.

Both Livingston <info@livingston.com> and Morning Star
<info@morningstar.com> have frame relay access routers
listed in the low-$2000 range.

...Sam
-- 
<skl@Connectivity.com> -- Connectivity Technology Inc.

"NetNews on CD's" product information: <NewsCD@CDPublishing.com>
			   or {ftp,gopher,www}.CDPublishing.com


-----------[000077][next][prev][last][first]----------------------------------------------------
Date:      5 Dec 1993 01:37:49 -0600
From:      roberts@decus.arc.ab.ca (Rob Slade, Ed. DECrypt & ComNet, VARUG rep, 604-984-4067)
To:        comp.protocols.tcp-ip
Subject:   "Open Systems Networking" by Piscitello/Chapin

BKOPSYNT.RVW  931013
 
Addison-Wesley Publishing Co.
P.O. Box 520
26 Prince Andrew Place
Don Mills, Ontario
M3C 2T8
416-447-5101
fax: 416-443-0948
or
Tiffany Moore, Publicity  72203.642@compuserve.com
John Wait, Editor, Corporate and Professional Publishing johnw@aw.com
1 Jacob Way
Reading, MA   01867-9984
800-527-5210
617-944-3700
5851 Guion Road
Indianapolis, IN   46254
800-447-2226
"Open Systems Networking", Piscitello/Chapin, 1993
lyman@bbn.com dave@mail.bellcore.com
 
Open systems and networking are two of the current "big issues" in computing
and information systems planning, even if few can tell you what they actually
are.  Every proprietary system is "open," and every company making even the
most peripheral component is committed to "networking".  OSI and TCP/IP are
recognizably two of the major "players' in this game, although their positions
may not be clear.  This state of affairs is not made any better by the many
rumours and myths:  TCP/IP is an academic toy; TCP/IP is an *example* of OSI;
buying OSI compliant products will guarantee inter-operability; TCP/IP now has
the commercial "high ground" and it is now *OSI* that is the academic toy. 
This book is both a conceptual introduction to open systems networking, and a
detailed comparison of the structures of TCP/IP and OSI.
 
That said, it is still easier, as with Usenet, to define what it is not, than
what it is.
 
This is not a technical manual.  Technical detail there is, and competent, too. 
This is not, however, a reprinting of the standards, although it is a good
guide to and through them.   While the work gives a good background for
programming and implementation, one suspects it is more for the manager than
the programmer.
 
When one is examining technical books, the mere sight of a "series" cover sets
off alarms.  Series books tend to be textbooks, or boring, or both.  This book
is not boring.  The writing style is lively, with the best (or most outrageous)
parts set off by ".AHA." boxes and italic text.  The anecdotes and background
will be of interest to anyone in the communications or networking field.
 
The preface is decidedly odd, and chapter one seems to be the preface.  Chapter
two is a quick overview of both the OSI and Internet structures.  Part two,
chapters three to five, is entitled, "Open Network Architecture":  it covers
the concepts and vocabulary of open systems, and compares the terms of the two
structures.  Part three deals with the way the "upper layers" and common
applications are handled, while part four covers the lower layers.  Finally,
part five makes, in a number of different ways, the point that the choice does
not have to be TCP/IP or OSI--the two systems can be complementary.
 
The references section contains many valuable listings.  An annotated
bibliography would have been helpful.  In a sense there is one--distributed
throughout the book.  It would have been handy to have collected some of this
into a single section.
 
This work provides a unique perspective, and some very important information. 
It belongs on every MIS shelf.  It also belongs in every college and university
library where any type of data communications and networking courses are
taught.  It should also come in very handy for every development project where
there is a question as to why TCP is being used rather than OSI ... or vice
versa ...
 
copyright Robert M. Slade, 1993   BKOPSYNT.RVW  931013
Permission granted to distribute with unedited copies of the Digest
======================
DECUS Canada Communications, Desktop, Education and Security group newsletters
Editor and/or reviewer ROBERTS@decus.ca, RSlade@sfu.ca, Rob Slade at 1:153/733
DECUS Symposium '94, Vancouver, BC, Mar 1-3, 1994, contact: rulag@decus.ca

-----------[000078][next][prev][last][first]----------------------------------------------------
Date:      Sat, 4 Dec 1993 18:32:22 +0000
From:      james@azrael.demon.co.uk (James R Grinter)
To:        comp.protocols.tcp-ip
Subject:   Re: New version of traceroute anywhere?

In article <1993Dec4.013329.29557@CSD-NewsHost.Stanford.EDU>
           jonathan@CS.Stanford.EDU "Jonathan Stone" writes:
>Two years later, LSRR was much more widely available; perhaps
>partly due to its being used to encapsulate IP multicast traffic.

Unfortunately LSRR is often blocked through routers.  Is there _really_
a valid security reason for this, or is it just paranoia? Can anyone
explain?

-- 
James R Grinter.
'If it ain't broke, don't fix it'.

-----------[000079][next][prev][last][first]----------------------------------------------------
Date:      4 Dec 1993 19:58:05 GMT
From:      jbrady@deepriver.East.Sun.COM (John Brady - SunNetworks Consultant)
To:        comp.protocols.tcp-ip
Subject:   REPOST: IP Mobility WG chair?

Hmmm... surprising silence from my first post of this question.


Who is the chair of the IP Mobility Working Group?


-- John Brady

-----------[000080][next][prev][last][first]----------------------------------------------------
Date:      Sat, 4 Dec 1993 20:34:02 GMT
From:      cricket@hpuecoz.nsr.hp.com (Cricket Liu)
To:        comp.protocols.tcp-ip
Subject:   Re: New version of traceroute anywhere?

Randy Diffenderfer (rdiffe01@cad.gmeds.com) wrote:

: Is there a new version of traceroute out there anywhere?  The "canonical" 
: version that I'm aware of is the one at ftp.uu.net, dated Jan 30, 1990 at 
: path /networking/ip/trace/traceroute_pkg.tar.Z.
 
: This one seems a bit dated, in that it seems to understand Suns only, and 
: old ones at that! :-)
 
: So, the question is, is there a more "modern" version out there good for
: Sun Solaris 2.x, HP HP-UX 9.x, IBM AIX 3.2.x, and DEC Ultrix 4.x?

For an HP-UX version, ftp to ftp.nikhef.nl.  Or try one of the HP-UX
archives, like ftp.cae.wisc.edu.

--
cricket

cricket@hp.com / Hewlett-Packard Professional Services / Englewood, CO

-----------[000081][next][prev][last][first]----------------------------------------------------
Date:      5 Dec 1993 00:38:20 GMT
From:      tli@cisco.com (Tony Li)
To:        comp.protocols.tcp-ip
Subject:   Re: New version of traceroute anywhere?

In article <755029942snz@azrael.demon.co.uk> james@azrael.demon.co.uk writes:
    Unfortunately LSRR is often blocked through routers.  Is there _really_
    a valid security reason for this, or is it just paranoia? Can anyone
    explain?
    
Yes, there's a valid security reason for doing this.

Tony


-----------[000082][next][prev][last][first]----------------------------------------------------
Date:      5 Dec 1993 00:39:03 GMT
From:      tli@cisco.com (Tony Li)
To:        comp.protocols.tcp-ip
Subject:   Re: REPOST: IP Mobility WG chair?

In article <2dqq4d$jr2@sixgun.East.Sun.COM> jbrady@deepriver.East.Sun.COM
writes: 
    
    Who is the chair of the IP Mobility Working Group?
    
Steve Deering and Greg Minshall.

Tony


-----------[000083][next][prev][last][first]----------------------------------------------------
Date:      Sun, 5 Dec 1993 03:13:09 GMT
From:      sfrazier@bikini.fmrco.com (Scott Frazier)
To:        comp.protocols.tcp-ip
Subject:   X11 and TCP/IP



Hi,

	I'm trying to configure two Combinet ISDN Ethernet LAN bridges
such that I can use them to effectively bridge a remote Sparcstation LX
to an Ethernet.  I setup the bridges and everything seems to be working
fine with the possible exception of bizarre X behavior.  When I start an
X client and try and set the display back to my remote workstation over
the ISDN line, the window comes up but keyboard events within the window
are ignored.  X programs that want to draw to the display succeed with no
problems 

	I placed a sniffer on the local net and I can see the X packets
coming over from the LX.  Unfortunately, there is no convenient way to
run the sniffer on the remote end, even though it's in my lab.
Can anyone suggest a possible reason for this lossage?  

								-S.



--
Scott Frazier				I-Kinetics, Inc.
Systems Engineer			19 Bishop Allen Drive
(617) 661-8181 x252			Cambridge, MA. 02139
(617) 570-4587				sfrazier@i-kinetics.com

-----------[000084][next][prev][last][first]----------------------------------------------------
Date:      5 Dec 93 14:23:17 GMT
From:      sherwood@ac.dal.ca
To:        comp.protocols.tcp-ip
Subject:   PCRoute won't recognize ATALK driver

I am trying to configure PCRoute with one SLIP and one AppleTalk interface,
but I can't get PCRoute to recognize the ATALK driver. Could someone that
has made this work let me in on the secret, please?

Thanks
John Sherwood
Dalhousie University
Halifax, Nova Scotia
John.Sherwood@Dal.Ca

-----------[000085][next][prev][last][first]----------------------------------------------------
Date:      5 Dec 1993 14:38:18 GMT
From:      jf1@stirling.ac.uk (Mr Jonathon Fletcher)
To:        comp.protocols.tcp-ip
Subject:   gethostbyname

I am trying to write a piece of code that will open connections to
multiple sites, but only one at a time. I'm using an HP7xx (08.07)
The problem is that after I've opened and closed (roughly) 54 
connections, gethostbyname returns me a ECONNREFUSED (Connection
refused) error. It's likely to be something very obvious, as I'm 
a real novice in this area. Do anyone have any ideas tht could
help ?

Please email !

Thanks,

-Jon

--
  Jonathon Fletcher, Information Services, Stirling University.
  jf1@stirling.ac.uk (X400: "/S=jf1/O=stirling/PRMD=uk.ac/C=gb/")


-----------[000086][next][prev][last][first]----------------------------------------------------
Date:      5 Dec 1993 16:15:06 GMT
From:      trier@odin.ins.cwru.edu (Stephen C. Trier)
To:        comp.protocols.tcp-ip
Subject:   Re: The connect-connect syndrome - A bug or feature?

In article <id.VCU41.09G@nmti.com>, jaleel ihsan <ihsan@nmti.com> wrote:
>I have a requirement[...] to have a communication protocol between two
>system in which the two sides have a "peer-to-peer" relationship,
>that's right "peer-to-peer" not "client-server".

You can do this anyway by having both sides listen on a well-known port
but connect from a random port.  Unless I'm missing something, this
will provide equivalent or superior results.  Is there something that
makes connect-connect superior in your application?

How does your application deal with the 4-minute TIME-WAIT delay after
the connection closes?

(Now, I'm not being critical -- I'm curious.  This is the first I've
heard of an application that actually has a use for the feature!)

        Stephen

-- 
Stephen Trier  KB8PWA       "The light at the end of the tunnel
Work: trier@ins.cwru.edu     may be an oncoming dragon"
Home: sct@po.cwru.edu                          - Unknown

-----------[000087][next][prev][last][first]----------------------------------------------------
Date:      Sun, 5 Dec 1993 16:17:26 GMT
From:      greulich@math-stat.unibe.ch (Andreas Greulich)
To:        comp.protocols.tcp-ip,comp.security.unix
Subject:   Re: TCP source routing and setsockopt(SO_DONTROUTE)

Timothy Newsham (newsham@wiliki.eng.hawaii.edu) wrote:
: As far as not trusting a TCP stream that doesn't work in both directions,
: this one is really easy.  The handshaking that goes on to set up a
: TCP "connection" pretty much insures that there is a two way connection.
: The only way to set up a TCP connection with only 1 direction of data
: flow is to guess at the sequence number of the remote host,  such an
: attack is outlined in S. Bellovin's paper on the security of TCP/IP.

I don't know that paper, but I found that guessing the sequence number
isn't difficult because most (actually any I'm aware of) tcp
implementations don't choose them by random, but use a global variable
that's incremented for every connection and in certain time intervals.
I think bsd increments by 128 (not sure anymore). To guess it, the
attacker just has to send a few "regular" packets (with real IP
source address) and watch how the sequence number increments. He has
a good probability to guess the next sequence number then. No guarantee
of course, as packets don't always need the same time to run through
the network, but still a good chance (the process can be iterated after
all). In my experiments I could always guess it right. The only problem
that made this form of attack unusable was the fact that the ACK (that
doesn't reach the attacker) reaches the host (that the attacker pretends
to be), and this machine - if online - sends back a reset packet which
interrupts the connection at the attacked machine - hopefully before
the rsh (or whatever) command was already received and executed. Of
course this only prevents the attack if this trusted host is online
at the time of attack, near enough to the target machine so the
time delay isn't too big, and not overloaded (so it can reply in time).
So, I would recommend an additional handshaking that includes
exchange of RANDOM numbers between teh machines that have to be
acknowledged in a 2-way style. Of course thsoe will only be pseudo
random, but still hard enough to guess I imagine.

By the way, in another experiment I made a strange observation, that
probably has to do with the bugged BSD 4.3 implementation (?). I tried
what happened if machine A sends connection packets to machine B (and
in this case pretends to be machine C), and to machine C (where it pretends
to be machine B), in both cases using appropriate "guessed" sequence
and port numbers. I wanted to see if those two machines (B and C)
can be connected together initiated by a machine A. What happened was
that machines B and C swapped SYN packets (I think those were SYN packets)
indefinitely. I couldn't interrupt it and I imagine it quite overloaded
the local ethernet (at least the LEDs on the multiport was stedily on).
As the connections weren't 'established', they didn't even appear in
the output of the netstat command (I tried it on suns running sunos 4.1.1).
I could only stop it by rebooting one of the two machines. I didn't
make further experiments because it seemed to be a bit too risky. I
don't know what would happen if machines B and C were very distant (they
were machines of the same cluster in my experiment), the time delay
would probably prevent a network crash. But I could imagine that
a malignent worm-like program could in this way cross-connect
arbitrary hosts on the internet in an iterated way and so slowly but
surely bring down the whole internet. As the IP address of machine A
appears nowhere in the packets, it couldn't be traced back. At least
not easily. Any thoughts about that?

A. Greulich (greulich@math-stat.unibe.ch)




-----------[000088][next][prev][last][first]----------------------------------------------------
Date:      5 Dec 1993 16:21:01 GMT
From:      trier@odin.ins.cwru.edu (Stephen C. Trier)
To:        comp.protocols.tcp-ip
Subject:   Re: Crazy-whack telnet question!

In article <2dpcsk$q9q@darkstar.ucsc.edu>,
Thaddeus H. Wood <pustule@cats.ucsc.edu> wrote:
>Greetings.  I would like to be able to communicate to a machine's
>telnet port 23, but without having to deal with the IAC characters
>or negotiation.  Is there a way to tell the remote telnet program
>to just speak to me in plain old text mode?

Nope.  If the machine is speaking telnet protocol, you need to speak
telnet protocol back.  There is no way around it.

It's not too hard to implement the minimum telnet protocol: Refuse
every option the remote tries to negotiate.  That is perfectly legal.

	Stephen

-- 
Stephen Trier  KB8PWA       "The light at the end of the tunnel
Work: trier@ins.cwru.edu     may be an oncoming dragon"
Home: sct@po.cwru.edu                          - Unknown

-----------[000089][next][prev][last][first]----------------------------------------------------
Date:      Sun, 5 Dec 1993 21:18:58 GMT
From:      newsham@wiliki.eng.hawaii.edu (Timothy Newsham)
To:        comp.protocols.tcp-ip,comp.security.unix
Subject:   Re: TCP source routing and setsockopt(SO_DONTROUTE)

In article <1993Dec5.161726.24116@aragorn.unibe.ch> greulich@math-stat.unibe.ch (Andreas Greulich) writes:
>
>I don't know that paper, but I found that guessing the sequence number
>isn't difficult because most (actually any I'm aware of) tcp
>implementations don't choose them by random, but use a global variable
>that's incremented for every connection and in certain time intervals.
>I think bsd increments by 128 (not sure anymore). To guess it, the
>attacker just has to send a few "regular" packets (with real IP
>source address) and watch how the sequence number increments. He has
>a good probability to guess the next sequence number then. No guarantee
>of course, as packets don't always need the same time to run through
>the network, but still a good chance (the process can be iterated after
>all). In my experiments I could always guess it right. The only problem

right,  this is covered in the paper.

>that made this form of attack unusable was the fact that the ACK (that
>doesn't reach the attacker) reaches the host (that the attacker pretends
>to be), and this machine - if online - sends back a reset packet which
>interrupts the connection at the attacked machine - hopefully before
>the rsh (or whatever) command was already received and executed. Of
>course this only prevents the attack if this trusted host is online
>at the time of attack, near enough to the target machine so the
>time delay isn't too big, and not overloaded (so it can reply in time).

I think Rob T. Morris (whose paper S.Bellovin's was based on) proposed
to flood the machine that you are spoofing in order to make it react
slowly or even drop the ACK packet it receives so that it doesnt reply
quickly with a RST.

Also you can combine some of the packets so that you send out only
two packets.  Since you dont get an ACK you send them almost right
after each other and hope they reach the remote in order and before 
the RST.

     SYN  -> remote
                      ( <- ACK + SYN, we never see it )
 (other host sends RES -> )
      ACK + DATA -> remote

if the ACK+DATA has the correct sequence number and the RES doesnt
reach the remote first, then the connection is established and the
data from the first packet has been sent to the machine listening
on the socket.  The data would probably be a packet to rsh to send
+ + to .rhosts or put something in a .forward or something of that
nature.


>By the way, in another experiment I made a strange observation, that
>probably has to do with the bugged BSD 4.3 implementation (?). I tried
>what happened if machine A sends connection packets to machine B (and
>in this case pretends to be machine C), and to machine C (where it pretends
>to be machine B), in both cases using appropriate "guessed" sequence
>and port numbers. I wanted to see if those two machines (B and C)
>can be connected together initiated by a machine A. What happened was
>that machines B and C swapped SYN packets (I think those were SYN packets)
>indefinitely. I couldn't interrupt it and I imagine it quite overloaded
>the local ethernet (at least the LEDs on the multiport was stedily on).

I've heard of something similar happening involving a storm of ACKs or
SYNs but dont remember the details.  Interesting.

>I could only stop it by rebooting one of the two machines. I didn't
>make further experiments because it seemed to be a bit too risky. I

maybe a program that listens for a storm of this nature (in promiscuous
mode) and sends out a fake RST to the hosts would do the trick.

>A. Greulich (greulich@math-stat.unibe.ch)


-----------[000090][next][prev][last][first]----------------------------------------------------
Date:      Sun, 5 Dec 1993 22:17:52 GMT
From:      arumble@blah.netcomm.pronet.com (Anthony Rumble)
To:        comp.protocols.tcp-ip,alt.winsock
Subject:   Problem with WinSock and ipxpkt....

I can't seem to get winsock working at all!!

Im on a novel network, with a few Unix boxes attached..

I can use ipxpkt with DOS Trumpet and things like NCSA telnet
perfectly.. WinQVT with pktint also works perfectly..

But.. If I use ipxpkt with either pkt trumpet.. or with
WinSock.. Every time I try to connect to something, I get
ARP: timed out..

I can see the ARP request going out, and returning.. But
it doesn't seem to recognise it..

Has anyone seen this before??

Please respond via e-mail

--
arumble@blah.netcomm.pronet.com	NetComm R&D
Anthony Rumble Voice x358 (02) 878-7358 Fax (02) 887-4649

-----------[000091][next][prev][last][first]----------------------------------------------------
Date:      Sun, 5 Dec 1993 22:43:01 GMT
From:      mintz@cup.hp.com (Ken Mintz)
To:        comp.protocols.tcp-ip
Subject:   Re: Should Dest. Unreachable cause TCP connect() to fail?

Jeffrey Mogul (mogul@pa.dec.com) writes:
> There are thus three possible approaches:
> 	(1) connect() always ignores "soft" unreachable messages.
> 	(2) connect() fails immediately on "soft" unreachable messages.
> 	(3) connect() ignores the first N-1 "soft" unreachable messages,
> 		and fails on the Nth such message.

  (4) Defer reporting the unreachable error until and if the retransmission
      time-out.  At that time, return any deferred error, returning
      ETIMEDOUT only if none.

  I think this could be applied both during and after connection 
  establishment.

  Note that this is suggested explicitly in RFC1122 under the discussion
  in section 4.2.3.9.

-- Ken Mintz

-----------[000092][next][prev][last][first]----------------------------------------------------
Date:      Mon, 6 Dec 93 00:03:35 GMT
From:      ftlofaro@unlv.edu (Frank Lofaro)
To:        comp.protocols.tcp-ip
Subject:   Re: The connect-connect syndrome - A bug or feature?

In article <2dt1ea$bko@usenet.INS.CWRU.Edu> trier@odin.ins.cwru.edu (Stephen C. Trier) writes:
>In article <id.VCU41.09G@nmti.com>, jaleel ihsan <ihsan@nmti.com> wrote:
>>I have a requirement[...] to have a communication protocol between two
>>system in which the two sides have a "peer-to-peer" relationship,
>>that's right "peer-to-peer" not "client-server".
>
>You can do this anyway by having both sides listen on a well-known port
>but connect from a random port.  Unless I'm missing something, this
>will provide equivalent or superior results.  Is there something that
>makes connect-connect superior in your application?
>
>How does your application deal with the 4-minute TIME-WAIT delay after
>the connection closes?
>

Probably by using the SO_REUSEADDR setsockopt() socket option, I guess...


-----------[000093][next][prev][last][first]----------------------------------------------------
Date:      Mon, 6 Dec 1993 00:42:00 GMT
From:      mintz@cup.hp.com (Ken Mintz)
To:        comp.protocols.tcp-ip
Subject:   TCP multibyte urgent data?

RFC1122 (sec. 4.2.2.4) requires the support of multibyte urgent data.

How has anyone implemented this?

The TCP protocol does not seem to support multibyte urgent data.  There is
only a pointer to the last [*] urgent octet in a segment, but no pointer 
to the first octet.

   [*] Some implementations treat this as a pointer to the last+1 octet.

Are we to assume that the urgent data extends to the first octet of that
segment?  Are there implementations that ensure that urgent and non-urgent
data are not mixed in a segment?

Can we and how do we handle outbound urgent data that exceeds MSS?  Do you
limit urgent data to MSS?  If so, how does the application learn,
especially in view of Path MTU discovery algorithms (RFC1191)?

   (BSD's TCP_MAXSEG could return this value, but this is synchronous and
   temporal in nature, given PMTU.)

How does that affect retransmission and ack policies?  The 4.3BSD
implementation seems oblivious to urgent data boundaries for these purposes.

Or have people interpreted RFC1122 in such a way that the BSD SO_OOBINLINE
suffices?

That is, it is up to the application protocol to identify the beginning and
length of multibyte urgent data.

-- Ken Mintz

-----------[000094][next][prev][last][first]----------------------------------------------------
Date:      Mon, 6 Dec 1993 02:53:52 GMT
From:      gwright@world.std.com (Gary R Wright)
To:        comp.protocols.tcp-ip
Subject:   Re: New version of traceroute anywhere?

In article <755029942snz@azrael.demon.co.uk>,
James R Grinter <james@azrael.demon.co.uk> wrote:
>Unfortunately LSRR is often blocked through routers.  Is there _really_
>a valid security reason for this, or is it just paranoia? Can anyone
>explain?

Assume:
	Host A and B behind a router R.
	Host C on the internet in front of router R.
	R restricts incoming packets to those with an IP destination
		address of A.
	R doesn't pay attention to loose source routing.

Then:
	Host C constructs IP packets with a loose source route to B through A.
	When the packet arrives at R, it will have a destination address of
		A which the router allows to pass.
	When the packet arrives at A, if A implements loose source routing,
		it will change the destination to B and A will forward the packet
		to host B.
	Host B will kindly reverse the route when it responds and the
		return packets will be routed through A, R, and back to C.
	You now have a host C communicating with host B through the
		firewall router.

In this scenario, host A will have to have IP forwarding turned on or
will have to be an internal router.  Also, Host B will have to correctly
reverse the route if R doesn't allow packets with a source address of B
to pass.

I hadn't though about this until the question was posted so I'd appreciate
any corrections/comments.

-----------[000095][next][prev][last][first]----------------------------------------------------
Date:      6 Dec 1993 03:17:20 GMT
From:      tli@cisco.com (Tony Li)
To:        comp.protocols.tcp-ip
Subject:   Re: Help with Class C subnetting please

In article <denis.79.000EF343@apollo.dcc.govt.nz> denis@apollo.dcc.govt.nz
(Denis Gordon) writes: 

    We are about to subnet our Class C addresses using a Cisco router. We
    have determined that subnets of 62 hosts will fit our needs for the
    forseeable future and have therefore settled on a 2 bit subnet mask
    allowing 4 subnets of 62 hosts. Right so far?
    
    The problem is this. In the router manual it says "do not use all zeros
    or all ones in the subnet field" and refers the reader to RFC 950 for
    the official word on Internet subnetting. So I looked it up and, sure
    enough, it says "the values of all zeros and all ones in the subnet
    field should not be assigned to actual (physical) subnets". This would
    seem to indicate that subnets 0 & 3 are unusable.
    
    Does this mean that of the 4 theoretical subnets I can only use 2
    (subnets 1 & 2)? Is there any way around this? (I don't want to use up
    more Class C addresses than I actually need by wasting half my address
    space.)
    
Correct.  Yes, you should get 9.1(8) and configure "ip subnet-zero".  The
router will allow you to use both subnets 0 and 3 then.

Tony

-----------[000096][next][prev][last][first]----------------------------------------------------
Date:      5 Dec 1993 14:15:30 +0800
From:      peter@ncrpda.curtin.edu.au (Peter N Lewis)
To:        comp.protocols.tcp-ip,comp.protocols.appletalk
Subject:   Re: Sockets type interface for MacTCP?

rmiller@netcom.com (Robert Miller) writes:

>Does anyone know if MacTCP supports any Berkley or Windows type sockets
>interface? Or any other TCP programmers interface.

There is the GUSI (available from nic.switch.ch).  Its MPW C++ and gives
a good socket interface (from what I hear).  There are several other
possibilities as well.

>I am looking for any tech info on MacTCP on this subject, also any sample
>code.

MacTCP dev deocumentation is at seeding.apple.com:mactcp.  Sample code
for using the GUSI is at nic.switch.ch.  NewsWatcher source code is at
ftp.acns.nwu.edu:/pub/newswatcher.
   Peter.
-- 
_______________________________________________________________________
Peter N Lewis <peter.lewis@info.curtin.edu.au>       Ph: +61 9 368 2055

-----------[000097][next][prev][last][first]----------------------------------------------------
Date:      Mon, 6 Dec 1993 03:48:04 GMT
From:      gwright@world.std.com (Gary R Wright)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP multibyte urgent data?

In article <CHL8M0.64J@cup.hp.com>, Ken Mintz <mintz@cup.hp.com> wrote:
>RFC1122 (sec. 4.2.2.4) requires the support of multibyte urgent data.
>How has anyone implemented this?

Trick question.  When discussing urgent/OOB data you have to be careful
to specify if you are discussing the abstract TCP protocol, or the
API (such as sockets or TLI) that a process uses to interact with TCP.
The BSD socket API's notion of OOB doesn't exactly match the TCP's
notion of urgent data.

>The TCP protocol does not seem to support multibyte urgent data.  There is
>only a pointer to the last [*] urgent octet in a segment, but no pointer 
>to the first octet.

TCP clearly supports multibyte urgent data, but it doesn't tell you
where the urgent data starts, only where it ends.  On the sending side,
an application must be able to pass a buffer of multibyte urgent data
to TCP.  TCP uses the urgent pointer to mark the end of that data in
the byte sequence.   In the common BSD implementation the process can
set the MSG_OOB flag in a sendmsg call to indicate that the entire buffer
is urgent data.  BSD doesn't queue the data any differently but will
attempt to send at least one byte of data (and the urgent pointer)
so that the receiving TCP knows that there is urgent data in the
data stream (even though it may not have been transmitted yet!).

The BSD implementation assumes that the TCP urgent
pointer points to the byte *just after* the last byte of urgent data.
This is incorrect according to RFC 1122 but is retained for backward
compatability. :-(

At the receiving side, BSD pulls the byte that appears just *before*
the urgent pointer out into a separate one-byte buffer that can be read
by a program by specifying MSG_OOB on a recvmsg system call (for
example).  If the process fails to read that single byte before another
TCP urgent pointer arrives then it will be overwritten by the new
urgent data.

Using setsockopt(SO_OOBINLINE) option, you can have the socket code
keep the urgent data in the standard read buffers and avoid loosing the
data if additional urgent data arrives.  In either case, the position
of the *most recent* urgent data is marked so that the program can know
when all data up to and including the urgent data has been read.

>Are we to assume that the urgent data extends to the first octet of that
>segment?  

Urgent data in TCP is not specified in terms of segment boundaries but 
as the sequence number of the last byte of urgent data--only the end
of the urgent data is identified by the protocol.

>Are there implementations that ensure that urgent and non-urgent
>data are not mixed in a segment?

The BSD implementation will avoid returning a read buffer that 
crosses the mark set by the arrival of urgent data.    I don't think
it makes any attempt to synchronize the urgent pointer with a segment
boundary.

>Can we and how do we handle outbound urgent data that exceeds MSS?  Do you
>limit urgent data to MSS?  If so, how does the application learn,
>especially in view of Path MTU discovery algorithms (RFC1191)?

There is no limit to the amount of urgent data since only the end is
marked.  I guess the sequence number of the urgent pointer couldn't be
too large as it might wrap into the invalid sequence space.  I'd have
to think about that a bit to see what restrictions that implies.

The API may limit the size of a write buffer marked as out of band data.
I guess in a POSIX system that would be the max value of a size_t
type.  Of course something that big probably shouldn't be considered
out-of-band at the application level.

>How does that affect retransmission and ack policies?  The 4.3BSD
>implementation seems oblivious to urgent data boundaries for these purposes.

Correct. The urgent data is just part of the normal byte sequence so
no special processing is done for retransmission and acking.

>Or have people interpreted RFC1122 in such a way that the BSD SO_OOBINLINE
>suffices?
>That is, it is up to the application protocol to identify the beginning and
>length of multibyte urgent data.

Yes.  

Of course an application can always choose to establish a second
TCP connection and use that to transfer OOB data.  As systems begin
to support type-of-service queuing and routing this will become more
useful.  Using a second TCP connection seems to me to make more sense
for true out-of-band data.  With the additional connection, your program
can bypass the buffering in the "standard" connection when sending data
and the receiving program can implement its own priority scheme by
using select to read from the appropriate socket when out-of-band
data arrives.

Especially with the non-standard interpretation of the urgent pointer
in BSD, it is easy to have "off by one" errors in the discussion of
this topic.

-----------[000098][next][prev][last][first]----------------------------------------------------
Date:      Mon, 6 Dec 1993 05:36:27 GMT
From:      mpearson@lynx.dac.northeastern.edu
To:        comp.protocols.tcp-ip
Subject:   SLIP for PC/Windows and UNIX/Ultrix! info-request

I have recently obtained WinSock for my system at home. But it has no
documentation.
What I would like to do is setup SLIP at home to connect to my ultrix
account. What do I need to do to get this one working?

Also, is there a way to impliment SLIP on UNIX/Ultrix without sysadmin
privelages? in any format? They dont feel the usage warrants setting it
up, and hey if it fits in my quota... I can run it... :)

Thanks for the help in advance..

please email me respones, skip the flames if any...
mpearson@lynx.dac.northeastern.edu


-- 
--
------------------------------------------------------------------------------
Matthew E. Pearson                 | "Got shiny diamonds, like the eyes of
mpearson@lynx.dac.northeastern.edu | a cat in the black and blue. Something is 

-----------[000099][next][prev][last][first]----------------------------------------------------
Date:      6 Dec 93 07:44:05 GMT
From:      ddl@harvard.edu (Dan Lanciani)
To:        comp.protocols.tcp-ip,comp.security.unix
Subject:   Re: TCP source routing and setsockopt(SO_DONTROUTE)

In article <1993Dec5.161726.24116@aragorn.unibe.ch>, greulich@math-stat.unibe.ch (Andreas Greulich) writes:

| By the way, in another experiment I made a strange observation, that
| probably has to do with the bugged BSD 4.3 implementation (?). I tried
| what happened if machine A sends connection packets to machine B (and
| in this case pretends to be machine C), and to machine C (where it pretends
| to be machine B), in both cases using appropriate "guessed" sequence
| and port numbers. I wanted to see if those two machines (B and C)
| can be connected together initiated by a machine A. What happened was
| that machines B and C swapped SYN packets (I think those were SYN packets)
| indefinitely.

Wow, I think you've found a new way to provoke the connect-connect bug!  Is
it my imagination, or is this topic (in different forms) appearing more
and more frequently of late?  Does this perhaps have some cosmic
significance?  In any case, I posted a patch a few months back.  Somebody
can dig it up or I can repost if necessary...

				Dan Lanciani
				ddl@harvard.*

-----------[000100][next][prev][last][first]----------------------------------------------------
Date:      Mon, 6 Dec 1993 09:10:48 GMT
From:      donp@novell.com (don provan)
To:        comp.protocols.tcp-ip
Subject:   Re: The connect-connect syndrome - A bug or feature?

In article <id.VCU41.09G@nmti.com> ihsan@nmti.com (jaleel ihsan) writes:
>I have a very good reason for TCP connect-connect to work exactly the
>way it is designed to.

I suspect you (and a few other people) are talking about the simpler
case where the two peers first listen on their port, and then connect
using it.  I agree this might be useful.  The more difficult case --
which, cool as it is, I claim is useless -- is where the two peers
connect to each other *without* listening first.  Since it would
require incredible synchronization to achieve a connection in such a
situation (the two SYNs *must* cross in transit), I doubt anyone's
found a way to use it.

						don provan
						donp@novell.com

-----------[000101][next][prev][last][first]----------------------------------------------------
Date:      Mon, 6 Dec 1993 09:26:04 GMT
From:      donp@novell.com (don provan)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP multibyte urgent data?

In article <CHL8M0.64J@cup.hp.com> mintz@cup.hp.com (Ken Mintz) writes:
>The TCP protocol does not seem to support multibyte urgent data.  There is
>only a pointer to the last [*] urgent octet in a segment, but no pointer 
>to the first octet.

Oh, no.  Not the urgent battle.  Oh, well...

My claim is that TCP *does* tell you where the urgent data starts: it
starts immediately.  You see, I believe there's a confusion here
between "urgent" and "important".  In my studies of RFC793, I've come
to the conclusion that "urgent data" is urgent in much the same way
one might have an "urgent need" to visit the restroom: it's not that
the results are important, it's just that it has to be taken care of
immediately.

When a TCP application recieves an urgent indication, it's supposed to
go into "urgent mode" until it gets to the urgent pointer.  The
details of "urgent mode" vary from application to application, but the
basic idea is that the data up to the urgent pointer is discarded.  It
doesn't seem as if the data just before the urgent pointer is any more
important than the rest of the drek, since TCP says it should be
discarded in just the same way as the rest of the pre-urgent data.

						don provan
						donp@novell.com

-----------[000102][next][prev][last][first]----------------------------------------------------
Date:      Mon, 06 Dec 1993 18:53:20 -0500
From:      johns@oxygen.house.gov (John Schnizlein)
To:        comp.protocols.tcp-ip
Subject:   Re: New version of traceroute anywhere?

In article <CHLEpt.H1o@world.std.com>, gwright@world.std.com (Gary R
Wright) wrote:

> In article <755029942snz@azrael.demon.co.uk>,
> James R Grinter <james@azrael.demon.co.uk> wrote:
> >Unfortunately LSRR is often blocked through routers.  Is there _really_
> >a valid security reason for this, or is it just paranoia? Can anyone
> >explain?
> 
> Assume:
> 	Host A and B behind a router R.
> 	Host C on the internet in front of router R.
> 	R restricts incoming packets to those with an IP destination
> 		address of A.
> 	R doesn't pay attention to loose source routing.
> 
You have identified the essential reason why screening routers should not
just
not pay attention (implement) source routing, but should drop any
source-routed
packets.

It seems you have answered Grinter's question very clearly: not paranoia.
-- 
disclaimer! we don't need no stinking disclaimer! |  John M. Schnizlein
everybody knows nobody can represent the views of |  router jockey
435 elected policy makers.

-----------[000103][next][prev][last][first]----------------------------------------------------
Date:      Mon, 06 Dec 1993 18:57:27 -0500
From:      johns@oxygen.house.gov (John Schnizlein)
To:        comp.protocols.tcp-ip
Subject:   Timbuktu Pro remote control over TCP/IP

I read in MacWEEK (11.15.93) that Timbukto Pro from Farallon will "support"
TCP/IP in addition to AppleTalk for its function of enabling one
(Macintosh) computer to operate another by remote control [pg 1 & 143].
Unfortunately the article concludes with "Farallon declined to comment."

Can anyone identify what TCP port is used for this?
If it does not use TCP, (TCP/IP is just a protocol label for some
journalists) can anyone identify the IP protocol authoritatively?

I would most like an answer from Farallon, but any knowledgable source is
welcome.

-- 
disclaimer! we don't need no stinking disclaimer!   John M. Schnizlein
everybody knows nobody can represent the views of   router jockey
435 elected policy makers.

-----------[000104][next][prev][last][first]----------------------------------------------------
Date:      Mon, 6 Dec 1993 11:42:20 GMT
From:      marka@syd.dms.CSIRO.AU (Mark Andrews)
To:        comp.protocols.tcp-ip
Subject:   Re: DNS - what RRs must the server return?

In article <DRW.93Dec4155314@runge.mit.edu> drw@runge.mit.edu (Dale R. Worley) writes:
>   : To put it another way, when I want to resolve an MX record to IP
>   : numbers, do I need code to do an extra query in case the MX query
>   : doesn't return the A's in the AR field?
>
>The usual advice is to be strictly conforming in what one generates,
>but liberal in accepting what other generate.  In this case, code to
>do the extra query in case the server doesn't remember to give you the
>A records.
>
>Dale
>
>Dale Worley		Dept. of Math., MIT		drw@math.mit.edu
>--
>Sometimes you're the windshield.
>Sometimes you're the bug.
>-- Dire Straits

	Additional record are sent "if and only if" the data for the
	addition record exists in the cache of the nameserver answering
	the query.

	Mark.

-----------[000105][next][prev][last][first]----------------------------------------------------
Date:      6 Dec 1993 12:54:17 GMT
From:      skok@itwds1.rus.uni-stuttgart.de (Holger Skok)
To:        comp.protocols.tcp-ip
Subject:   Wherza FAQ? - Subnetting question

Hi everyone,

I have a small (hopefully) problem to deal with, which could be treated
in the FAQ. If that's the case, please point me to it (ftp site would be
nice).

If not (or if you feel like answering anyway) here's my trouble:

We have a few UN*X boxes in a subdomain(?) with IP address 129.69.69. We
are free to use the addresses available and we have to make do with
them. That should be easy, after all there are only seven UN*X boxes and
a few PC's connected. Now, however we have obtained an additional Novell
network and want to be able to connect to the internet from the
Novell-client PC's. Everything on the PC's is setup correctly. We use
packet drivers and NCSA-telnet but from inside the Novell net there's no
connection - connection timeout. 
Reason is that we have two seperate networks. One is connected to the
rest of the world and has the UN*X boxes plus one interface card of the
Novell server connected to it while the other has all the Novell clients
hanging off of it and the other interface card of the Novell server
serving it. tcp/ip routing is installed on the Novell server. 
The server does not seem to understand where it has to route the packets 
to, though. 

In order for the routing to work, the routing software has to understand
that the two interface cards belong to different networks. It would be
easy if we could get another subnet from our computing center, but that
would really be wasteful of IP-node numbers. The only option remaining -
so we have been told - is to split our subnet into two (or four)
sub-subnets. One would have to fiddle with the netmask then.
How would that work?
Currently our netmasks are set to 255.255.255.0. We could presumably
mask two bits more (netmask 255.255.255.192) and split our subnet into
four sub-subnets. Would that work? How would the addresses have to be
chosen then, what would the IP numbers have to be in the two parts of
the subnet? What does the "broadcast" field have to be set to? (What's
being "broadcast" anyway?).

Thanks in advance for any hints,

HSK
-- 
***********************************************************************
*          skok@itwds1.energietechnik.uni-stuttgart.de                *
***********************************************************************

-----------[000106][next][prev][last][first]----------------------------------------------------
Date:      6 Dec 93 18:26:21
From:      drw@jordan.mit.edu (Dale R. Worley)
To:        comp.protocols.tcp-ip
Subject:   Re: Interpreting Multiple IP addresses from DNS

In article <restock.28.000C4E67@pacbell.com> restock@pacbell.com (Robert Stockwell) writes:
   My question is how does the client tell which interpretation is correct?  I 
   believe that the first interpretation is how most clients work.

If I remember correctly, in DNS replies the order is unspecified, so
there is no way to attach any meaning to the order in which you
receive them.

(I have seen it said that the proposed record type "SA" may have a
different meaning in this regard.)

Dale

Dale Worley		Dept. of Math., MIT		drw@math.mit.edu
--
Sex is just the beginning, but if you miss the beginning you'll miss
the end, too.

-----------[000107][next][prev][last][first]----------------------------------------------------
Date:      Mon, 6 Dec 1993 14:24:42 GMT
From:      iwj@cam-orl.co.uk (Ian Jackson)
To:        comp.protocols.tcp-ip
Subject:   Re: The connect-connect syndrome - A bug or feature?

In article <1993Dec6.091048.9881@novell.com> donp@novell.com (don provan) writes:
>In article <id.VCU41.09G@nmti.com> ihsan@nmti.com (jaleel ihsan) writes:
>I suspect you (and a few other people) are talking about the simpler
>case where the two peers first listen on their port, and then connect
>using it.

Using the Unix (BSD) socket API you can't listen on a socket first and
then do an active connect.

>   I agree this might be useful.  The more difficult case --
>which, cool as it is, I claim is useless -- is where the two peers
>connect to each other *without* listening first.  Since it would
>require incredible synchronization to achieve a connection in such a
>situation (the two SYNs *must* cross in transit), I doubt anyone's
>found a way to use it.

However you can do bind, and then wait for the information about what
the remote socket is, followed by connect.  If the other end does a
connect whose SYN arrives before the receiving end has done its
connect but after it has done the bind the receiving end will simply
not reply.  This will cause the sender to keep retransmitting until
the receiver is ready, at which point it will send a SYN and the
marvellous 3-way handshake will sort out any resulting mess.

Thus connect-connect can be useful, if both ends can tell each other
reasonably quickly where to connect to.  This could be useful in (for
example) a proxy file transfer, though I don't think that DARPA FTP
uses it.

I've actually tried using connect-connect, and it works.  I have
little Perl script I use to test such things (such things = TCP socket
munging).  If there is demand I'll post it or email it to people.

(PS: "Distribution: usa" removed from the header)
--
Ian Jackson  iwj@cam-orl.co.uk ..!uknet!cam-orl!iwj  These opinions are my own.
Olivetti Research Ltd, Old Addenbrookes Site, Trumpington St, Cambridge, UK;
Home: 35 Molewood Close, Cambridge, CB4 3SR; +44 223 327029.     +44 223 343333
Email also via: ijackson@nyx.cs.du.edu   PGP2 public key available on request

-----------[000108][next][prev][last][first]----------------------------------------------------
Date:      Mon, 6 Dec 1993 14:56:55 GMT
From:      denis@apollo.dcc.govt.nz (Denis Gordon)
To:        comp.protocols.tcp-ip
Subject:   Help with Class C subnetting please

We are about to subnet our Class C addresses using a Cisco router. We have 
determined that subnets of 62 hosts will fit our needs for the forseeable 
future and have therefore settled on a 2 bit subnet mask allowing 4 subnets of 
62 hosts. Right so far?

The problem is this. In the router manual it says "do not use all zeros or all 
ones in the subnet field" and refers the reader to RFC 950 for the official 
word on Internet subnetting. So I looked it up and, sure enough, it says "the 
values of all zeros and all ones in the subnet field should not be assigned 
to actual (physical) subnets". This would seem to indicate that subnets 0 & 3 
are unusable.

Does this mean that of the 4 theoretical subnets I can only use 2 (subnets 1 
& 2)? Is there any way around this? (I don't want to use up more Class C 
addresses than I actually need by wasting half my address space.)

Thanks for any help
Denis

---
Denis Gordon                 internet: denis@apollo.dcc.govt.nz
Network Administrator           phone: +64-3-474-3566
Dunedin City Council
Dunedin,New Zealand        DUNEDIN. it's all right here.
                                             ~~~~~

-----------[000109][next][prev][last][first]----------------------------------------------------
Date:      Mon, 6 Dec 1993 15:13:06 GMT
From:      ctkosti@afterlife.ncsc.mil (Chris Kostick)
To:        comp.protocols.tcp-ip
Subject:   uping - simple echo/reply program

About a month ago or so I submitted a question as to why ping seemed to have
a maximum packet size of 2000 bytes (on Sun's). It was never really resolved
so I wrote a program called uping that sends UDP packets to the ECHO port
and includes some of the functionality of ping. It's attached below.

This program works on a Sun for the most part but here are a few problems
I've encountered. BTW, this whole thing started when I wanted to observe
fragmentation of various sizes as it was generated from the host.

problems:

(i)
On almost every host that I have uping'd, the replying device only sends
back at most 1024 octets of the orignal message. An example

% uping -s 2048 valhalla
sending 2060 octets to host valhalla
1024 octets received, seq = 0   time = 107.38 ms
1024 octets received, seq = 1   time =  7.03 ms
1024 octets received, seq = 2   time =  6.96 ms
1024 octets received, seq = 3   time =  7.84 ms
^C
------------ uping statistics ------------
4 UDP packets transmitted, 4 UDP packets received,   0.00% packet loss
round-trip time (ms) min/avg/max =  6.96/32.30/107.38


This seems to go against the RFC. I thought all data was to be returned.
An IBM RS/6000 running AIX returns up to 4K.


(ii)
I could only get this to work on a Sun (SunOS 4.1.3). I tried and IBM
RS/6000 (AIX 3.2) and continually got this message

sending 1464 octets to host pokey
error  : Message too long
uping: write error. -1 bytes written. 1464 should have been sent


And on a HP9000 (HPUX 9.0) 

sending 1464 octets to host shaiton
1024 octets received, seq = 0   time = 15.73 ms
-1 octets received, seq = 0     time = 998.08 ms
1024 octets received, seq = 1   time =  9.01 ms


I haven't tried other architectures so if anyone wants to and can get it to
work let me know. Also, I'm not a professional C programmer nor a network
programmer, please clean up as desired.

---------------- [ snip snip snip ] ------------------------------------
/*
 *
 *	program:	uping.c
 *	author:		Chris Kostick, Dept. of Defense
 *	date:		Nov. 29, 1993
 *
 *	purpose:	Functionaly act like the PING program except send
 *			UDP packets to the ECHO service (port 7) instead
 *			of using ICMP Echo Request/Reply.
 */
#include <stdio.h>
#include <sys/types.h>
#include <netdb.h>
#include <sys/socket.h>
#include <netinet/in.h>
#include <arpa/inet.h>
#include <signal.h>
#include <sys/time.h>
#include <errno.h>

#ifndef	 INADDR_NONE
#define	 INADDR_NONE	-1L
#endif

#define  DEF_MESS_SIZE	1464	/* stuff message into 1 ethernet frame */
#define  MAX_MESS_SIZE	8192

typedef struct _sendbuf {
	int	seq;
	struct  timeval timestamp;
	char	data[MAX_MESS_SIZE+1-sizeof(int)-sizeof(struct timeval)];
} SENDBUF;

int	sfd;
int	data_length;
char	*prog;
SENDBUF	send_buf;


main(argc, argv)
int  argc;
char *argv[];
{
  int			i, n, c;
  unsigned long		inaddr;
  struct sockaddr_in	serv_addr, cli_addr;
  struct hostent	*host;
  int			cleanup(), send_pkt(), recv_pkt();

  char	 *data = "abcdefghijklmnopqrstuvwxyz0123456789ABCDEFGHIJKLMNOPQRSTUVW";

  prog = argv[0];

  if (argc == 1) {
    fprintf(stderr, "usage: %s [-s message_size] host\n", prog);
    exit(1);
  }

  /*
   *	process lone option
   *	and check for futher errors
   */
  if (strcmp(argv[1], "-s") == 0) {
    if (argc == 2) {		/* they forgot to specify the size */
      fprintf(stderr, "usage: %s [-s message_size] host\n", prog);
      exit(1);
    }
    if ((data_length = atoi(argv[2])) == 0) {
      fprintf(stderr, "%s: error in message size\n", prog);
      exit(1);
    }
    if (data_length+sizeof(int)+sizeof(struct timeval) > MAX_MESS_SIZE) {
      fprintf(stderr, "%s: message size too large. MAX=%d\n", prog,
							      MAX_MESS_SIZE);
      exit(1);
    }
    ++argv; ++argv;
    --argc; --argc;
    /*
     *	did they forget the host name
     */
    if (argc <= 1) {
      fprintf(stderr, "usage: %s [-s message_size] host\n", prog);
      exit(1);
    }
  }
  else {
    data_length = DEF_MESS_SIZE - (sizeof(int)+sizeof(struct timeval));
  }

  /*
   * server initialization
   */
  bzero((char *) &serv_addr, sizeof(serv_addr));
  serv_addr.sin_family = AF_INET;
  serv_addr.sin_port = 7;		/* ECHO service */

  /*
   *	see if it's an IP address
   */
  if ((inaddr = inet_addr(argv[1])) != INADDR_NONE) {
    bcopy((char *) &inaddr, (char *) &serv_addr.sin_addr, sizeof(inaddr));
  }
  else {	/* must be a host name */
    if ((host = gethostbyname(argv[1])) == NULL) {
      fprintf(stderr, "host name error: %s address not found\n", argv[1]);
      exit(2);
    }
 bcopy(host->h_addr, (char *) &serv_addr.sin_addr, host->h_length);
  }
  
  /*
   * 	establish socket
   */
  if ((sfd = socket(AF_INET, SOCK_DGRAM, 0)) < 0) {
    fprintf(stderr, "%s: can't open socket\n", prog);
    exit(3);
  }

  /*
   *	bind local address
   */
  bzero((char *) &cli_addr, sizeof(cli_addr));
  cli_addr.sin_family = AF_INET;
  cli_addr.sin_addr.s_addr = htonl(INADDR_ANY);
  cli_addr.sin_port = htons(0);

  if (bind(sfd, (struct sockaddr *) &cli_addr, sizeof(cli_addr)) < 0) {
    fprintf(stderr, "%s: bind error\n", prog);
    close(sfd);
    exit(4);
  }

  /*
   *	connect
   */
  if (connect(sfd, (struct sockaddr *) &serv_addr, sizeof(serv_addr)) < 0) {
    fprintf(stderr, "%s: connect error\n", prog);
    close(sfd);
    exit(5);
  }

  /*
   *	prepare the data portion of the send buffer. Stuff it full.
   */
  send_buf.data[0] = '\0';
  c = n = 0;
  do {
     n = (c+strlen(data) > data_length) ? data_length-c : strlen(data);
     strncat(send_buf.data, data, n);
     c += n;
  } while (c<data_length-1);
  send_buf.data[data_length] = '\0';

  /*
   *	let's send and gather stats
   */
  signal(SIGINT, cleanup);
  signal(SIGALRM, send_pkt);

  printf("sending %d octets to host %s\n", 
				data_length+sizeof(int)+sizeof(struct timeval),
				argv[1]);
  send_pkt();

  recv_pkts();

  /* 	we don't really get here	*/
}


extern	int	sfd;
extern  int	data_length;
extern  char	*prog;
extern	SENDBUF	send_buf;


int counter = 0;
/*
 *	send it out
 */
int
send_pkt()
{
  int	i, dl;
  struct timeval  tp;

  dl = data_length + sizeof(int) + sizeof(struct timeval);

  send_buf.seq = counter;
  gettimeofday(&tp, (struct timezone *) 0);
  send_buf.timestamp.tv_sec  = tp.tv_sec;
  send_buf.timestamp.tv_usec = tp.tv_usec;

  /*
   *	let's write it out
   */
  if ((i = write(sfd, send_buf, dl)) != dl) {
    perror("error  ");
    fprintf(stderr,
	    "%s: write error. %d bytes written. %d should have been sent.\n",
	    prog, i, dl);
    close(sfd);
    exit(6);
  }
  counter++;

  alarm(1);
}


double    min_rtt = 999999.0;
double    max_rtt = -1.0;
double    cumul_rtt = 0.0;
int	  expected = 0, missed = 0;


int
recv_pkts()
{

  int	    v, dl;
  double    send_ts, recv_ts, rtt;
  SENDBUF   buf;
  struct    timeval  tp;

  dl = data_length+sizeof(int)+sizeof(struct timeval);

  /*
   *	let's see what we get back.
   */
  for (;;) {
    v = read(sfd, &buf, dl);

    gettimeofday(&tp, (struct timezone *) 0);
    recv_ts = tp.tv_sec+(tp.tv_usec/1000000.0);

    send_ts = buf.timestamp.tv_sec+(buf.timestamp.tv_usec/1000000.0);

    rtt = (recv_ts-send_ts)*1000;
    printf("%d octets received, seq = %d\ttime = %5.2f ms\n", v, buf.seq, rtt);

    if (buf.seq != expected) missed++;
    expected++;

    cumul_rtt += rtt;
    if (rtt < min_rtt) min_rtt = rtt;
    if (rtt > max_rtt) max_rtt = rtt;
  }
}




/*
 *	someone stopped us, print stats
 */
int
cleanup()
{

 int	received;

 if (expected == 0)
   received = 0;
 else
   received = counter-missed;

 printf("\n------------ uping statistics ------------\n");
 printf("%d UDP packets transmitted, %d UDP packets received, %6.2f%% packet loss\n",
	counter, received, (1-(received/counter))*100.0);

 if (received != 0) {
   printf("round-trip time (ms) min/avg/max = %5.2f/%5.2f/%5.2f\n",
	min_rtt, cumul_rtt/received, max_rtt);
 }

 close(sfd);
 exit(0);
}

-----------[000110][next][prev][last][first]----------------------------------------------------
Date:      06 Dec 1993 16:17:11 GMT
From:      ppessi@snakemail.hut.fi (Pekka Pessi)
To:        comp.protocols.tcp-ip
Subject:   Re: ping: socket: permission denied

In article <HARMON.93Dec2132936@craycomm.casemo> harmon@craycomm.casemo ( Bob Harmon ( Eng. )) writes:
>In article <Dec01.175735.72297@melupl> bill@melupl (Bill Fulton) writes:
>>>>> Same is true on AIX. I presume this is because a ping requires access to
 
>I guess when one 'Presumes' one makes a 'Pres' out of you and me, thats Cool.
 
>Actually, this is because ping and rlogin and rcmd, lpd, ..... etcerta all
>require that a port bewteen 0 and 1024 be used, These ports can only
>be allocated by root for security, thus all applications which bind to
>these ports must be setuid root.  You can check /etc/services for a list.
>Check out the parallel lpd thread in this group for info on rresvport, etc.

	K0w1. Actually, ping uses a raw socket with ICMP protocol,
	which requires root permission, just like Bill said. There are
	no ports in ICMP.

--
Pekka.Pessi@hut.fi


-----------[000111][next][prev][last][first]----------------------------------------------------
Date:      7 Dec 1993 00:46:19 -0500
From:      lin@cs.purdue.edu (John Chueng-Hsien Lin)
To:        comp.protocols.tcp-ip
Subject:   BSD 4.4 Networking code question

  The latest issue of UNIX Review (Jan. '95, Vol. 12, No. 1) has an article
on BSD4.4 by Kirk McKusick. Mr. McKusick mentioned in the "Networking
Changes" section of the article:

  "... In addition, the routing table stores and caches route characteristics
   to speed the adaptation of the throughput and congestion-avoidance
   algorithms."

  I am interested in knowing what route characteristics did BSD 4.4
deduce? And how did it obtain them?  Any references or pointers are much 
appreciated.

Thanks,
John Lin (lin@cs.purdue.edu)

-----------[000112][next][prev][last][first]----------------------------------------------------
Date:      Mon, 6 Dec 1993 16:27:43 GMT
From:      jmota@lyra.lnec.pt ()
To:        comp.protocols.tcp-ip
Subject:   help me with X.25!!!

Ok, this may not be the right place to ask for help in the particual subject
i want, but i can't remember other one.

* Does anyone know some place where i could find find some kind of high-level
  library that could help me in my work on communications over X.25? or any
  info about the subject?

Any help is welcomed, mail me to the following address:
jmota@draco.lnec.pt

Thanx a lot! Joao Mota


Keywords: 


-----------[000113][next][prev][last][first]----------------------------------------------------
Date:      6 Dec 1993 18:01:46 GMT
From:      trier@slc6.ins.cwru.edu (Stephen C. Trier)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP multibyte urgent data?

"Oh, no, not again."
      - The pot of petunias in _The Hitchhiker's Guide Radio Scripts_
:-)

This is a near-annual subject of debate, and unfortunately, I was a
participant in the last round.  I'll try to limit my participation
this time...

In article <CHL8M0.64J@cup.hp.com>, Ken Mintz <mintz@cup.hp.com> wrote:
>RFC1122 (sec. 4.2.2.4) requires the support of multibyte urgent data.

Sort of.  It requires the support of urgent data in the TCP sense,
not necessarily in the sense of the OSI "expidited data" or BSD's
"OOB data".

>The TCP protocol does not seem to support multibyte urgent data.  There is
>only a pointer to the last [*] urgent octet in a segment, but no pointer 
>to the first octet.

What's neat is that the application can make use of this pointer to
convey multiple bytes of important data.  There's no need to use it as
the end of important data; it could also be the start.  Here are two
examples:

1) In Telnet, when a telnet sees urgent data, it reads rapidly up to
the urgent pointer, paying attention only to telnet IAC commands.
Normal data is discarded.  The "important information" resides before
the urgent pointer in one or more of the IAC sequences.

2) I could design a protocol where the "important information" lies
after the Urgent pointer, perhaps starting with a count of how many
bytes are "important".  The catch here is that if I send two batches of
"important information", I don't know whether the receiver will see
both or only the last one.  This might be desirable, depending on the
purpose of the protocol.

What's nice about this approach is that it guarantees reliable and
in-sequence delivery of important information.  The automatic
synchronization of important and normal data is also convenient.

>Are there implementations that ensure that urgent and non-urgent
>data are not mixed in a segment? ... Can we and how do we handle
>outbound urgent data that exceeds MSS?  ...  How does that affect
>retransmission and ack policies?

Yes, there are such implementations.  These are indeed problems with
such implementations.  Some implementors have tried to find solutions;
others have not.

One of the advantages of the simple Urgent mechanism I described above
is that it doesn't have these problems.  No data is "out of band", and
the "important data" itself is not expidited.  All it is is a signal to
the remote application so that the _application_ can expidite things.

>That is, it is up to the application protocol to identify the beginning and
>length of multibyte urgent data.

Exactly!

      Stephen

-- 
Stephen Trier  KB8PWA       "The light at the end of the tunnel
Work: trier@ins.cwru.edu     may be an oncoming dragon"
Home: sct@po.cwru.edu                          - Unknown

-----------[000114][next][prev][last][first]----------------------------------------------------
Date:      6 Dec 93 18:07:31 GMT
From:      rrooks@ecs.umass.edu
To:        comp.protocols.tcp-ip
Subject:   TCP/IP and X-Windows Packages for PC

   We currently dissatisfied with our purchase of Pathworks, since it doesn't
work with our ethernet card (Etherlink 16 by 3COM).  Because of that, we
would like to purchase another package so that we can run X-Windows and
have remote printing on our PC clone.  The remote printing would occur on
a printer hooked up to a LAT.  (DEC)

   Does anyone run this type of configuration and would have some advice for
what packages I might try?

Thanks,

Ray


-----------[000115][next][prev][last][first]----------------------------------------------------
Date:      6 Dec 93 22:37:58 EDT
From:      mckee@pacs.sunbelt.net
To:        comp.protocols.tcp-ip
Subject:   Re: TCP/IP and X-Windows Packages for PC

In article <22648.2d0374e3@ecs.umass.edu>, rrooks@ecs.umass.edu writes:
>    We currently dissatisfied with our purchase of Pathworks, since it doesn't
> work with our ethernet card (Etherlink 16 by 3COM).  Because of that, we
> would like to purchase another package so that we can run X-Windows and
> have remote printing on our PC clone.  The remote printing would occur on
> a printer hooked up to a LAT.  (DEC)
> 
>    Does anyone run this type of configuration and would have some advice for
> what packages I might try?
> 
> Thanks,
> 
> Ray
> 
You should be able to run that card via an NDIS driver with no problems.  I
have used another card in the same manner.

Tim McKee

-----------[000116][next][prev][last][first]----------------------------------------------------
Date:      Mon, 6 Dec 1993 19:37:25 GMT
From:      rouet@info.polymtl.ca (Marc Andre Rouet)
To:        comp.sys.novell,comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject:   tcp-ip interface

Hi,
	I am a developper wishing to port my communication software which 
currently works on a RS-232 (serial) conection to tcp-ip on a Novell Netware 
network.

Where can I get the interface specification, libraries and development tools
 needed to do that ?
Is there a standard published interface for all tcp-ip products on the pc
through interrupts (suggested books ...) or is Novell"s interface proprietary?

	Thamks!

	Marc-Andre Rouet (rouet@info.polymtl.ca)

-----------[000117][next][prev][last][first]----------------------------------------------------
Date:      6 Dec 1993 19:47:00 GMT
From:      heathh@cco.caltech.edu (Heath Ian Hunnicutt)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP multibyte urgent data?

I thought that an application should not attempt to send more than one byte
of urgent data for the following reason:  If the receiver's buffer is full,
the tcp send algorithm will be "probing" the receiver with one-byte, until
the data is acked, and the window changes.  If the sender sends urgent data
in this case, the receiver is required to deliver one byte of it.

This is something I overheard in a different debate, and I'm not sure that
I'm really clear on it.  Please correct me if I'm wrong.

Heath

-- 
--
From the Home for Amnesiac Computer Scientists....
  heathh@cco.caltech.edu


-----------[000118][next][prev][last][first]----------------------------------------------------
Date:      Mon, 6 Dec 1993 19:51:15 GMT
From:      donp@novell.com (don provan)
To:        comp.protocols.tcp-ip
Subject:   Re: The connect-connect syndrome - A bug or feature?

In article <1993Dec6.142442.10583@infodev.cam.ac.uk> iwj@cam-orl.co.uk (Ian Jackson) writes:
>>   I agree this might be useful.  The more difficult case --
>>which, cool as it is, I claim is useless -- is where the two peers
>>connect to each other *without* listening first.  Since it would
>>require incredible synchronization to achieve a connection in such a
>>situation (the two SYNs *must* cross in transit), I doubt anyone's
>>found a way to use it.
>
>However you can do bind, and then wait for the information about what
>the remote socket is, followed by connect.  If the other end does a
>connect whose SYN arrives before the receiving end has done its
>connect but after it has done the bind the receiving end will simply
>not reply.  This will cause the sender to keep retransmitting until
>the receiver is ready, at which point it will send a SYN and the
>marvellous 3-way handshake will sort out any resulting mess.

OK.  This sounds to me like a BSD invented quasi-state somewhere
between CLOSED and LISTEN which has all of the characteristics of the
LISTEN state which are relevant to my comments.  But now I understand
why BSDers always look at me funny when a talk about a listen followed
by a connect.  I didn't realize sockets wouldn't allow that.

(I call this a "quasi-state" because it's not CLOSED -- all SYNs are
RESET in CLOSED state -- and it's not LISTEN because the SYN would be
ACKed in LISTEN state.  Mind you, I don't see anything wrong with this
quasi-state, although I must admit I don't see any advantage to it over
just allowing connects from a socket in LISTEN state.  Connecting from
LISTEN even has its own arrow in the TCP state diagram in that SEND
from LISTEN goes to SYN-SENT, the first step in the active connection
process.)

						don provan
						donp@novell.com

-----------[000119][next][prev][last][first]----------------------------------------------------
Date:      Mon, 6 Dec 1993 20:18:17 GMT
From:      restock@pacbell.com (Robert Stockwell)
To:        comp.protocols.tcp-ip
Subject:   Interpreting Multiple IP addresses from DNS

When DNS returns multiple IP addresses from a single Domain name the result 
can be interpreted in two ways:

1) Primary, Secondary, ...

or

2) Pooling

In the first interpretation the client should try the first one in the list 
then, the second, then the third etc.  The idea is that the first is what 
SHOULD be used but the others are there just in case.  A good use for this is 
when you have a many local distributed servers and a master server.  You 
really want everybody to use the local servers.

In the second interpretation, the client randomly chooses in order to spread 
the workload over many servers.  

My question is how does the client tell which interpretation is correct?  I 
believe that the first interpretation is how most clients work.
--
Bob Stockwell
restock@pacbell.com

-----------[000120][next][prev][last][first]----------------------------------------------------
Date:      Mon, 6 Dec 1993 21:46:09 GMT
From:      korfhage@weston.poly.edu (Willard Korfhage)
To:        comp.protocols.tcp-ip
Subject:   TCP/IP Performance Papers?

A paper in 1989 by Clark, Jacobson, Romkey, and Salwen looked at TCP processing
overhead. Are there any more recent studies of protocol overhead? I am curious
to know if protocol implementations have improved, or not. Also, are there
any commercial workstations that have a coprocessor for handling protocols?

Thanks

   Willard

-----------[000121][next][prev][last][first]----------------------------------------------------
Date:      7 Dec 1993 07:47:07 -0600
From:      tdnycal@dsiaq1.ing.univaq.it (Dell'Elce Antonio)
To:        comp.protocols.tcp-ip
Subject:   A Remote Query Protocol

Here is a my protocol .. the Remote Query Protocol
I have styled it like an Internet-Draft...


I would like comments on it. Thank you.
I will summarize to that net. If any need.

Antonio dell`elce
tdnycal@dsiaq1.ing.univaq.it


-----------------------------------------------------------------------
draft-rquery-protocol-01.txt			      Antonio Dell'elce
INTERNET-DRAFT						  November 1993



			 Remote  Query  Protocol


1.0 Status of this memo

This document is an Internet-Draft. Internet-Drafts are working douments
of the Internet Engineering Task Force (IETF), its areas, and its
working group. Note that other groups may also distribute working
documents at any time. It is not appropriate to use Internet-Drafts as
reference material or to cite them other than as a "working draft" or
"work in progress."

To learn the current status of any Internet-Draft, please check the
1id-abstracts.txt list contained in the Internet-Drafts Shadow
DIrectories on ds.internic.net, nic.nordu.net, ftp.nisc.sri.com, or
munnari.oz.au.


2.0 Abstract

The purpose of the Rquery protocol is just to get information, alas it
makes possible to send a question to a remote host about certain
information it may have. The question received by the remote host
It must work in any computer network. Domains are used only where they
exist.

Examples of the RQUERY call may be: "What Services do you offer?", "Do
you know a host called XYZ?", "Is there a host a you know that supports
the XYZ protocol?", and so on. 

  (36)							       [Page  1]

INTERNET-DRAFT	    	  Remote Query Protocol		     November 93

Things that may be object of a remote query may be:

	-  SERVICES
	   
	   Any services that can be offered at remote site, such
	   Anonymous FTP, gophers, BBSes, guest or restricted accounts,
	   accounts on payment, NICs, or any other service. Queries
	   wanting information of a service, already. However, are more
	   difficult to implement.
	   
	   
	-  PROTOCOLS
	   
	   Any protocol offered. This kind of query has importance since
	   you may ask the protocol of any other host. See example 11.
	   
	   
	-  HOSTS/DOMAINS
	   
	   They are used for querying about existence of hosts, domains
	   and existence of a certain host under a certain domain, and
	   similar.
	   
	   
	-  USERS
	   
	   Querying for users may result as using RWHO, RUSERS, FINGER
	   and other this kind of queries may ask about users existance,
	   log-ins, in you host, domain, network or even host, domain or
	   network in another domain.
	   
	   
	-  OTHERS

	   Querying a conventional database for example. It may be used
	   with any other given convention set with the two parties (the
	   querying and the replier).




Dell'elce (81)						        [Page 2]
 
NETWORKING-DRAFT	     Remote Query Protocol	     November 93


The question may be asking about the resources, (1) of the same host 
queried, this is the network cosuming approach,(2) another host, (3)
a domain, or (4) a mixed of them.

Examples of an RQUERY for the case (1 - SERVICES) are:

00	"do you offer anonymous FTP?"
01	"do you have Public Accounts?"
02	"do you know user DOE?"
03	"what hosts there are in your domain?"
	
examples of an RQUERY for case (2 - HOST/DOMAINS) are:

04	"do you know a host that offers anonymous FTP service?"
05	"do you know a host that have Public Accounts?"
06	"do you know what services offer host XX.LCS.ANY.EDU?"
07	"do you know a server for the RQUERY protocol?"
08	"do you know a nameserver for domain ANY.EDU?"
09	"what hosts that offer Public Accounts do you know?"
10	"what hosts in the domain offer DIALUP service?"
11	"what protocols offer the VAXUX1.MYCOM.COM?"
12	"what services offer the VAXUX1.MYCOM.COM?"

examples of an RQUERY for case (3 - USERS) are:

13	"do you know user *?"


examples of an RQUERY for case (4 - OTHERS) are:

14	"give me information about zz001 in the ZZ database!"

The RQUERY protocol itself does not offer a way to traslate these
questions in computer-readable format, but the RQUERY itself try to
offer a medium for an already traslated question to be sent over a
network, and a reply be obtained.



Dell'elce (125)						       [Page  3]
 
INTERNET-DRAFT	    	  Remote Query Protocol		     November 93


Table of contents


1.0 Status of this memo . . . . . . . . . . . . . . . . . . . . . . . . 1
2.0 Abstract. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
3.0 Reply examples  . . . . . . . . . . . . . . . . . . . . . . . . . . 5
    3.1 Affermative reply . . . . . . . . . . . . . . . . . . . . . . . 5
    3.2 Error reply . . . . . . . . . . . . . . . . . . . . . . . . . . 5
    3.3 Query-another . . . . . . . . . . . . . . . . . . . . . . . . . 5
    3.4 Mixed reply . . . . . . . . . . . . . . . . . . . . . . . . . . 5
4.0 Format of a RQUERY packet . . . . . . . . . . . . . . . . . . . . . 6
5.0 Description of RQUERY Packet  . . . . . . . . . . . . . . . . . . . 6
    5.1 Fields meanings . . . . . . . . . . . . . . . . . . . . . . . . 8
	5.1.1 ID  . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
	5.1.2 Type  . . . . . . . . . . . . . . . . . . . . . . . . . . 8
	5.1.3 Information required host . . . . . . . . . . . . . . . . 8
	5.1.4 Recursion . . . . . . . . . . . . . . . . . . . . . . . . 9
	5.1.5 Date or timestamp . . . . . . . . . . . . . . . . . . . . 9
	5.1.6 Priority  . . . . . . . . . . . . . . . . . . . . . . . . 9
	5.1.7 Target  . . . . . . . . . . . . . . . . . . . . . . . . . 9
	5.1.8 Query type  . . . . . . . . . . . . . . . . . . . . . . .10
	5.1.9 Sequence  . . . . . . . . . . . . . . . . . . . . . . . .10
	5.1.10 Owner  . . . . . . . . . . . . . . . . . . . . . . . . .10
   5.2 Strings format and types . . . . . . . . . . . . . . . . . . . .10
       5.2.1 String Types . . . . . . . . . . . . . . . . . . . . . . .11
   5.3 Datestamp format . . . . . . . . . . . . . . . . . . . . . . . .11
   5.4 Structure of the QUERY field . . . . . . . . . . . . . . . . . .12
6.0 Rquery errors numbers . . . . . . . . . . . . . . . . . . . . . . .12
    6.1 Eplanation of Error codes . . . . . . . . . . . . . . . . . . .13
	6.1.1 No recursion  . . . . . . . . . . . . . . . . . . . . . .13
	6.1.2 Bad Packet format . . . . . . . . . . . . . . . . . . . .13
	6.1.3 No information  . . . . . . . . . . . . . . . . . . . . .13
	6.1.4 Too vague query . . . . . . . . . . . . . . . . . . . . .13
	6.1.5 Packet time-of-send expired . . . . . . . . . . . . . . .13
	6.1.6 Temporarily not accepting queries . . . . . . . . . . . .13
	6.1.7 Special queries not supported . . . . . . . . . . . . . .14
	6.1.8 Too congested for Special queries . . . . . . . . . . . .14
	6.1.9 Can't solve question  . . . . . . . . . . . . . . . . . .14
	6.1.10 Rqueries unsupported . . . . . . . . . . . . . . . . . .14
7.0 Possible behaviors of Rquery resolver . . . . . . . . . . . . . . .15
    7.1 Caching of Rquery replies . . . . . . . . . . . . . . . . . . .15
8.0 Syntax resolving  . . . . . . . . . . . . . . . . . . . . . . . . .15
    8.1 Examples of solved queries  . . . . . . . . . . . . . . . . . .16
9.0 Rquery extensions . . . . . . . . . . . . . . . . . . . . . . . . .16
    9.1 Updating databases  . . . . . . . . . . . . . . . . . . . . . .17
10.0 Security or Authentication . . . . . . . . . . . . . . . . . . . .17
     10.1 The Simple Security Protocol  . . . . . . . . . . . . . . . .17
11.0 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . .17
12.0 Document Expiration  . . . . . . . . . . . . . . . . . . . . . . .17

Dell'elce (180)						        [Page 4]
 
INTERNET-DRAFT	    	  Remote Query Protocol		     November 93

2.0 Rquery Replies


There various ways a RQUERY may be replied:

(a)  Affermative reply: the host queried replied affermatively.
(b)  error reply: the host queried replied negativily.
(c)  query-another: the queried replies saying to query another host.
(d)  mixed reply: the host replies negatively saying to query another
     host. 

The reply packet will contain the same ID of the question which it is a
reply. 


2.1 Affermative reply

An affermative reply, is built by the queried host depending on the data
it can find in its databases, a way to keep information for replying to
rqueries can found among RQUERY extension, that must not be considered
$mandatory pert of the protocol, but just an $optional one.


2.2 Error reply

The negative reply is issued whenever the queried system doesn't have
information about the subject queried, couldn't find any data about the query,
does not support Rquery (in this case it will usually use a mixed-reply, see
2.4).

The Rquery error packet will contain just one field other than the Header, the
error string.


2.3 Query-another

This is a very important side of this protocol since it permits to
program (or to a user.


2.4 Mixed reply

Usually a mixed reply happens when the reply error contain an error
string plus the resend field stating a place where the query-sender.


Dell'elce (230)						       [Page  5]
 
INTERNET-DRAFT	    	  Remote Query Protocol		     November 93

3.0 Format of a RQUERY packet

The Rquery protocol should be used with any kind of underlying protocol.

Each string in the RQUERY protocol mast be a packet string i.e a string
with a byte (8-octet) header. Each string should be an UPPERCASE string,
whenever possible, since the query must be case-insensitive. The Rquery
strings are describe in section 4.2.

A graphical description of the Rquery packet follows in section 4.0.


4.0 Description of a Rquery Packet

The Header
                                                 1   1   1   1   1   1
         0   1   2   3   4   5   6   7   8   9   0   1   2   3   4   5
       +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
       |		I				D	       |
       +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
       |        	      S  e  q  u  e  n  c e		       |
       +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
       | Q   Q | H   H | R | D | P   P   P   P | O | T   T   T | S   S |
       +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
       |			     P  A  D			       |
       +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
       |							       |
       \			T I M E S T A M P		       \
       |							       |
       +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+





Dell'elce (269)						       [Page  6]
 
INTERNET-DRAFT	    	  Remote Query Protocol		     November 93

- Body of (a normal packet) packet:

       +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
       |							       |
       \			   O R I G I N			       \
       \		       ( O p t i o n a l )		       \
       |							       |
       +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
       |							       |
       \		    Q U E S T I N G  U S E R		       \
       \		       ( O p t i o n a l )		       \
       |							       |
       +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
       |							       |
       \			    H  O  S  T			       \
       |							       |
       +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
       |							       |
       \		     R E S O U R C E  T Y P E		       \
       |							       |
       +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
       |							       |
       \			     Q U E R Y			       \
       |							       |
       +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
       |							       |
       \			     R E P L Y			       \
       \		        ( O p t i o n a l )		       \
       |							       |
       +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
       |							       |
       \			   C O M M E N T		       \
       \		        ( O p t i o n a l )		       \
       |							       |
       +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+


						 1   1   1   1   1   1
	 0   1   2   3   4   5   6   7   8   9   0   1   2   3   4   5
       +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
       |		     R Q U E R Y  H E A D E R		       |
       +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
       |			     E R R O R			       |
       +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
       |							       |
       \			    H  O  S  T			       \
       \		        ( O p t i o n a l )		       \
       |							       |
       +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+

Dell'elce (323)						       [Page  7]
 
INTERNET-DRAFT	    	  Remote Query Protocol		     November 93

The fields: ORIGIN, QUESTING-USER are optional string-fields that
represent the querying user. The origin means the host where the user
generated the query.
The QUESTING-USER contains the name of the user. They might be useful
depending on the network, programs, the lower-level protocols used,
especially if they do not show specifically the sender of packet.


The fields HOST, RESOURCE-TYPE, QUERY, are all strings as described in
(), they represent, in the field 'host', the host of which information
is wanted, in the field resource-type, the kind of resource the system
is queried, in the field query, there is the core of the RQUERY.

The error packet type contains but the header only the error string.


4.1 Fields meanings

Following fields are graphically described in the section 4.0.
	

4.1.1 Identifier.

Identify a single RQUERY-Ask packet. It is originated by the sender.
Any reply to the query should have the same ID.


4.1.2 Type.

It is marked by QQ in the graphical description. This field describe the
type of format of the RQUERY packet Values:
	
	00 Ask packet
	01 Reply packet.
	10 Error packet.
	11 Extesion packet This last type is used when data received as
	   reply is longer more than the maximum size of a Rquery
	   packet. 


4.1.3 Information required host.
	
It is marked by HH in the graphical description. It points of which host
or hosts the query wants information Values:
	
	00 Host to which the RQUERY is sent.
	01 Only the host specified in the Host field.
	10 A Domain specified in the Host field.
	11 A List of host and domains Specified in the Host field.
	
Using "*" as a name of a system, Any system is meant..

Dell'elce (379)						       [Page  8]
 
INTERNET-DRAFT	    	  Remote Query Protocol		     November 93

4.1.4 Recursion.
	
It is marked by A in the graphical description. It says to the queried
host to send the question to other hosts in the case it can't reply to
or can't send a full reply to the query. Values:
	
	0  Don't send to other hosts.
	1  Send to other hosts or do recursion.
	

4.1.5 Date or timestamp.
	
It is marked D in the graphical description. If set it means that a
date/timestamp field is used to show to time the message is sent.
This field however refers to the timestamp which idicates when the query
has been generated.

Values:
	
	0  Timestamp is not used.
	1  Timestamp is used. It must be used if packet is of kind 00 or
	   11. 
	
	
4.1.6 Priority.
	
It is marked by PPPP (four bits) in the graphical description. It is
priority of the Rquery.

It is set by the sender according what the sender thinks may receive
as reply to the question. A RQUERY must have a lower priority if it
the data expected as a reply will be very long. Zero (0000) is the
highest priority meanwhile fifteen (1111) is the lowest priority.


4.1.7 Target.

The target of the query, what is the object of the query. It should be
of help to the Rquery-solver to do its work.

		000 services
		001 protocols
		010 hosts/domains
		011 <undefined>
		100 <undefined>
		101 <undefined>
		110 private convention query
		111 others

Dell'elce (432)						       [Page  9]
 
INTERNET-DRAFT	    	  Remote Query Protocol		     November 93


4.1.8 Special query-type

The meaning of this field is still to be defined.


4.1.9 Sequence

It is used to reconstruct message that was divided in several packets
(of course this field is only used when the lower level protocol doesn't
support message reconstruction, and when packet is so large that it must
be divided by the lower level protocol.

Recostruction of a message is done this way: The reconstruct must 'keep
in mind' the Sequence number and the ID number. All packets with same
ID, are part of the same message. Usually the need of a message
reconstruction will only needed if packets are part of reply.
 

4.1.10 Owner

It estabilishes who is the original sender of the query. It is set to 0
if the query is originated by another, otherwise it is set to 1, meaning
it is originated by the packet sender itself. This filed offers a faster
means to control who is the sender of the packet. The receiver of a
packet may not consider it 


4.2 Strings format and usage

With the term string is by represented a data container, which is used
to 'contain' information about either the question and the reply. By it
may be represented either normal ASCII string 
 a 1st byte is used a the
string-type field described in 4.2.1., than there is a size word, which
permits a size of the string of up to 65536 characters (the value 0 is
considered as 1). The strings in the RQUERY follow the header bitmaps
and may have any order, however they differ depending to the kind of
Rquery packet:

- A Rquery ask packet

The ASK packet has the Origin and Questing-user fields (optional),
which says who has sent the packet, for example a packet sent by
NOSEY@NOSEY-ALPHA.MYNET.MYCOM.COM, would have the Origin set as
"NOSEY-ALPHA.MYNET.MYCOM.COM" and the Questing user set as "NOSEY".
	
After these two optional fields comes the core of the ASK packet, comes
the core the packet the strings host, resource-type, query (see notes of
paragraph 4.0.).
	

Dell'elce (488)						       [Page 10]
 
INTERNET-DRAFT	    	  Remote Query Protocol		     November 93

4.2.1 String types

Types of strings in the Rquery protocol. This ID are places


String name		ID

Host			 1
Resource type		 2
Query			 3
Comment			 4
Origin			 5
Reply			 6
Questing user		 7
Security		 8
Timestamp		 9



4.3 Datestamp format

A datestamp is long 64 bits and divided in 4 equal fields, each is an
signless 16-bit word. The structure following is used alone in the
Rquery header and is 'ecapsulated' in the Timestamp string.


- It is the number of YEARs.

- It represents the number of DAYS.

- Each unit represents 15 seconds.

- The last word represents the WHY of the datestamp origin.


			    D  A  T  E  S  T  A  M  P

						 1   2   3   4   5   6
	 0   1   2   3   4   5   6   7   8   9   0   1   2   3   4   5
       +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
       |	 First word (Unsigned)	 	Number of Years.       |
       +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
       |	 Second	word (Unsigned) Number of Days.		       |
       +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
       |	 Third Word (Unsigned)  Numner of quarter of Minutes   |
       +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
       |	 Last word (Unsigned)   Why of datestamp origin	       |
       +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+


Dell'elce (542)						       [Page   ]
 
INTERNET-DRAFT	    	  Remote Query Protocol		     November 93

4.4 Structure of the QUERY field

The Query string-field follows a particular structure:
the first two bits in the first byte of the string,


		      0   1   2   3   4   5   6   7
		    +---+---+---+---+---+---+---+---+
		    |          <binary keys>        |
		    +---+---+---+---+---+---+---+---+
		    |	       <string keys>        |
		    +---+---+---+---+---+---+---+---+
		    |				    |
		    \		  K E Y S	    \
		    |				    |
		    +---+---+---+---+---+---+---+---+

The <binary-keys> field contains the number of keys of the question,
they are described in 8.0., and are a list 16-bits 'words'. The
<string-keys> is the number keys which is 


5.0 Errors

An error may happen for any $motif (see 5.1), the error field which is a
string as any other field is


List of Errors code numbers

Number		Error name

  1		No recursion
  2		Bad packet format
  3		No information
  4		Too vague query
  5		Packet time-of-send expired
  6		Temporarily not accepting queries
  7		Special queries not accepted
  8		Too congested for Special queries
  9		Can't solve question
 10		Rqueries unsupported




Dell'elce (592)						       [Page   ]
 
INTERNET-DRAFT	    	  Remote Query Protocol		     November 93

5.1 Eplanation of Error codes

5.1.1 No recursion

The query packet sent wanted recursion, but the replying host didn't
offer it, so an the server host had to sent back error of code 1.

5.1.2 Bad Packet format

The packet received by the replier was corrupt or strings of undefined
type. This error may happen when query had a 'private convention' that
the replier didn't know.

5.1.3 No information

No information was found or could be found about query sent.

5.1.4 Too vague query

The query sent may result in a too large reply that the replier does not
allow. This may be set accordingly to the server (replier) will, if the
replier is located in a low-bandwidth net, the reply may 'clog' the
network.

5.1.5 Packet time-of-send expired

The packet is too old, alas it has gone too much around the network too
be served, this error code must be used to save network bandwidth. The
error code may verify want the Recursion flag is set (this means that
the querying host wanted the query to be forwarded to other hosts and
doing so has reach the error-replying host too late for a reply).

5.1.6 Temporarily not accepting queries

The replying host is tempoararily not accepting Rqueries for any reason.

Dell'elce (635)						       [Page   ]
 
INTERNET-DRAFT	    	  Remote Query Protocol		     November 93

5.1.7 Special queries not supported.

The Rquery packet contains a query that can't be replied by the receiver
due to its kind.

5.1.8 Too congested for Special queries

The kind of query sent exceed the maximum that can be served due to the
many other being server.

5.1.9 Can't solve question

The time given iternally to any query to be 'solved' has finished. There
must be set a time-limit, for not consuming much system(proc)-time or for
the query to be replied too slowly.

5.1.10 Rqueries unsupported

This reply may be sent by a ``simple replier'' so to let know that it
does not offer Rquery and optionally query antoher system.



Dell'elce (665)						       [Page   ]
 
INTERNET-DRAFT	    	  Remote Query Protocol		     November 93

7.0 Possible behaviors of Rquery resolver

A program has't to know the way a Rquery-resolver treating its query,
but however it can trace the replies it has from that 'resolver', in
order to avoid unuseful duplication of datagrams in the network.

7.1 Caching Rquery replies

Sometimes maintaining an 'history' of the replies obtained to queries,
will permit a better forwarding of future queries. As avoiding send the
query to host that are unable to reply.

- Keeping note of forwarding-errors

A host may reply to the query by saying you to (r)query another host,
this may be kept aside since when processing another query may be of
help.

For example if in a domain, a host if used as the lone-in-domain Rquery
replier, and if you send a Rquery to system 'Z.LCS.ANY.EDU', i wil
probably say you: RQUERY is protocol unsupported, send RQUERY to
'RQS.ANY.EDU'. The local resolver should cache it and next time send the
query to 'RQS.ANY.EDU' then if necessary send it to 'Z.LCS.ANY.EDU'.

An example of caching:

host		pri	handled-by
Z.LCS.ANY.EDU	16	RQS.ANY.EDU

This is example is taken for the case of error 10 ('Rquery unsupported',
5.1.10). Future queries that wanted information about Z.LCS.ANY.EDU will
be send to RQS.ANY.EDU; Another feature that can be added to the caching
is a TTL field (time-to-live), the will contain the time (in seconds)
information about it is valid.
 
8.0 Syntax resolving

This how the question send through Rqueries must be solved.
This is a list of question keywords solved to a 16-octet word.

Syntax		Hexadecimal encoding	Syntax aliases

which		0001			
where		0002			
what		0003			who
do		0004			do you, do he, do it, and
					similar 

is		1001			
has		1002
know		1003			knows, is known to
offer		1004			offers, offering


Dell'elce (725)						       [Page 15]
 
INTERNET-DRAFT	    	  Remote Query Protocol		     November 93

8.1 Examples of solved queries.

Here are described some examples about traslating an ASCII query. The
RQUERY protocol must not offers a means for fully traslating an English
question into $binarized byte-string. It offers a set of traslation for
a not too varied set of question.


- ``do you know any host offering anonymous FTP?''

The right and full traslation of it following table of par. 9.0 is

- 0004 (do you)

- 1003 (know)

- ``FTP'' ``ANONYMOUS''

Note: that 'any host' is not traslated, it is not used this field, the
question field, but it is used in the HH field (see 4.1.3 the host
information wanted) in the header.

9.0 Rquery extensions

The RQUERY protocol itself doesn't offer many $tools (options .?) needed
for fully replying to Rqueries, such as the maintainance of databases
regarding possible replies, one the why of this behavior may be
determined by the variety of the kind of reply.


Dell'elce (759)						       [Page   ]
 
INTERNET-DRAFT	    	  Remote Query Protocol		     November 93

9.1 Updating databases

Given the nature of the Rquery protocol, no updating-protocol is
provided, but it would be very important to have a form of updating
databases that strictly regard the Rquery protocol.


10.0 Security or Authentication

The RQUERY protocol doesn't basically support security or authentication
due to the various kind of replies to queries that can be had and the
questions that can be sent.

However in the querying packet can be included a string (using format
shown in 4.2) that may include any security or authentication data has
two parts have convened.

10.1 The Simple Security Protocol (SSP)

The Simple Security Protocol (SSP) is a format specification of Security
string. Its purpose is to supply a simple but efficient means of
screening unauthorized queries to obtained. It is still to be defined.

11.0 Author's Address

   Antonio Dell'Elce
   V COLLI DELLA FONTE 53
   66030 FRISA CH
   ITALY

   Phone: +39-872-58430

   Email: tdnycal@DSIAQ1.ING.UNIVAQ.IT


12.0 Document Expiration

This document expires May 31, 1994











Dell'elce (812)						       [Page 17]


-----------[000122][next][prev][last][first]----------------------------------------------------
Date:      6 Dec 1993 22:53:12 GMT
From:      barmar@think.com (Barry Margolin)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP multibyte urgent data?

In article <CHL8M0.64J@cup.hp.com> mintz@cup.hp.com (Ken Mintz) writes:
>RFC1122 (sec. 4.2.2.4) requires the support of multibyte urgent data.
>
>How has anyone implemented this?
>
>The TCP protocol does not seem to support multibyte urgent data.  There is
>only a pointer to the last [*] urgent octet in a segment, but no pointer 
>to the first octet.
>
>   [*] Some implementations treat this as a pointer to the last+1 octet.
>
>Are we to assume that the urgent data extends to the first octet of that
>segment?  Are there implementations that ensure that urgent and non-urgent
>data are not mixed in a segment?

The TCP layer cannot assume anything about where the beginning of the
urgent data is, except that it is obviously no earlier than the beginning
of the segment the URG flag set.  As a result of datagram merging during
retransmission processing, it's quite possible for an urgent packet to be
merged with a preceding non-urgent packet.  The application protocol should
define how the beginning of the urgent data is recognized, if necessary.

Look at how TELNET uses urgent data for instance.  As soon as a system
receives a segment with the urgent flag set, it starts scanning the
incoming data for special characters.  In particular, see the last
paragraph of p.9 and p.10 of RFC 854, where the [IP, Synch] sequence is
described.  The IP character precedes the urgent segment, but the
expectation is that all the data that precedes the urgent pointer will be
forwarded, so the application is guaranteed to see the IP.

>Can we and how do we handle outbound urgent data that exceeds MSS?  Do you
>limit urgent data to MSS?  If so, how does the application learn,
>especially in view of Path MTU discovery algorithms (RFC1191)?

The TCP specification doesn't say that the urgent pointer has to point to a
character in the current datagram.  You can have a 500-octet segment
containing an urgent pointer of 1000; the following packet would presumably
be 500 octets and have an urgent pointer of 500.  Both packets would be
sent urgently.

>That is, it is up to the application protocol to identify the beginning and
>length of multibyte urgent data.

Yes.
-- 
Barry Margolin
System Manager, Thinking Machines Corp.

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

-----------[000123][next][prev][last][first]----------------------------------------------------
Date:      Mon, 6 Dec 1993 23:00:48 GMT
From:      lees@austin.ibm.com (Lee Slaughter)
To:        comp.protocols.tcp-ip
Subject:   BSD44 timed diffs

Would anyone have an idea if/who at Berkeley might keep a record of
diffs between current (BSD44) source (timed) and their older versions?
   (Actually a list of what's been fixed and changed, rather than an actual
   'diff' output.)
There doesn't appear to be any such thing with their source and it
is usually quite helpful to have a README file or some such with
the diffs, as other source I've seem seems to have.

Thanks.

lee slaughter
====================================================================
Lee Slaughter                      AIX RISC System/6000 Comm Support
11400 Burnet Road                  Austin, TX 78758              
e-mail: lees@austin.ibm.com        Phone: (512) 838-2817 TL 678-2817
====================================================================

-----------[000124][next][prev][last][first]----------------------------------------------------
Date:      Tue, 7 Dec 1993 00:43:34 GMT
From:      jonathan@CS.Stanford.EDU (Jonathan Stone)
To:        comp.protocols.tcp-ip
Cc:        jonathan@cs.stanford.EDU
Subject:   Source routing considered not-harmful?

gwright@world.std.com (Gary R Wright) writes:

>Assume:
>	Host A and B behind a router R.
>	Host C on the internet in front of router R.
>	R restricts incoming packets to those with an IP destination
>		address of A.
>	R doesn't pay attention to loose source routing.

Any such R is braindead. Sure, turn off LSRR through braindead
routers.  But routers don't *have* to be this braindead, surely?

Gary Wright continues:

>	When the packet arrives at R, it will have a destination address of
>		A which the router allows to pass.

Are any routers so stupid as to do this?  The packet in Gary's
example has a source route  _through_  A to *B*. The minimally correct
(that is, *necessary*, but not necessarily *sufficient*!) thing for a
packet-filtering router that implements the LSRR option) to do is to
apply its filter algorithm to the address `B'.  Not to the address A.

Is it *really* the case that firewalling routers
used to try and filter source-routed packets based  on the `next hop'
of the source route?  And that the response of the vendor community
to this `security hole' is to turn off source routing?
I find that hard to believe.

I'm asserting R can plausibly do either of the following:
	* Not honour source-routed packets, and toss any
	  source-routed packets in the bitbucket;
or
	* Understand (i.e., implement and honour) source routing,
	  but apply to addresses in source-routed packets ALL
	  the firewll address-filtering mechanism to the *final*
          point in the source-routed packet. Not the next hop address.
	  Plausibly, just plausibly, extremist router vendors
	  could offer configuration options to have firewall routers
	  filter *all* the not-yet-reached hops in a source route;
	  rejecting packets for which *any* hop in the source route
	  doesn't match the filter.  However, the typical uses
	  for source routing are `classic' IPmulticast tunneling
	  and `third-party' traceroute; and both *these* applications
	  only have one entry in a source route. Filtering
	  these packets doesn't seem unreasonably expensive.

I also assert that either of those options adds *no* new security
loopholes.  At least, I cannot see any; and I'd appreciate
any being pointed out to me.  I truly don't understand the
implicit assertion in this thread that only the first of these options
is viable.  If the second approach isn't feasible, I'd welcome an
explanation of *why*.

I can see that cpu cost might be an argumetn against this check.
But it's surely not on the common path.  Firewall implementations
usually also block out certain application-level protocols
(e.g., NFS), so they need to look at the IP header length to find
things like UDP port numbers.  If one's doing that, the
additional cost for packets with a longer-than-minimal IP header
lengh, and checking those packets for an LSSR option, and filtering
it, seems to me to be tolerable.

Perhaps the answer may boil down to ``our engineers have better
things to do.'' Fine, but *I* wouldn't buy a router from such a vendor.

And a sincere question: are people who use firewalls truly so paranoid
they don't want source-routed packets going through the IP module of
`hidden-behind-the-firewall'hosts without even passing up to user-level
on such hosts?   Besides, surely only hosts with forwarding turned on
(i.e., routers behind the firewall) would forward source-routed packets
in any case?

-Jonathan Stone
 Stanford DSG


-----------[000125][next][prev][last][first]----------------------------------------------------
Date:      Tue, 7 Dec 1993 04:06:25 GMT
From:      vjs@calcite.rhyolite.com (Vernon Schryver)
To:        comp.protocols.tcp-ip
Subject:   Re: BSD44 timed diffs

In article <CHMyLE.1Iyp@austin.ibm.com> lees@austin.ibm.com (Lee Slaughter) writes:
>Would anyone have an idea if/who at Berkeley might keep a record of
>diffs between current (BSD44) source (timed) and their older versions?
>   (Actually a list of what's been fixed and changed, rather than an actual
>   'diff' output.)
>There doesn't appear to be any such thing with their source and it
>is usually quite helpful to have a README file or some such with
>the diffs, as other source I've seem seems to have.

I don't know what actually appeared on any of the 4.4BSD tapes, but
there is a CHANGES file in vangogh:/usr/src/usr.bin/timed.

A slightly newer version of the timed source including that CHANGES file
is in sgi.com:sgi/src/timed.tar.Z.  I've noticed some people are mirroring
sgi.com, so it may be elsewhere as well.


Vernon Schryver    vjs@rhyolite.com

-----------[000126][next][prev][last][first]----------------------------------------------------
Date:      Tue, 7 Dec 1993 04:48:53 GMT
From:      ben@datacomm.ucc.okstate.edu (Ben James)
To:        comp.sys.novell,comp.protocols.tcp-ip
Subject:   Novell's Token.lan Driver doesn't work without route.nlm

I posted a message a few weeks ago about not being able to get TCPIP to work 
properly on a Netware 3.12 server after an upgrade from 3.11 .  

Here is a brief summary of the problem and a solution of sorts...

You may experience problems using The Token.Lan driver version 3.24 which comes
with NetWare 3.12.  It works fine for most things but when tring to do TCPIP on
Token-Ring Network through a NetBuilder II bridge the fileserver will ignore 
broadcast traffic with the destination of C000FFFFFFFF.  The Reason this 
presents a problem is the bridges will translate a packet with the address of 
FFFFFFFFFFFF into C000FFFFFFFF while bridging it from one media (ethernet,FDDI)
onto a Token-Ring port on our network.  I believe the C000FFFFFFFF represents 
a limited broadcast or multicast for Token-Ring and the Token.lan driver should
be paying attention to it.  Version 3.16 of the token.lan driver does not 
present this problem and seems to be an easy replacement for Version 3.24.

It seems as though novell has taken the multicast abilities out of their 
token.lan driver and put them in their route.nlm.  For most people this does 
not present a problem.  In our case the problem exists because we are on a 
Source Routing Transparent Network and we don't need and can't load the 
route.nlm.  The ability to easily switch back to Source Routeing has long since
passed so I guess were stuck with using the old version of token.lan for now and
possibly for life.

Just wanted everyone to know,
Ben James

P.S. I have not contacted novell with this problem.  Instead hopefully one of 
their dedicated employees will see this and follow up.

Ben James
ben@okway.okstate.edu
ben@datacomm.ucc.okstate.edu

-----------[000127][next][prev][last][first]----------------------------------------------------
Date:      Tue, 7 Dec 1993 06:45:43 GMT
From:      jarocki@dvorak.amd.com (John Jarocki)
To:        comp.dcom.lans.ethernet,comp.protocols.tcp-ip
Subject:   Re: port number question

In article <1993Dec1.144521.10812@jts.com>, Jim Carroll  <jimc@jts.com> wrote:
>I've been trying to sleuth a bandwidth usage problem and have
>come up with the following:
>
>- during normal business hours, upwards of 96% of the traffic
>is UDP;

And none of it NFS?

>- of this UDP traffic, the offending destination ports are:
>
>	1. 1022
>	2. 1021
>	3. 1020
>
>(sometimes 2 and 3 switch around, but 1 keeps top honours);
>
>- there is no mention of any of these ports in /etc/services.
>
>Would anybody have an idea what process(es) belong to these
>ports?

I've been wrestling with this same problem very recently and
I think I've just come up with answer answer -- thanks to a little
utility that is now even *more* useful to me than it was before.
The tool is "lsof" (list open files):

%> lsof -n
COMMAND     PID     USER   FD  TYPE     DEVICE     SIZE   INODE/NAME
nfsd        108     root    3  inet 0xff64938c              UDP *:2049
portmap      56     root    3  inet 0xff64478c              UDP *:1025
portmap      56     root    4  inet 0xff644b0c              UDP *:111
portmap      56     root    5  inet 0xff64490c              TCP *:111
...


Here's one location for it:

Host ftp.uu.net    (192.48.96.9)
Last updated 10:01 11 Nov 1993
 
    Location: /usenet/comp.sources.unix/volume25
      FILE    -rw-rw-r--   42266 bytes  00:00  2 Dec 1991  lsof.Z

>Also, can anybody recommend a free utility available on the
>Internet which:
>
>- is similar in function to Delft U.'s Beholder/Gobbler, but
>will run under SunOS (4.1.x);
>
>- can be ASCII, but X/Motif preferred;
>
>- can be similar to Sun's traffic tool, but will actually run
>under X/Motif.
>
>- can breakdown/filter traffic displays, display a frequency
>bar chart, whatever.

Have you tried xtr?  I've occasionally found it useful.  Archie
should be able to find it for you.

>SunOS 4.1.x functionality mandatory.  Will show interest
>in Solaris 2.x versions.
>
>I already have Curtin U's Etherman/Interman/Packetman, and
>the DOS tool ETHLD103.ZIP.  It was between these two that I
>was able to get this far.  Oh, some credit goes to nfswatch
>and etherfind.

You drive a hard bargain.  Those are two good toolsets. ;-)
Personally, I use NetMetrix for most of this stuff and like
it quite a bit.  But it doesn't meet your criteria of being
"free"; in fact it's quite expensive.

>Thanks for any info.
>-- 
>Jim Carroll   | If Jim Morrison drove his van to Van Morrison's gym,
>jimc@jts.com  | would Don Johnson use the john in Van Johnson's van?
>              |   - Charles Fleischer

cheers,
--john

-- 
John Jarocki - john.jarocki@amd.com

-----------[000128][next][prev][last][first]----------------------------------------------------
Date:      7 Dec 1993 11:23:30 -0000
From:      cudep@csv.warwick.ac.uk (Ian Dickinson)
To:        comp.windows.x,comp.sys.sun.misc,comp.protocols.tcp-ip,comp.unix.internals
Subject:   Re: Cannot accept chooser connection Software caused connection abort

I'm posting my own followup to a wider audience since I didn't even get
any "me too"s form the net (though another sysadmin on campus has had
identical problems but at a much lower frequency).

In article <2d299r$a8t@spatula.csv.warwick.ac.uk> I wrote:
>I'm having regular problems with MIT X11R5pl24 xdm running under SunOS4.1.3.
>The parent xdm daemon is eating up large amount of our machine.
>
>I'm getting a busy loop on WaitForSomething(), where select() returns
>showing the chooserFd to be set.  Once inside ProcessChooserSocket(),
>accept() fails on this fd, returns -1 and errno is set to "Software caused
>connection abort".  This isn't listed in the list of error returns in the
>accept man page.  ProcessChooserSocket() returns, and the select immediately
>returns with the same fd and the same problem, hence the busy loop.
>
>It looks like the code expects the pending connection to be cleared when
>accept() fails, but it doesn't appear to in this case.  I certainly don't
>see any Xterminals battering the machine to cause each loop.
>
>Here's the repeating part of an strace of the offending xdm:
>
>...
>select(6, fdset0:[ 4 5], 0, 0, (struct timeval *)0) = 1 (fdset0:[5])
>accept(5, 0xeffffa28, 1024) = -1 (Software caused connection abort)
>getpid() = 29667 ([ppid: 1])
>write(2, "error (pid 29667): ", 19) = 19
>write(2, "Cannot accept chooser connection".., 33) = 33
>...
>
>Anybody got any ideas on how I can fix this?
>There aren't any changes between the code I'm running and PL26.

Having further delved into the code, it seems that the chooserFd
should only be used (surprise, surprise) with the a chooser process
forked by the local instance of xdm.  Since we don't use CHOOSER
at all in our Xaccess files, it should never be called.  In fact,
it looks like the system is aborting the socket for some (unknown)
reason, and select is returning so the socket can be cleaned up.
Since I don't have a source license, and ECONNABORTED is undocumented
for these system calls, I'm at a loss as to how/why/when it is generated.

Since then I've been running with the following kludge:

*** choose.c.ORIG	Mon Aug 26 16:50:12 1991
--- choose.c	Fri Dec  3 15:22:53 1993
***************
*** 343,348 ****
--- 343,368 ----
      client_fd = accept (fd, buf, &len);
      if (client_fd == -1)
      {
+ #include <errno.h>
+ extern int chooserFd;
+ 	int tfd;
+ 
+ 	if (errno == ECONNABORTED) {
+ 	    debugLevel++;
+ 	    LogError("ECONNABORTED on chooser accept\n");
+ 	    shutdown(fd, 0);
+ 	    close(fd);
+ 	    tfd = socket (AF_INET, SOCK_STREAM, 0);
+ 	    Debug ("ReCreated chooser socket %d\n", tfd);
+ 	    if (tfd == -1)
+ 	    {
+ 		LogError ("chooser socket re-creation failed\n");
+ 		chooserFd = -1;
+ 	    }
+ 	    dup2(tfd, fd);
+ 	    listen (fd, 5);
+ 	    debugLevel--;
+ 	}
  	LogError ("Cannot accept chooser connection\n");
  	return;
      }

Anyone got any better ideas?
Am I on the right track?

Cheers,
-- 
Ian 'Vato' Dickinson - NIC handle: ID17                           Kibo bait :-)
cudep@csv.warwick.ac.uk  ...!uknet!warwick!cudep          ...!uknet!spuddy!vato
             MIME mail welcome - don't send me no steenkin' X.400
thesheerantiwarlordablenessofitalljustblewmyminduntiltherewasonlyteamlimpidleft

-----------[000129][next][prev][last][first]----------------------------------------------------
Date:      Tue, 7 Dec 1993 11:55:23 GMT
From:      rstevens@noao.edu (W. Richard Stevens)
To:        comp.protocols.tcp-ip
Subject:   Re: BSD 4.4 Networking code question

>  The latest issue of UNIX Review (Jan. '95, Vol. 12, No. 1) has an article
> on BSD4.4 by Kirk McKusick. Mr. McKusick mentioned in the "Networking
> Changes" section of the article:
>
>  "... In addition, the routing table stores and caches route characteristics
>   to speed the adaptation of the throughput and congestion-avoidance
>   algorithms."
>
>  I am interested in knowing what route characteristics did BSD 4.4
> deduce? And how did it obtain them?  Any references or pointers are much 
> appreciated.

Well, here is the structure of that information from the Net/2 release.
I just checked and the 4.4BSD structure is nearly identical.  Take a look
at the <net/route.h> file:

  /*
   * These numbers are used by reliable protocols for determining
   * retransmission behavior and are included in the routing structure.
   */
  struct rt_metrics {
          u_long  rmx_locks;      /* Kernel must leave these values alone */
          u_long  rmx_mtu;        /* MTU for this path */
          u_long  rmx_hopcount;   /* max hops expected */
          u_long  rmx_expire;     /* lifetime for route, e.g. redirect */
          u_long  rmx_recvpipe;   /* inbound delay-bandwith product */
          u_long  rmx_sendpipe;   /* outbound delay-bandwith product */
          u_long  rmx_ssthresh;   /* outbound gateway buffer limit */
          u_long  rmx_rtt;        /* estimated round trip time */
          u_long  rmx_rttvar;     /* estimated rtt variance */
  };

Here are the comments from the function tcp_close() in the file "netinet/
tcp_subr.c".  The values in the above structure can also be set by the
route(8) command.

        /*
         * If we sent enough data to get some meaningful characteristics,
         * save them in the routing entry.  'Enough' is arbitrarily
         * defined as the sendpipesize (default 4K) * 16.  This would
         * give us 16 rtt samples assuming we only get one sample per
         * window (the usual case on a long haul net).  16 samples is
         * enough for the srtt filter to converge to within 5% of the correct
         * value; fewer samples and we could save a very bogus rtt.
         *
         * Don't update the default route's characteristics and don't
         * update anything that the user "locked".
         */

Rich Stevens  (rstevens@noao.edu)

-----------[000130][next][prev][last][first]----------------------------------------------------
Date:      Tue, 7 Dec 1993 14:07:17 GMT
From:      mintz@cup.hp.com (Ken Mintz)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP multibyte urgent data?

Thank you for all the comments.  They confirm my conviction that the
interpretation of the beginning of multibyte urgent data is indeed left to
the application layer.  Therefore, it is easy to comply with RFC1122.

Thanks again.

-- Ken Mintz

PS:  There were references to "debates" last year or earlier.  If anyone has
a copy of the complete thread or can give me an approximate date, I would
appreciate the information.

-----------[000131][next][prev][last][first]----------------------------------------------------
Date:      Tue, 7 Dec 1993 14:37:35 GMT
From:      mintz@cup.hp.com (Ken Mintz)
To:        comp.protocols.tcp-ip
Subject:   IGMP == mrouted support?

From a technical standpoint, I know that IGMP support does not necessarily
imply kernel support for mrouted (host-based multicast forwarding), i.e.,
the DVMRP ioctls.

But my question is:  do most people think otherwise?  That is, when you
hear of a "fully compliant" multicast implementation with IGMP support,
do you ass-u-me that that includes support for mrouted?

(Are there any multicast implementations that do __not__ support mrouted?)

-- Ken Mintz (mintz@cup.hp.com)

-----------[000132][next][prev][last][first]----------------------------------------------------
Date:      Tue, 7 Dec 93 14:57:42 GMT
From:      pjmp@gec-rl-hrc.co.uk (Peter J M Polkinghorne)
To:        comp.protocols.tcp-ip
Subject:   BOOTP vendor info (RFC1084)

We are using BOOTP to distribute configuration information to a number
of PCs running various TCP/IP software.

We have two BOOTP servers - one Hellsoft running on a Novell file server
and one on a Sun, BOOTP 2.2.

They have differing behaviours: Hellsoft fills in the vendor area with a
RFC1084 information, even when the client had filled it with nulls.

BOOTP 2.2 can be forced to give the RFC1084 magic cookie, but never fills in
any info, unless the client asked for it. Checking the code reveals comments
to the effect: we could add in extra info, but do not.

Reading the RFCs leaves me completely unclear as to what the client is
supposed to do. It appears to allow both behaviours.

This is a pity, as bootp could in theory with RFC1084, give all the config
info required.

Any email replies will be summarised ... if sufficient.

--
Peter Polkinghorne,               Internet: pjmp@gec-rl-hrc.co.uk
GEC Hirst Research Centre,        JANET:    pjmp@uk.co.gec-rl-hrc
Elstree Way, Borehamwood,  "World is crazier and more of it than we think,
Herts. WD6 1RX ENGLAND     Incorrigibly plural" - Snow - Louis Macneice.

-----------[000133][next][prev][last][first]----------------------------------------------------
Date:      Tue, 7 Dec 1993 15:04:33 GMT
From:      john@iastate.edu (John Hascall)
To:        comp.protocols.tcp-ip
Subject:   Re: Crazy-whack telnet question!

trier@odin.ins.cwru.edu (Stephen C. Trier) writes:
}In article <2dpcsk$q9q@darkstar.ucsc.edu>,
}Thaddeus H. Wood <pustule@cats.ucsc.edu> wrote:
}>Greetings.  I would like to be able to communicate to a machine's
}>telnet port 23, but without having to deal with the IAC characters
}>or negotiation.  Is there a way to tell the remote telnet program
}>to just speak to me in plain old text mode?
 
}Nope.  If the machine is speaking telnet protocol, you need to speak
}telnet protocol back.  There is no way around it.
}It's not too hard to implement the minimum telnet protocol: Refuse
}every option the remote tries to negotiate.  That is perfectly legal.

   There is more to the telnet protocol than just option
   processing...

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

-----------[000134][next][prev][last][first]----------------------------------------------------
Date:      7 Dec 93 20:20:47
From:      ed@odi.com (Ed Schwalenberg)
To:        comp.protocols.tcp-ip,comp.unix.solaris
Subject:   Re: TLI, TCP, t_bind(), and AI

In article <1993Dec7.215404.2442@mdivax1.uucp> robinson@mdd.comm.mot.com (Jim Robinson) writes:
  attempting to bind a TCP endpoint to a port that is in use already as a
  'server' (i.e. someone has already bound to that port w/ qlen > 0). My
  question is why does t_bind() do this? If I wanted any random port I would
  have specified a request address of NULL. If I want port 6666, then that's
  what I want, not 32786. This seems to be a case of the system trying to do
  me a favour that I don't want. However, because it seems so blatantly
  wrong, I have to conclude that *I* am missing some important piece of the
  puzzle.
  -- 

It's a documented feature of TLI (not just the Solaris implementation) that
you have to check the returned port to confirm that it's the one you wanted.
Whether this "feature" is a good idea is a matter of opinion.

-----------[000135][next][prev][last][first]----------------------------------------------------
Date:      Tue, 7 Dec 1993 16:32:19 GMT
From:      Beberness@semail.jsc.nasa.gov (Beberness, Benjamin)
To:        comp.protocols.tcp-ip
Subject:   MacTCP compliant with BSD?

Is MacTCP compliant with BSD?  If not, is there a driver for the
Macintosh that is compliant?

-----------[000136][next][prev][last][first]----------------------------------------------------
Date:      Tue, 7 Dec 1993 17:35:23 GMT
From:      dirk@incom.de (Dirk Koeppen)
To:        comp.protocols.tcp-ip,comp.protocols.tcpip
Subject:   DHCP server

Hi,

does anybody know if someone is working on a DHCP server or if there is already  
one available ?

thanks,
dirk

--
                   Dirk Koeppen EDV-Beratungs-GmbH
            Holzwiesenweg 22 * D-63073 Offenbach * Germany
  Phone: +49 69 89 3000 * FAX: +49 69 89 3004 * email: dirk@incom.de

-----------[000137][next][prev][last][first]----------------------------------------------------
Date:      Tue, 7 Dec 1993 17:41:31 GMT
From:      donp@novell.com (don provan)
To:        comp.sys.novell,comp.protocols.tcp-ip
Subject:   Re: TCPIP with Netware 3.12 and 3Com NetBuilder 2

In article <1993Nov30.033159.18379@osuunx.ucc.okstate.edu> ben@datacomm.ucc.okstate.edu (Ben James) writes:
>I am currently working on a problem with a combination of a 3.12 server
>and a NetBuilderII Bridge.  The problem arose when I upgraded our 3.11 server
>to 3.12 and SAA 1.2 to SAA 1.3 .  Somewhere in the process I lost IP.  
>Everything is defined right and even works to a very limited extent.  The
>section of network of inportance is a NetBuilderII bridge/Router.  This 
>device has 3 Token-Ring Cards An FDDI Card and a few ethernet cards.  Before
>the upgrade I had no problems pinging back and forth between the ethernet and
>this server on Token-Ring.  I also never had a problem from any of the 
>stations on FDDI or one of the Other Token Rings.  Now our server is dead as
>far as IP is concerned.  IPX works great.

My best guess is that this has something to do with the token-ring
addresses being bit reversed from ethernet addresses, also known as
the "canonical" vs. "non-canonical" problem.  The old 3.11 token-ring
drivers just ignored this problem, but the newer drivers in NetWare
3.12 can be configured either way.  It may just be that they're
configured the wrong way for your environment.  Specifically, my guess
would be that they are configured to use canonical addressing, but
your environment is set up for MAC addresses on the token-ring network
to follow the old non-canonical practice.

Unfortunately this doesn't explain why IPX continues to work, but
perhaps that has something to do with your specific topology or some
behavior of the bridge that I don't understand.

So try configuring the NetWare 3.12 token-ring driver to use
non-canonical addresses and see if that helps any.  I'm afraid I don't
know exactly how to do that, but it should be spelled out fairly
clearly in the 3.12 manuals.

I hope this helps.  I've never myself seen a network bridged between
ethernet and token-ring, so I'm forced to try and imagine the
consequences, which makes my vision somewhat blurred...

						don provan
						donp@novell.com

-----------[000138][next][prev][last][first]----------------------------------------------------
Date:      Tue, 7 Dec 1993 18:06:56 GMT
From:      donp@novell.com (don provan)
To:        comp.protocols.tcp-ip
Subject:   Re: Source routing considered not-harmful?

In article <1993Dec7.004334.28161@CSD-NewsHost.Stanford.EDU> jonathan@CS.Stanford.EDU (Jonathan Stone) writes:
>Are any routers so stupid as to do this?  The packet in Gary's
>example has a source route  _through_  A to *B*. The minimally correct
>(that is, *necessary*, but not necessarily *sufficient*!) thing for a
>packet-filtering router that implements the LSRR option) to do is to
>apply its filter algorithm to the address `B'.  Not to the address A.

You have some very good points and I think your recommendation for
router behavior is sound and should be followed, etc., etc., etc.

At the same time, I'd like to point out that this specially trusted
host, A, is ultimately responsible for this security hole.  Why is
*it* forwarding source routed packets?  This is something like
limiting inbound Telnet access to A, but then having an anonymous
account on A that can Telnet out to any other machine within the
protected network.  If the trusted machine is going to present
outsiders uncontrolled access to other machines in the network, it's
probably not a very good choice for the secured point of contact.

						don provan
						donp@novell.com

-----------[000139][next][prev][last][first]----------------------------------------------------
Date:      Tue, 7 Dec 1993 19:51:13 GMT
From:      evansmp@mb48035.aston.ac.uk (Mark Evans)
To:        comp.dcom.lans.ethernet,comp.protocols.tcp-ip
Subject:   Re: port number question

Jim Carroll (jimc@jts.com) wrote:
: I've been trying to sleuth a bandwidth usage problem and have
: come up with the following:
 
: - during normal business hours, upwards of 96% of the traffic
: is UDP;
 
: - of this UDP traffic, the offending destination ports are:
 
: 	1. 1022
: 	2. 1021
: 	3. 1020
 
: (sometimes 2 and 3 switch around, but 1 keeps top honours);

It might help if you also looked at the destination and source
IP adresses.

: - there is no mention of any of these ports in /etc/services.
 
: Would anybody have an idea what process(es) belong to these
: ports?

These are reserved ports so the receiving process, if one 
exists is likely to be privilaged.
n.b. there need not be a receiving process.

-----------[000140][next][prev][last][first]----------------------------------------------------
Date:      Tue, 7 Dec 1993 21:04:26 GMT
From:      kannan@cs.ualberta.ca (Kannan Thiruvengadam)
To:        comp.protocols.tcp-ip
Subject:   Need for Connectionless protocols/services

The question is as direct as this :

"Is there any need for connectionless services/protocols ? Can we not just 
do with connection-oriented protocols/services ?"

How sensible is the above argument ?

-----------[000141][next][prev][last][first]----------------------------------------------------
Date:      Tue, 7 Dec 1993 21:05:58 GMT
From:      SYSNET@engvax.picker.com (Leonard A. Visconti)
To:        comp.protocols.tcp-ip
Subject:   Open IP address

Sorry if this is an FAQ.... Is the ip address 193.x.x.x assigned or is
it available to be used as a generic address for internal or non-public
networks? If not, is there an ip address that can be used as such? Thanks.




-------------------------------------------------------------------------------
|  Leonard A. Visconti 			Picker International                  |
|  Network Analyst			595 Miner Road			      |
|  visconti@picker.com			Highland Heights, Ohio  44143         |
|					(216)473-4801                         |
 -------------------------------------------------------------------------------

-----------[000142][next][prev][last][first]----------------------------------------------------
Date:      8 Dec 1993 11:12:54 -0800
From:      lstowell@pyrnova.mis.pyramid.com (Lon Stowell)
To:        comp.protocols.tcp-ip
Subject:   Re: XRemote

In article <1993Dec8.143450.1@mvax.uakom.sk> gajdos@uakom.cs (Peter Gajdos) writes:
>
>Does anybody know, where I could find description about XRemote protocol
>( ftp site, directory, etc. ) and exist any free software for DOS side,
>which work with XRemote ?

  If you are talking about the item trademarked as X-Remote, contact
  NCD.  


-----------[000143][next][prev][last][first]----------------------------------------------------
Date:      7 Dec 93 21:54:44 GMT
From:      robinson@mdd.comm.mot.com (Jim Robinson)
To:        comp.protocols.tcp-ip,comp.unix.solaris
Subject:   TLI, TCP, t_bind(), and AI

Under solaris 2.3 t_bind() will choose another address (port) when
attempting to bind a TCP endpoint to a port that is in use already as a
'server' (i.e. someone has already bound to that port w/ qlen > 0). My
question is why does t_bind() do this? If I wanted any random port I would
have specified a request address of NULL. If I want port 6666, then that's
what I want, not 32786. This seems to be a case of the system trying to do
me a favour that I don't want. However, because it seems so blatantly
wrong, I have to conclude that *I* am missing some important piece of the
puzzle.
-- 
Jim Robinson
robinson@mdd.comm.mot.com
{ubc-cs!van-bc,uunet}!mdivax1!robinson


-----------[000144][next][prev][last][first]----------------------------------------------------
Date:      7 Dec 1993 22:20:29 GMT
From:      dkschubr@vela.acs.oakland.edu (dkschubr)
To:        comp.protocols.tcp-ip
Subject:   CLNS

Can anyone out there give me any information pertaining
to acquiring 32 byte TCP/IP addresses?

I would like to implement and test this out in the near
future.

send responses to dkschubr@vela.acs.oakland.edu
Thanks.
-- 
_______________________________________________________________
_______________________________________________________________
                     Dave Schubring
               dkschubr@vela.acs.oakland.edu

-----------[000145][next][prev][last][first]----------------------------------------------------
Date:      Tue, 7 Dec 1993 22:33:43 GMT
From:      k2@bl.physik.tu-muenchen.de (Klaus Steinberger)
To:        comp.protocols.tcp-ip
Subject:   Re: Domain Name Servers

cooker@ci.ua.pt (Fernando Cozinheiro) writes:

>I have heard some references abou two different Name Servers: Domain Name
>Servers and IEN-116. We have an old terminal server that includes on its

IEN-116 was not very widely used, and is not in use anywhere as I know.
It doesn't fit actual needs. The Domain Name Service (DNS) is the right
one.

Sincerely,
Klaus
--
Klaus Steinberger               Beschleunigerlabor der TU und LMU Muenchen
Phone: (+49 89)3209 4287        Hochschulgelaende
FAX:   (+49 89)3209 4280        D-85748 Garching, Germany
Internet: Klaus.Steinberger@Physik.Uni-Muenchen.DE

-----------[000146][next][prev][last][first]----------------------------------------------------
Date:      7 Dec 1993 22:48:58 GMT
From:      fgs@kepler.unh.edu ( F r e D  S l a m A )
To:        comp.protocols.tcp-ip
Subject:   Obtaining netmask from a c program


	How does one obtain the netmask from a host from with-in a C
	program? Not the broadcast... but the netmask...

	-Fred
-- 
 ===============================================================================
 Frederick G. Slama at >>>>>>>>>>>>>| slama@ctron.com
 The University of New Hampshire <<<| fgs@kepler.unh.edu   F_SLAMA@unhh.unh.edu
 ===============================================================================

-----------[000147][next][prev][last][first]----------------------------------------------------
Date:      Wed, 8 Dec 1993 00:50:08 GMT
From:      mintz@cup.hp.com (Ken Mintz)
To:        comp.protocols.tcp-ip
Subject:   Re: Obtaining netmask from a c program

F r e D  S l a m A (fgs@kepler.unh.edu) writes:
> How does one obtain the netmask from a host from with-in a C
> program? Not the broadcast... but the netmask...

  Well, this __will__ depend on the API you are using.  Below is a BSD
  implementation.

-- Ken Mintz

#include <sys/types.h>
#include <sys/socket.h>
#include <sys/ioctl.h>
#include <net/if.h>
struct ifreq ifr;
int s;
char name[IFNAMSIZ];

strcpy(name, "lan0");  /* usually input, e.g. from the command line */

s = socket(AF_INET, SOCK_DGRAM, 0);
memcpy(ifr.ifr_name, name, sizeof(ifr.ifr_name));
ioctl(s, SIOCGIFNETMASK, (caddr_t)&ifr);
printf("%s\n", inet_ntoa(((struct sockaddr_in*)&ifr.ifr_addr)->sin_addr));

-----------[000148][next][prev][last][first]----------------------------------------------------
Date:      Wed, 8 Dec 1993 01:05:06 GMT
From:      c.oneill@trl.oz.au (Chris O'Neill)
To:        comp.protocols.tcp-ip
Subject:   Re: BSD 4.4 Networking code question

In article <2e15bbINNl96@excalibur.cs.purdue.edu> lin@cs.purdue.edu (John
Chueng-Hsien Lin) writes:
>  The latest issue of UNIX Review (Jan. '95, Vol. 12, No. 1) has an article
>on BSD4.4 by Kirk McKusick. Mr. McKusick mentioned in the "Networking
>Changes" section of the article:
>
>  "... In addition, the routing table stores and caches route characteristics
>   to speed the adaptation of the throughput and congestion-avoidance
>   algorithms."
>
>  I am interested in knowing what route characteristics did BSD 4.4
>deduce? And how did it obtain them?  Any references or pointers are much 
>appreciated.

I'd also be interested in knowing how the route charateristics are used "to
speed the adaptation of the throughput and congestion-avoidance algorithms". 
Especially considering that Van Jacobson's congestion-avoidance algorithms do
not use any such stored information.  Hence any new approach that makes use of
such stored information would be substantially different from Van Jacobson's
algorithms and ought to be well-publicised.

Chris O'Neill
Telecom Australia Research Labs

-----------[000149][next][prev][last][first]----------------------------------------------------
Date:      Wed, 8 Dec 1993 01:47:40 GMT
From:      jonathan@CS.Stanford.EDU (Jonathan Stone)
To:        comp.protocols.tcp-ip
Subject:   Re: IGMP == mrouted support?

>But my question is:  do most people think otherwise?  That is, when you
>hear of a "fully compliant" multicast implementation with IGMP support,
>do you ass-u-me that that includes support for mrouted?

Personally, I don't so assume.  Steve Deering's opinion would have
to be the authoritative one, though.  IGMP is a protocol
whereby an IP-multicast capable host, call it H,informs the local
IPmulticast router, R of H's membership in various groups.
It's up to H to do the appropriate routing to deliver IPmulticast
packets to and from the local net H and R share.  H can be either
a `real' router (a multihomed host that does IP forwarding)
or a ``proxy'' router (a single-homed host that tunnels IPmulticast
traffic through deficient, non-multicast capable routers, to
another proxy.)

`mrouted' is just one method of providing a multicast proxy.
Currently it's the *only* way of forwarding multicast traffic.
Come the  Millenium, router vendors may agree on a routing algorithm 
that can be run on the routers, rather than on proxy hosts via mrouted.
Until then, if you want to send or recieve IPmulticast
traffic to or from a host off your local subnet, you need
need *one* proxy  multicast router on your local net. But that
doesn't mean *all* multicast hosts on the local subnet need to,
or should be capable of, running mrouted.

>(Are there any multicast implementations that do __not__ support
> mrouted?)

The short answer is ``yes, and there will be more in the future.''
OSPF-capable routers need to join the ``all local routers''
multicast group, in order to negotiate primary and secondary
OSPF routers for their attached subnets. Such routers do not
support mrouted -- or at least they didn't two years ago.
FTP, Inc's PC-TCP (or whatever the trademark is) would be a good
candidate for an end-host IPMulticast implementation that did not
support mrouted. A release supporting IPmulticast was due out Dec 1.
MacTCP 3.0, when and if it appears, should be another candidate.

The long answer is: Gregorio.Stanford.EDU has Steve Deering's
IPmulticast distributions for SunOS 4.1.x, and Ultrix 4.1 and 4.2,
in both source and binary-distribution forms. Both these distributions
include mrouted support, though the  Ultrix code is a year old, and 
still only supports LSSR tunnelling, not IP-in-IP tunneling. LSRR 
tunneling is more expensive on at least one popular router than IP-in-IP
tunneling.  I understand 4.4BSD also supports ipmulticast.

Irix 4.0.5 includes IPmulticast *and* an old-style-tunneling
mrouted.  That's the only vendor implementation I know of for sure.

I've never seen a Solaris prompt, but Solaris 2.x reputedly
includes IPmulticast. HP internal sources have `promised' support for
IPmulticast would be in every version of HP-UX since 8.0 (inclusive);
I'm not sure, but I think they're still promising.


-----------[000150][next][prev][last][first]----------------------------------------------------
Date:      Wed, 8 Dec 1993 04:59:40 GMT
From:      vjs@calcite.rhyolite.com (Vernon Schryver)
To:        comp.protocols.tcp-ip
Subject:   Re: Open IP address

In article <1993Dec7.210558.909@picker.com> SYSNET@engvax.picker.com (Leonard A. Visconti) writes:
>Sorry if this is an FAQ.... Is the ip address 193.x.x.x assigned or is
>it available to be used as a generic address for internal or non-public
>networks? If not, is there an ip address that can be used as such? Thanks.

192.0.2.x has been officially assigned for such purposes.

Check the "Assigned Numbers" RFC for authority.


Vernon Schryver    vjs@rhyolite.com

-----------[000151][next][prev][last][first]----------------------------------------------------
Date:      8 Dec 93 17:04:17 -0500
From:      glazer@ohstpy.mps.ohio-state.edu (JON GLAZER)
To:        comp.protocols.ppp,comp.protocols.tcp-ip
Subject:   wierd problem with KA9Q.

I am using a rather recent version of DIS KA9Q that supports PPP.  I am using
it as a PPP router to my internet provider and my own lan.  I am also using it
as an SMTP gateway.  Now all of this works fine.  The problem is that I I have
an FTP server elsewhere on the network (a bit nicer than the one in KA9Q).  I'd
like to make this public.  The server works fantastic over the local network
but when you try to connect to it from the internet, you get the usuall User:
and Pass: prompts and you can enter the info, but then it hangs.  The FTP
server says somone logged in but that someone is not doing anything.

I believe this is a KA9Q problem.  I have seen a couple of problems when TCP/IP
traffic originates from more than one location simulataneously.  Don't know if
that's a key but it could be.  Does anyone have any clues?

Thanks,
Jon


-----------[000152][next][prev][last][first]----------------------------------------------------
Date:      Wed, 8 Dec 1993 14:47:02
From:      tcoy@umi.com (Todd A. Coy)
To:        comp.protocols.tcp-ip
Subject:   Shareware NFS software

I am looking for any Public Domain type of software for the PC that will allow 
the mounting of a Unix boxes PCNFSD drive.  

Please resond to tcoy@umi.com

Thanx  

--Todd

-----------[000153][next][prev][last][first]----------------------------------------------------
Date:      08 Dec 1993 11:05:13 GMT
From:      droms@sol.cs.bucknell.edu (Ralph E. Droms)
To:        comp.protocols.tcp-ip,comp.protocols.tcpip
Subject:   Re: DHCP server

In article <CHoE71.6Ku@dksoft.incom.de> dirk@incom.de (Dirk Koeppen) writes:

   does anybody know if someone is working on a DHCP server or if there is already  
   one available ?

From the notes of the last IETF FHCP WG meeting, here is a list of
participants in the most recent DHCP interoperability test:

   J. Allard and Fred  Lien organized two  rounds of interoperability  testing.
   At the second round of testing, 7 servers and 12 clients were tested:

     o Microsoft:  NT server, NT client, DOS client
     o Sun:  server and client
     o HP: client
     o Boeing:  server and client
     o DEC: client
     o WIDE project (Japan):  client, server and relay agent
     o SGI: server and client
     o Competitive Automation:  server and client
     o FTP Software:  Windows and OS/2 servers, Windows and DOS clients

   At present, there are  no freely--distributable implementations.   The  WIDE
   project's implementation, described in a  short presentation to the WG,  may
   be made available, but needs additional work first.

The mailing list for DHCP-related discussion is
host-conf@sol.cs.bucknell.edu.

--
- Ralph Droms                 Co-Director, Computer Services
  droms@bucknell.edu          Associate Professor of Computer Science
  (717) 524-1801              Bucknell University
  (717) 524-3760 (fax)        Lewisburg, PA 17837

-----------[000154][next][prev][last][first]----------------------------------------------------
Date:      Wed, 8 Dec 1993 12:27:00 GMT
From:      ketil@edb.tih.no (Ketil Albertsen,TIH)
To:        comp.protocols.tcp-ip
Subject:   Re: Need for Connectionless protocols/services

In article <2e3r17$2gv@dingo.cc.uq.oz.au>, ggm@dingo.cc.uq.oz.au (George Michaelson) writes:


In article <2e3r17$2gv@dingo.cc.uq.oz.au>, ggm@dingo.cc.uq.oz.au (George Michaelson) writes:

[...  (Can we make due with CO services/protocols only?)]

>>How sensible is the above argument ?
>
>Well I think not very. Consider one-way communication channels for
>instance. How do you intend running a connected service with no
>back-packetflow?

Couldn't the original request also be modified to: Is there any 
absolute need for one-way communication channels?

You seem to take for granted that there is an absolute such need, hence 
for connectionless services/protocols. But is there any application that 
cannot be realized with two-way channels?

(Note that in any virtual circuit -oriented CO protocol, there is no
need to transmit a single byte in the opposite direction after connection
establishment.)

>How do you run connection-oriented multicasting 1:many and why is it
>'better' than datagram multicasting?

That's not hard to do with analog data; it is called phone conferencing.
The same idea can easily be applied to digital communication.

Having >1 talker makes it somewhat more difficult (in particular when
you don't have the human intelligence presumably present in a voice
phone conference to sort out various info), but the idea of tokens
are certainly not new in the data communication world.

Notice that >1 talker is a functional extension to CL multicasting;
to emulate conferencing in a CL environment, external functions are
required for organizing n 1:n one-way multicasts so that they look 
like one coordinated n:n conference.

-----------[000155][next][prev][last][first]----------------------------------------------------
Date:      Wed, 8 Dec 1993 13:42:25 GMT
From:      atkinson@itd.nrl.navy.mil (Ran Atkinson)
To:        comp.protocols.tcp-ip
Subject:   Re: IGMP == mrouted support?

In article <1993Dec8.014740.19958@CSD-NewsHost.Stanford.EDU> jonathan@CS.Stanford.EDU (Jonathan Stone) writes:

>`mrouted' is just one method of providing a multicast proxy.
>Currently it's the *only* way of forwarding multicast traffic.

  For this reason, in the short term, we expect all multicast capable
hosts to be supplied with an mrouted(8) that uses the most recent
tunnelling technology on gregorio.stanford.edu.  In the long term,
mrouted(8) clearly won't be needed and will fade out.

>Come the  Millenium, router vendors may agree on a routing algorithm 
>that can be run on the routers, rather than on proxy hosts via mrouted.

  There are two primary contenders for standard multicast routing
protocol at this point, both of which are reportedly being implemented
by (different) major router vendors.  Both are being worked on by the
IETF and so will be fully open specs. Proteon is reportedly _shipping_
Multicast-OSPF today.  I know of more than one vendor that is building
a PIM/ESL implementation.  I personally favour M-OSPF, but mainly
because we use OSPF locally and an integrated solution is attractive
from an administrative point of view.

>FTP, Inc's PC-TCP (or whatever the trademark is) would be a good
>candidate for an end-host IPMulticast implementation that did not
>support mrouted. A release supporting IPmulticast was due out Dec 1.

	But gee it sure would be good to have the capability of
setting up a PC as a low-rent mrouter, particularly for smaller
PC-oriented sites.

>MacTCP 3.0, when and if it appears, should be another candidate.

	It isn't clear that MacTCP 3.0 will support IP Multicasting.
IMHO, MacTCP should already support IP Multicasting but Apple seems to
be behind on this.  The omission is surprising since the new A/V Macs
could really take advantage of the multicast technology.

>I understand 4.4BSD also supports ipmulticast.

Yes. I am also told this, though I haven't seen 4.4 BSD sources yet.

>Irix 4.0.5 includes IPmulticast *and* an old-style-tunneling
>mrouted.  That's the only vendor implementation I know of for sure.

The newer tunnelling is available at no cost from an SGI anonymous
ftp site, probably as unsupported software, but it reportedly works.

>I've never seen a Solaris prompt, but Solaris 2.x reputedly
>includes IPmulticast. 

Yes.  Solaris 2.x does support IP multicast.  

DEC's OSF/1 for the Alpha cpu also supports IP multicast.

>HP internal sources have `promised' support for IPmulticast would be 
>in every version of HP-UX since 8.0 (inclusive); I'm not sure, 
>but I think they're still promising.

Accurate description.  The most recent data is that HP internal sources
now say that IP multicasting might appear in HPUX 10.x.  HP is usually
behind the times in networking technology, so this is no surprise.

However, a set of kernel patches to add multicasting to HPUX 8.x, made
by someone else, are floating around the net (perhaps in Sweden ?).
Hack kernels at your own risk.  The HPUX kernel seems pretty fragile
in our experience.

Ran
atkinson@itd.nrl.navy.mil

-----------[000156][next][prev][last][first]----------------------------------------------------
Date:      Wed, 8 Dec 1993 13:44:32 GMT
From:      giani@YorkU.CA
To:        comp.protocols.tcp-ip
Subject:   Has anybody heard anything about Zinc Protocol...

Hi everybody,

I am looking for somw info about the Zinc protocol. 

Any help will be greatly appreciated.

Thanks,

Ioannis at : giani@yorku.ca


-----------[000157][next][prev][last][first]----------------------------------------------------
Date:      Wed, 8 Dec 1993 13:51:52 GMT
From:      nguyen@PHUONG.raleigh.ibm.com (Phuong Thanh Nguyen)
To:        comp.protocols.tcp-ip
Subject:   Re: Obtaining netmask from a c program

In article <2e318q$g6l@mozz.unh.edu>, fgs@kepler.unh.edu ( F r e D  S l a m A ) writes:
|> 
|> 	How does one obtain the netmask from a host from with-in a C
|> 	program? Not the broadcast... but the netmask...
|> 
|> 	-Fred
|> -- 
You can do it easily by open an ICMP socket, turn the MASK REQUEST on
and send it to the host you want.  The host will reply back with its
mask address.  Pay attention on network bytes and host bytes.

Phuong Nguyen
|>  ===============================================================================
|>  Frederick G. Slama at >>>>>>>>>>>>>| slama@ctron.com
|>  The University of New Hampshire <<<| fgs@kepler.unh.edu   F_SLAMA@unhh.unh.edu
|>  ===============================================================================
 
-- 
--------------------------------------------------------------------------
| Disclaimer: My opinions and IBM's are two different entities           |
| Hope you have a "phuongtastic" day      PNGUYEN@VNET.IBM.COM           |
--------------------------------------------------------------------------

-----------[000158][next][prev][last][first]----------------------------------------------------
Date:      Wed, 08 Dec 93 13:56:49 GMT
From:      amdunn@mongrel.adscorp.on.ca (Andrew M. Dunn)
To:        comp.protocols.tcp-ip
Subject:   inetd.spawn info


When inetd spawns a daemon (listed in inetd.conf) what is the best
way for the daemon to get information on who or what connected (ie.
IP address, host, port #, etc).

Or _is_ there a way at all?

The daemon can be rather naive, otherwise, and merrily consume
stdin and spew stdout, but 'twould be useful to find out the
kind of information it'd get if it'd done the listen/connect/accept
sequence itself.

FYI, _I'm_ trying to do this on SCO Unix 3.2v4.2, with SCO
TCP/IP 1.2, but general-case answers are desired as well.


Plz reply by e-mail and I'll summarize and post the summary
(it's more reliable that way <grin>)


Andy

-- 
   Andy Dunn           <amdunn@adscorp.on.ca> or <uunet!mongrel!amdunn>    
:-------------------------------------------------------------------------:
   "For people who know Chuck and Di -- but think it's what you do when    
    you eat a bad sausage"  Labatt's Blue Light billboard advertisement.

-----------[000159][next][prev][last][first]----------------------------------------------------
Date:      Wed, 8 Dec 93 15:26:12 GMT
From:      ploeger@aplki.toppoint.de (Andreas Ploeger)
To:        comp.protocols.tcp-ip
Subject:   Mac NCSA Telnet 2.5 using SLIP

Hi,

I'm trying to set up NCSA Telnet for the Mac using SLIP and can't get it to  
work.

Trouble starts with the entry hardware=Serial in the config.tel file: At  
startup this leads to an error message.

Could someone please send me his configuration files?

Thanks,

Andreas
-- 

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

Andreas Ploeger                      E-Mail: ploeger@tpki.toppoint.de

-----------[000160][next][prev][last][first]----------------------------------------------------
Date:      Wed, 8 Dec 1993 16:05:32 GMT
From:      Philipp_Huber@hpber002.swiss.hp.com (Philipp Huber)
To:        comp.protocols.tcp-ip
Subject:   FTP server for LM 2.2 of Microsoft

Hallo,

has anybody of you seen an FTP implementation on  LM 2.2 of Microsoft with
OS/2 1.3.1?

Any hints are appreciated.

regards,
Philipp Huber

Philipp_Huber@HP8700.desk.hp.com                      HP Switzerland
c=ch admd=arcom prmd=hp orgn=hp orgu=hp8700  Response Center - Network Team
Tele  : +41 31 980 32 48                                            Meriedweg 11              
Fax   : +41 31 980 33 90                                            CH-3172 Niederwangen

-----------[000161][next][prev][last][first]----------------------------------------------------
Date:      8 Dec 93 14:34:49 +0100
From:      gajdos@uakom.cs (Peter Gajdos)
To:        comp.protocols.tcp-ip
Subject:   XRemote

Hi,

Does anybody know, where I could find description about XRemote protocol
( ftp site, directory, etc. ) and exist any free software for DOS side,
which work with XRemote ?

If You know it, please e-mail me.

--Peter Gajdos

-----------[000162][next][prev][last][first]----------------------------------------------------
Date:      Wed, 8 Dec 1993 18:15:40 GMT
From:      albertk@cs.kun.nl (Albert Koppes)
To:        comp.protocols.tcp-ip
Subject:   PPP, satellite, extended window and VXWorks

As a followup to previous questions in this group, a more detailed
question about PPP over satellite.


Our future architecture: 

We have two hosts A and B:

One host A, a VME based processor running TCP/IP under 
VxWork.

The other host B , a VAX station running TCP/IP for OpenVMS.


Host A and B will communicate via a satellite link of 1 Mbps, and
will use about 10 TCP connections simultaneously.
We will be using PPP. 
Some of the TCP connections need to transfer data at a speed up to 200kbps, 
almost reaching the critical 10**5 bandwith*delay product. 


1. What is your opinion about the need for us to use extended window sizes ? 
The satellite link is supposed to have a BER of 10**(-7,-8).
 
2. Is anybody familiar with any implementation of extended windowsizes according to
RFC 1323 (or window scaling)  under VxWorks ?


3. Has somebody used PPP Protocol Field Compression and Address/Control Field
compression on such high speed links ? 


Thanks in advance for all suggestions and answers.
A summary will be provided to all interested.



Frank Zeppenfeldt
EUMETSAT
Germany



-----------[000163][next][prev][last][first]----------------------------------------------------
Date:      Wed, 8 Dec 1993 19:07:18 GMT
From:      mbennett@netcom.com (Michael Bennett)
To:        comp.protocols.tcp-ip
Subject:   POSIX (1003.12) compliant TCP/IP Applications

Does anyone know of any efforts in progress to provide 1003.12 compliant TCP/IP applications (ie, FTP/FTPD/TELNET/TELNETD,etc).  Any repository or associated pointers would be greatly appreciated.

Thanks..   
---------------------------------------------------------------





-----------[000164][next][prev][last][first]----------------------------------------------------
Date:      Wed, 8 Dec 93 19:22:27 GMT
From:      mmccarri@physics.ucla.edu (Mike McCarrick)
To:        comp.protocols.tcp-ip
Subject:   hung CLOSE_WAITs on my Sun

Hi,

If I use netstat to check the socket status on my Sparc 10, I frequently
see a number of connections hung in the CLOSE_WAIT state. These
are typically pop3 or telnet connections from a remote pc. The hung
connections stay around for many days, even though the pc has come
back up and is connected again with a new socket. Can anyone shed
light on what may be causing the socket to remain in the CLOSE_WAIT
state and what I can do to clean things up?  

Thanks,
Mike

-- 
Dr. Michael McCarrick                   UCLA Department of Physics
Plasma Physics Lab                              405 Hilgard Avenue
mmccarri@physics.ucla.edu                    Los Angeles, CA 90024

-----------[000165][next][prev][last][first]----------------------------------------------------
Date:      8 Dec 93 22:06:03 GMT
From:      mills@athena.tay.dec.com (George Mills)
To:        comp.protocols.tcp-ip
Subject:   PCs and pings (a dreadfull combination)

We've learned the hard way that PC's dislike being pinged.
The PC pauses like mad (sometimes crashes) when it is pinged.

Now that the hotest things these days is automated network topoligy
systems (NetView 6000), the PC's are hurting.

Our current TCP-IP vender for PCs is PC-NFS. I wonder if folks
perhaps running (FTP's, B&W's, Novell's, or PC-NFS) have seen this
problem also. We are using drivers NDIS drivers.

It's seems most vulnerable while the PC is doing heavy NFS traffic
and hit by several pings while in Windows.

Any Ideas on how to deal with this?


-----------[000166][next][prev][last][first]----------------------------------------------------
Date:      9 Dec 93 00:07:32 GMT
From:      jc@minya.UUCP (John Chambers)
To:        comp.protocols.tcp-ip
Subject:   Re: "large security gap in the Internet"


Independently of all the discussion so far, I'd suggest that  one  way
to  deal with Yet Another Fuss over sendmail is to ask a question that
is perhaps on the verge of being rhetorical in nature:

  If someone were to suggest that you install a new shell  program  on
  your  computer  which  runs  with  root  permissions and requires no
  password from remote users logging in, would you install it?
 
Most people would instantly answer "Of course  not."  They  might  add
something like "Are you crazy or something?" But the above question is
actually a fairly accurate description of sendmail.

The best way to handle sendmail is to first install a good mailer, and
then run the command:
  find .  -name 'sendmail*' -exec /bin/rm -f {} ';'
 
 - - -
 
For those who need further explication ...


(1) sendmail is a shell.  It talks in ASCII to anyone who knows how to
connect to its TCP port (25). Like any shell, it accepts commands, and
it does them.  If you'd like to test this, first get a transcript of a
sendmail  session  by  sending mail to someone (perhaps yourself) on a
nearby machine with verbosity enabled, via a command such as:
  mail -v foo@bar
where foo and bar are some appropriate strings.  This will show you  a
sendmail  session, with initial capitalized 4-byte upper-case commands
in sendmail's "command language".  Next, connect to the machine's smtp
port yourself:
  telnet bar 25
When  you  get the connected message, type the commands that the "mail
-v" command showed you. You should get the same behavior.  It will ask
you to enter the message, ending with a "." line, and you can send any
message that you like at this point just by typing it.

I've used this on occasion to demo that I can use sendmail  to  "fake"
email  from  an arbitrary source.  You wouldn't believe how upset this
gets the average user of email.

You might object "But even if sendmail is  a  shell,  it  has  a  very
resetrictive command set." What you perhaps don't know is that not all
of its commands are documented. And among the ones that are documented
are ways of doing remote executions of other programs. Unless you have
the source (and years to anyalyze it  ;-),  it's  extremely  naive  to
think  that its command set is limited to what's in the RFC or the man
page.

(2) sendmail runs as root.  Well, ok, it is *possible* to run it  with
lesser  permissions, if you are a sendmail guru.  If you are among the
other 99.999% of  humanity,  you  will  run  it  however  your  vendor
delivered  it,  and in all systems I've seen, its default is to run as
root.  If you try to change this, find that you can't quite get it  to
work.   You  will  give  up,  and  run it as root (as it came from the
vendor) so that it will work. Unless you have the source (and years of
spare  time  ;-),  you  probably won't be able to get it to work right
with non-root permissions.

(3) sendmail requires no password from remote users.  When you did the
test  in  (1),  did  it  ask  you  for a password?  Did you need to do
anything that identified you? Furthermore, if you used a bogus user or
host  name  in  the  HELO  message,  you  can  compare  notes with the
recipient to verify that sendmail did  nothing  to  indicate  who  you
really were.  Security?  Who needs it?


For most of the last decade, it has been a mystery to  me  why  people
are foolish enough to allow sendmail to run on their machine. It's not
like there's a shortage of SMTP mailers out there;  your  neighborhood
archive likely has at least half a dozen replacements. I once wrote an
SMTP server in half a day, and none of my neighbors even noticed  that
I wasn't running sendmail. It's easy to replace sendmail. Why don't we
all do it, and be done with its problems?


-- 
Verbosity leads to unclear, inarticulate things.
   -- Dan Quayle

-----------[000167][next][prev][last][first]----------------------------------------------------
Date:      9 Dec 93 07:58:20 MDT
From:      jrd@cc.usu.edu (Joe Doupnik)
To:        comp.protocols.tcp-ip
Subject:   Re: hung CLOSE_WAITs on my Sun

In article <1993Dec8.192227.18303@physics.ucla.edu>, mmccarri@physics.ucla.edu (Mike McCarrick) writes:
> Hi,
> 
> If I use netstat to check the socket status on my Sparc 10, I frequently
> see a number of connections hung in the CLOSE_WAIT state. These
> are typically pop3 or telnet connections from a remote pc. The hung
> connections stay around for many days, even though the pc has come
> back up and is connected again with a new socket. Can anyone shed
> light on what may be causing the socket to remain in the CLOSE_WAIT
> state and what I can do to clean things up?  
> 
> Thanks,
> Mike
> 
> -- 
> Dr. Michael McCarrick                   UCLA Department of Physics
> Plasma Physics Lab                              405 Hilgard Avenue
> mmccarri@physics.ucla.edu                    Los Angeles, CA 90024
----------
	It's a third-closed(tm) situation. If you can locate a copy of 
the TCP state diagram, such as in RFC793.TXT, the situation is clearer:
	 state		actions
	ESTABLISHED  receive FIN, send ACK, next state is CLOSE_WAIT 
	CLOSE_WAIT   close local, send FIN, next state is LAST_ACK 
	LAST_ACK     receive ACK, next state is CLOSED 
	CLOSED (and done).

	The FIN & ACK in each direction is a three way handshake.
	The place to get stuck is LAST_ACK, waiting for the ACK from
the remote node. To get stuck one step earlier, in CLOSE_WAIT, usually
means trouble closing up the local material such as open files. This
can occur if the other (remote) side has not ACK'd all the bytes sent
to it. In your situation it means the remote PC walked away from a connection 
after sending a FIN and it did not care about anything else. Such cases 
are not uncommon (I just finished cleaning up this area in my own code). 
A proper emergency exit would have the PC sending a RST to reset the 
connection.
	Joe D.

-----------[000168][next][prev][last][first]----------------------------------------------------
Date:      Thu, 9 Dec 93 03:45:00 GMT
From:      bgrubb@nyx.cs.du.edu (Bartley Grubb)
To:        comp.protocols.tcp-ip
Subject:   New Free Magazine

I work for an organization that is considering launching a
magazine on Internet.  The magazine will cover end user needs and
span from terminals to workstations.  The magazine will also
cover software, peripherals and networks that run on these
machines.
     The publication is Free for the subscribers and unbiased.
It will be totally supported by sponsors.
     Here is how it works.  Once a week the service will e-mail,
to the people who wish to be on the list, a Table of Contents.
Each article in the Table of Contents will be identified by an
item number.  To get the full text of an article, you just list
the item numbers in a message to the automated server.  The
server will return the articles in seconds.  To use the system
you do not have to have full Internet access only e-mail.
     As Internet is becoming more commercialized everyday, we are
dedicated to operate this publication from only sponsor support
and provide it free to the subscribers.  We truly feel that
Internet services should be free to the end users.  In order to
accomplish this the sponsors require us to build a large
subscriber base to prove that it is a valid concept.
     If you would like to show your support please sent a message
to "bgrubb@nyx.cs.du.edu".  We would also like your comments about
what you would like to see included in this magazine.  All replies
to this address will be added to the e-mail list.  If you don't
have any comments and would just like to show your support please
feel free to send a blank message as all responses will be tallied.
If you have a friend who might be interested please encourage them
to send a message also.


-----------[000169][next][prev][last][first]----------------------------------------------------
Date:      Thu, 9 Dec 1993 09:29:39
From:      jobrien@mcs.umes.umd.edu (James M. O'Brien, Jr)
To:        comp.protocols.tcp-ip
Subject:   Wierd problem bootp & arp table changes

I've discovered a problem on our system net that as of yet I can't explain nor 
can the folks a the site causing the problem.

Scenario:

Netware 3.11 server running HellSoft Bootpd.nlm providing bootp support
for PC on our net at UMES.

UMES and several (about 6) other UMD Campus are all on one bridged ethernet,
having bootp reuqest, etc... from all over....

Problem:

A PC will send a bootp request and receive a response correctly.  PC uses 
tcpip app (say trumpet newsreader), trys to access the NNTP server.  App
fails on DNS of NNTP hostname. 

Cause:  Checking the arp tables on a SUN reveals that the IP address assigned 
to the PC is no longer mapped to the physical ethernet addres of the PC.
Its somehow been remapped to a ether address on a machine at another campus.

Further research using LZFW shows the PC sending DNS packets, and the 
responses being sent to the 'bad' address.

Eventually the arp tables drop the bad mapping (inactivity I guess?) and things
function correctly for a short time then it happens all over again.  I've 
verified this for about 6 or 7 pc's, all using bootp, and about 3 different 
ether address's in the arp tables.

The bad address aren't assigned in RFC 1340 and what I've been told is that
they are used for the VAX's

If the PC doesn't use BOOTP then the above does not happen.

Does any one have an exlpanation?  Ideas how to correct problem?

TIA.

- Jim O.



Jim O'Brien, CNE                University of Maryland Eastern Shore
jobrien@mcs.umes.umd.edu        Network Manager

-----------[000170][next][prev][last][first]----------------------------------------------------
Date:      8 Dec 1993 15:24:15 +1000
From:      ggm@dingo.cc.uq.oz.au (George Michaelson)
To:        comp.protocols.tcp-ip
Subject:   Re: IGMP == mrouted support?

Just to add a bit, the 4.2 Ultrix code *does* work in Ultrix 4.3 subject
to some massaging of the diffs, and encapsulated multicast IS available
for ultrix as well as sunos, and is vastly preferred for deployed use.

You can just use the sunos distributed code for ip_mroute.[ch] and
the relevant mrouted sources.

parcftp.xerox.com/pub/net-research is where the newer ipmulticast code is
to be found.

-George
-- 
                         George Michaelson
G.Michaelson@cc.uq.oz.au The Prentice Centre      | There's no  market for
                         University of Queensland | hippos in Philadelphia
Phone: +61 7 365 4079    QLD Australia 4072       |          -Bertold Brecht

-----------[000171][next][prev][last][first]----------------------------------------------------
Date:      9 Dec 1993 06:26:46 +0100
From:      urlichs@smurf.sub.org (Matthias Urlichs)
To:        comp.protocols.tcp-ip
Subject:   Re: The connect-connect syndrome - A bug or feature?

In comp.protocols.tcp-ip, article <2dt1ea$bko@usenet.ins.cwru.edu>,
  trier@odin.ins.cwru.edu (Stephen C. Trier) writes:
> In article <id.VCU41.09G@nmti.com>, jaleel ihsan <ihsan@nmti.com> wrote:
> >I have a requirement[...] to have a communication protocol between two
> >system in which the two sides have a "peer-to-peer" relationship,
> >that's right "peer-to-peer" not "client-server".
> 
> You can do this anyway by having both sides listen on a well-known port
> but connect from a random port.  Unless I'm missing something, this
> will provide equivalent or superior results.  Is there something that
> makes connect-connect superior in your application?
> 
It's not equivalent, because if the two sides decide to open a connection 
simultaneously, your solution will create two TCP streams instead of one. 
Assuming that the application in question can't tolerate that, you now need
to extend the protocol to determine which connection to close down.

-- 
Could the high divorce rate be associated with a desire
to get more experience under one's belt?
-- 
Matthias Urlichs        \ XLink-POP Nürnberg   | EMail: urlichs@smurf.sub.org
Schleiermacherstraße 12  \  Unix+Linux+Mac     | Phone: ...please use email.
90491 Nürnberg (Germany)  \   Consulting+Networking+Programming+etc'ing      42

-----------[000172][next][prev][last][first]----------------------------------------------------
Date:      9 Dec 93 18:24:05 -0600
From:      latoga@cnsvax.uwec.edu
To:        comp.protocols.tcp-ip
Subject:   ** Question about Subnet Masking...

I humbley seek the wisdom and experience of the net...

I am looking for a breif but accurate desciption of subnet masking. 
First I will state the problem.  We, the networking department that I am
employed at, are having a few problems (actually a lot of problems).  The
problem concerning the network is as follows.  I read a document that I
downloaded off of Hewlett Packard's Network Advisory BBS that talked about
subnet masking.  The most of it was rather technical and I am not fully briefed
on the finer points of tcp/ip.  The jist of it said that when computers
broadcast a message onto the net they use the hex string HH-HH-HH-HH-HH-HH
(which is all ones in binary).  Some older systems, notable earlier versions
of BSD, will use the hex string representation of all zeros.  Now if not all
machines are are set to the same subnet mask this will cause a "storm" of error
messages coming from ARP which has detrimental effects on your network. My
first question is....
 (1)  What exactly does the subnet mask do in such that not having all of them
      on your network set the same result in these storms?

We currenly have a HP Network Analyzer that we were using to pickup packets
with no source address and garbled destination address.  For the most part the
address had the first two set of characters of H (ex. HH-HH-...), then they
would be random hex characters there after.  
 (2)  Could this be resulting from not having all of our machines set with the
      same subnet mask?  If so, could you give a brief explanation of why; if
      not, could you give theories of what else might be causing this?

I appreciate everyones time and effort.  

Mailed responses would be prefered (it is almost finals week), but I will try 
to check the group regularly since this might be of interst to others.

+-----------------------+
      Greg A. Lato       
 latoga@cnsvax.uwec.edu       
+-                     -+
 Computing and Networking 
         Services
 University of Wisconsin
        Eau Claire         
 
       


-----------[000173][next][prev][last][first]----------------------------------------------------
Date:      Thu, 9 Dec 1993 08:24:26 GMT
From:      padams@mail.trincoll.edu (P.A.)
To:        comp.protocols.tcp-ip,comp.sys.mac.comm,alt.internet.services,comp.infosystems.www
Subject:   How many Sites are connected with TCP/IP, SLIPP

Hi,

I am trying to put together/find some information about how many sites
are connected to the internet via TCP/IP, or SLIP connections.  

I Specifically I would like to know:

The number of total sites
Name of site
How many users at each site. ex. 10,000 students/employees
Type of network at site -  ex. Campus dorm network 
Type of network connection - ex. T1  
Type of Computers used at site. ex. Mac, PC, UNIX

Thanx. Any answers or pointers would be very helpfull
Respond By email and I will post a summary!

-P-

padams@mail.trincoll.edu

-----------[000174][next][prev][last][first]----------------------------------------------------
Date:      8 Dec 1993 16:08:39 +1000
From:      ggm@dingo.cc.uq.oz.au (George Michaelson)
To:        comp.protocols.tcp-ip
Subject:   Re: Need for Connectionless protocols/services

kannan@cs.ualberta.ca (Kannan Thiruvengadam) writes:

>The question is as direct as this :
 
>"Is there any need for connectionless services/protocols ? Can we not just 

Yes.

>do with connection-oriented protocols/services ?"

No.

>How sensible is the above argument ?

Well I think not very. Consider one-way communication channels for
instance. How do you intend running a connected service with no
back-packetflow?

How do you run connection-oriented multicasting 1:many and why is it
'better' than datagram multicasting?

-George
-- 
                         George Michaelson
G.Michaelson@cc.uq.oz.au The Prentice Centre      | There's no  market for
                         University of Queensland | hippos in Philadelphia
Phone: +61 7 365 4079    QLD Australia 4072       |          -Bertold Brecht

-----------[000175][next][prev][last][first]----------------------------------------------------
Date:      Thu, 9 Dec 1993 11:55:11 GMT
From:      rstevens@noao.edu (W. Richard Stevens)
To:        comp.protocols.tcp-ip
Subject:   Re: inetd.spawn info

> When inetd spawns a daemon (listed in inetd.conf) what is the best
> way for the daemon to get information on who or what connected (ie.
> IP address, host, port #, etc).
>
> Or _is_ there a way at all?

Assuming a TCP server, the standard way is to call getpeername() on
any one of stdin/stdout/stderr to retrieve the client's IP address
and port number.  You'll then have to call gethostbyaddr() to convert
the IP address into a hostname.

	Rich Stevens  (rstevens@noao.edu)

-----------[000176][next][prev][last][first]----------------------------------------------------
Date:      Thu, 9 Dec 1993 12:07:02 GMT
From:      zonker@diku.dk (Claus Engdahl)
To:        comp.protocols.tcp-ip
Subject:   Re: Domain Name Servers

k2@bl.physik.tu-muenchen.de (Klaus Steinberger) writes:

>cooker@ci.ua.pt (Fernando Cozinheiro) writes:
 
>>I have heard some references abou two different Name Servers: Domain Name
>>Servers and IEN-116. We have an old terminal server that includes on its
 
>IEN-116 was not very widely used, and is not in use anywhere as I know.
>It doesn't fit actual needs. The Domain Name Service (DNS) is the right
>one.


IEN-116 might be needed if your terminalserver is old. We use IEN-116
for old "Bridge" terminalservers. But as "k2" points out, you should
try with a domainnameserver first.





-- 
Claus Engdahl (zonker@diku.dk)

-----------[000177][next][prev][last][first]----------------------------------------------------
Date:      09 Dec 1993 12:07:07 GMT
From:      viola@xtp137.uni-muenster.de (Joerg_Viola)
To:        comp.protocols.tcp-ip
Subject:   Choosing port number

Being new to this group, I don't know wether this is a FAQ (or even
if there is a FAQ list):

One needs a port number to establish a server/client connection.
How does one retrieve it? Currently I am choosing randomly a number
bigger than IPPORT_USERRESERVED, but there must be a better way !

Further, when I have a number how does the client know about it ?

Sorry for these silly questions :-)

joerg

-----------[000178][next][prev][last][first]----------------------------------------------------
Date:      Thu, 9 Dec 1993 12:27:34 GMT
From:      rob@inmos.co.uk (Robin Pickering)
To:        comp.security.misc,comp.protocols.tcp-ip
Subject:   Re: "large security gap in the Internet"

In article <1521@minya.UUCP> jc@minya.UUCP (John Chambers) writes:
>
>The best way to handle sendmail is to first install a good mailer, and
>then run the command:
>  find .  -name 'sendmail*' -exec /bin/rm -f {} ';'
> 
> [Loads of random nonsense, claiming deficiencies in sendmail by
>  demonstrating reservations about the SMTP protocol.
>  In particular asserting that sendmail is insecure because it
>  talks a protocol which, according to to your analysis has the
>  following problems:
>  1) doesn't insist on a password for everyone delivering mail. (!)
>  2) uses ASCII (what do you suggest, EBCDIC??)
>  3) doesn't verify the host given in a HELO (Not true BTW)
> ]
>
>For most of the last decade, it has been a mystery to  me  why  people
>are foolish enough to allow sendmail to run on their machine. It's not
>like there's a shortage of SMTP mailers out there;  your  neighborhood
>archive likely has at least half a dozen replacements. I once wrote an
>SMTP server in half a day, and none of my neighbors even noticed  that
>I wasn't running sendmail. It's easy to replace sendmail. Why don't we
>all do it, and be done with its problems?

Let me try to understand your argument:

 The SMTP protocol has a number of security problems.

 Therefore sendmail, which is used at a huge number of sites and has been
 the subject of vast amounts of development effort and critical review is a 
 security hole on the basis of it's use of SMTP.

 My mailer which I hacked together in half a day, and which uses the same
 insecure SMTP protocol is much more secure.

Hmm, don't quite understand the reasoning behind that last step :-)

If your argument was that sendmail is just too complex for us to have
total confidence in it's security, I would probably agree with you.

However the delivery of mail in the modern Internet & beyond is a very
complex job and in my experience nothing short of sendmail is capable
of delivering all of the features need. Dumb SMTP servers may be
acceptable for leaf node MTAs at little single machine "site" but
real-world MTAs which provide service to large sites need:

    Control over delivery and address re-writing (users can't be expected
        to know that site.bitnet needs different treatment to site.edu
        or even that node::user isn't a valid Internet address!)
    Loads of different mail transports, with different addressing
        requirements (SMTP, UUCP, DECNET, Grey Book(RIP))
    User aliasing for 1000s of users.
    Ability to interact with large distributed databases in routing
        decisions (NIS mailhosts, aliases, DNS)
    Ability to encode policy decisions in mailer routing
    Buck-stops-here mail routing i.e. if I don't know about it then it
        doesn't exist (no smart-host fallback).
    Acting as lowest pref MX for a number of domains & domain aliasing.
    Utterly reliable mail queueing and re-try for transient mail errors
    Mail to programs (needs to be carefully managed but still a must for
                      certain things)

To list but a few.

Sendmail does all of the above, other SMTP agents may do a few of them.
The cost of this sophistication is that it can be difficult to configure
and secure, particularly for the growing number of "internet weekend
drivers".

There is a serious use for easy to configure SMTP servers at single user or
leaf node sites, but this certainly doesn't mean that sendmail is
intrinsically bad. For many of us, it is the only tool which will do the
job. Quite why the e-mail world has evolved to the point where a solution
as complex as sendmail is required is another completely separate question.

--
    Rob.

-----------[000179][next][prev][last][first]----------------------------------------------------
Date:      Thu, 9 Dec 1993 12:51:53 GMT
From:      u8223501@cc.nctu.edu.tw ()
To:        comp.protocols.tcp-ip
Subject:   Physical address and Virtual address ?

Hellow Everybody :

    I am the first time to use the News. There is a question that I
need your help. I can not distinguish from Physical address and virtual
address. Can you tell me what Physical and Virtual address are ? I am 
also wondering what are the Physical address of Ethernet , FDDA, Token-ring
and Token-bus . Please tell me the answer !

					Francis Perng
					E-mail 82423001@im.mgt.ncu.edu.tw

C
a

-----------[000180][next][prev][last][first]----------------------------------------------------
Date:      09 Dec 1993 13:25:58 GMT
From:      perrot_s@ion.epita.fr (Stephane Perrot)
To:        comp.protocols.tcp-ip
Subject:   Re: Is Telnet 127.0.0.1 more efficient?


>  Suppose I am in 140.120.1.21 (a unix system)
>  (1). Telnet 140.120.1.21
>  (2). Telnet 127.0.0.1  i.e. loopback
>   Both (1) and (2) can telnet to the same machine.
>
>  Is case (1) can work more efficient than (2)?
>  Is case (1) cause telnet packets seen by other machine in the same lan?

	No & No, both will provide the same result, your packets won't
	be sent to the physical layer.
	The kernel resolve the routing problem in the IP layer and
	they just have a small "travel" in the kernel...

--
Stephane Perrot                                           perrot_s@epita.fr
MORPHO Systemes                               (load-library "std-disclaim")

-----------[000181][next][prev][last][first]----------------------------------------------------
Date:      Thu, 9 Dec 1993 13:44:26 GMT
From:      johny@watson.ibm.com (Johny Srouji)
To:        comp.protocols.tcp-ip
Subject:   Information about NFS over TCP

Hi,

I need some information about NFS implemented over TCP rather
than UDP. Any papers or articles about this issue will help.

What are the benefits of such an approach?
Do you know of any existing implementation?
I know that Rick Macklem has implemented NFS over TCP for
4.4BSD Reno. Do you know of any performance comparison with
the implementation over UDP?

Please mail your answers to: johny@vnet.ibm.com

Thanks in advance for your help,


--
Johny Srouji
Systems Structure and Availability

IBM Israel and Technology Ltd............ Haifa 31905 .............. Israel
Internet: johny@vnet.ibm.com...... Vnet: srouji at haifasc3................
Telephone: 01-972-4-296475.............................Fax: 01-972-4-296114



-----------[000182][next][prev][last][first]----------------------------------------------------
Date:      Thu, 9 Dec 1993 14:23:26 GMT
From:      kurt@unirsvl.rsvl.unisys.com (Kurt Matthys )
To:        comp.protocols.tcp-ip,comp.unix.solaris
Subject:   Re: TLI, TCP, t_bind(), and AI

In <ED.93Dec7202047@kayak.odi.com> ed@odi.com (Ed Schwalenberg) writes:

>In article <1993Dec7.215404.2442@mdivax1.uucp> robinson@mdd.comm.mot.com (Jim Robinson) writes:
>  attempting to bind a TCP endpoint to a port that is in use already as a
>  'server' (i.e. someone has already bound to that port w/ qlen > 0). My
>  question is why does t_bind() do this? If I wanted any random port I would
>  have specified a request address of NULL. If I want port 6666, then that's
>  what I want, not 32786. This seems to be a case of the system trying to do
>  me a favour that I don't want. However, because it seems so blatantly
>  wrong, I have to conclude that *I* am missing some important piece of the
>  puzzle.
>  -- 
 
>It's a documented feature of TLI (not just the Solaris implementation) that
>you have to check the returned port to confirm that it's the one you wanted.
>Whether this "feature" is a good idea is a matter of opinion.

You must be running XPG3.  As I understand it, X/Open changed the behaviour of
t_bind() in XPG4 to do what you want.  They didn't change the call or the 
parameters, just the behaviour.

Kurt Matthys
kurt@rsvl.unisys.com


-----------[000183][next][prev][last][first]----------------------------------------------------
Date:      Thu, 9 Dec 1993 14:52:44 GMT
From:      news@carmen.logica.co.uk (News Manager Account)
To:        comp.protocols.tcp-ip
Subject:   Re: RFC where ever you are

In article <BOB.93Dec2080736@roughy.MorningStar.Com> bob@MorningStar.Com (Bob Sutterfield) writes:
>In article <19931202115243.marianne@dp0120.kub.nl> marianne@kub.nl  (baliemedewerkers C.I.C ) writes:
>   Could somebody tell me where i can find RFC on an FTP site somewhere.
>
>Try nic.ddn.mil:rfc/* or ftp.uu.net:inet/rfc/*.
>--
>Bob Sutterfield, Morning Star Technologies            +1 614 451 1883
>1760 Zollinger Rd, Columbus Ohio USA, 43221-2856      +1 800 558 7827
>bob@MorningStar.Com                                   +1 614 459 5054 (FAX)

-----------[000184][next][prev][last][first]----------------------------------------------------
Date:      Thu, 9 Dec 1993 15:34:41 GMT
From:      lawson@netcom.com (Steven Lawson)
To:        comp.protocols.tcp-ip
Subject:   Experiences with Fusion TCP/IP?

Does anyone have experience with the Fusion TCP/IP stack from Pacific
Softworks/NRC?  I am especially interrested in how well it handles
larger internetwork environments, say in a mini/mainframe environment?

Basically, is it robust enough that an OEM could drop all other network
strategies and rely on this package alone for reliable networking on
200+ user systems?

I am in the process of generating a recommendation, like what I have seen
so far, and would really like to hear what others think...

- Steve


-----------[000185][next][prev][last][first]----------------------------------------------------
Date:      Thu, 9 Dec 1993 15:47:47 GMT
From:      ccs@aber.ac.uk (Christopher Samuel)
To:        comp.security.misc,comp.protocols.tcp-ip
Subject:   Re: "large security gap in the Internet"

In article <1993Dec9.122734.24944@inmos.co.uk> of comp.security.misc,
           rob@inmos.co.uk (Robin Pickering) doodled:

> In article <1521@minya.UUCP> jc@minya.UUCP (John Chambers) writes:
 [chomp]
> >For most of the last decade, it has been a mystery to  me  why  people
> >are foolish enough to allow sendmail to run on their machine. It's not
> >like there's a shortage of SMTP mailers out there;  your  neighborhood
> >archive likely has at least half a dozen replacements. I once wrote an
> >SMTP server in half a day, and none of my neighbors even noticed  that
> >I wasn't running sendmail. It's easy to replace sendmail. Why don't we
> >all do it, and be done with its problems?
> 
> Let me try to understand your argument:
> 
> The SMTP protocol has a number of security problems.

It has some authentication problems (mostly cured by 8.6.4), rather
than inherent security problems..

> Therefore sendmail, which is used at a huge number of sites and has
> been the subject of vast amounts of development effort and critical
> review is a security hole on the basis of it's use of SMTP. 

Well sendmail is a good demonstration that the implimentation of a
protocol can be far more important than the choice of protocol.  The
recent "bug of the month club" has served very well to show that
oversights can lead to dangerous situations.. 

In general: Sendmail (up to 8.6.4) can be a security hole due to it's
            *implimentation* of the SMTP protocol.

> My mailer which I hacked together in half a day, and which uses the
> same insecure SMTP protocol is much more secure. 

Depends on the implimentation, doesn't it..

> Hmm, don't quite understand the reasoning behind that last step :-)

S'obvious, if you're talking about the implimentation rather than the
specification. 

> If your argument was that sendmail is just too complex for us to have
> total confidence in it's security, I would probably agree with you. 

I concur, but then again, I'm running PP, which is even more complicated.
ObGripe: I really detest X.400.

> However the delivery of mail in the modern Internet & beyond is a very
> complex job and in my experience nothing short of sendmail is capable
> of delivering all of the features need. Dumb SMTP servers may be
> acceptable for leaf node MTAs at little single machine "site" but
> real-world MTAs which provide service to large sites need:
> 
 [long list of capabilities deleted]
> 
> To list but a few.
> 
> Sendmail does all of the above, other SMTP agents may do a few of them.

Far be it from me to fan the flames of a holy war, but try checking out
SMail, it does all those (*including* greybook), and doesn't suffer from
the same holes in it's SMTP implimentation as pre-8.6.4 sendmail did. 

Oh yeah, I don't believe that sendmail 8.6.4 will work in the
UK-sendmail package, as a flag that the CBS software requires is no
longer present, so SMail may do one thing that 8.6.4 sendmail won't!

Chris
-- 
 Christopher Samuel, Computer Unit, U.W Aberystwyth, Aberystwyth, WALES
 E-mail: ccs@aber.ac.uk         PGP 2.3 public key available on request
 Then hast thou joined the ARPANET?     Oh come to me, my bankrupt boy!
 Quick, call the NIC! Send RFCs!      He chortled in his joy.  - RFC527

-----------[000186][next][prev][last][first]----------------------------------------------------
Date:      Thu, 9 Dec 1993 16:42:50 GMT
From:      manager@netcentral.nchu.edu.tw (Lee Chee Siong)
To:        comp.protocols.tcp-ip
Subject:   Is Telnet 127.0.0.1 more efficient?

Hi,
   A good question but make me confuse.

   Suppose I am in 140.120.1.21 (a unix system)
     (1). Telnet 140.120.1.21
     (2). Telnet 127.0.0.1  i.e. loopback
   Both (1) and (2) can telnet to the same machine.

   Is case (1) can work more efficient than (2)?

   Is case (1) cause telnet packets seen by other machine in
the same lan?

   Any comment is welcome.


<><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><>
<> CS Lee  (Lee Chee Siong  §õ§Ó²»)                 <>  If you can give     <>
<> System Manager of Computer Center                <>       nothing else,  <>
<> National Chung Hsing University,                 <>                      <>
<> Taichung, Taiwan, Republic of China.             <>  at least give a     <>
<> Internet Address: manager@netcentral.nchu.edu.tw <>       cheerful face  <>
<><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><>

-----------[000187][next][prev][last][first]----------------------------------------------------
Date:      9 Dec 1993 17:08:07 GMT
From:      dargers@rzdspc13.informatik.uni-hamburg.de (Torsten Dargers)
To:        comp.protocols.tcp-ip,alt.winsock
Subject:   Re: Problem with WinSock and ipxpkt....

Anthony Rumble (arumble@blah.netcomm.pronet.com) wrote:
: I can't seem to get winsock working at all!!
 
: Im on a novel network, with a few Unix boxes attached..
 
: I can use ipxpkt with DOS Trumpet and things like NCSA telnet
: perfectly.. WinQVT with pktint also works perfectly..
 
: But.. If I use ipxpkt with either pkt trumpet.. or with
: WinSock.. Every time I try to connect to something, I get
: ARP: timed out..

Did you use winpkt and correct version of it ?

: I can see the ARP request going out, and returning.. But
: it doesn't seem to recognise it..

That always happened to me when my packet-driver did not
work correctly. Now I'm using ODI-Driver and ODIPK
version 2.0 (or up).

Now anything works fine.

Hope this helps.

Torsten

-----------[000188][next][prev][last][first]----------------------------------------------------
Date:      Wed, 8 Dec 93 23:12:38 +1100
From:      lukeh@softtruk.apana.org.au (Luke Howard)
To:        comp.protocols.tcp-ip
Subject:   Re: Wherza FAQ? - Subnetting question

In <2dva1p$168k@info2.rus.uni-stuttgart.de> skok@itwds1.rus.uni-stuttgart.de (Holger Skok) writes:
>Hi everyone,
 
>I have a small (hopefully) problem to deal with, which could be treated
>in the FAQ. If that's the case, please point me to it (ftp site would be
>nice).
 
>If not (or if you feel like answering anyway) here's my trouble:
 
>We have a few UN*X boxes in a subdomain(?) with IP address 129.69.69. We
>are free to use the addresses available and we have to make do with
>them. That should be easy, after all there are only seven UN*X boxes and
>a few PC's connected. Now, however we have obtained an additional Novell
>network and want to be able to connect to the internet from the
>Novell-client PC's. Everything on the PC's is setup correctly. We use
>packet drivers and NCSA-telnet but from inside the Novell net there's no
>connection - connection timeout. 
>Reason is that we have two seperate networks. One is connected to the
>rest of the world and has the UN*X boxes plus one interface card of the
>Novell server connected to it while the other has all the Novell clients
>hanging off of it and the other interface card of the Novell server
>serving it. tcp/ip routing is installed on the Novell server. 
>The server does not seem to understand where it has to route the packets 
>to, though. 
 
>In order for the routing to work, the routing software has to understand
>that the two interface cards belong to different networks. It would be
>easy if we could get another subnet from our computing center, but that
>would really be wasteful of IP-node numbers. The only option remaining -
>so we have been told - is to split our subnet into two (or four)
>sub-subnets. One would have to fiddle with the netmask then.
>How would that work?

This is something I'm looking at at the moment and - believe me -
it's very confusing! Some one else will explain better, but I'll
tell you what I know.

My mask is 255.255.255.248. My SLIP router's address would be
(if it existed) 202.12.87.242. The subnet I have been assigned
is identified as 202.12.87.48.

That way, so my knowledgable IP friends tell me, I have
IP numbers from 202.12.87.48 to 202.12.87.55 for my personal
use. The address 202.12.87.48 is reserved (being I suppose
equivelent to 202.12.87.0 if it was a proper subnet address)
and 202.12.87.55 becomes the broadcast address. So I assume
the broadcast address is the maximum address in this little
"subsubnet". Exactly what number it is depends on how many
bits you have assigned, which in turn depends on the netmask.

>Currently our netmasks are set to 255.255.255.0. We could presumably
>mask two bits more (netmask 255.255.255.192) and split our subnet into
>four sub-subnets. Would that work? How would the addresses have to be
>chosen then, what would the IP numbers have to be in the two parts of
>the subnet? What does the "broadcast" field have to be set to? (What's
>being "broadcast" anyway?).
 
>Thanks in advance for any hints,

So for your situation, you would have your 129.69.69 address divided
into four subnets, which should be more than enough - and you would
set the broadcast addresses appropriately. You will need to configure
the routing to route an "unusual" number of bits - for example,
with my KA9Q I have:

route add 202.12.87.48/29 eth0

which routes the first 29 bits of 202.12.87.48 (which I think
translates to .48 ==> .55) to the Ethernet interface. A default
routing statement routes everything else to SLIP. Normally
with /X, X is a "nice" number like 16 or 24 indicating whether
it's a class B or C address, but in this case where we're splitting
a Class C address into little bits, it is quite odd.

I can't vouch for the accuracy of the above information as 
I barely understand it myself, but I hope it is of some
assistance. Please let me know (via email) how you go as I'm
most interested in NetWare TCP/IP support.

-- 
+-----------------------------------------------------------------------+
| Luke Howard (Melbourne)            email: lukeh@softtruk.apana.org.au |
| Member of APANA                       ip: lukeh@suburbia.apana.org.au |
+-----------------------------------------------------------------------+

-----------[000189][next][prev][last][first]----------------------------------------------------
Date:      Thu, 9 Dec 93 17:37:16 GMT
From:      howland@us-es.sel.de (Gary Howland US/END 60/1/25)
To:        comp.protocols.tcp-ip
Subject:   Network licence broadcasts: Recommended methods?

Hi,

Can anybody tell me if there is a recommended approach to enforcing
a software licence on software by means of network broadcasts?
ie. suppose I am running some software that wishes to ensure no one else
is running the same piece of software on the same network.  What is the recommended or "polite" way of doing this?  Is a network broadcast every
10 minutes considered impolite?

Many thanks in advance.

Gary

-- 
Gary Howland			Email:    howland@us-es.sel.de	
Alcatel SEL AG. Lorenzstrasse 10, D-70435 Stuttgart, Germany  

-----------[000190][next][prev][last][first]----------------------------------------------------
Date:      Thu, 9 Dec 1993 18:05:01 GMT
From:      ccs@aber.ac.uk (Christopher Samuel)
To:        comp.protocols.tcp-ip,comp.sys.mac.comm,alt.internet.services,comp.infosystems.www
Subject:   Re: How many Sites are connected with TCP/IP, SLIPP

In article <1993Dec9.082426.13648@starbase.trincoll.edu> of
	alt.internet.services, padams@mail.trincoll.edu (P.A.) doodled:

> I am trying to put together/find some information about how many sites
> are connected to the internet via TCP/IP, or SLIP connections. 

Last estimate I saw put it at over 3,000,000 machines connected.

As for sites, you could try asking those nice people at rs.internic.net
who deal with network registrations, they *may* be able to help.. 

Chris
-- 
 Christopher Samuel, Computer Unit, U.W Aberystwyth, Aberystwyth, WALES
 E-mail: ccs@aber.ac.uk         PGP 2.3 public key available on request
 Then hast thou joined the ARPANET?     Oh come to me, my bankrupt boy!
 Quick, call the NIC! Send RFCs!      He chortled in his joy.  - RFC527

-----------[000191][next][prev][last][first]----------------------------------------------------
Date:      Thu, 9 Dec 1993 18:43:47 GMT
From:      mintz@cup.hp.com (Ken Mintz)
To:        comp.protocols.tcp-ip
Subject:   Re: Physical address and Virtual address ?

Franics Perng <u8223501@cc.nctu.edu.tw> writes:
> I am the first time to use the News. There is a question that I
> need your help. I can not distinguish from Physical address and virtual
> address. Can you tell me what Physical and Virtual address are ? I am 
> also wondering what are the Physical address of Ethernet , FDDA, Token-ring
> and Token-bus . Please tell me the answer !

  This is a confusion of two different uses of similar terminology.

  When talking about networking, "physical address" refers to the hardware
  address of an interface, also called the MAC address or station address,
  for example 08-00-09-12-34-56.

  Higher (TCP/IP) layers use IP addresses (for example, 15.13.104.4) to 
  refer to systems.  The IP address must be translated into a hardware
  address in order for the network interface to transmit the packet.

  (Applications often use host names, which must be translated to IP
  addresses, for example by looking into /etc/hosts.)

  Physical and virtual addresses are terms that refer to methods of 
  referring to locations in main memory.  These are not networking terms.
  Virtual addressing refers to the full address range of an application,
  which might be larger than the amount of available main memory.  (In  
  that case, part of the application's address space is kept on disk.)

  When portions of a virtual address space is brought into main memory,
  physical addressing refers to the actual address range used by the
  application in main memory.

  Typically, only the lowest levels of the operating system (for example,
  drivers) use physical addresses to refer to this memory.  Hardware
  address translation tables permit the rest of the system to use virtual
  addresses.

  So, if you are writing a network interface driver, you are likely to
  come across both uses of the term "physical address".  You must put
  the interface "physical address" (hardware address) into the frame
  before transmission; and you must pass the main memory physical address
  of the buffer that contains frame to the interface.

-- Ken Mintz

-----------[000192][next][prev][last][first]----------------------------------------------------
Date:      9 Dec 1993 21:20:55 GMT
From:      CA6343@CONRAD.APPSTATE.EDU (Abad, Christian Nicholas      )
To:        comp.protocols.tcp-ip
Subject:   HELP: TCP/IP and BBSs (is this right?!?)

okay folks here it is: a problem that we think we have solved, but we wanted to 
get some input to make sure before we go ahead with the project.

We are trying to set up a BBS on the Internet using VBBS (Ms-Dos)  We currently 
have an Ethernet card and a 486, and we haven't had any luck finding software 
that will monitor the Ethernet card and allow the BBS to answer it like a modem.
Several suggestions have been creating a dedicate dfileserver machine in 
addition to the 486 running the BBS software.  So the following is our proposed 
solution to this problem:

Computer #1:
a 486 running Ms-Dos and VBBS (our bbs package)
Serial Board

Computer #2:
a 8088 (or maybe newer if we can get our hands on one)
Ethernet Card
Serial Board


The idea here is that we would have Computer #2 answer the Ethernet card and 
via null modem cable (attached to serial board on BOTH computers) communicate 
with the 'dedicated fileserver' 486 (Computer #1) running VBBS.

Now the question we have are:

1.  Will this configuration work?
2.  What software do we need to monitor the Ethernet card (something cheap, 
    preferred)?
3.  Can we support multiple users if we use a Digiboard?
3a. If multiple users can be supported using a Digiboard what additional 
    software/hardware would we need? 
4.  Are we out of our minds?

thanks in advance,
christian abad
ca6343@conrad.appstate.edu 
personal email would be appreciated if possible :-)


-----------[000193][next][prev][last][first]----------------------------------------------------
Date:      Thu, 9 Dec 1993 21:48:43 GMT
From:      raj@cup.hp.com (Rick Jones)
To:        comp.protocols.tcp-ip
Subject:   Re: Is Telnet 127.0.0.1 more efficient?

Stephane Perrot (perrot_s@ion.epita.fr) wrote:
: >  Suppose I am in 140.120.1.21 (a unix system)
: >  (1). Telnet 140.120.1.21
: >  (2). Telnet 127.0.0.1  i.e. loopback
: >   Both (1) and (2) can telnet to the same machine.
: >
: >  Is case (1) can work more efficient than (2)?
: >  Is case (1) cause telnet packets seen by other machine in the same lan?
: 	No & No, both will provide the same result, your packets won't
: 	be sent to the physical layer.
: 	The kernel resolve the routing problem in the IP layer and
: 	they just have a small "travel" in the kernel...

The answer to question A is implementation dependent. My understanding
of BSD networking is that case 1 and 2 will take slightly different
paths, the path in 2 being slightly shorter.

Also, in HP-UX 9.0 (and Irix something i believe), the loopback
interface is configured to support "checksum offload." This
performance enhancement, can only be utilized by TCP if it knows that
the feature is present. To know that, it must know that it's packets
are being sent over that loopback interface. On UX, (and I believe
Irix), if you just sent to 'hostname' the TCP software believes that
it is being routed through the primary interface of the system, on UX,
this is typically the ethernet interface, which does not support
checksum offload.

If, however, there is a host route for the Ethernet interface's IP
address, pointing at 127.0.0.1, TCP will notice that there is checksum
offload available, and your performance will improve.

Of course, this will not be a "BIG" component of a Telnet session as
the packets are rather small (byte at a time), however, it can be
quite noticeable in a bulk transfer or with larger packets.
Checksumming, is after all, mostly part of the per-byte cost of
transfer and not per packet.

I think that you will notice that Irix automagically sets-up these
host routes for the local interfaces. HP-UX 9.X does not. There is a
brief discussion of this checksum offload, in the context of HP-UX
9.0, in a document "HP-UX Release 9.0 networking Performance
Enhancements" available via anonymous FTP from
col.hp.com:dist/networking/briefs/copyavoid.ps. Feel free to download
that and peruse it.

rick jones
PS - I may have the ftp path slightly wrong - look around a bit before
you give up and send me email ;-)

-----------[000194][next][prev][last][first]----------------------------------------------------
Date:      Fri, 10 Dec 1993 00:06:50 GMT
From:      miltonm@austin.ibm.com (Milton D. Miller II)
To:        comp.protocols.tcp-ip
Subject:   Re: Is Telnet 127.0.0.1 more efficient?


In article <PERROT_S.93Dec9132558@ion.epita.fr>, perrot_s@ion.epita.fr (Stephane Perrot) writes:
> [ quoteing someone else ]
> >  Suppose I am in 140.120.1.21 (a unix system)
> >  (1). Telnet 140.120.1.21
> >  (2). Telnet 127.0.0.1  i.e. loopback
> >   Both (1) and (2) can telnet to the same machine.
> >
> >  Is case (1) can work more efficient than (2)?
> >  Is case (1) cause telnet packets seen by other machine in the same lan?
> 
> 	No & No, both will provide the same result, your packets won't
> 	be sent to the physical layer.
> 	The kernel resolve the routing problem in the IP layer and
> 	they just have a small "travel" in the kernel...
> 
> --
> Stephane Perrot                                           perrot_s@epita.fr
> MORPHO Systemes                               (load-library "std-disclaim")

For telnet, you won't see the difference except for cat /etc/termcap, but
some implementations set the mtu of the loopback to 65536, avoiding 
some tcp segmenting.

milton
--
Milton Miller  KB5TKF  miltonm@austin.ibm.com
I never speak for IBM.

-----------[000195][next][prev][last][first]----------------------------------------------------
Date:      10 Dec 1993 13:29:35 -0800
From:      lstowell@pyrnova.mis.pyramid.com (Lon Stowell)
To:        comp.protocols.tcp-ip
Subject:   Re: PCs and pings (a dreadfull combination)

In article <KERCH.93Dec10113136@reynaldo.parc.xerox.com> kerch@parc.xerox.com writes:
>
>Be that as it may, any TCP/IP stack that crashes when it gets a ping 
>is BROKEN.  See rfc1122 (Host Requirements):
>
>
>3.2.2.6  Echo Request/Reply: RFC-792
>      Every host MUST implement an ICMP Echo server function that
>      receives Echo Requests and sends corresponding Echo Replies.
>      A host SHOULD also implement an application-layer interface
>      for sending an Echo Request and receiving an Echo Reply, for
>      diagnostic purposes.
>
   Nowhere in there does it say that a host must reply to each and
   every ping from a faster, more powerful host that can ping faster
   than the slower host can handle same.

   It would be more socially responsible behavior to just silently
   discard the pings rather than crashing, but it would also be
   more socially responsible behavior on the pingor to not generate
   more pings than it really needs to...say once a second or so.
   The pingor should be aware that some pingees may not have powerrisc
   chips to play with.


-----------[000196][next][prev][last][first]----------------------------------------------------
Date:      10 Dec 93 11:49:45
From:      dougm@boulder.Central.Sun.COM (Doug McCallum)
To:        comp.protocols.tcp-ip,comp.unix.solaris
Subject:   Re: TLI, TCP, t_bind(), and AI

In article <CHrun3.F1x@unirsvl.rsvl.unisys.com> kurt@unirsvl.rsvl.unisys.com (Kurt Matthys ) writes:

   >It's a documented feature of TLI (not just the Solaris implementation) that
   >you have to check the returned port to confirm that it's the one you wanted.
   >Whether this "feature" is a good idea is a matter of opinion.

   You must be running XPG3.  As I understand it, X/Open changed the behaviour of
   t_bind() in XPG4 to do what you want.  They didn't change the call or the 
   parameters, just the behaviour.

Solaris is TLI, at present.  All the way back to SVR3, TLI has said
that a transport provider "may" select a different address if the
requested one wasn't available.  

The first XTI specification (CPG3) said it slightly differently in
that if an address was not available (or specified) it "will" assign
an appropriate address if automatic generation of addresses is
supported.  The difference is that SVR4 said "may" and XTI said "will
- if supported".  Since SVR4 says that you can assign an address (it
doesn't require it) and there is no way to know whether it does or
not, you have to check for it.

The revised XTI spec (1990), it says that if a requested address is
"not" available, there will be an error.  This is XPG4 behavior as you
indicated.

-----------[000197][next][prev][last][first]----------------------------------------------------
Date:      10 Dec 93 12:41:00
From:      Steinar.Haug@runit.sintef.no (Steinar Haug)
To:        comp.dcom.isdn,comp.protocols.tcp-ip,comp.dcom.cell-relay
Subject:   Re: Why connectionless ?

> >Why did B-ISDN decide to offer Connectionless Services (hence use connectionless protocols) ? 
> 
> There are lots of sensitive TCP/IP-oriented souls out there, so
> before I state my opinion, I will have to add:
> *** FLAME ON ***
> 
> The "war" between the Internet and the OSI camps are essentially that
> between CL and CO services. ITU-T (CCITT) has always been in the CO 
> camp, hence considered The Great Enemy from the Internet side. 

Actually, the Internet world prefers to choose the protocol most suitable
for the job at hand. I'd say that the combination of connectionless (IP)
and connection-oriented (TCP) has proven itself eminently successful across
a large range of networking techonologies, speeds, and user requirements.
Can you show me an ISO/ITU-T transport protocol that will work across a speed
range of 1200 bit/s to 800 Mbit/s like TCP is known to do?

I'd also argue that probably the most significant difference between ITU-T
(CCITT) and the Internet world is the Internet world's reliance on protocols
that have been proven to work by actual interoperable implementations, as
opposed to the ITU (CCITT) and ISO tendency of standardizing by committee and
without requiring that the protocols actually be implementable and useful.

> Now, most of the B-ISDN/ATM groundwork was done by ITU-T, and the
> technology looks promising as a candidate for being The Common One for
> future networking. For this to happen, both sides must show flexibility.
> 
> The CO camp has sacrificed network error correction and flow control,
> thus taken a major step in the direction of IP philosophy, but they
> have retained the end-to-end connection orientation and net level muxing.
> 
> On the other hand, the Internet camp must sacrifice their beloved datagram 
> philosophy. Lots of their super-fancy routing strategies, of which they are 
> so proud, are of little or no value in ATM. But their essential objections
> against CONP, like X.25, as being too heavy and overloaded with functions
> (error correction, flow control etc.) have been fully honored.

I don't think the Internet world has to "sacrifice" anything, actually. The
Internet world will continue to choose the best protocol and technology for
the job. It's quite likely that ATM will be an important part of the future
Internet - but I see no reason why this should be done just to make ITU-T
happy.

Note that ATM does not offer an *inter*network service, which the Internet
world regards as extremely important. This is one very good reason to run
IP on top of ATM. The need for an internetwork service has never really been
understood by the ITU/ISO side of the world - and it's one of the reasons for
the commercial sucess of TCP/IP.

There is a lot of work being done in the Internet world on new protocols to
handle the emerging requirements of new multimedia services, etc. Some of
the new protocols include features which are typically thought of as being
connection-oriented, ie. connection setup and resource reservation. The
Internet world will continue to use "their beloved datagram philosophy"
where it makes sense, and will use new protocols which are not pure datagram
where *that* makes the most sense.

> I suppose that it shines through that generally, I am also in favor of CO 
> services/protocols. Yet I support the idea of simulating IP over B-ISDN/ATM;
> it is absolutely necessary to get the Internet to join forces with OSI.
> 
> Once we've got the ATM networks in place, we can show users the relative
> advantages of OSI TS mapped directly from CO services to CO protocols vs.
> the TCP-over-multihop-CL-IP-over-CO-ATM mess. Lots of TCP/IP-based systems,
> both service interfaces and applications *claim* to be network independent
> (eg. TLI) although it isn't very true yet. Getting B-ISDN/ATM out will be a
> strong incentive to make it true, and the future may give better solutions.

It sounds like you think only the Internet world uses connectionless services
and protocols. I'd recommend you to take a look at the real world, and you'll
see that there are many other users of connectionless services. Ever heard of
Novell? It's just a small insignificant protocol running on a few PCs and PC
servers :-)  Novell uses IPX at the network layer - and IPX happens to be
connetionless. Just to give one example...

Steinar Haug, system/networks administrator
SINTEF RUNIT, University of Trondheim, NORWAY
Email: Steinar.Haug@runit.sintef.no, Steinar.Haug@delab.sintef.no

-----------[000198][next][prev][last][first]----------------------------------------------------
Date:      Fri, 10 Dec 1993 09:37:20 GMT
From:      crj@comserv.itri.org.tw (Robert Chen)
To:        comp.protocols.tcp-ip
Subject:   Help: How to get TCP connection timeout signal ?

  Many users use PC to "telnet" our server. Sometimes they drop the 
connection with abnormal procedure, such as reset the PC. We want to
"know" who these guys are and when these guys do this.

  After the TCP connection is established, is there any signal when TCP drops
the connection ?

  And how can I get this information ?

Thanx in advance !

Robert Chen,  ³¯¦p¸g  ¤u¬ã°|°|³¡¹q¸£¤¤¤ß¹q¸£»Pºô¸ôªA°È³¡
Computer & Network Service Dept., Computer Center, ITRI, Hsin-Chu, Taiwan, ROC.
Email: crj@comserv.itri.org.tw	  Tel.:	886-35-917558	 Fax: 886-35-820026

-----------[000199][next][prev][last][first]----------------------------------------------------
Date:      10 Dec 93 09:53:41 GMT
From:      ICH312@DJUKFA11.BITNET
To:        comp.protocols.tcp-ip
Subject:   tcpip numbers in sweden

I am interested in getting information about the tcpip network in sweden.

I'll be next year in sweden and I want to use my home tcpip system for
mail and ftp.

Please forward these information directly to my e-mail address.

Thanks

R. Bauer

-----------[000200][next][prev][last][first]----------------------------------------------------
Date:      Fri, 10 Dec 1993 10:50:21 GMT
From:      atkinson@itd.nrl.navy.mil (Ran Atkinson)
To:        comp.protocols.tcp-ip
Subject:   Re: PPP, satellite, extended window and VXWorks

In article <CHqAq4.Jww@sci.kun.nl> albertk@cs.kun.nl (Albert Koppes) writes:

>Host A and B will communicate via a satellite link of 1 Mbps, and
>will use about 10 TCP connections simultaneously.
>We will be using PPP. 
>Some of the TCP connections need to transfer data at a speed up to 200kbps, 
>almost reaching the critical 10**5 bandwith*delay product. 
 
>1. What is your opinion about the need for us to use extended window sizes ? 
>The satellite link is supposed to have a BER of 10**(-7,-8).

Over satellite links, the TCP Large Windows extensions are normally
valuable.  VJ Header Compression is often also helpful.

>2. Is anybody familiar with any implementation of extended windowsizes 
>according to RFC 1323 (or window scaling)  under VxWorks ?

VxWorks seems to have fairly off-the-shelf BSD networking code.  I
don't think it would be hard to port Tom Skibo's freely distributable
implementation of RFC-1323 into the VxWorks TCP/IP code.  The harder
problem is that the VMS machine probably won't support RFC-1323 _or_
use of VJ header compression.

>3. Has somebody used PPP Protocol Field Compression and Address/Control Field
>compression on such high speed links ? 


Have you asked over in comp.protocols.ppp ?  That might be a better
place to ask about PPP details.

Ran
atkinson@itd.nrl.navy.mil

-----------[000201][next][prev][last][first]----------------------------------------------------
Date:      Fri, 10 Dec 1993 10:54:37 GMT
From:      atkinson@itd.nrl.navy.mil (Ran Atkinson)
To:        comp.protocols.tcp-ip
Subject:   Re: PCs and pings (a dreadfull combination)

In article <mills.755388363@dialup.athena.tay.dec.com> mills@athena.tay.dec.com (George Mills) writes:


>Now that the hotest things these days is automated network topoligy
>systems (NetView 6000), the PC's are hurting.
 
>Any Ideas on how to deal with this?

1. Turn off the 'ping' mechanism in NetView/6000
2. Refuse to purchase products from vendors that erroneously believe
   that having their NMS ping hosts regularly is a good thing.
3. Shoot the developers. (just kidding, no need to call the police :-)

Using ping(8) semi-continuously as a tool to determine network
topology is unwise.  It consumes lots of bandwidth and causes many
networking problems.  Ping was meant to be used by humans to debug
problems, it was never intended to be called repetitively by stupid
NMSs.

Ran
atkinson@itd.nrl.navy.mil




-----------[000202][next][prev][last][first]----------------------------------------------------
Date:      Fri, 10 Dec 1993 14:28:41 GMT
From:      coghlan@bcarh5f8.bnr.ca (Patrick Coghlan)
To:        comp.dcom.isdn,comp.protocols.tcp-ip,comp.dcom.cell-relay
Subject:   Re: Why connectionless ?

In article <STEINAR.HAUG.93Dec10124100@runit.sintef.no>, Steinar.Haug@runit.sintef.no (Steinar Haug) writes:

|> Actually, the Internet world prefers to choose the protocol most suitable
|> for the job at hand. I'd say that the combination of connectionless (IP)
|> and connection-oriented (TCP) has proven itself eminently successful across
|> a large range of networking techonologies, speeds, and user requirements.
|> Can you show me an ISO/ITU-T transport protocol that will work across a speed
|> range of 1200 bit/s to 800 Mbit/s like TCP is known to do?
|> 
|> I'd also argue that probably the most significant difference between ITU-T
|> (CCITT) and the Internet world is the Internet world's reliance on protocols
|> that have been proven to work by actual interoperable implementations, as
|> opposed to the ITU (CCITT) and ISO tendency of standardizing by committee and
|> without requiring that the protocols actually be implementable and useful.

Well, isn't X.25 implementable and useful?

Today, corporations use LAN technology at each site but rely more on 
protocols like X.25 and frame-relay to interconnect them through
commercial carriers.

Eventually, ATM hubs and backbone networks will supplant existing LAN
technology.

|> It sounds like you think only the Internet world uses connectionless services
|> and protocols. I'd recommend you to take a look at the real world, and you'll
|> see that there are many other users of connectionless services. Ever heard of
|> Novell? It's just a small insignificant protocol running on a few PCs and PC
|> servers :-)  Novell uses IPX at the network layer - and IPX happens to be
|> connetionless. Just to give one example...

Just one key point, most homes/businesses have a point-of-presence on
the public network (phone company).  It is this network that will form
the backbone for most services.  It is far more likely that these services
will run on top of a protocol such as frame-relay or ATM rather than the
Internet protocols.

-----------[000203][next][prev][last][first]----------------------------------------------------
Date:      Fri, 10 Dec 1993 16:59:39 GMT
From:      mac@devildog.att.com (Mike Carr)
To:        comp.protocols.tcp-ip
Subject:   Changing KEEPALIVE Timers

I need to know if a process can change certain TCP timers. Some of the timers 
that I'd like to change are: TCPTV_KEEP, TCPTV_MAXIDLE, TCPTV_MAXKEEP.

I checked out setsockopt(), but it doesn't look like it's possible.

Is there any other function that might work (something similar to ioctl)?

Thanks for any help.

mac@devildog.att.com

-----------[000204][next][prev][last][first]----------------------------------------------------
Date:      Fri, 10 Dec 1993 17:58:58 GMT
From:      lillie@comm.mot.com (Ross Lillie)
To:        comp.protocols.tcp-ip
Subject:   IP Header IDENTIFICATION field

Is the IDENTIFICATION field of the IP header utilized *only* for packet
reassembly in the event of fragmentation?  Do any higher layer protocols
rely upon the IDENTIFICATION field for any type of event notification?

For example, ICMP inserts its own IDs into control message bodies when it
is required to uniquely identify some network event.  However I need to know
if applications/protocols exist (and are widely used) that use this field in
any (ugly) manner for their own purposes.

Any insight into the possible (mis)use of this header field in any widely
used protocols/applications would be very helpful.  Please email any responses
to the address below.

Thanks to all in advance,
--
Ross J. Lillie	    	    	    	    Email: lillie@comm.mot.com
LMPS Systems Research Lab   	    	    Phone: 708.576.0012
Motorola, Inc.	    	    	    	      FAX: 708.576.3240
1301 E. Algonguin Rd.  IL02/2240
Schaumburg, Illinois  60196

-----------[000205][next][prev][last][first]----------------------------------------------------
Date:      Fri, 10 Dec 1993 18:39:48 GMT
From:      ercm20@festival.ed.ac.uk (Sam Wilson)
To:        comp.protocols.tcp-ip
Subject:   Re: Physical address and Virtual address ?

Ken Mintz (mintz@cup.hp.com) wrote:
:   When talking about networking, "physical address" refers to the hardware
                                 ^^^^^^^^
:   address of an interface, also called the MAC address or station address,
:   for example 08-00-09-12-34-56.
 
:   Higher (TCP/IP) layers use IP addresses (for example, 15.13.104.4) to 
:   refer to systems.  The IP address must be translated into a hardware
                                                             ^^^^^^^^
:   address in order for the network interface to transmit the packet.

Just one word of warning: most ethernet interfaces have a unique address
assigned in logic or firmware by the manufacturer.  When running DECnet
phase 4 on ethernet the software changes the ethernet address of an
interface to include an encoded form of the higher-level DECnet address. 
DEC refer to the original, burnt-in address and the new modified address
as the physical address and the hardware address, but I can never
remember which is which.  In every other case you could expect terms
like 'physical address' and 'hardware address' to be interchangeable. 

Sam Wilson
Network Services Division
Computing Services, The University of Edinburgh
Edinburgh, Scotland, UK


-----------[000206][next][prev][last][first]----------------------------------------------------
Date:      10 Dec 1993 19:31:36 GMT
From:      kerch@reynaldo.PARC.Xerox.Com (Berry Kercheval)
To:        comp.protocols.tcp-ip
Subject:   Re: PCs and pings (a dreadfull combination)

>>>>> "Ran" == Ran Atkinson <atkinson@itd.nrl.navy.mil> writes:
In article <CHtFn2.DIJ@ra.nrl.navy.mil> atkinson@itd.nrl.navy.mil (Ran Atkinson) writes:
    Ran> In article <mills.755388363@dialup.athena.tay.dec.com>
    Ran> mills@athena.tay.dec.com (George Mills) writes:
    >> Now that the hotest things these days is automated network
    >> topoligy systems (NetView 6000), the PC's are hurting.
    >> Any Ideas on how to deal with this?

    Ran> Using ping(8) semi-continuously as a tool to determine
    Ran> network topology is unwise.  It consumes lots of bandwidth
    Ran> and causes many networking problems.  

Be that as it may, any TCP/IP stack that crashes when it gets a ping 
is BROKEN.  See rfc1122 (Host Requirements):

Section 3.1:
      The Internet layer of host software MUST implement both IP and
      ICMP.  See Section 3.3.7 for the requirements on support of IGMP.
Section 3.2.2:
      If an ICMP message of unknown type is received, it MUST be
      silently discarded.

3.2.2.6  Echo Request/Reply: RFC-792
      Every host MUST implement an ICMP Echo server function that
      receives Echo Requests and sends corresponding Echo Replies.
      A host SHOULD also implement an application-layer interface
      for sending an Echo Request and receiving an Echo Reply, for
      diagnostic purposes.

  --berry


--

Berry Kercheval :: kerch@parc.xerox.com 
"...start with Plan 9, which is free of sin..." -Mark V. Shaney


-----------[000207][next][prev][last][first]----------------------------------------------------
Date:      Fri, 10 Dec 1993 20:04:28 GMT
From:      rama@letaba.cs.rice.edu (Ramarao Kanneganti)
To:        comp.protocols.tcp-ip
Subject:   Help with examples in Unix Network programming ...

Hi,

I was told that the example code in Unix network programming book by
Richard Stevens is available on ftp. Can you please send me the ftp
address if you know?

Also, can you point some good books on Using Sockets in Unix?

Thanks a lot.
Rama

rama@cs.rice.edu



-----------[000208][next][prev][last][first]----------------------------------------------------
Date:      Fri, 10 Dec 1993 20:42:14 GMT
From:      diego@cs.ualberta.ca (Diego Novillo)
To:        comp.protocols.tcp-ip
Subject:   How do I get my own IP address?

I am running a Unix box at home and I would want to get my own IP address. I
would be using SLIP because I just have a regular phone line. Is this possible
to do? If so, how do I get one?

Thanks in advance.

Diego.

--
Diego A. Novillo                 | "Young enough not to care too much
University of Alberta            |  About the way things used to be
Computing Science Dept.          |  I'm young enough to remember the future
Internet: diego@cs.ualberta.ca   |  The past has no claim on me"
Edmonton, Alberta -- Canada      |               Rush - Counterparts

-----------[000209][next][prev][last][first]----------------------------------------------------
Date:      Fri, 10 Dec 1993 20:55:09 GMT
From:      sandstro@pinto.nas.nasa.gov (Timothy A. Sandstrom)
To:        comp.unix.internals,comp.protocols.tcp-ip,comp.unix.wizards
Subject:   sockets and signals

I've got a server-client environment where the server needs to send a
signal to the client [possibly on another platform]. I've been trying
to send a signal by writing an OOB message over the connecting
socket. 

Given:
------------------------------------------------------------------------------
client [immediately after socket connect established]:

external void sigurg_handler(int mesg);
external void sigio_handler(int mesg);

	signal(SIGURG, sigurg_handler);
	signal(SIGIO, sigio_handler);
	res = fcntl(module_data.command_socket, F_SETOWN, getpid());
	/* ... doing something interuptable and re-entrant ... */
------------------------------------------------------------------------------
server [sometime after socket connection established]:

#define ABORT_SIGNAL	(-1)
	int mesg = ABORT_SIGNAL;
	
	/* QUESTION: shouldn't this next call produce a SIGURG signal in the
	   the client process? Or do I need to poll the socket to determine
	   if there is an "execeptional condition" pending? */

	send( socket_desc, &mesg, sizeof(int), MSG_OOB );
------------------------------------------------------------------------------

Thanks in advance for any replies!

         :::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
         : Timothy A. Sandstrom        : Mail Stop N258-2            :
         : Sterling Software Inc.      : sandstro@nas.nasa.gov       :
         : NASA Ames Research Center   : PHONE : (415) 604-1429      :
         : Moffett Field, CA 94035     : FAX   : (415) 604-4377      :
         :-----------------------------------------------------------:
         :              Member of the FAST development team          :
         ::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: 

-----------[000210][next][prev][last][first]----------------------------------------------------
Date:      Fri, 10 Dec 1993 21:25:44 GMT
From:      skibo@florida.wpd.sgi.com (Thomas Skibo)
To:        comp.protocols.tcp-ip
Subject:   Re: PPP, satellite, extended window and VXWorks

In article <CHtFFx.DFq@ra.nrl.navy.mil>, atkinson@itd.nrl.navy.mil (Ran Atkinson) writes:
|> In article <CHqAq4.Jww@sci.kun.nl> albertk@cs.kun.nl (Albert Koppes) writes:
|> >2. Is anybody familiar with any implementation of extended windowsizes 
|> >according to RFC 1323 (or window scaling)  under VxWorks ?
|> 
|> VxWorks seems to have fairly off-the-shelf BSD networking code.  I
|> don't think it would be hard to port Tom Skibo's freely distributable
|> implementation of RFC-1323 into the VxWorks TCP/IP code.  The harder
|> problem is that the VMS machine probably won't support RFC-1323 _or_
|> use of VJ header compression.
|> 

If you can get it, try getting the mods from the BSD 4.4 code.  Some
bug fixes went into there that aren't in the Reno patch.

-- 

Thomas Skibo		Media Servers Division / Advanced Networking
skibo@sgi.com		Silicon Graphics, Inc.

-----------[000211][next][prev][last][first]----------------------------------------------------
Date:      10 Dec 1993 20:33:06 +0100
From:      urlichs@smurf.sub.org (Matthias Urlichs)
To:        comp.protocols.tcp-ip
Subject:   Re: uping - simple echo/reply program

In comp.protocols.tcp-ip, article <1993Dec6.151306.25213@afterlife.ncsc.mil>,
  ctkosti@afterlife.ncsc.mil (Chris Kostick) writes:
> 
> On almost every host that I have uping'd, the replying device only sends
> back at most 1024 octets of the orignal message.

ECHO is implemented by inetd. If inetd is using only a 1024-character buffer 
for the message, you're going to see only 1024 bytes coming back.

> sending 1464 octets to host shaiton
> 1024 octets received, seq = 0   time = 15.73 ms
> -1 octets received, seq = 0     time = 998.08 ms
> 1024 octets received, seq = 1   time =  9.01 ms
> 
Huh? The -1 is an error. Look at errno to see what the error message is.

-- 
COUVIER'S OBSERVATION:
There's nothing more frightening than ignorance in action.
-- 
Matthias Urlichs        \ XLink-POP Nürnberg   | EMail: urlichs@smurf.sub.org
Schleiermacherstraße 12  \  Unix+Linux+Mac     | Phone: ...please use email.
90491 Nürnberg (Germany)  \   Consulting+Networking+Programming+etc'ing      42

-----------[000212][next][prev][last][first]----------------------------------------------------
Date:      Fri, 10 Dec 93 23:40:33 GMT
From:      lars@spectrum.CMC.COM (Lars Poulsen)
To:        comp.protocols.tcp-ip
Subject:   Re: ** Question about Subnet Masking...

In article <1993Dec9.182405.11415@cnsvax.uwec.edu>
   Greg A Lato <latoga@cnsvax.uwec.edu> writes:
Lato>                                The problem concerning the
Lato> network is as follows.  I read a document that I downloaded
Lato> off of Hewlett Packard's Network Advisory BBS that talked
Lato> about subnet masking.  The most of it was rather technical and
Lato> I am not fully briefed on the finer points of tcp/ip.  The
Lato> jist of it said that when computers broadcast a message onto
Lato> the net they use the hex string HH-HH-HH-HH-HH-HH (which is
Lato> all ones in binary).  Some older systems, notable earlier
Lato> versions of BSD, will use the hex string representation of all
Lato> zeros.  Now if not all machines are are set to the same subnet
Lato> mask this will cause a "storm" of error messages coming from
Lato> ARP which has detrimental effects on your network. My first
Lato> question is....
Lato>  (1)  What exactly does the subnet mask do in such that not
Lato>  having all of them
Lato>       on your network set the same result in these storms?

There are a lot of misconceptions here, and at the risk of sounding
arrogant, I would hope there's someone around your facility who can
take some time to teach you a little more background about Ethernet,
IP and Network Management.

A byte of all-ones is conventionally written as FF in hex.
The kind of address that consists of 6 bytes (48 bits) is called a
MAC (Media Access Control) or hardware address. Indeed, a destination
address of all one bits (FF-FF-FF-FF-FF-FF) indicates a broadcast.

The kind of address that has subnet masks applied to it, is called
an IP address, and it is conventionally written as 4 decimal numbers
separated by dots. The IP address of my workstation is 193.89.36.2.
Computers attached to the same network have IP addresses that have
the first part in common. Often a facility will have several physical
cables. Traditionally, such a facility would get a class B network
number (16 bits of network number; all hosts have addresses where the
first two bytes are the same) and the hosts on the individual physical
networks would have an 8-bit field more in common. (The individual
networks would then be joined by routers.) In such a situation,
the NETMASK would be 255.255.0.0 (described in the same notation
as the IP addresses) and the SUBNETMASK would be 255.255.255.255.

Early systems (4.2BSD, and SunOS to this day as it comes from Sun)
used the localpart of zero to indicate broadcasts; soon, however,
it was defined that all ones in the local part would be a broadcast.

I.e. on my local network here, 193.89.36.0 versus 193.89.36.255.
Most hosts that believe that an address ending in zeroes is a
broadcast, think that an address ending in xx.yy.xx.255 is just another
host address. Most hosts, when they receive a packet that is not
addressed to them, will "forward" it, i.e. send it out in the direction
where they think it should go. In this case, that would be back out to
the ethernet, where all the other machines now get it (again) and
all the old/misconfigured ones forward it. This is known as a broadcast
storm, and it is very unhealthy.

Newer machines (again excluding Suns) know that if they received the
packets in a broadcast, they should not forward it. (Firm rule!!)

The best cure against this nonsense, is to turn off IP forwarding on
all machines that are not designated as routers. There is a simple
patch for this (patch a zero into the variable "_ipforwarding" with
adb). And while you are at it, fix the broadcast address, too.

Lato> We currenly have a HP Network Analyzer that we were using to
Lato> pickup packets with no source address and garbled destination
Lato> address.  For the most part the address had the first two set
Lato> of characters of H (ex. HH-HH-...), then they would be random
Lato> hex characters there after.
Lato>  (2)  Could this be resulting from not having all of our
Lato>  machines set with the
Lato>       same subnet mask?  If so, could you give a brief
Lato>       explanation of why; if not, could you give theories of
Lato>       what else might be causing this?

What the network analyzer is recording, is packet fragments caused by
collisions. When the broadcast storms are cured, look again.
-- 
/ Lars Poulsen			Internet E-mail: lars@CMC.COM
  CMC Network Products		Phone: (011-) +45-31 49 81 08
  Hvidovre Strandvej 72 B	Telefax:      +45-31 49 83 08
  DK-2650 Hvidovre, DENMARK	Internets: designed and built while you wait

-----------[000213][next][prev][last][first]----------------------------------------------------
Date:      Sat, 11 Dec 1993 00:50:52 GMT
From:      cml0464@ultb.isc.rit.edu (C.M. Leung)
To:        comp.security.misc,comp.protocols.tcp-ip
Subject:   Re: "large security gap in the Internet"

In article <1993Dec9.154747.14005@aber.ac.uk> ccs@aber.ac.uk (Christopher Samuel) writes:
>
>Far be it from me to fan the flames of a holy war, but try checking out
>SMail, it does all those (*including* greybook), and doesn't suffer from
>the same holes in it's SMTP implimentation as pre-8.6.4 sendmail did. 
>
>Oh yeah, I don't believe that sendmail 8.6.4 will work in the
>UK-sendmail package, as a flag that the CBS software requires is no
>longer present, so SMail may do one thing that 8.6.4 sendmail won't!
>
>Chris

I read somewhere that there is another tool called Multi-channel memo
Distribution Facility which is an alternative to sendmail.  Anyone has
experience with that one?

Regards

-----------[000214][next][prev][last][first]----------------------------------------------------
Date:      Sat, 11 Dec 1993 01:17:24 GMT
From:      nsuri@ai.uwf.edu (Niranjan Suri)
To:        comp.protocols.tcp-ip,comp.sys.ibm.pc.hardware.networking
Subject:   smc_wd packet driver and windows on MCA machine??

Hello - I've been trying to configure SMC_WD 11.7.3 packet driver to
run with 
Windows 3.1 on a PS/2 model 80. I've got the packet driver working well
with CUTCP, but as soon as as I try to bring up windows, the machine
will
lock up on the next command. I've tried with and without emm386 loaded.
Does anyone know if there is a known problem with this config? I got
the
SMC_WD packet driver out of the PC/TCP 2.3 release - they had stuck in
their
banner... The DOS is 5.0.2.... It's not smartdrive or the mouse....

==========   autoexec.bat   ==================================

C:\WINDOWS\SMARTDRV.EXE
PROMPT $p$g
PATH C:\WINDOWS;C:\DOS;c:\bin;c:\cutcp
C:\WINDOWS\mouse.COM /Y
c:\bin\smc_wd 0x60 
SET TEMP=C:\tmp
SET CONFIGTEL=C:\cutcp\config.tel
SET PATH=C:\PCTCP;%PATH%
SET PCTCP=C:\PCTCP\PCTCP.INI


==========    config.sys   ==================================

DEVICE=C:\dos\HIMEM.SYS
DOS=HIGH
DEVICE=C:\DOS\SETVER.EXE
FILES=30
DEVICE=C:\WINDOWS\SMARTDRV.EXE /DOUBLE_BUFFER
STACKS=9,256



Thanks In Advance, Tom Cowin


-----------------------------------------------------------------
Tom Cowin
Internet: tcowin@ai.uwf.edu
-----------------------------------------------------------------

-----------[000215][next][prev][last][first]----------------------------------------------------
Date:      11 Dec 1993 02:15:44 GMT
From:      tstark@clark.net (Tim Stark)
To:        comp.protocols.tcp-ip,comp.os.linux.help
Subject:   Help! Route problem!

    I have my own SLIP access to the internet world while my company have
its own network for internal use. Its network address is 14.0.0.0 while my
SLIP access is 198.17.243.88 (is linked to the real internet). After I
logined as SLIP and I no longer access to the company's network anymore and
can access to SLIP interface. :(

    My IP address is 198.17.243.88 on my own PC running Linux 0.99pl13.
    My company network address is 14.*.*.* with a router (14.211.3.20).
    My SLIP host address is 198.17.243.4 (SLIP router). 

My netstat -rn is:

Kernel routing table
Destination net/address   Gateway address           Flags RefCnt    Use Iface
default                   198.17.243.4              UGN        0     18 sl0
14.211.0.0                *                         UH         0      0 eth0
127.0.0.1                 *                         UH         0      0 lo
198.17.243.4              *                         UH         0      0 sl0

    I can't access to 14.211.0.0 while I can access to 198.17.243.4 for
rest of the world. :(

    How do I access both internal network and SLIP network in the same time?
Help! If so, I will appericate that. Thanks you!!!

-- Tim Stark

--
Timothy Stark			Inet: tstark@clark.net
6130 Edsall Rd. #301		TDD: (703)212-9731  FAX: (703)212-7598
Alexandria, Va. 22304-5859	Voice: Via VA Relay Center (800)828-1140
"God bless you! - My friend, Washington DC. - The Most Deaf Population City!"

-----------[000216][next][prev][last][first]----------------------------------------------------
Date:      11 Dec 1993 02:34:48 GMT
From:      gsteckel@harpoon.East.Sun.COM (Geoff Steckel - Sun BOS Hardware CONTRACTOR)
To:        comp.dcom.isdn,comp.protocols.tcp-ip,comp.dcom.cell-relay
Subject:   Re: Why connectionless ?

Just to throw some gasoline on the waves/flames.  You can guess my bias!
In article <1993Dec10.142841.24569@bcarh54a.bnr.ca> coghlan@bcarh5f8.bnr.ca (Patrick Coghlan) writes:

>Well, isn't X.25 implementable and useful?

When it first came out, there was at least 1 fatal error in the spec.
Lotsa red faces over that one!
It also required major surgery to handle significant transmission delay.
It also (still) has some serious problems with transient circuit disruption.

>Today, corporations use LAN technology at each site but rely more on 
>protocols like X.25 and frame-relay to interconnect them through
>commercial carriers.

Because they have to, in most cases.

>Eventually, ATM hubs and backbone networks will supplant existing LAN
>technology.

Maybe.  And maybe us get-the-*!@-job-done types will be running our TCP/IP, etc
OVER the physical layer, just the way we always have.

>Just one key point, most homes/businesses have a point-of-presence on
>the public network (phone company).  It is this network that will form
>the backbone for most services.  It is far more likely that these services
>will run on top of a protocol such as frame-relay or ATM rather than the
>Internet protocols.

You (and the telco in general, and ATMers in general) miss the point.  TCP/IP,
etc., run OVER any kind of connection that can be made.  ATM could be one of
many MEANS to the end of communication.  (There is one problem, which is being
firmly pushed under the rug by ATMers, which is the way congestion/packet
loss is handled.  Disaster!).

I am connected over the public phone network.  I can use X.25, or PPP, or
whatever.  If I _have_ to use one protocol/stack, then I am no longer getting
_service_ that I want.

The telco types don't understand that (most) data applications can tolerate
delay _much_ better than they can tolerate data loss.  If there is _any_
possibility of data loss, then an end-to-end protocol between the data
source and sink must be implemented - thus TCP/IP & co.  ATM can't solve
the problem alone.  For ATM to succeed for data transmission in the real
world, either the switches or the endpoints must have _massive_ buffers,
equal to end-to-end-check-time * data-rate.  Otherwise data will be lost,
which is unacceptable.

(Whew.  Exxon Valdez mode off)

-- 
	geoff steckel (gwes%om3@trilobyte.com)
Disclaimer: I am not affiliated with Sun Microsystems, despite the From: line.
This posting is entirely the author's responsibility.

-----------[000217][next][prev][last][first]----------------------------------------------------
Date:      Sat, 11 Dec 1993 05:23:07 GMT
From:      rossw@ccu1.aukuni.ac.nz (Ross Williamson)
To:        comp.protocols.tcp-ip
Subject:   Re: Is Telnet 127.0.0.1 more efficient?

manager@netcentral.nchu.edu.tw (Lee Chee Siong) writes:

>Hi,
>   A good question but make me confuse.
 
>   Suppose I am in 140.120.1.21 (a unix system)
>     (1). Telnet 140.120.1.21
>     (2). Telnet 127.0.0.1  i.e. loopback
>   Both (1) and (2) can telnet to the same machine.
 
>   Is case (1) can work more efficient than (2)?

They should be about the same.  The only thing that should make a
difference is if you use a name rather than an address.

----
Ross Williamson
rossw@ccu1.auckland.ac.nz
Auckland University, New Zealand
Of course these opinions are my own and thank <!!> for that
                               ----
        Once upon a time, in a little directory, there was a bug.
        A big, bad, evil bug.  But then one day, the mighty programmer
        came and slew it, and there was much rejoicing.


-----------[000218][next][prev][last][first]----------------------------------------------------
Date:      11 Dec 1993 09:14:03 GMT
From:      root@jacobs.mn.org (Mike Horwath)
To:        comp.protocols.tcp-ip,comp.os.linux.help
Subject:   Re: Help! Route problem!

Tim Stark (tstark@clark.net) wrote:
:[about his network]
 
:     My IP address is 198.17.243.88 on my own PC running Linux 0.99pl13.
:     My company network address is 14.*.*.* with a router (14.211.3.20).
:     My SLIP host address is 198.17.243.4 (SLIP router). 
 
: My netstat -rn is:
: Kernel routing table
: Destination net/address   Gateway address           Flags RefCnt    Use Iface
: default                   198.17.243.4              UGN        0     18 sl0
: 14.211.0.0                *                         UH         0      0 eth0
: 127.0.0.1                 *                         UH         0      0 lo
: 198.17.243.4              *                         UH         0      0 sl0
 
:     I can't access to 14.211.0.0 while I can access to 198.17.243.4 for
: rest of the world. :(
 
:     How do I access both internal network and SLIP network in the same time?
: Help! If so, I will appericate that. Thanks you!!!
 
: Timothy Stark			Inet: tstark@clark.net

 This is not that hard to fix, do this:

 route del 198.17.243.4
 route add <your normal IP on network 14.211.0.0> eth0

 then you should now be fine.  here is my network setup:

Kernel routing table
Destination net/address   Gateway address           Flags RefCnt    Use Iface
default                   134.84.101.120            UGN        0 104073 sl0
192.20.2.0                *                         UN         0      0 eth0
134.84.101.0              *                         UN         0   1582 sl0
192.20.2.128              *                         UH         0  39824 eth0
127.0.0.1                 *                         UH         0 171436 lo

I hope this helps.

--
Mike Horwath    IRC: Drechsau   BBS: Drechsau   LIFE: lover
root@jacobs.mn.org  drechsau@jacobs.mn.org
Jacob's Ladder  612-588-0201  UUCP, UseNet, Linux files, BBS

-----------[000219][next][prev][last][first]----------------------------------------------------
Date:      11 Dec 93 11:50:17 GMT
From:      pete@tecc.co.uk (Pete Bentley)
To:        comp.security.misc,comp.protocols.tcp-ip
Subject:   Re: "large security gap in the Internet"

C.M. Leung (cml0464@ultb.isc.rit.edu) wrote:
 >> I read somewhere that there is another tool called Multi-channel memo
 >> Distribution Facility which is an alternative to sendmail.  Anyone has
 >> experience with that one?

You mean MMDF. :-)
Yes - we use it all the time.  It's generally quicker to port MMDF
to a new machine than to try and set up a working sendmail.cf (but
that's just me).  There hasn't been any real development work on
MMDF for years --- the original authors went on to produce PP as
a replacement.  Some of us just never got around to learning enough
about PP to use it instead of MMDF.  One of the nicer features of
MMDF (and PP) are the way the mail channels are modular, so incoming
SMTP mail is handled by a small program that simply injects the mail
into the main queue.  Of course, the main queue handler is still too
big and complex to fully understand and so may contain security holes...

Pete.

-----------[000220][next][prev][last][first]----------------------------------------------------
Date:      11 Dec 93 17:09:04 GMT
From:      jamie@clark.net (Jamie H. Clark)
To:        comp.protocols.tcp-ip,comp.os.linux.help
Subject:   Re: Help! Route problem!

Mike Horwath (root@jacobs.mn.org) wrote:
: Tim Stark (tstark@clark.net) wrote:
: :[about his network]
 
: :     My IP address is 198.17.243.88 on my own PC running Linux 0.99pl13.
: :     My company network address is 14.*.*.* with a router (14.211.3.20).
: :     My SLIP host address is 198.17.243.4 (SLIP router). 
 
: : My netstat -rn is:
: : Kernel routing table
: : Destination net/address   Gateway address           Flags RefCnt    Use Iface
: : default                   198.17.243.4              UGN        0     18 sl0
: : 14.211.0.0                *                         UH         0      0 eth0
: : 127.0.0.1                 *                         UH         0      0 lo
: : 198.17.243.4              *                         UH         0      0 sl0
 
: :     I can't access to 14.211.0.0 while I can access to 198.17.243.4 for
: : rest of the world. :(
 
: :     How do I access both internal network and SLIP network in the same time?
: : Help! If so, I will appericate that. Thanks you!!!
 
: : Timothy Stark			Inet: tstark@clark.net
 
:  This is not that hard to fix, do this:
 
:  route del 198.17.243.4
:  route add <your normal IP on network 14.211.0.0> eth0

What if he tries to access a site in Internet? so he would need
default gateway for address that are not in local networks.

route add default 198.17.243.1
route add 198.17.243.0 198.17.243.88

198.17.243.1 is the router connected to the Internet.
198.17.243.88 is slip port on Tim's Linux PC.

So any address not in routing table will go to the 198.17.243.1
(router.clark.net) and in order to access 198.17.243.0 network,
just go to SLIP port.

I am not sure about Linux's route and routed commands, 
how can he make it static so it won't have to depend on RIP update?

He will run routed, so his routing table will get updates from
routers on his company's internal network.

:  then you should now be fine.  here is my network setup:
 
: Kernel routing table
: Destination net/address   Gateway address           Flags RefCnt    Use Iface
: default                   134.84.101.120            UGN        0 104073 sl0
: 192.20.2.0                *                         UN         0      0 eth0
: 134.84.101.0              *                         UN         0   1582 sl0
: 192.20.2.128              *                         UH         0  39824 eth0
: 127.0.0.1                 *                         UH         0 171436 lo
 
: I hope this helps.
 
: --
: Mike Horwath    IRC: Drechsau   BBS: Drechsau   LIFE: lover
: root@jacobs.mn.org  drechsau@jacobs.mn.org
: Jacob's Ladder  612-588-0201  UUCP, UseNet, Linux files, BBS

--
Jamie Clark, jamie@clark.net| ClarkNet Public Access Internet, info@clark.net,
Dial-up shell, SLIP/PPP & UUCP, Modem (410) 730-9786, login guest | "Knowledge
is power; the ability to acquire knowledge at will is more powerful."  (Jamie)

-----------[000221][next][prev][last][first]----------------------------------------------------
Date:      Sat, 11 Dec 1993 17:44:34 GMT
From:      rlm@netcom.com (Robert McMillin)
To:        comp.sys.sgi.bugs,comp.protocols.tcp-ip
Subject:   Re: X11 and DECNET

On Sat, 11 Dec 1993 00:01:58 GMT, "RANDOLPH J. HERBER, HERBER@FNALA.FNAL.GOV, +1 708 840 2966, CD/HQ - CDF" <HERBER@fnalv.fnal.gov> said:

>     To paraphase N. Khruschev, `IP with TCP and UDP will bury OSI'.  And,
>     in the sense of the original Russian, TCP/IP will not kill OSI; but,
>     it will be at the graveside throwing dirt on the corpse.  X.400 and
>     X.500 may survive.  Even DECnet with most of its ills repaired by
>     DECnet Phase V may be at the funeral.
 
>     OSI will die of its immaturity, lack of good implementations, and expense.

Very likely.  And I don't hold out much promise for X.400 and X.500,
either, even despite the purported "simplification" of X.400 from
seven to four addressing fields (Texaco et al. proposed this one).
Open Systems Today publishes these brave little articles about X.400
finally fixing this or that problem, when in the real world, it's
pretty clear that domain addressing and SMTP is carrying the huge bulk
of mail traffic, and that one of its descendants will reach down and
crush X.400 with sheer dominance...
-- 
Robert L. McMillin | rlm@helen.surfcty.com (preferred) | rlm@netcom.com

"[The] Internet is like a giant jellyfish.  You can't step on it.  You can't
go around it.  You've got to go through it."

	-- John Evans, Pres. of News Corp.'s Electronic Data division, on
	   why that company purchased Delphi Internet Services Corp.


-----------[000222][next][prev][last][first]----------------------------------------------------
Date:      11 Dec 93 17:45:50 GMT
From:      km@mathcs.emory.edu (Ken Mandelberg)
To:        comp.protocols.tcp-ip,comp.dcom.lans
Subject:   Security on Cisco 7000

We just moved from local Cisco routers in our building, to a shared
Cisco 7000 box at a central location. The problem is that while we had
full control of the local routers, thats a problem with the shared
7000.

Is there any provision in the 7000 to give configuration permissions in
something less than a global way: Per port, certain paramters, etc?


---
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

-----------[000223][next][prev][last][first]----------------------------------------------------
Date:      11 Dec 93 19:57:52 GMT
From:      muh@physics1 (Yury M. Mukharsky)
To:        comp.protocols.tcp-ip
Subject:   Remote control program for PC?

Dear netters,

Does anybody know about remote control program, which will work over TCP/IP.
Something to connect PC linked by Ethernet to campus network to home computer.
So I could login to UNIX machine, run something and connect to PC. In simpest
case any of multitude of serial-port remote control programs will do, if it
can be setup to operate via BIOS, instead of talking directly to the UART chip.
I could run net14 and fool the program. On UNIX host I can "short circuit" two ports
and connect to other one from home.

Any advices?

Yury

-----------[000224][next][prev][last][first]----------------------------------------------------
Date:      12 Dec 1993 09:18:26 -0000
From:      barryf@iol.ie (Barry Flanagan)
To:        comp.protocols.tcp-ip
Subject:   Re: Remote control program for PC?

Yury M. Mukharsky (muh@physics1) wrote:
: Dear netters,
 
: Does anybody know about remote control program, which will work over TCP/IP.
: Something to connect PC linked by Ethernet to campus network to home computer.
: So I could login to UNIX machine, run something and connect to PC. In simpest
: case any of multitude of serial-port remote control programs will do, if it
: can be setup to operate via BIOS, instead of talking directly to the UART chip.
: I could run net14 and fool the program. On UNIX host I can "short circuit" two ports
: and connect to other one from home.

Well Doorway will do the DOS redirecting, and can use BIOS or FOSSIL to talk to the
comm port. Try archie for drwy220.zip.

Where can I get net14?

-- 
Barry Flanagan - <barryf@iol.ie>
 ----
| Ireland On-Line, West Wing, Udaras Complex, Furbo, Galway,Ireland
| Tel/Fax : +353 91 92727 / 26 * BBS : +353 91 92722 (4 Lines)

-----------[000225][next][prev][last][first]----------------------------------------------------
Date:      Sun, 12 Dec 1993 11:45:53 +0000
From:      col@sensorat.demon.co.uk (Colin Roughley)
To:        comp.protocols.tcp-ip
Subject:   Re: dos version of TALK anywhere?

In article <1993Dec1.122902.205646@uctvax.uct.ac.za> weissman@uctvax.uct.ac.za writes:

>Hello,
>
>I am trying to find a version of internet TALK which will run on dos machines.
>Does anyone know where to find such a critter??
>
>Avrohom Weissman
>Weissman@uctvax.uct.ac.za
>University of Cape Town   South Africa
>
>

If you manage to track this elusive little critter down, I would really  
appreciate any info. that you get.

Cheers.

-- 
Colin Roughley
Col@senorat.demon.co.uk

-----------[000226][next][prev][last][first]----------------------------------------------------
Date:      13 Dec 1993 02:10:32 -0800
From:      skl@Connectivity.com (Samuel Lam)
To:        comp.protocols.tcp-ip
Subject:   Re: Lattisnet, what and who.

In article <CHxB8A.CC3@matilda.vut.edu.au>, nick@matilda.vut.edu.au
 (Michael Bethune) wrote:
>Does anyone know of a product called LattisNet, what is it.
>What does it do and whose is it?

It's pre-10BASE-T twisted-pair Ethernet, and its vendor is Synoptics.

Synoptics can be reached at 800-PRO-NTWK or 408-988-2400.  The number
for their Kew, Victoria, Australia office is 61-3-853-0799.

...Sam
-- 
<skl@Connectivity.com> -- Connectivity Technology Inc.

"NetNews on CD's" product information: <NewsCD@CDPublishing.com>
			   or {ftp,gopher,www}.CDPublishing.com


-----------[000227][next][prev][last][first]----------------------------------------------------
Date:      Sun, 12 Dec 1993 13:09:46 GMT
From:      nick@matilda.vut.edu.au (Michael Bethune)
To:        comp.protocols.tcp-ip
Subject:   Lattisnet, what and who.

Does anyone know of a product called LattisNet, what is it.
What does it do and whose is it?
-- 
------------------------------------
-  Michael Bethune             -----  
--  Independent UNIX Consultant.----
---  Michael Bethune and Assoc.  ---

-----------[000228][next][prev][last][first]----------------------------------------------------
Date:      Sun, 12 Dec 1993 13:19:18 GMT
From:      nick@matilda.vut.edu.au (Michael Bethune)
To:        comp.protocols.tcp-ip,comp.protocols.cisco
Subject:   OSPF, experience?

Does anyone have practical experience of OSPF,
particularly on large networks in excess of 1000 hosts?

Whats it servicability.

I've heard, for instance, that changes in topology can cause outages whilst
the network converges which can result in problems with flaky lines.

The protocol seems to require a large management overhead. Is this true.
-- 
------------------------------------
-  Michael Bethune             -----  
--  Independent UNIX Consultant.----
---  Michael Bethune and Assoc.  ---

-----------[000229][next][prev][last][first]----------------------------------------------------
Date:      Sun, 12 Dec 1993 14:47:42 GMT
From:      ucacjon@ucl.ac.uk (Jon Crowcroft)
To:        comp.dcom.isdn,comp.protocols.tcp-ip,comp.dcom.cell-relay
Subject:   Re: Why connectionless ?

In article <1993Dec10.142841.24569@bcarh54a.bnr.ca>, coghlan@bcarh5f8.bnr.ca (Patrick Coghlan) writes:
|> In article <STEINAR.HAUG.93Dec10124100@runit.sintef.no>, Steinar.Haug@runit.sintef.no (Steinar Haug) writes:
 
|> Well, isn't X.25 implementable and useful?

not really.
 
|> Today, corporations use LAN technology at each site but rely more on 
|> protocols like X.25 and frame-relay to interconnect them through
|> commercial carriers.

yes frame relay, no, not x.25 - in europe more people use anything but...
|> 
|> Eventually, ATM hubs and backbone networks will supplant existing LAN
|> technology.

disagree - hubs wil lreplace backbone,s but if 100base vg or whatever
its called this week, or dec personal ether etc take off, and video compression
chips get cheap, why would anyone run anything but IP, IPX  or their successor
to the desk top?

|> Just one key point, most homes/businesses have a point-of-presence on
|> the public network (phone company).  It is this network that will form
|> the backbone for most services.  It is far more likely that these services
|> will run on top of a protocol such as frame-relay or ATM rather than the
|> Internet protocols.

it is key that ATM _may_ provide LAN Hubs and WAN backbones, but it is moot whether
it'll do much more...there are many other emergent technologies that'll do 10Mbps to every 
home

however, that doesnt stop it being fun trying....

the real argument, by the way, that x.25 lost was not the 'conenction versus datagram' one,
 it was the need for hop-by=hop backpressure flow control and erropr recovery...which,
 you will note, ATM does NOT propose - (i know some purist will say x.25 is an interface,but
most people implemented and interpreted it as i've said...)...

also note that resoruce reservation is being added to IP, so we have a convergence on
what is the right way to build multiservice networks....between ietf and ITU!

now, can anyone point me at a spec on how to do G.703 or other circuit emulation over
AAL1?

thanks


-- 
jon crowcroft (hmmm...)

-----------[000230][next][prev][last][first]----------------------------------------------------
Date:      Sun, 12 Dec 1993 15:19:09 GMT
From:      Chuck Smoko <csmoko@nswc.navy.mil>
To:        comp.protocols.tcp-ip
Subject:   Richard Stevens book in Wayne's World 2

Hey folks,
I just saw "Wayne's World 2" yesterday and noticed that Garth's new
girlfriend is carrying a copy of "Unix Network Programming".  It must
be a well read title, because even Garth seemed to be familiar with
it.

							chuck smoko

PS: The clip that I am speaking of was at the very end of the movie.

                        csmoko@nswc.navy.mil

   __                             __       ()
  /  ) /           /)            /  )      /\               /
 /    /_  __. __  // _  _       /--/      /  )  ____   ____/_  __
(__/ / /_(_(_/ (_(/_(<_/_)_    /  ( o    /__/__/) ) )_(_) / <_(_)

-----------[000231][next][prev][last][first]----------------------------------------------------
Date:      13 Dec 1993 05:24:08 -0800
From:      koreth@spud.Hyperion.COM (Steven Grimm)
To:        comp.protocols.tcp-ip,comp.unix.admin
Subject:   tcptop posted to alt.sources

I've posted "tcptop", a SunOS 4.x utility for monitoring active TCP
connections going across an Ethernet (actually a fancy frontend for
the "etherfind" program) to alt.sources.  Check it out if you're
interested in that sort of thing.  If you don't get alt.sources, it
is also available via ftp from ftp.hyperion.com in /pub.

-Steve

-----------[000232][next][prev][last][first]----------------------------------------------------
Date:      12 Dec 93 22:22:34 GMT
From:      jwhite@efn.org (Jeremy White)
To:        comp.protocols.tcp-ip
Subject:   ftpsites for PC Slip

Does anyone know where to ftp SLIP for the PC????

-----------[000233][next][prev][last][first]----------------------------------------------------
Date:      13 Dec 1993 08:29:48 -0500
From:      tim@jade.spctrm.com (Tim Fry)
To:        comp.protocols.tcp-ip
Subject:   Info on T_ERROR t_look() return value

Hi, 

Can anyone provide more information on what a T_ERROR return value from the 
TLI t_look(NSL) call means. The man page I am looking at describes it only as 
being a "fatal error condition" -- I presume this means that it is a value 
resulting from a severe problem in the underlying transport provider (in my 
case TCP). Is there any more information that can be obtained?  t_errno is 
only documented as being set when the call actually fails (returns -1 instead 
of T_ERROR). Will errno ever be set for instance?

I'm running this binary on a Wyse 7000i SVR4 machine and the condition only 
crops up under heavy TCP traffic load. The binary was compiled on Interactive 
3.2.

One curious thing I noticed is that T_ERROR is documented as being a t_look() 
return value in Interactive, RS6000/AIX and SCO but not on the Wyse (although 
it exists with the same numeric value in /usr/include/sys/tiuser.h ) or on 
Ultrix. Does this indicate a change in the TLI standard since SVR3/AIX?

Thanks for any help

----
Tim Fry                      Spectrum Systems Inc
tim@spctrm.com               214 King Street West, Suite 310
Tel: (416) 592 1384          Toronto Ont. M5H 3S6
Fax: (416) 592 1392          Canada

-----------[000234][next][prev][last][first]----------------------------------------------------
Date:      Mon, 13 Dec 1993 15:20:58 -0800
From:      frank@calcom.socal.com (Frank Keeney)
To:        comp.protocols.tcp-ip
Subject:   Remote control program for PC?

On Dec 11 19:57, Yury M. Mukharsky wrote:

 > Does anybody know about remote control program, which will 
 > work over TCP/IP. Something to connect PC linked by Ethernet 

Try Telnetd which is available at most ftp sites. Or for a much better
commercial program for $150.00 try Everywhere Access from SNSI at (705)
652-1572 or info@snsi.com.

  Frank

 * Origin: yume no naka ni... (1:102/645)

-----------[000235][next][prev][last][first]----------------------------------------------------
Date:      Mon, 13 Dec 1993 02:29:25 GMT
From:      lawson@netcom.com (Steven Lawson)
To:        comp.protocols.tcp-ip
Subject:   Re: Richard Stevens book in Wayne's World 2

Chuck Smoko (csmoko@nswc.navy.mil) wrote:
: Hey folks,
: I just saw "Wayne's World 2" yesterday and noticed that Garth's new
: girlfriend is carrying a copy of "Unix Network Programming".  It must
: be a well read title, because even Garth seemed to be familiar with
: it.
 
: 							chuck smoko
 
: PS: The clip that I am speaking of was at the very end of the movie.

No WAY....   :-) 

-----------[000236][next][prev][last][first]----------------------------------------------------
Date:      Mon, 13 Dec 1993 03:50:46 GMT
From:      hmchen@fcom.ee.ntu.edu.tw (Hung-ming Chen)
To:        comp.protocols.tcp-ip
Subject:   [Q] Keep a permanent connection or connect when using?

Hi Netters,

  I am writing some network programs. In these programs I will
transfer burst data amoung computers. Now I design the
programs keeping permanent socket connections. But It seems
sometimes get troubles. Especially, a client computer
disconnects abnormally, the server program will go mad, it
receives a unknown signal from the network repeatly. 

  Could some help me to solve it? Or should I connect when
some data want to send and then disconnect immediately when
the data is sent? But it has some difficulties, the data may
send out to more than one computer or many differnt types of
data to a same one in a short moment. 

  What should I do for such a system? Any advice is
appropriate.

Thanks in advance.

Fred Chen

-----------[000237][next][prev][last][first]----------------------------------------------------
Date:      13 Dec 93 13:49:46
From:      Steinar.Haug@runit.sintef.no (Steinar Haug)
To:        comp.protocols.iso,comp.protocols.tcp-ip
Subject:   Re: Why Connectionless Services were included

> Each service for its use!  But: There are in fact very few UDP-based
> application protocols (at least when measured by bytes transferred!) -
> and even fewer where it is a good choice (an example where it is NOT: 
> Remote procedure calls, in the general case).

1. The amount of DNS traffic in the Internet is most definitely significant.
Just ask any of the service providers.

2. The amount of NFS traffic in many LAN environments is also significant.

Both of these use UDP. We can discuss endlessly whether they *should* use
UDP or not, but the fact is that they (mostly) do.

("Mostly", because there are TCP-based NFS implementations, which may work
better in the WAN case, and DNS zone transfers use TCP instead of UDP).

You seem to imply that RPC in the general case should use a connection-oriented
protocol. I'm not at all convinced that a majority of RPC researchers and/or
users would agree with you...

Steinar Haug, system/networks administrator
SINTEF RUNIT, University of Trondheim, NORWAY
Email: Steinar.Haug@runit.sintef.no, Steinar.Haug@delab.sintef.no

-----------[000238][next][prev][last][first]----------------------------------------------------
Date:      13 Dec 93 14:13:05
From:      Steinar.Haug@runit.sintef.no (Steinar Haug)
To:        comp.protocols.iso,comp.protocols.tcp-ip
Subject:   Re: Issue for dicussion - Connection Oriented Vs Connectionless  Protocols

> >transaction processing folks would have very very serious problems with the
> >number of packets you HAVE to exchange to get presentation syntax negotiated after session
> >setup, after transport asetup 
>
> An interresting question. Do you have the answer? How many packets do
> you HAVE to send?  There are of course (at least) two cases - Session
> may re-use a Transport connection, or it may establish a new one. At
> the lower level, it depends eg. on chosen TP.

In the most extreme case, the answer is fairly simple: 3 packets must be
exchanged.

- First packet (A to B) is connection setup + transaction data + request for
connection termination.

- Second packet (B to A) is ack of connection setup + transaction response
(commit OK) + ack of connection termination.

- Third packet (A to B) is ack of transaction response.

Under some circumstances, this can even be shortened to two packets.

Such transactions cannot be done with normal TCP, but see RFC 1379 for a
proposed extension to TCP to support such transactions.

It's quite clear that if you're aiming for three-packet transactions, you
don't have time to wait for negotiation at each layer.

Steinar Haug, system/networks administrator
SINTEF RUNIT, University of Trondheim, NORWAY
Email: Steinar.Haug@runit.sintef.no, Steinar.Haug@delab.sintef.no

-----------[000239][next][prev][last][first]----------------------------------------------------
Date:      13 Dec 1993 10:04:55 GMT
From:      tomw@kalpana.com (Tom Walsh)
To:        comp.protocols.tcp-ip
Subject:   Re: Richard Stevens book in Wayne's World 2

In article Jry@netcom.com, lawson@netcom.com (Steven Lawson) writes:
> Chuck Smoko (csmoko@nswc.navy.mil) wrote:
> : Hey folks,
> : I just saw "Wayne's World 2" yesterday and noticed that Garth's new
> : girlfriend is carrying a copy of "Unix Network Programming".  It must
> : be a well read title, because even Garth seemed to be familiar with
> : it.
 
> : 							chuck smoko
 
> : PS: The clip that I am speaking of was at the very end of the movie.
> 
> No WAY....   :-) 

Way!

---
----------*----------*----------*---------*---------*---------*
Tom Walsh

"To Internet or not to Internet, That is the question"

			( 408 ) 749-1600 ext 153
			( 408 ) 749-1690 ( FAX )
			internet: tomw@kalpana.com
				  tomw@netcom.com
---------*----------*----------*---------*---------*---------*



-----------[000240][next][prev][last][first]----------------------------------------------------
Date:      Mon, 13 Dec 1993 10:15:34 GMT
From:      yates@lgx.unisys.ch (Craig Yates Unisys Bern)
To:        comp.sys.sun.admin,comp.protocols.tcp-ip
Subject:   TCP/IP Sun <-> IBM ES 9000


We are trying to connect from our SUN SS10 (4.1.3) to an IBM ES9000 
running MVS/ESA 4.2.0 under VM/XA 2.1.  

From the IBM to our machine(the Sun), there is no problem, but we 
get either "Connection refused" for rcp/rlogin or for telnet :-
Sun$ telnet ibm
    Connected to 156.25.11.10
    Escape character  is ^]
    ACC4091 VLT ERROR: VLT RC=14
    Connection closed by foreign host

Now the people installing the IBM have been and gone, and I cannot
get them to debug the IBM configuration.  I do not know MVS, or
have the time to learn it.  Any ideas ?.  Email replies preferred.  

Thanks
-- 
yates@lgx.unisys.ch       "Snow is cool"
Craig B. Yates            ++41 31 380 3727
UNISYS AG                 ++41 31 372 0485 - FAX
Chutzenstrasse 24

-----------[000241][next][prev][last][first]----------------------------------------------------
Date:      Mon, 13 Dec 1993 13:01:41 GMT
From:      djn@csc.liv.ac.uk (David Nixon)
To:        comp.windows.x,comp.sys.sun.misc,comp.protocols.tcp-ip,comp.unix.internals
Subject:   Re: Cannot accept chooser connection Software caused connection abort

Ian Dickinson (cudep@csv.warwick.ac.uk) wrote:

> In article <2d299r$a8t@spatula.csv.warwick.ac.uk> I wrote:
> >I'm having regular problems with MIT X11R5pl24 xdm running under SunOS4.1.3.
> >The parent xdm daemon is eating up large amount of our machine.

I posted a detailed description of this problem - as encountered under HP-UX
8.07 - to comp.unix.internals during the summer: No replies: either
knowledgeable people were all on holiday, or I posted it to the wrong group.

> >
[ Description deleted of the R5 XDM looping around a select() call as its
"chooser" TCP socket indicates data to be read; but attempts to accept() the
connection fail with the error ECCONABORTED ]

This error is not documented by HP but comments in the BSD 4.3 source code
define describe it as the *Protocol* having detected that the peer will send no
more data. I found that the problem would typically occur after of few hours
of XDM activity on some busy machines. Disabling the use of  "indirect" X11 
queries; and hence connections to the "chooser" socket, did not resolve the
problem.


> Anyone got any better ideas?

Unable to find what was causing select() to trigger on the chooser socket - in
the absence of requests for chooser service - I disabled this feature of
XDMR5. (The other thing I disliked about running the "chooser" was the way 
"chooser" processes would hang around even if their DISPLAY host was powered
off.)

At the moment for booting discless "Xterminals" I use 'direct' requests  with
hostnames taken in round-robin fashion from a list. As a slight refinement,  
hosts are checked to be up before their name is issued to the X term starting
X11.

[ Anyone like to comment on the "fairness", or otherwise, of using 
'broadcast' XDM requests with large numbers of clients and potential hosts on
a LAN. ]

> Am I on the right track?

Well you have given a good enough description of the problem.

> Cheers,
> -- 
> Ian 'Vato' Dickinson - NIC handle: ID17                           Kibo bait :-)

David Nixon -- Computer Science Dept. University of Liverpool


-----------[000242][next][prev][last][first]----------------------------------------------------
Date:      13 Dec 1993 15:15:02 GMT
From:      dbld@ccmailpc.ctron.com (Duane Dixon)
To:        comp.protocols.tcp-ip
Subject:   TFTP DOS based?

Greetings all,

	We are curious, here, if there is a stand-alone DOS based TFTP 'daemom'
that will run on a networked DOS machine and download requested files via
TFTP download.

	Any help would be greatly appreciated.


d^2
---
                                 Duane Dixon
                         Cabletron Technical Support
            Email: dbld@wraith.ctron.com or dbld@ccmailpc.ctron.com

-----------[000243][next][prev][last][first]----------------------------------------------------
Date:      Mon, 13 Dec 1993 15:32:24 GMT
From:      ketil@edb.tih.no (Ketil Albertsen,TIH)
To:        comp.protocols.iso,comp.protocols.tcp-ip
Subject:   Re: Issue for dicussion - Connection Oriented Vs Connectionless  Protocols

In article <STEINAR.HAUG.93Dec13141305@runit.sintef.no>, 
Steinar.Haug@runit.sintef.no (Steinar Haug) writes:

[re: Number of packets for conn. establishment: ]

>In the most extreme case, the answer is fairly simple: 3 packets must be
>exchanged.

The question was brought up in an OSI-oriented frame of reference;
do you happen to have similar figures for OSI connections?


-----------[000244][next][prev][last][first]----------------------------------------------------
Date:      Mon, 13 Dec 1993 16:17:43 GMT
From:      coghlan@bcarh5f8.bnr.ca (Patrick Coghlan)
To:        comp.dcom.isdn,comp.protocols.tcp-ip,comp.dcom.cell-relay
Subject:   Re: Why connectionless ?

In article <2ebbk8$646@dr-pepper.East.Sun.COM>, gsteckel@harpoon.East.Sun.COM (Geoff Steckel - Sun BOS Hardware CONTRACTOR) writes:
 
|> You (and the telco in general, and ATMers in general) miss the point.  TCP/IP,
|> etc., run OVER any kind of connection that can be made.  ATM could be one of
|> many MEANS to the end of communication.  (There is one problem, which is being
|> firmly pushed under the rug by ATMers, which is the way congestion/packet
|> loss is handled.  Disaster!).

Modern packet networks don't lose packets very often (1 in 10**6 packets).  
Anyway, packet recovery occurs at the endpoints of communication with
TCP/IP.  ATM networks would also do this recovery at the endpoints.  Where 
is the disaster in this?

ATM networks send congestion notification to each traffic source and 
expect them to back off.  Doesn't TCP/IP do the same?

|> I am connected over the public phone network.  I can use X.25, or PPP, or
|> whatever.  If I _have_ to use one protocol/stack, then I am no longer getting
|> _service_ that I want.
|> 
|> The telco types don't understand that (most) data applications can tolerate
|> delay _much_ better than they can tolerate data loss.  If there is _any_
|> possibility of data loss, then an end-to-end protocol between the data
|> source and sink must be implemented - thus TCP/IP & co.  ATM can't solve
|> the problem alone.  For ATM to succeed for data transmission in the real
|> world, either the switches or the endpoints must have _massive_ buffers,
|> equal to end-to-end-check-time * data-rate.  Otherwise data will be lost,
|> which is unacceptable.

ATM switches do provide hardware buffering.  But remember that there
are two types of ATM connections: variable-bit rate and continuous bit
rate.  With VBR you must expect data loss and be able to recover at
a higher protocol layer.  With CBR you don't expect data loss (e.g.
video) and thus recovery is required only for data (but not voice,
video etc.).

Do TCP/IP types have a solution for data, voice and video?  Would you
pay to be connected to both the public network and the Internet?

-----------[000245][next][prev][last][first]----------------------------------------------------
Date:      13 Dec 93 21:22:33
From:      Steinar.Haug@runit.sintef.no (Steinar Haug)
To:        comp.protocols.iso,comp.protocols.tcp-ip
Subject:   Re: Issue for dicussion - Connection Oriented Vs Connectionless  Protocols

> >In the most extreme case, the answer is fairly simple: 3 packets must be
> >exchanged.
> 
> The question was brought up in an OSI-oriented frame of reference;
> do you happen to have similar figures for OSI connections?

No, I don't. Somebody who knows the OSI protocols better than I do should
answer this. To make it more realistic, we should really have *two* answers:

1. The minimum number of packets for one transaction over a full OSI stack,
given that no session exists beforehand.

2. The minimum number of packets for one transaction over a full OSI stack,
given that there is already a session between the hosts involved.

Case 2 is interesting because high-performance environments would probably
keep a session up at all times.

Steinar Haug, system/networks administrator
SINTEF RUNIT, University of Trondheim, NORWAY
Email: Steinar.Haug@runit.sintef.no, Steinar.Haug@delab.sintef.no

-----------[000246][next][prev][last][first]----------------------------------------------------
Date:      13 Dec 1993 16:55:03 GMT
From:      armand@cats.ucsc.edu (Armand)
To:        comp.protocols.tcp-ip
Subject:   Help with SLIP8250



i have installed X Appeal and wwant to use it with my 16.8k modem.
i have the slip8250 packet driver but am not sure how to install it
properly.... i'm using it on com1, 57600 baud (locked port), and the
rest of the settings should be standard stuff.... please help....

also, once i get the driver installed, how do i actually go ahead and
make a connection? i could use as much help as i can get at this point.
that includes with xappeal.....

thanks



-----------[000247][next][prev][last][first]----------------------------------------------------
Date:      13 Dec 93 17:29:43 GMT
From:      robinson@mdd.comm.mot.com (Jim Robinson)
To:        comp.protocols.tcp-ip,comp.unix.solaris
Subject:   Re: TLI, TCP, t_bind(), and AI

In retrospect it may not have been obvious from my post, but I did realize
that this [choosing another port, if the requested one was unavailable] was
documented behaviour. My question is what is the rationale for this design
decision? Under what circumstances would such a feature be useful? Do such
circumstances justify complicating that code, the vast majority, for which
a specific port, and only that port, will do? 

I have not seen a rationale for this in the solaris documentation or in any
of my networking textbooks that discuss TLI.

-- 
Jim Robinson
robinson@mdd.comm.mot.com
{ubc-cs!van-bc,uunet}!mdivax1!robinson


-----------[000248][next][prev][last][first]----------------------------------------------------
Date:      Mon, 13 Dec 1993 17:37:58 GMT
From:      art@acc.com (Art Berggreen)
To:        comp.protocols.tcp-ip
Subject:   Re: ** Question about Subnet Masking...

In article <1993Dec10.234033.4713@spectrum.CMC.COM> lars@spectrum.CMC.COM (Lars Poulsen) writes:
>The kind of address that has subnet masks applied to it, is called
>an IP address, and it is conventionally written as 4 decimal numbers
>separated by dots. The IP address of my workstation is 193.89.36.2.
>Computers attached to the same network have IP addresses that have
>the first part in common. Often a facility will have several physical
>cables. Traditionally, such a facility would get a class B network
>number (16 bits of network number; all hosts have addresses where the
>first two bytes are the same) and the hosts on the individual physical
>networks would have an 8-bit field more in common. (The individual
>networks would then be joined by routers.) In such a situation,
>the NETMASK would be 255.255.0.0 (described in the same notation
>as the IP addresses) and the SUBNETMASK would be 255.255.255.255.
						  ^^^^^^^^^^^^^^^

Ooops, I assume you meant 255.255.255.0 there, Lars.
All one netmasks are usually HOSTMASKS.

Art


-----------[000249][next][prev][last][first]----------------------------------------------------
Date:      Mon, 13 Dec 1993 20:10:14 +0000
From:      andy@drebin.demon.co.uk (Andrew Ellam)
To:        comp.protocols.tcp-ip
Subject:   ftpsites for PC Slip

 
  > Does anyone know where to ftp SLIP for the PC???? 
 
Try ftp.demon.co.uk
 
Good luck,
Andy.
 
+---------------------------------------------------------------------------+
    This ^ dotted line is (c)Me. Plagiarisers will be summarily garotted. 
    DEMON is a commercial internet host in which I have no interest. That 
 is, I'm interested, but I've not got any money in it. You know what I mean.
                This .sig was beta-tested by James Woodman.


-----------[000250][next][prev][last][first]----------------------------------------------------
Date:      Mon, 13 Dec 1993 20:12:05 GMT
From:      rgallen@muug.mb.ca (Rennie Allen)
To:        comp.protocols.tcp-ip
Subject:   Re: Richard Stevens book in Wayne's World 2

In <2eheo7$ond@kalpana.kalpana.COM> tomw@kalpana.com (Tom Walsh) writes:

>In article Jry@netcom.com, lawson@netcom.com (Steven Lawson) writes:
>> Chuck Smoko (csmoko@nswc.navy.mil) wrote:
>> : Hey folks,
>> : I just saw "Wayne's World 2" yesterday and noticed that Garth's new
>> : girlfriend is carrying a copy of "Unix Network Programming".  It must
>> : be a well read title, because even Garth seemed to be familiar with
>> : it.
 
>> : 							chuck smoko
 
>> : PS: The clip that I am speaking of was at the very end of the movie.
>> 
>> No WAY....   :-) 
 
>Way!

Shyaaa... right.... and monkeys might fly outa my butt...

email: rgallen@muug.mb.ca              mail:  Expert Technology Corporation   
QUICS: rgallen (613) 591-0934                 34 Riverstone Rd. 
Voice: (204) 339-8005                         Winnipeg, Manitoba, Canada R2V 4B2
Fax:   (204) 488-5943


-----------[000251][next][prev][last][first]----------------------------------------------------
Date:      Mon, 13 Dec 1993 22:17:32 GMT
From:      mintz@cup.hp.com (Ken Mintz)
To:        comp.protocols.tcp-ip,comp.unix.solaris
Subject:   Re: TLI, TCP, t_bind(), and AI

Jim Robinson (robinson@mdd.comm.mot.com) writes:
> I have not seen a rationale for this in the solaris documentation or in any
> of my networking textbooks that discuss TLI.

  I cannot justify it either.  But as a clarification, the behavior is
  specified by ATT's TLI.  That is, it is standard behavior, not an anomaly
  of the Solaris implementation.

-- Ken Mintz

-----------[000252][next][prev][last][first]----------------------------------------------------
Date:      13 Dec 93 23:58:12 GMT
From:      evm@opo.van.wa.us
To:        comp.os.vms,comp.protocols.tcp-ip,comp.sys.dec,comp.sys.m68k
Subject:   KA9Q ported to 68000?

I've got a few Dec DS200/mc terminal servers floating around that I have been 
looking to use in a way other that what they were intended for. They talk lat
and need to be downloaded at each boot so they are not too usefull for say a
sun or hp shop.

	They have 1 AUI connection for ethernet and 8 serial lines 
with a max speed of 38Kbps. Internally is a 10 MHz 68000, 768 Kb Ram 
and 128 Kb Eprom.

	Ka9q is a software package to do TCP/IP routing on an intel 
based PC platform. It routes between one ethernet lan and up to 8 or 
so serial SLIP connections. I've been told that a 286 can handle the 
routing for one or 2 SLIP lines without too much problem.

	As that I have this DS200 box and it has ethernet, serial 
lines and a 68000 with ram and rom. I was wondering what it would take 
to port ka9q over to the DS200. You can buy a DS200 for $200 or so if 
only ka9q were ported.

	So:

	Has anyone ported ka9q over to a 68000?

	How does a 68000 at 10 MHz compair to a 286 or 386?

	Has anyone reprogrammed a DS200 for another functions?


	Comments...


Regards, Ethan
 
........        ........        ........
OPO Observatory
17104 ne 35th Cir	Ethan VanMatre          
Vancouver, Wa 98682	evm@opo.van.wa.us

-----------[000253][next][prev][last][first]----------------------------------------------------
Date:      Tue, 14 Dec 1993 03:03:57 GMT
From:      dobo@cs.UAlberta.CA (W. Dobosiewicz)
To:        comp.dcom.isdn,comp.protocols.tcp-ip,comp.dcom.cell-relay
Subject:   Re: Why connectionless ?

coghlan@bcarh5f8.bnr.ca (Patrick Coghlan) writes:

>In article <2ebbk8$646@dr-pepper.East.Sun.COM>, gsteckel@harpoon.East.Sun.COM (Geoff Steckel - Sun BOS Hardware CONTRACTOR) writes:
> 
>|> You (and the telco in general, and ATMers in general) miss the point.  TCP/IP,
>|> etc., run OVER any kind of connection that can be made.  ATM could be one of
>|> many MEANS to the end of communication.  (There is one problem, which is being
>|> firmly pushed under the rug by ATMers, which is the way congestion/packet
>|> loss is handled.  Disaster!).
 
>Modern packet networks don't lose packets very often (1 in 10**6 packets).  
>Anyway, packet recovery occurs at the endpoints of communication with
>TCP/IP.  ATM networks would also do this recovery at the endpoints.  Where 
>is the disaster in this?
>ATM networks send congestion notification to each traffic source and 
>expect them to back off.  Doesn't TCP/IP do the same?

You seem to be thinking that tomorrow's networks will still run at T1
rates or less. Consider the validity of your statement when using OC-48
rates. Endpoint recovery? Congestion notification to a source that is a
million bits away?

>|> I am connected over the public phone network.  I can use X.25, or PPP, or
>|> whatever.  If I _have_ to use one protocol/stack, then I am no longer getting
>|> _service_ that I want.
>|> 
>|> The telco types don't understand that (most) data applications can tolerate
>|> delay _much_ better than they can tolerate data loss.  If there is _any_
>|> possibility of data loss, then an end-to-end protocol between the data
>|> source and sink must be implemented - thus TCP/IP & co.  ATM can't solve
>|> the problem alone.  For ATM to succeed for data transmission in the real
>|> world, either the switches or the endpoints must have _massive_ buffers,
>|> equal to end-to-end-check-time * data-rate.  Otherwise data will be lost,
>|> which is unacceptable.
 
>ATM switches do provide hardware buffering.  But remember that there
>are two types of ATM connections: variable-bit rate and continuous bit
>rate.  With VBR you must expect data loss and be able to recover at
>a higher protocol layer.  With CBR you don't expect data loss (e.g.
>video) and thus recovery is required only for data (but not voice,
>video etc.).

Data traffic is a typical VBR application. In fact, it is so bursty that
it beats any VBR video in burstiness. And yet, data loss is hard to
accept, especially in high-bandwidth networks (you cannot use a cheap
sliding window flow control, so a lot of data may have to be resent,
making the VBR rate even more bursty).

>Do TCP/IP types have a solution for data, voice and video?  Would you
>pay to be connected to both the public network and the Internet?

If TCP (and IP) ever pretended to provide a solution for a 1 Gb/s
transport of voice/video and data, we would all have a good laugh.
But TCP/IP is not for ATM transmission rates (again, consider the sliding
window flow control). Even X.25 with D=0 makes more sense, but not
enough.
--
Wlodek Dobosiewicz

-----------[000254][next][prev][last][first]----------------------------------------------------
Date:      14 Dec 93 04:47:15 GMT
From:      amutiso@hughes.scg.hac.com (Anthony Mutiso)
To:        comp.binaries.ibm.pc.d,comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc,comp.sys.ibm.pc.hardware.networking
Subject:   PC based Network Bridge

Hello Netters,
I remember once seeing a PC based software network bridge package go
by on the net. Does anyone have any references to any packages?

Thanks for all the help

Anthony
--
Anthony Mutiso (amutiso@hughes.scg.hac.com)            Life-motto: Logic Rules.



-----------[000255][next][prev][last][first]----------------------------------------------------
Date:      14 Dec 1993 06:28:02 GMT
From:      napalm@ugcs.caltech.edu (K. Bruner)
To:        comp.protocols.tcp-ip
Subject:   Re: Richard Stevens book in Wayne's World 2

rgallen@muug.mb.ca (Rennie Allen) writes:

>>> Chuck Smoko (csmoko@nswc.navy.mil) wrote:
>>> : Hey folks,
>>> : I just saw "Wayne's World 2" yesterday and noticed that Garth's new
>>> : girlfriend is carrying a copy of "Unix Network Programming".  It must
>>> : be a well read title, because even Garth seemed to be familiar with
>>> : it.
>Shyaaa... right.... and monkeys might fly outa my butt...

Then I think we better all get over to Canada ASAP, because that's
something I want to see!

--
Confound those who have said our remarks before us.
					--Aelius Donatus

-----------[000256][next][prev][last][first]----------------------------------------------------
Date:      Tue, 14 Dec 1993 08:27:53 GMT
From:      ketil@edb.tih.no (Ketil Albertsen,TIH)
To:        comp.dcom.isdn,comp.protocols.tcp-ip,comp.dcom.cell-relay
Subject:   Re: Why connectionless ?

In article <1993Dec13.161743.24947@bcarh54a.bnr.ca>, coghlan@bcarh5f8.bnr.ca 
(Patrick Coghlan) writes:

>Modern packet networks don't lose packets very often (1 in 10**6 packets).
>Anyway, packet recovery occurs at the endpoints of communication with
>TCP/IP.  ATM networks would also do this recovery at the endpoints. 


Don't misinterpret Patrick here: The ATM network itself does NOT do any
recovery of packet loss. The end *users* of the ATM network may do it
at a low level, in a HDLC-like link protocol, or at a higher level, such 
as TCP or OSI TP4.


(By the way: Isn't a cell loss of one in 10**6 rather pessimistic with the
buffer sizes used in ATM networks, and with fiber optic links? I am not 
a transmission guy myself, so I don't know, but I have seen a lot better 
figures quoted other places!)

-----------[000257][next][prev][last][first]----------------------------------------------------
Date:      14 Dec 93 13:37:50
From:      finn@ISI.EDU (Greg Finn)
To:        comp.dcom.isdn,comp.protocols.tcp-ip,comp.dcom.cell-relay
Subject:   Re: Why connectionless ?

In article <dobo.755838237@swalwell> dobo@cs.UAlberta.CA (W. Dobosiewicz) writes:

   If TCP (and IP) ever pretended to provide a solution for a 1 Gb/s
   transport of voice/video and data, we would all have a good laugh.
   But TCP/IP is not for ATM transmission rates (again, consider the sliding
   window flow control). Even X.25 with D=0 makes more sense, but not
   enough.

I have a 500 Mb/s per channel TCP/IP based LAN cable coming into my
office now.  We have performed > 1 Gb/s memory-to-memory transfers
between workstations using this technology.  We are now designing our
second generation gigabit interfaces to sustain 500 Mb/s into the
host-system memory with burst-mode DMA and hardware IP checksum.  It
fits onto a single-side SBus card area.  We are also designing camera
and display devices that sit directly on this type of gigabit LAN.

So what's your point exactly?  Should I stop wasting my time?

--- ggf
--

-----------[000258][next][prev][last][first]----------------------------------------------------
Date:      14 Dec 1993 17:56:52 -0500
From:      bet@panix.com (Bennett Todd)
To:        comp.security.misc,comp.protocols.tcp-ip
Subject:   Re: "large security gap in the Internet"

In article <1993Dec9.122734.24944@inmos.co.uk>, Robin Pickering <rob@inmos.co.uk> wrote:
>In article <1521@minya.UUCP> jc@minya.UUCP (John Chambers) writes:
>>
>>The best way to handle sendmail is to first install a good mailer, and
>>then run the command:
>>  find .  -name 'sendmail*' -exec /bin/rm -f {} ';'
>[...]
>However the delivery of mail in the modern Internet & beyond is a very
>complex job and in my experience nothing short of sendmail is capable
>of delivering all of the features need.

Zachariassen's Zmailer (available via anon ftp from ftp.cs.toronto.edu
in pub/zmailer.tar.Z) is has stronger features than sendmail for
handling the complex email problems of a large site, and it performs
better than sendmail. It also has a far better design; it is
reasonable to hope that an email system with small, separate programs
for each networking daemon and client, for local delivery, and for
routing, will be more secure than a single humongous monolithic
program that tries to do all these things.

Plus, besides all those other advantages, it doesn't have a
sendmail.cf file!

-Bennett
bet@panix.com

-----------[000259][next][prev][last][first]----------------------------------------------------
Date:      Tue, 14 Dec 1993 09:37:31 GMT
From:      ucacjon@ucl.ac.uk (Jon Crowcroft)
To:        comp.protocols.iso,comp.protocols.tcp-ip
Subject:   Re: Issue for dicussion - Connection Oriented Vs Connectionless  Protocols

In article <STEINAR.HAUG.93Dec13212233@runit.sintef.no>, Steinar.Haug@runit.sintef.no (Steinar Haug) writes:
|> > >In the most extreme case, the answer is fairly simple: 3 packets must be
|> > >exchanged.
|> > 
|> > The question was brought up in an OSI-oriented frame of reference;
|> > do you happen to have similar figures for OSI connections?
|> 
|> No, I don't. Somebody who knows the OSI protocols better than I do should
|> answer this. To make it more realistic, we should really have *two* answers:

its about 13 packets...steve kille worked it out once

the layerists got so carried away that they said they could ignore lower layers 
functions and just use service, so very little piggybacking is feasible as you 
go down the stack...

however, obviously,m the number of packets to set up and tear down a conenction
fro mthe application layer down can be amortized over a number of exchanges - 
provided the application actually does a number - if its a lot of clients for a single
transaction server then you lose very very very badly compared with a connectionles
rpc like NFS uses....hence novell and nfs dont use iso:-)

and that just about wrpas it up for 98% of the installed base in the world

-- 
jon crowcroft (hmmm...)

-----------[000260][next][prev][last][first]----------------------------------------------------
Date:      14 Dec 1993 10:52:38 GMT
From:      sarkies@ltisun8.epfl.ch (Professeur)
To:        comp.dcom.isdn,comp.protocols.tcp-ip,comp.dcom.cell-relay
Subject:   Re: Why connectionless ?

In article <1993Dec14.082759.17443W@lumina.edb.tih.no>, ketil@edb.tih.no (Ketil Albertsen,TIH) writes:
|> 
|> (By the way: Isn't a cell loss of one in 10**6 rather pessimistic with the
|> buffer sizes used in ATM networks, and with fiber optic links? I am not 
|> a transmission guy myself, so I don't know, but I have seen a lot better 
|> figures quoted other places!)

Well the stated requirement for ATM switches to my knowledge is 1 cell in 10**9,
which is supposed to match the expected random loss rate in optical fibre
transmission. If packets are 1-2Kbytes long say, then I guess that averages to
about 1 packet lost in 10**7. Not too far off.

-- 

Ken Sarkies

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Sauve qui peut, la Grande Panique,
Rien n'est simple, tout se complique.
- Sempe
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

  [8-)#  (balding, bespectacled, eversmiling scratchy-bearded me)

-----------[000261][next][prev][last][first]----------------------------------------------------
Date:      Tue, 14 Dec 1993 11:46:08 +0000
From:      glassbm@epona.demon.co.uk (Martin Glassborow)
To:        comp.protocols.tcp-ip
Subject:   Assignment of Subnet Numbers automated?

Has anyone out there in netland written a program which automates the
process of allocating Subnet Numbers a la RFC1219? If so, could they
copy it to me....I can use most types of source..

Thanks in advance,

Martin
-- 
Martin Glassborow
Systems Environment
Lloyds Bank plc

-----------[000262][next][prev][last][first]----------------------------------------------------
Date:      14 Dec 1993 11:55:54 GMT
From:      jenwen@pdd.iii.org.tw (Jenwen)
To:        comp.protocols.tcp-ip
Subject:   Re: TFTP DOS based?

Duane Dixon (dbld@ccmailpc.ctron.com) wrote:
: 	We are curious, here, if there is a stand-alone DOS based TFTP 'daemom'
: that will run on a networked DOS machine and download requested files via
: TFTP download.

Hi, You can try PCIP package,where have a tftp program,client and server.
Besides telnet program(tn.exe) has a built-in tftp server so that you 
can turn tftp server on and tftp files to your PC. PCIP can be found
in many nodes,says,130.238.98.11(pinus),146.169.3.7(puffin),etc.
Try pcip directory. Good luck.

Jenwen
Institute for Information Industry,Taiwan.


-----------[000263][next][prev][last][first]----------------------------------------------------
Date:      14 Dec 1993 14:49:45 -0000
From:      tim@pipex.net (Tim Goodwin)
To:        comp.security.misc,comp.protocols.tcp-ip,comp.mail.misc
Subject:   Re: "large security gap in the Internet"

In article <CHvCvt.2rG@tecc.co.uk>, Pete Bentley <pete@tecc.co.uk> wrote:
>                                     One of the nicer features of
>MMDF (and PP) are the way the mail channels are modular, so incoming
>SMTP mail is handled by a small program that simply injects the mail
>into the main queue.

PP channels are modular, but I wouldn't exactly describe the program
as `small'...

USER       PID %CPU %MEM   SZ  RSS TT STAT START   TIME COMMAND
root     15516 11.8  2.3  168 1368 ?  S    14:41   0:00 smtp-in smtp-in
root     15460  0.0  2.3  168 1372 ?  S    14:39   0:00 smtp-in smtp-in
root     15512  0.0  2.4  168 1404 ?  S    14:41   0:00 smtp-in smtp-in
root     15513  0.0  2.3  168 1368 ?  S    14:41   0:00 smtp-in smtp-in

(I believe the bloat is mostly due to ISODE, which each PP program
carries around to enable it to talk to the others.  Fortunately, it's
a shared library.)

Followups to comp.mail.misc.

Tim.


-- 
Tim Goodwin | "Alvestrand's equality: gateways = pain"
PIPEX Ltd   |     -- Harald T Alvestrand.

-----------[000264][next][prev][last][first]----------------------------------------------------
Date:      Tue, 14 Dec 93 15:31:07 GMT
From:      cliffb@cjbsys.bdb.com (cliff bedore)
To:        comp.protocols.tcp-ip
Subject:   Re: dos version of TALK anywhere?

In article <755696753snz@sensorat.demon.co.uk> Col@sensorat.demon.co.uk writes:
>In article <1993Dec1.122902.205646@uctvax.uct.ac.za> weissman@uctvax.uct.ac.za writes:
>
>>Hello,
>>
>>I am trying to find a version of internet TALK which will run on dos machines.
>>Does anyone know where to find such a critter??
>>
>>Avrohom Weissman
>>Weissman@uctvax.uct.ac.za
>>University of Cape Town   South Africa
>>
>>
>
>If you manage to track this elusive little critter down, I would really  
>appreciate any info. that you get.
>
>Cheers.
>
>-- 
>Colin Roughley
>Col@senorat.demon.co.uk

I just got "Super TCP/NFS" from Frontier Technologies and it has a talk program
with it.(in addition to email,telnet,ftp,nfs,news etc) that seems to work quite
nicely.  I got it at FEDUNIX for $99.00 (show special I think) I haven't tried
all the features but it does seem to do the right thing.

I have no financial interest in Frontier Technologies but I am happy with the
results so far.

Cliff

-- 
Cliff Bedore
7403 Radcliffe Dr. College Park MD 20840
cliffb@cjbsys.bdb.com


-----------[000265][next][prev][last][first]----------------------------------------------------
Date:      14 Dec 93 15:56:40 GMT
From:      froud@sunlab41.sx.ac.uk (Froud D D M)
To:        comp.protocols.tcp-ip,comp.unix.questions
Subject:   Non-blocking sockets - successful connection detection?

Talking about SOCK_STREAMs under unix (in this case SunOs 4.1.3)...

Could anyone spare a few seconds to tell me the "approved" method for 
determining if a completed non-blocking connection call was successful 
or not?

I know that a completed connect(2) call can be detected by checking for
write conditions using select(2) - but this doesn't tell you if the
connection was successful. I *can* check by following this with a write and
checking for an EPIPE error. Failing this, a refused connection will be
immediately followed by a read condition with zero characters pending, so
I *could* pick it up there (differentiating between a closing socket and a
socket that never connected).

Which of the above methods (or any other one) is the "approved" 
multi-platform method? 

Sorry if this is a minor question, but there seems little documentation on
socket usage in non-blocking mode.

Replies via email would be prefered (froud@essex.ac.uk).

Thanks

Dominic Froud

-----------[000266][next][prev][last][first]----------------------------------------------------
Date:      14 Dec 93 16:02:26 GMT
From:      sleight@happy.oz.dg.com (sleight)
To:        comp.protocols.tcp-ip
Subject:   Re: Lattisnet, what and who.

In article <CHxB8A.CC3@matilda.vut.edu.au> nick@matilda.vut.edu.au (Michael Bethune) writes:
>From: nick@matilda.vut.edu.au (Michael Bethune)
>Subject: Lattisnet, what and who.
>Date: 12 Dec 93 13:09:46 GMT
 
>Does anyone know of a product called LattisNet, what is it.
>What does it do and whose is it?
>-- 
>------------------------------------
>-  Michael Bethune             -----  
>--  Independent UNIX Consultant.----
>---  Michael Bethune and Assoc.  ---
Lattisnet is a Synoptics product.  It refers to Hub's.

Andrew
--------------------------------+----------------------------------------
Andrew Sleight                  | Internet:  sleight@happy.oz.dg.com
Data General                    | ACSnet:    sleight@dgaust.dg.oz.au
407 Pacific Highway             | CEO:       Andrew_Sleight@DGA.ceo.dg.com
Artarmon, Sydney, Australia     | Phone:     (61) 2 436-5600

-----------[000267][next][prev][last][first]----------------------------------------------------
Date:      14 Dec 1993 18:39:12 GMT
From:      peter.gregory@asix.wa.com. (Peter Gregory)
To:        comp.protocols.tcp-ip
Subject:   Re: dos version of TALK anywhere?

In article <1993Dec1.122902.205646@uctvax.uct.ac.za> weissman@uctvax.uct.ac.za writes:

>I am trying to find a version of internet TALK which will run on dos machines.
>Does anyone know where to find such a critter??

Beame & Whiteside has a real nice implementation of "talk" (and many other
TCP/IP services, IMHO).  Available commercially.  Send mail to bws.com for
information.

A happy former-user (former, because I changed jobs),.

Pete

--

Peter Gregory  [NICname PG11]  peter.gregory@asix.wa.com
Senior Consultant. ASIX Inc., 1420 Fifth Ave, Suite 2200, Seattle, WA  98101

No Admittance.  Admittance by Appointment Only.  No Appointments.


-----------[000268][next][prev][last][first]----------------------------------------------------
Date:      Tue, 14 Dec 1993 18:46:02 +0000
From:      dave@llondel.demon.co.uk (David Hough)
To:        comp.os.vms,comp.protocols.tcp-ip,comp.sys.dec,comp.sys.m68k
Subject:   Re: KA9Q ported to 68000?

In article <1993Dec13.155812.138@opo.van.wa.us> evm@opo.van.wa.us writes:
>	So:
>
>	Has anyone ported ka9q over to a 68000?
>
>	How does a 68000 at 10 MHz compair to a 286 or 386?
>
>	Has anyone reprogrammed a DS200 for another functions?
>
No idea what the performance is like, but implementations of ka9q exist for
the Atari and Amiga computers, so it *is* possible.

Dave 
-- 

*****************************************************************************
* G4WRW @ GB7WRW.#41.GBR.EU AX25     *    Start at the beginning. Go on     *
* dave@llondel.demon.co.uk  Internet *     until the end. Then stop.        *
* g4wrw@g4wrw.ampr.org      Amprnet  *      (the king to the white rabbit)  *
*****************************************************************************

-----------[000269][next][prev][last][first]----------------------------------------------------
Date:      Tue, 14 Dec 93 17:04:00 +0200
From:      riku.saikkonen@compart.fi (Riku Saikkonen)
To:        comp.protocols.tcp-ip
Subject:   Remote control program fo

MU>Does anybody know about remote control program, which will work over TCP/IP.
MU>Something to connect PC linked by Ethernet to campus network to home compute
MU>So I could login to UNIX machine, run something and connect to PC. In simpes

/pub/msdos/pktdrvr/telnetd.zip from Simtel mirrors. (you also need
WATTCP for it) It's a telnet server that only works with text mode DOS
programs.

-=- Rjs -=- riku.saikkonen@compart.fi
---
 * OLX 2.1 TD * hey1 who stole my shift-key///


-----------[000270][next][prev][last][first]----------------------------------------------------
Date:      14 Dec 93 20:41:43 GMT
From:      fisque@eden.rutgers.edu (Stanton Michael Fisque)
To:        comp.protocols.tcp-ip
Subject:   VersaTerm or other SLIP software for Mac


looking for something called VersaTerm or other software that will allow me to
engage a TCP/IP connect over modem ...

have tried PPP and it's not implemented by the host so i must use SLIP...

any help, binhexed files, ftp locations, etc appreciated..

-stanton

-----------[000271][next][prev][last][first]----------------------------------------------------
Date:      15 Dec 1993 10:49:49 -0800
From:      ddean@opus.eng.sc.rolm.com (Drew Dean)
To:        comp.dcom.cell-relay,comp.protocols.tcp-ip,comp.dcom.isdn
Subject:   Re: Why connectionless ?

In article <1993Dec15.090800.7971W@lumina.edb.tih.no>,
Ketil Albertsen,TIH <ketil@edb.tih.no> wrote:
[Ketil does math that I did not check to come up with a 300,000 cell window
needed if doing window-based flow control across 3000km at 2.4 Gb/s]

>Obviously, you can't run a 300,000 slot window (among other things,
>you can't waste 2*20 bits of the ATM cell for sequence number!), so you
>would ACK/NAK in much larger units. Do checksum calculation, packet
>numbering etc. in units of 50 Kbytes, and you are left with "only" a
>3000 slot window. This wouldn't reduce the requirement for a 15 Mbyte
>buffer, though!
>To some people, 100 Mbytes of buffer (and the processing capacity to 
>manage it) is peanuts. To a lot of others, it is not. Also, to some 
>mathmaticians, the real world is just a special case of no particular 
>interrest.
>
>ka.

Extra special disclaimer:  despite the affiliation listed above, I'm not
a telephone engineer; my background is TCP/IP.

You've proposed something a lot like Van Jacobson's window scale option.
If you're really running 2.4 Gb/s, I don't think the requirement for a 15 MB
buffer is too extreme -- right now, it takes a LOT of computer to generate
a 2.4 Gb/s stream, and if you're going to run that across 3000 km (ie. from
California to Illnois or Ohio), you need ~ $500 of RAM for your network
buffers.  On a > $1M machine, who cares ?

That window-based flow control requires large buffers on long runs is well
known.  The TCP/IP community accepts this. I remember the days when I
personally couldn't think of owning 1 MB of RAM.  (Just the chips would have
cost $3200 or so in 1981).  Now, my notebook computer has 8 MB, and a 10 Mb/s
Ethernet link can use up most of its CPU....

-- 
Drew Dean               (408) 492-5524
ddean@robadome.com      ROLM, a Siemens company
Opinions expressed above are my own, not Siemens'.

-----------[000272][next][prev][last][first]----------------------------------------------------
Date:      Tue, 14 Dec 1993 22:07:32 GMT
From:      donp@novell.com (don provan)
To:        comp.protocols.tcp-ip,comp.unix.solaris
Subject:   Re: TLI, TCP, t_bind(), and AI

In article <1993Dec13.172836.10752@mdivax1.uucp> robinson@mdd.comm.mot.com (Jim Robinson) writes:
>In retrospect it may not have been obvious from my post, but I did realize
>that this [choosing another port, if the requested one was unavailable] was
>documented behaviour. My question is what is the rationale for this design
>decision? Under what circumstances would such a feature be useful? Do such
>circumstances justify complicating that code, the vast majority, for which
>a specific port, and only that port, will do? 

I wasn't there, so I can't say what the rational actually was, and I
don't particularly care for the behavior, either, so I'm not one to
defend it, but I've always assumed that it was intended to allow an
application where a particular port was convenient, but not essential.
So, as one example, an application might prefer providing the primary
file transfer services on TCP port 21, but if there's already a file
transfer provider on port 21, it would be satisfied to provide a
secondary service on an arbitrary port.  The run-of-the-mill TCP FTP
applications would find the primary file transfer service where it
always is, but a more sophisticated client might provide a choice of
file transfer services if more than one were available (assuming a
mechanism for discovering the secondary services).

To answer your last question, I don't personally think this is useful
enough to be justified (in my scenario, for example, it's trivial to
open another stream if the fixed port open fails), but it seems a
defendable position.  Perhaps there are better examples, though.

						don provan
						donp@novell.com

-----------[000273][next][prev][last][first]----------------------------------------------------
Date:      14 Dec 1993 22:36:11 GMT
From:      snelson@ptdca2.intel.com (Shannon Nelson)
To:        comp.os.os2.networking,comp.sys.ibm.pc.hardware.networking,comp.protocols.tcp-ip,comp.misc
Subject:   Need serial to network adaptor recommendations


I'm looking for some recommendations (and warnings?) on serial-to-TCP
devices.  I have a device with a serial port interface that I want to
make available via the ethernet.  I'm exploring my options, including
large-scale terminal servers, but I'd like to find something smaller,
similar to the devices for putting printers on the network.

It needs to accept TCP/IP connections and direct them to a serial
port (rs232, rs422, or rs485).  I'm interested in both single serial
and several serial ports on a device, but definitely no more than
eight, typically more like 1-3 connections.

If anyone has suggestions or warnings on where to go, what to get, and
who to talk to, I'd appreciate it.

Post followups if desired, but please email direct to me as I can't keep
up on all the various groups.

Thanks,
sln
-- 
==============================================================================
Shannon Nelson              Portland Technology Development, Intel Corp.
snelson@ptd.intel.com       (503) 642-8149	I don't speak for Intel
                  Parents can't afford to be squeemish.

-----------[000274][next][prev][last][first]----------------------------------------------------
Date:      14 Dec 1993 23:06:14 GMT
From:      mpadovan@jpmorgan.com (Michael Padovano)
To:        comp.protocols.tcp-ip,comp.unix.solaris
Subject:   Re: TLI, TCP, t_bind(), and AI

In article 10752@mdivax1.uucp, robinson@mdd.comm.mot.com (Jim Robinson) writes:
> In retrospect it may not have been obvious from my post, but I did realize
> that this [choosing another port, if the requested one was unavailable] was
> documented behaviour. My question is what is the rationale for this design
> decision? Under what circumstances would such a feature be useful? Do such
> circumstances justify complicating that code, the vast majority, for which
> a specific port, and only that port, will do? 
> 
> I have not seen a rationale for this in the solaris documentation or in any
> of my networking textbooks that discuss TLI.

The rational is that some applications may want an alternate address if the
requested address is not available.  

For example, consider a server application that publishes its address in a global database.  When that application begins, it asks for a specific address.  If that
address is not available, it can either:

	1.  Exit; or
	2.  Ask for another address, and publish its new address in the database.

The TLI behavior automatically gets your application an alternate address if 
the requested address is not available, saving you the effort of asking for 
another one.

Does that justify complicating the code for the vast majority of servers for which
only one port will do?  Well, maybe not.  But, it is just another "if" statement
in the server application at startup time, so its not really a lot of overhead.

Hope this helps!

---
Michael Padovano


-----------[000275][next][prev][last][first]----------------------------------------------------
Date:      Tue, 14 Dec 1993 23:49:00 GMT
From:      de5@sws1.ctd.ornl.gov (Dave Sill)
To:        comp.security.misc,comp.protocols.tcp-ip,comp.security.unix,comp.mail.sendmail
Subject:   Re: "large security gap in the Internet"

Bennett Todd (bet@panix.com) wrote:

: Zachariassen's Zmailer (available via anon ftp from ftp.cs.toronto.edu
: in pub/zmailer.tar.Z) is has stronger features than sendmail for
: handling the complex email problems of a large site,

That's a pretty strong statement.  Can you explain some of these
features?

: and it performs better than sendmail.

Compared to sendmail 8?  How much better?

: It also has a far better design; it is
: reasonable to hope that an email system with small, separate programs
: for each networking daemon and client, for local delivery, and for
: routing, will be more secure than a single humongous monolithic
: program that tries to do all these things.

Sendmail doesn't do local delivery at all, and merely modularizing the
process does not guarantee more security.  It might make it easier
to achieve more security, and it might have other advantages, but it's
still subject to the quality of implementation.

: Plus, besides all those other advantages, it doesn't have a
: sendmail.cf file!

Sendmail 8 and IDA both have friendly macroized configuration files.

My personal experience with zmailer was that it was pretty easy to
build and install, but kinda tricky to configure and run.  There are
lots of files and directories to keep track of, and you can forget
everything you know about sendmail, because it won't help a bit.

--
Dave Sill (de5@ornl.gov)             Computers should work the way beginners
Martin Marietta Energy Systems       expect them to, and one day they will.
Workstation Support                                            -- Ted Nelson
URL http://gatekeeper.dec.com/archive/pub/DEC/DECinfo/html/dsill.html

-----------[000276][next][prev][last][first]----------------------------------------------------
Date:      Wed, 15 Dec 1993 02:25:39 GMT
From:      c.oneill@trl.oz.au (Chris O'Neill)
To:        comp.dcom.cell-relay,comp.protocols.tcp-ip,comp.dcom.isdn
Subject:   Re: Why connectionless ?

In article <dobo.755838237@swalwell> dobo@cs.UAlberta.CA (W. Dobosiewicz)
writes:
>coghlan@bcarh5f8.bnr.ca (Patrick Coghlan) writes:
>
>>In article <2ebbk8$646@dr-pepper.East.Sun.COM>, gsteckel@harpoon.East.Sun.COM
 (Geoff Steckel - Sun BOS Hardware CONTRACTOR) writes:
>> 
>>|> You (and the telco in general, and ATMers in general) miss the point.  
>>|> TCP/IP, etc., run OVER any kind of connection that can be made.  ATM 
>>|> could be one of many MEANS to the end of communication.  (There is one 
>>|> problem, which is being firmly pushed under the rug by ATMers, which 
>>|> is the way congestion/packet loss is handled.  Disaster!).
 
>>Modern packet networks don't lose packets very often (1 in 10**6   
>>packets). Anyway, packet recovery occurs at the endpoints of 
>>communication with TCP/IP.  ATM networks would also do this recovery at 
>>the endpoints.  Where is the disaster in this?
>>ATM networks send congestion notification to each traffic source and 
>>expect them to back off.  Doesn't TCP/IP do the same?
>
>You seem to be thinking that tomorrow's networks will still run at T1
>rates or less. Consider the validity of your statement when using OC-48
>rates. Endpoint recovery? Congestion notification to a source that is a
>million bits away?

Million, schmillion.  What's the problem?  Is there some law of physics that
butts in at a million bits?  Statements like "Window based protocols like TCP
do not scale well to high bandwidth-long delay networks" are invalid.

What are the things that have to be scaled?

Processing speed?  Not really a problem with available processor speed doubling
every year or two, IP routing that can be done in 37 instructions per packet
and TCP processing that can be done in 60 instructions per packet.

Time delays?  Time delays in any process do not have to change as bit rates
increase.  If everything is faster, queuing delays are the same.

Buffer sizes?  Of course buffer sizes (in terms of bits) have to proportional
to bit rates but buffer sizes in terms of queuing delay do not change, i.e. if
you think there is a queuing delay problem with high speed networks then there
already was such a problem with low speed networks.  The only reason you didn't
notice it before is because there weren't many delay-sensitive applications
carried on lower speed (packet) networks.

So TCP/IP networks appear to scale quite happily to higher speeds without any
performance drawback (time-delay related or otherwise) so the question is not
one of speed.  The question is how do you enable networks (of any speed) to
provide a lower queuing delay service than is now available from TCP/IP
networks.  Two ways of doing this are:

1. Carry all traffic in a different way to the way it is now handled by IP
networks so that the queuing delay is acceptable to everyone.  This will cost
something in efficiency.

2. Separate traffic in some way that allows efficiency gains for users who can
tolerate queuing delays comparable with the propagation delay of their service.

Before anyone asserts that one of these approaches is better than the other
they had better make sure of their argument.  So I do take exception to
statements such as "Endpoint recovery? Congestion notification to a source that
is a million bits away?" which do not contain good arguments.

>>|> I am connected over the public phone network.  I can use X.25, or PPP, 
>>|> or whatever.  If I _have_ to use one protocol/stack, then I am no 
>>|> longer getting _service_ that I want.
>>|> 
>>|> The telco types don't understand that (most) data applications can 
>>|> tolerate delay _much_ better than they can tolerate data loss.  If 
>>|> there is _any_ possibility of data loss, then an end-to-end protocol 
>>|> between the datasource and sink must be implemented - thus TCP/IP & 
>>|> co.  ATM can't solve the problem alone.  For ATM to succeed for data 
>>|> transmission in the real world, either the switches or the endpoints 
>>|> must have _massive_ buffers, equal to end-to-end-check-time * data-
>>|> rate.  Otherwise data will be lost, which is unacceptable.
 
>>ATM switches do provide hardware buffering.  But remember that there
>>are two types of ATM connections: variable-bit rate and continuous bit
>>rate.  With VBR you must expect data loss and be able to recover at
>>a higher protocol layer.  With CBR you don't expect data loss (e.g.
>>video) and thus recovery is required only for data (but not voice,
>>video etc.).
>
>Data traffic is a typical VBR application. In fact, it is so bursty that
>it beats any VBR video in burstiness. And yet, data loss is hard to
>accept, especially in high-bandwidth networks (you cannot use a cheap
>sliding window flow control, 

Really.  So what's wrong with using TCP's window flow control that has Van
Jacobson's congestion avoidance and control algorithms.  Pretty cheap (to
implement) algorithm as far as I can tell.  Although I know of no papers
published that document its effect on internet congestion, it is reputed to
have made a big difference to internet congestion so that it is now an
insignificant problem.  I would be surprised if you hadn't heard of Jacobson's
paper (Congestion Avoidance and Control, published in ACM SIGCOMM '88) but
perhaps you'd better read it carefully so that you can understand why the
algorithms so effective in controlling and avoiding congestion.

>so a lot of data may have to be resent,
>making the VBR rate even more bursty).

Actually, Van Jacobson's algorithms make the total traffic less bursty.

>>Do TCP/IP types have a solution for data, voice and video?  Would you
>>pay to be connected to both the public network and the Internet?
>
>If TCP (and IP) ever pretended to provide a solution for a 1 Gb/s
>transport of voice/video and data, we would all have a good laugh.

I hope you've learned your lesson about blind assertions by now.  TCP is only
meant to suit a range of applications not including voice and video.  But it is
quite suitable for data above 1 Gb/s.  IP networks will need a change to the
service model to properly support voice and voice/video and this is being
worked on.  Papers describing competing approaches are:

"A Scheduling Service Model and a Scheduling Architecture for an Integrated
Services Packet Network" by Shenker Zhang and Clark, anonymous ftp at
parcftp.xerox.com:/transient/service-model.ps

"Link-sharing and Resource Management Models for Packet Networks" by Sally
Floyd, anonymous ftp at ftp.ee.lbl.gov:link.ps.Z

>But TCP/IP is not for ATM transmission rates (again, consider the sliding
>window flow control). 

Make sure you understand Van Jacobson.

>Even X.25 with D=0 makes more sense (than TCP/IP), 

You don't see statements like that every day.

>but not enough.
>
>Wlodek Dobosiewicz

Chris O'Neill
Telecom Australia Research Labs

-----------[000277][next][prev][last][first]----------------------------------------------------
Date:      Wed, 15 Dec 1993 08:18:17 UNDEFINED
From:      jwh2@cornell.edu (James W. Howell)
To:        comp.security.misc,comp.protocols.tcp-ip,comp.security.unix,comp.mail.sendmail
Subject:   Re: "large security gap in the Internet"

At Cornell we have discovered by trying both sendmail and zmailer that zmailer 
works well as a hub site mailer and sendmail works better on machines where 
final delivery and outgoing SMTP host traffic is done.
Jim

In article <1993Dec14.234900.9220@ornl.gov> de5@sws1.ctd.ornl.gov (Dave Sill) 
writes:>From: de5@sws1.ctd.ornl.gov (Dave Sill)
>Subject: Re: "large security gap in the Internet"
>Date: Tue, 14 Dec 1993 23:49:00 GMT
 
>Bennett Todd (bet@panix.com) wrote:
 
>: Zachariassen's Zmailer (available via anon ftp from ftp.cs.toronto.edu
>: in pub/zmailer.tar.Z) is has stronger features than sendmail for
>: handling the complex email problems of a large site,
 
>That's a pretty strong statement.  Can you explain some of these
>features?
 
>: and it performs better than sendmail.
 
>Compared to sendmail 8?  How much better?
 
>: It also has a far better design; it is
>: reasonable to hope that an email system with small, separate programs
>: for each networking daemon and client, for local delivery, and for
>: routing, will be more secure than a single humongous monolithic
>: program that tries to do all these things.
 
>Sendmail doesn't do local delivery at all, and merely modularizing the
>process does not guarantee more security.  It might make it easier
>to achieve more security, and it might have other advantages, but it's
>still subject to the quality of implementation.
 
>: Plus, besides all those other advantages, it doesn't have a
>: sendmail.cf file!
 
>Sendmail 8 and IDA both have friendly macroized configuration files.
 
>My personal experience with zmailer was that it was pretty easy to
>build and install, but kinda tricky to configure and run.  There are
>lots of files and directories to keep track of, and you can forget
>everything you know about sendmail, because it won't help a bit.
 
>--
>Dave Sill (de5@ornl.gov)             Computers should work the way beginners
>Martin Marietta Energy Systems       expect them to, and one day they will.
>Workstation Support                                            -- Ted Nelson
>URL http://gatekeeper.dec.com/archive/pub/DEC/DECinfo/html/dsill.html


-----------[000278][next][prev][last][first]----------------------------------------------------
Date:      Wed, 15 Dec 1993 04:25:45 GMT
From:      gja@ee.mu.OZ.AU (Grenville Armitage)
To:        comp.dcom.isdn,comp.protocols.tcp-ip,comp.dcom.cell-relay
Subject:   Re: Why connectionless ?

In article <1993Dec13.161743.24947@bcarh54a.bnr.ca> coghlan@bcarh5f8.bnr.ca (Patrick Coghlan) writes:
>In article <2ebbk8$646@dr-pepper.East.Sun.COM>, gsteckel@harpoon.East.Sun.COM (Geoff Steckel - Sun BOS Hardware CONTRACTOR) writes:
 [...]
>|> (There is one problem, which is being
>|> firmly pushed under the rug by ATMers, which is the way congestion/packet
>|> loss is handled.  Disaster!).
>
>Modern packet networks don't lose packets very often (1 in 10**6 packets).  

The question is about loss under congestion conditions. No one is
arguing that modern subnet technologies don't have very low intrinsic
PDU loss rates.

>Anyway, packet recovery occurs at the endpoints of communication with
>TCP/IP.  ATM networks would also do this recovery at the endpoints.  Where 
>is the disaster in this?

The "disaster" that many people in the (vaguely defined) 'packet world'
see is that ATM touts stat muxing as a bonus, but many of the 
(similarly vaguely defined) telco-ATM 'true believers' dont yet
_seem_ to have come to grips with the associated congestion problems.

>ATM networks send congestion notification to each traffic source and 
>expect them to back off.  Doesn't TCP/IP do the same?

Transient congestion, which is expected to occur when you're stat
muxing, is hardly solved by the long-time-lag
approach of signalling back to the source transport layer. The
response time of having the source ATM layer temporarily throttle
back the cell injection rate may even be too slow.

	[..]
>ATM switches do provide hardware buffering.

But the question is, "how much?". See previous threads in
comp.dcom.cell-relay about buffering requirements of bursty
vs CBR traffic.

	[..]

>Do TCP/IP types have a solution for data, voice and video?

[As an aside, you might want to look into the various packages
 available for audio/video over current generation IP, e.g. 'vat',
 BBNs 'PictureWindow', etc.]

>Would you
>pay to be connected to both the public network and the Internet?

They are not mutually exclusive.

gja

-----------[000279][next][prev][last][first]----------------------------------------------------
Date:      Wed, 15 Dec 1993 05:30:38 GMT
From:      arumble@blah.netcomm.pronet.com (Anthony Rumble)
To:        comp.protocols.tcp-ip,alt.winsock
Subject:   Re: Problem with WinSock and ipxpkt....

: : ARP: timed out..
 
: Did you use winpkt and correct version of it ?

YES

: : I can see the ARP request going out, and returning.. But
: : it doesn't seem to recognise it..
 
: That always happened to me when my packet-driver did not
: work correctly. Now I'm using ODI-Driver and ODIPK
: version 2.0 (or up).
 
: Now anything works fine.

Hmm.. Ive got ODI drivers.. but not ODIPKT..

Could someone send me ODIPKT??

--
arumble@blah.netcomm.pronet.com	NetComm R&D
Anthony Rumble Voice x358 (02) 878-7358 Fax (02) 887-4649

-----------[000280][next][prev][last][first]----------------------------------------------------
Date:      15 Dec 93 06:04:46 GMT
From:      jkay@cs.ucsd.edu (Jon Kay)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP/IP Performance Papers?

In article <CHMv4y.Eqw@poly.edu> korfhage@weston.poly.edu (Willard Korfhage) writes:
>A paper in 1989 by Clark, Jacobson, Romkey, and Salwen looked at TCP processing
>overhead. Are there any more recent studies of protocol overhead?  

Yes, there are.  We took measurements of TCP/IP on a RISC workstation
(a DECstation 5000/200).  The bottom line of the study is about
performance under realistic workloads, as opposed to earlier studies
such as Clark et al, which focussed on maximizing throughput.  This
changes the face of the matter because copying and checksumming are
much less important for the full packet workload, which mostly
consists of small packets, than for maximum throughput tests which use
maximum sized packets, with maximum window sizes and other things
uncommon in Real Programs running on Real Systems.  

> I am curious
> to know if protocol implementations have improved, or not. 

It's hard to say how much protocol implementations have improved.  I
can tell you that they've improved vastly, and continue to improve
now.  Quantifying the change is really tough...  I once tried to
compare our measurements to Clark et al's and Cabrera et al's [1]
measurements.  Different authors report using different hardware with
different operating systems driven by different workload generators.
Clark et al focused so narrowly on considerations for maximal
throughput that we could only make comparisons of hardware (extra,
extra, DECstation 5000 faster than Sun 3, read all about it!).  Cabrera
et al presented thorough results on the VAX, but both hardware and
software were so old that it was hard deciding how to attribute the
differences we saw.

The paper in question can be ftp'ed from 
ucsd.edu:/pub/csl/fastnet/sigcomm93.ps.Z
The reference is as follows:

J. Kay, J. Pasquale, "The Importance of Non-Data Touching Processing
Overheads in TCP/IP," Proceedings of the SIGCOMM '93 Symposium on
Communications Architectures and Protocols, September 1993.

An additional paper of interest, ftp-able from the same directory, is

J. Kay, J. Pasquale, "Measurement, Analysis, and Improvement of UDP/IP
Throughput for the DECstation 5000," Proceedings of the Winter 1993
Usenix Conference, 249-258, January 1993.


						Jon

[1]     L.-F. Cabrera, E. Hunter, M. J. Karels, D. A. Mosher, "User-
Process Communication Performance in Networks of Com-
puters," IEEE Transactions on Software Engineering, 14(1), 
38-53, January 1988.
(A detailed performance analysis of 4.2 BSD networking)

-----------[000281][next][prev][last][first]----------------------------------------------------
Date:      Wed, 15 Dec 93 06:27:58 GMT
From:      khan@pslu1.psl.wisc.edu (Mumit Khan)
To:        comp.protocols.ppp,comp.protocols.tcp-ip
Subject:   PPP or/and SLIP via term server w/out PPP/SLIP support?

PPP/SLIP folks:

           rring                 LAT CONNECT             rlogin
  SPARCbook ---> LAT term server -----------> DEC/Ultrix ------> SPARC

I've been trying to setup SLIP/PPP from my home SPARCbook (4.1.2) and
work machine (SunOS 5.3) and having a hell of a bad time. The big problem 
is that I dial into a terminal server that supports DEC LAT only and then 
``connect'' to a DECstation/Ultrix gateway machine and then rlogin to my 
work SPARCstation. I have SLIP on my home SPARCbook and installed SLIP on 
work SPARC (the one that comes with Solaris 2.x PCNFS), as well as 
dp-2.x/3.x on both ends, and still not a clue on how to go about getting 
either to work.

I'd appreciate any help and/or pointers to the relevant info source.

thanks
mumit -- khan@xraylith.wisc.edu

-----------[000282][next][prev][last][first]----------------------------------------------------
Date:      Wed, 15 Dec 1993 07:33:17 GMT
From:      bob@speakez.com (Robert Crowe)
To:        comp.protocols.appletalk,comp.protocols.tcp-ip
Subject:   Possible to run tcp/ip over localtalk?


Hi, I was wondering if it is possible to run tcp/ip over localtalk.  Ideally,
using MacTCP or some equivilant.  What are the pros and cons?  The reason we
would even consider trying is that some of the Macs can't accept ethernet
cards, and our only other alternative is to go with a SCSI->Ethernet converter.

I am interested in any feedback anyone has regarding this, including hardware
and/or software solutions.

Thanks,

Bob.

-- 
===========================================================
Robert Crowe               email:    bob@speakez.com
SpeakEasy Software         voice:    +1 619 457 4776 x202


-----------[000283][next][prev][last][first]----------------------------------------------------
Date:      Wed, 15 Dec 1993 08:19:30 GMT
From:      alex@newcom.kiae.su (Rudnev Aleksei)
To:        comp.security.misc,comp.protocols.tcp-ip,comp.security.unix,comp.mail.sendmail
Subject:   Re: "large security gap in the Internet"

In <1993Dec14.234900.9220@ornl.gov> de5@sws1.ctd.ornl.gov (Dave Sill) writes:

>Bennett Todd (bet@panix.com) wrote:
 
>: Zachariassen's Zmailer (available via anon ftp from ftp.cs.toronto.edu
>: in pub/zmailer.tar.Z) is has stronger features than sendmail for
>: handling the complex email problems of a large site,
 
>That's a pretty strong statement.  Can you explain some of these
>features?
 
>: and it performs better than sendmail.
 
>Compared to sendmail 8?  How much better?
Sendmail-8 don't differ hardly from other sendmail's:
- ONE queue spool directory for ALL mail (let's image
size of this dir for site processing 100,000 messages/day),
- Sendmail is asking DNS, mailer-tables etc... EVERY TIME it is trying to
send mail... There is not global routing cash, there is not global cash
of really unavailable hosts, etc...

- Sendmail's SMTP server is very slow and expencive. It is VERY simple
task - to receive 1 message via SMTP, why does it need so much CPU, DISK
and Network's resources as Sendmail use?

Throught Sendmail-8 is a little (LITTLE) better than 5.65, it is not
good solusion for large sites.


You can make PROF of SENDMAIL, look into it... and I think you'll don't
ask any questions more - why Sendmail is slow -:)

Rudnev Aleksei <alex@kiae.su>

-----------[000284][next][prev][last][first]----------------------------------------------------
Date:      Wed, 15 Dec 1993 09:07:48 GMT
From:      ketil@edb.tih.no (Ketil Albertsen,TIH)
To:        comp.dcom.cell-relay,comp.protocols.tcp-ip,comp.dcom.isdn
Subject:   Re: Why connectionless ?

In article <1993Dec15.022539.6797@trl.oz.au>, c.oneill@trl.oz.au (Chris 
O'Neill) writes:

>Million, schmillion.  What's the problem?  Is there some law of physics that
>butts in at a million bits?  Statements like "Window based protocols like TCP
>do not scale well to high bandwidth-long delay networks" are invalid.

Did you ever roll out your tape measure to find out how long a bit is?

In an ATM net at 622 Mbps, a bit is somewhere around two feet long. So
you can fit in approx 6 ATM cells per km of fiber. With 50 km (30mi)
between switches, there will be 300 cells running down the pipe before
the first one pours out at the receiving end, and another 300 cells
before the ACK has come back - assuming *zero* delay in the switch.
If you were running a window mechanism at ATM cell level, you'd need a 
window size of >600 cells, 3 kbytes. Think of it as 12 cells/km (20/mi).

That is for *one* hop, with no delays. Try scaling it somewhat: Make 
it a 2.4 Gbps link; that requires a window of 50 cells/km. Make the 
end-to-end distance say, 2 time zones, 3000 km. That makes it 150,000
cells - still without considering any sort of delay but only the speed 
of light. So yes, the laws of physics do come into play.

At these distances, switching delays have surprisingly little effect.
At 2.4 Gbps, you transmit approx 5000 cells/ms. If total delays through
all switches add up to 30 ms (then you are into a range where phone guys
start looking out; phone is certainly relevant for ATM), then switching 
delays will contribute approx the same as signal propagation to the 
required window size, for a total buffer of 300,000 cells, or 15 Mbytes.

Obviously, you can't run a 300,000 slot window (among other things,
you can't waste 2*20 bits of the ATM cell for sequence number!), so you
would ACK/NAK in much larger units. Do checksum calculation, packet
numbering etc. in units of 50 Kbytes, and you are left with "only" a
3000 slot window. This wouldn't reduce the requirement for a 15 Mbyte
buffer, though!

Notice that I didn't draw the worst possible scenario: Even if you draw
straight lines on a map (or rather, globe), you can have six times as
great end-to-end distances on Earth's surface. 30 ms delay is in the 
"real-time" range - six times this delay is still within the tolerances 
for voice phone lines. So we are up to 10 Mbytes of window buffer space.

To some people, 100 Mbytes of buffer (and the processing capacity to 
manage it) is peanuts. To a lot of others, it is not. Also, to some 
mathmaticians, the real world is just a special case of no particular 
interrest.

One way to reduce the buffer requirements is not to utilize the 
available 2.4 Gbps capacity alone, but multiplex data with other users. 
Appearently you have solved a problem: If you effectively use only 1% 
of the capacity, you need only a 1 Mbyte buffer. But out there, there
are 99 other guys like you that also allocate buffers. Whether 
distributed or centralized: Windowing a 2.4 Gbps line across the earth, 
with total delays at voice phone takes 100 Mbytes of buffer to keep the
line busy.

***

All the above figures and calculations, I drew straight out of my head
- I didn't even use a paper and pencil, even less a calculator. I hope
I didn't loose a magnitude anywhere... But even if I did, I think the
problem of windowing at high speeds would be illustrated well with far
lower figures than the ones I came to.

ka.



-----------[000285][next][prev][last][first]----------------------------------------------------
Date:      15 Dec 1993 09:23:14 GMT
From:      hta@uninett.no (Harald T. Alvestrand)
To:        comp.protocols.iso,comp.protocols.tcp-ip
Subject:   Re: Why Connectionless Services were included

The information services Gopher and WWW follow an essentially
connectionless model - that of "connect, request, reply, clear".
The decision to use TCP for the protocol was, I think, based on the
difficulty of handling multi-megabyte UDP datagrams.

I think that if this had been done according to an OSI "Model", the
application would have CL Presentation and Session, with a choice
of CO or CL at the Transport level (of *course* OSI CLTS has no
problems handling multimegabyte datagrams - has it? (smileys go here:-))

In general, a CL model at the application layer is appropriate when
the number of partners is much larger than the number of things one
wants to keep track of, and the application can work in the absence of
per-connection "state".
(You save a *lot* of effort when there simply isn't a connection table
that can fill up anywhere!)

DNS is the classical example where CL is appropriate both at the application
level (because it does not need to keep peer state) and at the transport
level (because both requests and responses are reasonably small).

I believe the E-mail model which Sendmail was implemented to is pretty
close to a CL model; all the "status" is kept with the message, and no
information about a peer MTA is kept. On the other hand, most X.400
implementations keep state about the connection to a peer MTA, which
allows "intelligent" behaviour like queueing and not opening many connections
to the same MTA; both have their benefits.

-- 
                   Harald Tveit Alvestrand
                Harald.T.Alvestrand@uninett.no
      G=Harald;I=T;S=Alvestrand;O=uninett;P=uninett;C=no
                      +47 73 59 70 94
My son's name is Torbjørn. The letter between "j" and "r" is o with a slash.

-----------[000286][next][prev][last][first]----------------------------------------------------
Date:      15 Dec 93 15:37:18 CST
From:      mlo@cray.com (Mick Oyer)
To:        comp.protocols.tcp-ip
Subject:   Sun OS 4.1.3 sockets problem with dynamically linked libraries ??

Hello:

I spent the last day and a half tracking down a problem with a client-server
setup, so I thought I'd post this and see if anyone has seen anything
similar - I'm running Sun OS 4.1.3, soon to be Solaris.

I had tried to compile and run 2 programs that were taken verbatim out of
"Using C on the UNIX System" by David Curry.  One program 'inet-server.c',
would supposedly establish a connection as a server, the other, 'inet-client.c'
would connect as client, and the two would send messages back and forth.

I know I had tried these in the past, and they worked great.  Well, I
recompiled and ran them yesterday, and the server would fail with a
'Can't assign requested address' message (EADDRNOTAVAIL) at the bind
call:

if (bind(s, &sin, sizeof(sin)) < 0) {
	perror("server: bind");
}


After much time and effort was expended, I finally tried recompiling with
'-Bstatic', and it worked.

So, my question is, what is different in static vs. dynamic libraries
that would cause this?  I've done these steps 4 or 5 times, every time
I use -Bstatic it works, otherwise, not.  Library problem with 4.1.3?


---
   | Michael (Mick) Oyer   EMAIL  :  mlo@cherry.cray.com  ||  uunet!cray!mlo   |
   | Sr. Software Analyst  VMAIL  :  work: (612)-683-5855                      |
   | Cray Research, Inc.   USNAIL :  655F Lone Oak Dr., Eagan, MN 55120        |


-----------[000287][next][prev][last][first]----------------------------------------------------
Date:      Wed, 15 Dec 1993 10:08:33 GMT
From:      lmd@cayman (Luis Delgado)
To:        comp.protocols.tcp-ip
Subject:   telnet (8bits)


Hello:

I was trying to use xmodem across a telnet session, but I only can do it in
8 bits mode.

Apparently the standard telnet command does support 8 bits (or is there a turn-
around ?). 

When I access the target host from our netblazer, using telnet -8 -noesc, there
is no problem. But if I try it from a local sun workstation, i can't see any
any of putting telnet in 8 bits mode.

Thanks in advance for any help, sugestions, for using xmodem across the internet

Best Regards,

Luis Delgado
e-mail: lmd@inesc.pt, cis: 100024,3520

-----------[000288][next][prev][last][first]----------------------------------------------------
Date:      Wed, 15 Dec 1993 11:30:07 GMT
From:      lmd@cayman (Luis Delgado)
To:        comp.protocols.tcp-ip
Subject:   Re: telnet (8bits)


ERRATA!

I said " telnet supports 8 bit mode...", but I meant to say

" telnet does NOT support 8 bits mode..." in the context of the previous
text, of course.

Thanks .

Luis Delgado
e-mail: lmd@inesc.pt, cis: 100024,3520

-----------[000289][next][prev][last][first]----------------------------------------------------
Date:      Wed, 15 Dec 93 20:55:00 -0500
From:      tom.kauffman@channel1.com (Tom Kauffman)
To:        comp.protocols.tcp-ip
Subject:   supernet/subnet question

Subject: supernet/subnet question

I need to have some kind soul clarify my understanding of subnets and
supernets (and point me to the RFC on supernets, if possible)?

We have been assigned a group of 8 class C addresses by the InterNIC:
199.19.8.0 through 199.19.15.0 (I think - I left the doc at the office).

If I use a netmask of 255.255.248.0 and a subnet mask of 0.0.7.128, do I
end up with 14 subnets of 126 hosts each, all on a defacto net of
199.19.8.0? We're about to start playing in the tech support group and
it would be nice to get the bloody addressing set up right (there are
many more ways to shoot yourself in the foot that we'll find later :-).

We will NOT be connecting to the Internet in '93; maybe sometime in '94,
although my bet at the office is early '95 - so we'll have the basics
well sorted out before hand.

Tom Kauffman
Senior Systems Programmer
NIBCO, Inc.
---
 þ QMPro 1.51 þ Klein bottle for rent.  Inquire within.

-----------[000290][next][prev][last][first]----------------------------------------------------
Date:      Wed, 15 Dec 1993 13:35:21 GMT
From:      jay@su25h.ess.harris.com (Jay Claybaugh)
To:        comp.protocols.tcp-ip
Subject:   Help with OOB data under Solaris 2.3

I have two Sun LX machines (Solaris 2.2) with tasks connected via a connection-oriented stream socket.
It's possible for one side to become busy processing data and allow the incoming socket stream
to fill with data.  I would like the capability to send a priority message over this link to cause the
receive end to flush all data on the link in response to a mode change which invalidates previously
sent data.

My problem is that the priority OOB message appears to be tagged priority on about 50% of the time
on the receive side.

By using "snoop" to monitor the network messages, I can see that the message is always tagged
as a priority message.  However, on the receive task, sometimes select indicates an exception
file descriptor is set and sometimes it simply shows the priority message as a normal message which
is at the end of the stream data.

I would appreciate any help on how to solve the problem of flushing the data and why the OOB
does not appear to operate consistently.

			Jay

-- 
--------------------------------------------------------------------------
 Jay Claybaugh                   | ARPA  : jay@su25h.ess.harris.com
 Harris Corp., MS 5W/5837        | USENET: 
 PO Box 91000, Melbourne, FL     | PHONE:  (407) 729-7492
                 32902           | FAX:    (407) 729-7273
--------------------------------------------------------------------------


-----------[000291][next][prev][last][first]----------------------------------------------------
Date:      15 Dec 1993 14:31:10 GMT
From:      jfjr@mbunix.mitre.org (Freedman)
To:        comp.protocols.tcp-ip
Subject:   Experimental Protocols


    We are experimenting with a new protocol called SWIPE (J.
Ioannidis and M. Blaze). We are using Sun SPARCs running 4.1.3 as
testbeds so its basically a 4.3 BSD environment. SWIPE is essentially
IP encapsulated in IP. It is implemented as a pseudo driver on the
output side and some ip kernel code on the input side. The pseudo
driver is set up by configuring it as a point to point interface, no
arp and no broadcast.

 Here is my problem.

   I have three Suns, SunA, SunB and SunC, all on the same subnet, all
have one ethernet interface, le0. The swipe pseudo driver is called
sw0. SunA and SunB are running SWIPE, Sun C is not. I would like, at
least for my testing purposes to send packets from SunA to SunC by way
of SunB. The packet from SunA to SunB is a SWIPE packet - an IP packet
addressed to SunC but encapsulated in another IP packet addressed to
SunB. When SunB receives the packet I would like it to unpack the
encapsulated packet and forward it to SunC. This part doesn't happen.
I can get SunA to send the encapsulated packet to SunB which, I think,
should relay the packet to SunC. The much hoped for relay doesn't
happen. SunB unencapsulates the packet and puts in on the ip input
queue but the packet doesn't get relayed, it just gets dropped.

   I am using ping so the packet in question is an ICMP echo request
which should get to ICMP which in turn should at least send an ICMP
redirect (shouldn't it). Is my problem configuration?. Is there
something I can do to SunB to make it act as a sort of one interface
gateway?

                                           Thank You
                                          Jerry Freedman,Jr

-----------[000292][next][prev][last][first]----------------------------------------------------
Date:      Wed, 15 Dec 1993 14:48:47 GMT
From:      mark@alias.com (Mark Andrews)
To:        comp.protocols.tcp-ip
Subject:   Re: Richard Stevens book in Wayne's World 2

In <2eheo7$ond@kalpana.kalpana.COM> tomw@kalpana.com (Tom Walsh) writes:

>In article Jry@netcom.com, lawson@netcom.com (Steven Lawson) writes:
>> Chuck Smoko (csmoko@nswc.navy.mil) wrote:
>> : Hey folks,
>> : I just saw "Wayne's World 2" yesterday and noticed that Garth's new
>> : girlfriend is carrying a copy of "Unix Network Programming".  It must
>> : be a well read title, because even Garth seemed to be familiar with
>> : it.
 
>> : 							chuck smoko
 
>> : PS: The clip that I am speaking of was at the very end of the movie.
>> 
>> No WAY....   :-) 
 
>Way!
 
>---
>----------*----------*----------*---------*---------*---------*
>Tom Walsh
 
>"To Internet or not to Internet, That is the question"
 
>			( 408 ) 749-1600 ext 153
>			( 408 ) 749-1690 ( FAX )
>			internet: tomw@kalpana.com
>				  tomw@netcom.com
>---------*----------*----------*---------*---------*---------*


Yah, it was there. I mailed the author to tell him about it and
he said that he had saw the movie on the weekend. Like all of
us, he was surprised to see it.

The line from Garth was something like:

   Ooh, a UNIX book!

-----------[000293][next][prev][last][first]----------------------------------------------------
Date:      15 Dec 1993 16:49:37 GMT
From:      johnson@gluon.physics.wayne.edu (James M. Johnson)
To:        comp.protocols.appletalk,comp.protocols.tcp-ip
Subject:   Re: Possible to run tcp/ip over localtalk?

In article <CI2Fnw.4rB@speakez.com> bob@speakez.com (Robert Crowe) writes:
>
>Hi, I was wondering if it is possible to run tcp/ip over localtalk.  Ideally,
>using MacTCP or some equivilant.  What are the pros and cons?  The reason we
>would even consider trying is that some of the Macs can't accept ethernet
>cards, and our only other alternative is to go with a SCSI->Ethernet converter.
>
>I am interested in any feedback anyone has regarding this, including hardware
>and/or software solutions.
>

	I have recently done this.  We use MacTCP on the Macs and have
it use Localtalk as the network medium. Another alternative would
be to use PPP on those machines to connect them via a serial line--
we've also done that.

	In order to run TCP/IP over localtalk, you'll need a TCP router
on appletalk.  There are commercial ones available, but we had $0
budget to work with, so we used PCRoute.  It runs on a PC box (we
used an old XT) with an ethernet card and an Apple PC localtalk card.
I was able to borrow all of these parts from elsewhere on campus, so
there was no cost.  We've been happy with it, although there are
some problems.  First of all, the router seems to "freeze up" 
after 5 or 6 days of running, so we power cycle it every few days.
Secondly, although transfers from ether->localtalk are no problem,
ftp transfers going the other way seem to hang after 30K or so is
transfered.  That is not a big concern, since most of the traffic
is to localtalk.  Finally, although I can connect to Suns on the
ethernet, I can't seem to find the SGI machines.  This may be
a routing problem due to my lack of expertise.

	All in all, it works OK for things like POPmail, and we
are convinced we've gotten our money's worth (since it cost us $0).

	If you have any more questions, feel free to contact me.

		Jimbo

Jim Johnson                                     Department of Physics
Phone: (313) 577-2739                           Wayne State University
Internet: johnson@gluon.physics.wayne.edu           Detroit, MI  48202
            "Back off man, I'm a scientist"  --Ghostbusters

-----------[000294][next][prev][last][first]----------------------------------------------------
Date:      Wed, 15 Dec 1993 18:28:35 GMT
From:      barnett@grymoire.crd.ge.com (Bruce Barnett)
To:        comp.protocols.tcp-ip
Subject:   SunOS 4.1.1 vs. SunOS 4.1.3 performance difference

	I have done some casual analysis of some Sun SPARC 2 and SPARC
10's here, and noticed that when a SunOS 4.1.1 system sends large
files to a 4.1.3 system, packets are dropped (0.2%). Yet when a large
file transfer goes from 4.1.3 to 4.1.1, zero packets are dropped. I'm
using ttcp (ttcp -t -s -n2048 -l32768 -b32768/ttcp -r -s -l32768 -b32768).

Why would a 4.1.1 source cause a 4.1.3 destination to drop packets,
yet a 4.1.3 source doesn't?  Both machines were SPARC-2's, and were
idle at the time.  I tried the test several times, and it is
repeatable.

Is this related to Wesley Irish's investigation on Ethernet hardware
problems?  I can measure a subtle different in inter-packet delays
between these two implementations.
--
Bruce Barnett <barnett@crd.ge.com> uunet!crdras!barnett

-----------[000295][next][prev][last][first]----------------------------------------------------
Date:      15 Dec 1993 18:42:45 GMT
From:      take@robadome.com
To:        comp.protocols.tcp-ip
Subject:   Request for a FAQ

Can someone please send me a FAQ for this group or 
at least tell me where I can get one?

Thanks



-----------[000296][next][prev][last][first]----------------------------------------------------
Date:      Wed, 15 Dec 1993 18:58:56 GMT
From:      macker@itd.nrl.navy.mil (Joseph P. Macker)
To:        comp.protocols.tcp-ip
Subject:   Re: Help with examples in Unix Network programming ...

In article <CHu53I.B0p@rice.edu>, rama@letaba.cs.rice.edu (Ramarao
Kanneganti) wrote:

> Hi,
> 
> I was told that the example code in Unix network programming book by
> Richard Stevens is available on ftp. Can you please send me the ftp
> address if you know?
> 
Use anonymous FTP to ftp.uu.net and get file
published/books/stevens.netprog.tar.Z.  The errata is also located there as
stevens.netprog.errata.Z.

Thanks to Rich Stevens for posting this information originally..

-----------[000297][next][prev][last][first]----------------------------------------------------
Date:      Wed, 15 Dec 1993 19:03:11 GMT
From:      macker@itd.nrl.navy.mil (Joseph P. Macker)
To:        comp.protocols.tcp-ip
Subject:   Re: Richard Stevens book in Wayne's World 2

In article <1993Dec12.151909.13192@relay.nswc.navy.mil>, Chuck Smoko
<csmoko@nswc.navy.mil> wrote:

> Hey folks,
> I just saw "Wayne's World 2" yesterday and noticed that Garth's new
> girlfriend is carrying a copy of "Unix Network Programming".  It must
> be a well read title, because even Garth seemed to be familiar with
> it.
> 
if I remember right Garth's exact words are
" Book on UNIX... COooooolll! "

-----------[000298][next][prev][last][first]----------------------------------------------------
Date:      16 Dec 1993 11:51:28 -0800
From:      lstowell@pyrnova.mis.pyramid.com (Lon Stowell)
To:        comp.protocols.tcp-ip
Subject:   Re: ping question

In article <CI50Gn.IFA@cbfsb.cb.att.com> bmoss@cbnewsb.cb.att.com (MOSS) writes:
> > ping -s machineA
>PING machineA : 56 data bytes
>64 bytes from machineA  (x.x.x.x): icmp_seq=0. time=20. ms
>64 bytes from machineA  (x.x.x.x): icmp_seq=0. time=39. ms
>64 bytes from machineA  (x.x.x.x): icmp_seq=1. time=18. ms
>64 bytes from machineA  (x.x.x.x): icmp_seq=1. time=21. ms
>64 bytes from machineA  (x.x.x.x): icmp_seq=2. time=20. ms
>64 bytes from machineA  (x.x.x.x): icmp_seq=2. time=45. ms
>64 bytes from machineA  (x.x.x.x): icmp_seq=3. time=26. ms
>64 bytes from machineA  (x.x.x.x): icmp_seq=3. time=28. ms
>64 bytes from machineA  (x.x.x.x): icmp_seq=4. time=46. ms
>64 bytes from machineA  (x.x.x.x): icmp_seq=4. time=70. ms
>64 bytes from machineA  (x.x.x.x): icmp_seq=5. time=40. ms
>64 bytes from machineA  (x.x.x.x): icmp_seq=5. time=43. ms
>64 bytes from machineA  (x.x.x.x): icmp_seq=6. time=64. ms
>64 bytes from machineA  (x.x.x.x): icmp_seq=6. time=93. ms
>^?
>----machineA PING Statistics----
>7 packets transmitted, 14 packets received, -100% packet loss
>round-trip (ms)  min/avg/max = 18/40/93
>
>I don't have enough experience to just "know" why this is happening.  
>It seems like there are two machineA's sending an ICMP echo reply 
>back to me from my echo request.
>
   If the "machineA" and internet address are identical on both of the
   ping replies, it looks more like you have multiple routes to
   machineA and the routers, bridges, hosts, whatever are not smart
   enough to detect this.  Since one reply always lags the other this
   seems to be the case.  Is there a WAN connection involved?  

   I don't know what kind of machine you are on, but if it has
   anything resembling a record-route feature try invoking it...
   will nail the culprit pretty rapidly.

   Some pings have the -Rv option....some arp caches would give you
   the ethernet address for both of the replies.  

   Post the machine type and operating system level of your pingor and
   someone on the net will be able to give you more explicit advice. 



-----------[000299][next][prev][last][first]----------------------------------------------------
Date:      Wed, 15 Dec 1993 21:03:46 +0200
From:      yoav@tapuz.cc.biu.ac.il (Yoav Wasserman)
To:        comp.protocols.tcp-ip
Subject:   SO_DEBUG with setsockopt

Hi,

    Can someone explain to me, please, how to work with SO_DEBUG option
in setsockopt subroutine ? and how can I get the DEBUG information on
the specified socket ?


    Thanks in advance.


            \|/
           (o o)
-------oOo--(_)--oOo-----------------------------------------------------------
 Yoav Wasserman                               E-mail: yoav@tamar.cc.biu.ac.il
 Unix Group, Bar-Ilan University,             Phone: +972-3-5318879,
 Israel.                                      Fax: +972-3-5344446
-------------------------------------------------------------------------------

-----------[000300][next][prev][last][first]----------------------------------------------------
Date:      Thu, 16 Dec 1993 00:46:57 GMT
From:      sadkins@bigbird.cs.ohiou.edu (Scott W. Adkins)
To:        comp.protocols.tcp-ip
Subject:   Re: Richard Stevens book in Wayne's World 2

In article <macker-151293140311@whitefang.itd.nrl.navy.mil> macker@itd.nrl.navy.mil (Joseph P. Macker) writes:
>In article <1993Dec12.151909.13192@relay.nswc.navy.mil>, Chuck Smoko
><csmoko@nswc.navy.mil> wrote:
>
>> Hey folks,
>> I just saw "Wayne's World 2" yesterday and noticed that Garth's new
>> girlfriend is carrying a copy of "Unix Network Programming".  It must
>> be a well read title, because even Garth seemed to be familiar with
>> it.
>> 
>if I remember right Garth's exact words are
>" Book on UNIX... COooooolll! "

Did you notice his shirt when he said that?  I do believe it had a picture
of the Amiga Video Toaster... :-)  (if you have heard of it...) :-)  That
was definitely a great scene!

Scott
-- 
         Scott W. Adkins           Internet: sadkins@ohiou.edu
         ~~~~~~~~~~~~~~~                     ak323@cleveland.freenet.edu
    Ohio University of Athens        Bitnet: adkins@ouaccvma.bitnet

-----------[000301][next][prev][last][first]----------------------------------------------------
Date:      16 Dec 1993 01:10:57 GMT
From:      fernande@slate.uucp (Jose Roberto Fernandez)
To:        comp.dcom.isdn,comp.protocols.tcp-ip,comp.dcom.cell-relay
Subject:   Re: Why connectionless ?

finn@ISI.EDU (Greg Finn) writes:

>In article <dobo.755838237@swalwell> dobo@cs.UAlberta.CA (W. Dobosiewicz) writes:
 
>   If TCP (and IP) ever pretended to provide a solution for a 1 Gb/s
>   transport of voice/video and data, we would all have a good laugh.
>   But TCP/IP is not for ATM transmission rates (again, consider the sliding
>   window flow control). Even X.25 with D=0 makes more sense, but not
>   enough.
 
>I have a 500 Mb/s per channel TCP/IP based LAN cable coming into my
>office now.  We have performed > 1 Gb/s memory-to-memory transfers
>between workstations using this technology.  We are now designing our
>second generation gigabit interfaces to sustain 500 Mb/s into the
>host-system memory with burst-mode DMA and hardware IP checksum.  It
>fits onto a single-side SBus card area.  We are also designing camera
>and display devices that sit directly on this type of gigabit LAN.
 
>So what's your point exactly?  Should I stop wasting my time?

Sorry to budge in but...  The distance, the distance, don't forget the
distance.
-- 
Jose Roberto Fernandez
fernande@cps.msu.edu
Computer Science
Mich. St. Univ.

-----------[000302][next][prev][last][first]----------------------------------------------------
Date:      Thu, 16 Dec 1993 01:40:13 GMT
From:      shwake@nearside.UUCP (Raymond Shwake)
To:        comp.protocols.tcp-ip
Subject:   Clarkson TCP crashes Windows 3.1 in Enhanced mode. Why?

	We're using Clarkson TCP/IP through the "ndis shim" driver
(DIS_PKT.DOS) on clients running StarGroup Lan Manager (mostly basic,
not enhanced). Clarkson's TELBIN runs rock-solid from the DOS shell
(tested under both 5.0 and 6.0), and so far seems to run fine when
called from Windows running in Standard mode. However, if Windows is
running in 386 Enhanced mode, it'll typically run fine for up to 20
seconds or so, then completely crash Windows to the point the system
must be cold booted. It happens whether running EMM386 or not.

	Microsoft was unable to assist. Can anyone here?
-- 

uunet!media!irscscm!nearside!shwake			shwake@rsxtech

-----------[000303][next][prev][last][first]----------------------------------------------------
Date:      Thu, 16 Dec 1993 03:09:03 GMT
From:      stevea@lachman.com (Steve Alexander)
To:        comp.protocols.tcp-ip
Subject:   Re: Info on T_ERROR t_look() return value

In article <2ehqoc$g7g@jade.spctrm.com> tim@jade.spctrm.com (Tim Fry) writes:
>Can anyone provide more information on what a T_ERROR return value from the 
>TLI t_look(NSL) call means. The man page I am looking at describes it only as 
>being a "fatal error condition" -- I presume this means that it is a value 
>resulting from a severe problem in the underlying transport provider (in my 
>case TCP). Is there any more information that can be obtained?  t_errno is 
>only documented as being set when the call actually fails (returns -1 instead 
>of T_ERROR). Will errno ever be set for instance?

T_ERROR means that the I_PEEK ioctl (see the streamio man page) failed, and 
in this case, the value of errno will indicate why it failed.  It may well
be that the something on the stream sent up an M_ERROR, which means that the
stream is essentially unusable.

-- 
Steve Alexander, Lachman Technology, Inc. | stevea@lachman.com
(708) 505-9555 x256 FAX: (708) 505-9574	  | ...!{sun,ico}!laidbak!stevea

-----------[000304][next][prev][last][first]----------------------------------------------------
Date:      Thu, 16 Dec 1993 08:42:45 GMT
From:      james@kaiwan.com ( )
To:        comp.binaries.ibm.pc.d,comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc,comp.sys.ibm.pc.hardware.networking
Subject:   Re: PC based Network Bridge(wireless bridge)

In article <AMUTISO.93Dec13204715@hughes.hughes.scg.hac.com>,
Anthony Mutiso <amutiso@hughes.scg.hac.com> wrote:
=Hello Netters,
=I remember once seeing a PC based software network bridge package go
=by on the net. Does anyone have any references to any packages?
=
=Thanks for all the help
=
=Anthony
=--
=Anthony Mutiso (amutiso@hughes.scg.hac.com)            Life-motto: Logic Rules.
=
=

-----------------------------------------------------------------------------
This FAQ may be cited as:
 
  Aboba, Bernard D.(1993) "comp.protocols.tcp-ip.ibmpc Frequently
  Asked Questions (FAQ)" Usenet news.answers, available via 
  file://netcom1.netcom.com/pub/mailcom/IBMTCP/ibmtcp.zip, 
  51 pages.
 
-----------------------------------------------------------------------------
PCROUTE v2.24   Free
 
These packages can convert a PC into a TCP/IP router (PCROUTE) or an
Ethernet Bridge (PCBRIDGE).
 
Available via FTP; ftp.acns.nwu.edu, mget /pub/pcroute/pcroute2.24.*
and pcbridge1.2.*
 
Erick Engelke (erick@development.uwaterloo.ca) says: "Excellent
product.  I have used it for years with many heavily used subnets.
Advice: use a 25 Mhz 286 or a similarly fast 386 DX.  Uses only
conventional memory so don't buy more than 1 Mb.Only takes a small
amount of DOS memory."
 
 
Vance Morrison, LANport, Inc., 2040 Polk Street #340, San Francisco,
CA 94109, (415)775-0188, email: lanport@cup.portal.com.
 
Suggestion
PCBRIDGE v2.77  Free
 
Originally by Vance Morrison of Northwester, PCBRIDGE has been taken over by  
Alessandro Fanelli and Luigi Rizzo. The latest version of PCBRIDGE is now ROMabl
e. The  
software is available by anonymous ftp from pical3.iet.unipi.it
(131.114.9.12), cd /pub/bridge.
 
 
Alessandro Fanelli, Luigi Rizzo (luigi@iet.unipi.it),
Universita` di Pisa - via Diotisalvi 2, 56126 Pisa, Italy
Tel. +39-50-568533  -- Fax +39-50-568522
 
Downright Speculation
Drawbridge v1.1
 
Drawbridge is a bridging filter that requires two ethernet cards. 
It is comprised of three programs: Filter, Filter Compiler and Filter
Manager.
 
It is available via anonymous ftp from sc.tamu.edu (128.194.3.57)
get pub/security/drawbridge/drawbridge-1.1.tar.Z, 
drawbridge-1.1-des.tar.Z
 
 
Downright Speculation
KarlBridge v1.41
 
This software provides a two port Ethernet to Ethernet bridge that can filter
based on any Ethernet protocol, including IP, XNS, DECNET, LAT, EtherTalk,
NetBEUI, Novell IPX, etc. 
 
 
It will also act as an IP firewall by filtering IP packets based 
on IP address/network/subnet combinations and socket numbers. It can 
also filter DECNET and AppleTalk Phase 1 & 2 packets. Novell SAP and NCR 
WaveLAN filtering are coming in a future release.
Available via ftp 128.146.1.7, cd /pub/kbridge
-----------------------------------------------------------------------------

There has another bridge - nbr11.zip which run on ndis driver and token
ring. I am currently testing nbr11 with NCR WaveLan and NE2000 clone
using ndis drivers. The result is frustrating. Ping and telnet work,
but massive FTP and flooding crash. Don't know which one should blame,
ndis drivers? NE2000 clone? NCR WaveLan? nbr11? PC clones? 
(Yes I try to build a wireless bridge.)


-- 
info@kaiwan.com,Anonymous FTP,Telnet kaiwan.com(192.215.30.2)FAX#714-638-0455 
DATA# 714-539-0829,830-6061,310-527-4279 818-579-6701 16.8k/14.4k 8-N-1
ZyXEL U-1496E 16.8K: $279.00, U-1496E+ 19.2K: $389.00 Voice/FAX/Data Modems
AT&T DATA Port 14.4K: $189.00(Int) $209(Ext) w/ QuickLink II, FAX/DATA Modems

-----------[000305][next][prev][last][first]----------------------------------------------------
Date:      15 Dec 1993 15:20:23 +1100
From:      colinp@nms.otc.com.au (Colin Panisset)
To:        comp.sys.sun.admin,comp.sys.sun.wanted,comp.protocols.tcp-ip,comp.unix.admin,comp.sys.sun.misc
Subject:   dynamic IP allocation with rarpd (or similar)

Greetings,

  I'm after a version of rarpd to handle dynamic IP allocation for a network
  of PCs. Local conditions preclude me running a RARP server on a PC or on
  a Novell fileserver, but I have a need to be able to dynamically allocate
  an IP number from a range of defined addresses. 

  Such a server would run under SunOS 4.1.x, and need not be capable of
  handling other (plain) RARP requests. It need not be clever.

  Is there such a beast? If there is, I'd prefer one that didn't use 
  the bpf device, since that involves kernel mods and I'm trying to 
  standardise things as much as possible; if its the only option, though,
  then I'll take it.

  Replies by email preferred, but I'll read posts as well.

  TIA,
    -- Colin.

--
  Colin Panisset *:^) +61 2 339 3938 | Log! Log! it's big, it's heavy, it's
        colinp@nms.otc.com.au        | wood! Log! Log! it's better than bad,
  So There.      Fax: +61 2 339 3818 | it's good!           -- Ren & Stimpy
  ------------------ PGP 2.3 key available on request. ----------------

-----------[000306][next][prev][last][first]----------------------------------------------------
Date:      Thu, 16 Dec 1993 11:05:56 GMT
From:      DUNCAN@alphadbn.alpha.co.za (Duncan MacMillan)
To:        comp.protocols.tcp-ip
Subject:   odipkt equivalent for OS/2

Is there a odipkt equivalent that works with OS/2 2.1.  Has anyone got ODIPKT 
working on OS/2 2.1?

Thaks for the help.


-------------------------------------------------------------------------
| Duncan MacMillan          |  Mail Addresses                           |
| Alpha Computer Services   |  MHS : Duncan at ALPHADBN (+27)(31)421619 |
| Durban                    | Internet : duncan@alphadbn.alpha.co.za    |
|-----------------------------------------------------------------------|
|  Comments expressed in this message are not necessarily those of my   |
|  employer but may be personal ones.                                   |
|-----------------------------------------------------------------------|

-----------[000307][next][prev][last][first]----------------------------------------------------
Date:      Thu, 16 Dec 1993 11:52:47 +0000
From:      alistair@ichthya.demon.co.uk (Alistair Bell)
To:        comp.protocols.tcp-ip
Subject:   Gateways, EGP, etc.

I am being commissioned to write TCP/IP router software, and, having read RFCs
904 (EGP) and 1009 (Requirements of Internet Gateways) am still rather in the
dark as to (a) what most people use as an interior gateway protocol, and (b) how
arbitrary EGP routing is carried out (does an EGP router need to carry
information about the topology of the _whole_ internet?).

It further appears that RFC 904 has not been updated but expected itself to be
updated; as the Internet has expanded massively since 1984, have scaling
problems been found with EGP?

Also, I saw (I think in RFC 1500) that a revision to RFC 1009 was being
'actively prepared'; is there anywhere I can see a draft of the revision?

And, I suppose, being a relative newcomer to TCP/IP routing, any pointers to
documentation and/or books would be helpful.

Replies by mail to alistair@ichthya.demon.co.uk would be appreciated; as usual,
I'll post a summary if people are interested.

-- 
Alistair Bell,                               The views in this article are not
Brown's Operating System Services Ltd.,      necessarily those of Brown's
St. Agnes House,                             Operating System Services Ltd.,
Cresswell Park,                              nor of Demon Systems.
Blackheath,
London
SE3 9RD.
Tel. 081-852 3299.

-----------[000308][next][prev][last][first]----------------------------------------------------
Date:      Thu, 16 Dec 93 13:32:19 GMT
From:      amolitor@blefscu.network.com (Andrew Molitor)
To:        comp.security.misc,comp.protocols.tcp-ip
Subject:   Re: "large security gap in the Internet"

In article <2en4ar$e9a@bushwire.apana.org.au>, markd@bushwire.apana.org.au (Mark Delany) writes:
|> I used to believe this, but the latest sendmail clocks in at a mere
|> 13,000 lines of executable code (or thereabouts) which doesn't seem
|> overly daunting to me for the task at hand. I suspect that it is more
|> a matter of reputation than reality.

	This is partly right. I dunno from 8.6.whateveritis, but 5.6x
isn't that large. The trouble is that, despite being a small piece
of code, it's very tricky to understand. There's global data all over,
there's data in these envelopes that's being massaged by everyone
under the sun. There are globals which are set to values which look
bad, but since that's in a child process, so it's ok, and so on.

	It's small, but tracking what happens, line by line, even in
a trivial case, is exceedingly difficult.

		Andrew Molitor
		not speaking for NSC

-----------[000309][next][prev][last][first]----------------------------------------------------
Date:      Thu, 16 Dec 1993 13:44:30 GMT
From:      rstevens@noao.edu (W. Richard Stevens)
To:        comp.protocols.tcp-ip
Subject:   Re: SO_DEBUG with setsockopt

>    Can someone explain to me, please, how to work with SO_DEBUG option
> in setsockopt subroutine ? and how can I get the DEBUG information on
> the specified socket ?

You run trpt(8).  SO_DEBUG just saves the information in a circular buffer
in the kernel, then you run trpt to output the information.  Unless you
really need to see the information in the TCP control block, a tool such
as tcpdump might be more useful.

	Rich Stevens  (rstevens@noao.edu)

-----------[000310][next][prev][last][first]----------------------------------------------------
Date:      16 Dec 1993 22:05:42 -0500
From:      zhang@ms.uky.edu (Bing Zhang)
To:        comp.protocols.tcp-ip
Subject:   Source codes of TCP/IP for UNIX in public domain?

Could anybody tell me the ftp address to obtain the source codes of TCP/IP for 
UNIX in public domain?   Please send me the ftp address to  zhang@ms.uky.edu

Thank you very much.
Bing Zhang


-----------[000311][next][prev][last][first]----------------------------------------------------
Date:      16 Dec 1993 13:53:06 GMT
From:      casper@fwi.uva.nl (Casper H.S. Dik)
To:        comp.protocols.tcp-ip
Subject:   Re: Sun OS 4.1.3 sockets problem with dynamically linked libraries ??

mlo@cray.com (Mick Oyer) writes:

>if (bind(s, &sin, sizeof(sin)) < 0) {
>	perror("server: bind");
>}


>After much time and effort was expended, I finally tried recompiling with
>'-Bstatic', and it worked.
 
>So, my question is, what is different in static vs. dynamic libraries
>that would cause this?  I've done these steps 4 or 5 times, every time
>I use -Bstatic it works, otherwise, not.  Library problem with 4.1.3?

You don't give all your source code, so i'll have to guess:
Your sin structure lives on the stack and isn't properly
filled in.  (The difference between statically linked executables
and dynamically linked executables is that in the static environment
the stack is just allocated and all 0s.  Unitialized stuff on
the stack will be all 0s in the beginning of the program.
This is especially true for stuff declared in main().
The dynamic linker uses some stack spaces as part of
program start-up and further activities.  This leaves
stuff on the stack.  This is perfectly acceptable.

The program is broken.  Fix it by properly initialising all
fields of sin.

Casper

-----------[000312][next][prev][last][first]----------------------------------------------------
Date:      16 Dec 1993 14:29:24 GMT
From:      sarkies@ltisun8.epfl.ch (Professeur)
To:        comp.dcom.cell-relay,comp.protocols.tcp-ip,comp.dcom.isdn
Subject:   Re: Why connectionless ?

In article <2enm8d$ivi@opus.eng.sc.rolm.com>, ddean@opus.eng.sc.rolm.com (Drew Dean) writes:

|> California to Illnois or Ohio), you need ~ $500 of RAM for your network
|> buffers.  On a > $1M machine, who cares ?
|> 

There have been a lot of posts on this statement, so I may as well add one.
Won't these buffers need to be in every switch? If so, it is not so much a
question of adding $500 to the network connection of some supercomputer
user, but of adding it to everyone's network connection, regardless of whether
that person uses it or not. The costs of this buffering will need
to be spread over all network users, and as someone pointed out, it will not
be the sort of memory in your PC, but high speed high cost stuff, along with
all the control and maintenance costs. So if 99.99% of network users make
64K telephone calls needing a few K of buffering, will they be happy with this
cost?

-- 

Ken Sarkies

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Sauve qui peut, la Grande Panique,
Rien n'est simple, tout se complique.
- Sempe
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

  [8-)#  (balding, bespectacled, eversmiling scratchy-bearded me)

-----------[000313][next][prev][last][first]----------------------------------------------------
Date:      16 Dec 1993 14:31:12 GMT
From:      bab@se40.wg2.waii.com (Brian Button)
To:        comp.lang.c++,comp.object,comp.protocols.tcp-ip,comp.sys.sun.misc
Subject:   Suggestions for distributed processing library wanted

We're developing an application which will be spread among several
workstations, and we need a library which will allow us to distribute
a lot of data between different processes, regardless of where they
live.

The library must support a high throughput to handle the amount of
data we need to pass, and it should support the ability to broadcast
messages to an entire group of processes, as well as the ability to
address directly a single application.

Basically, we're looking for something like Sun's ToolTalk, but with
much better performance. To get this, I have a feeling I'm going to
have to write this myself, but management wanted me to ask first :)

Any and all hints and pointers will be appreciated.

Thanks,
bab
--
|-----------------------|----------------------------------------------------|
| Brian Button          | email : button@wg2.waii.com                        |
| Design Engineer       |         71023.276@compuserve.com                   |
| Western Geophysical   | voice : (713)964-6221                              |
| 3600 Briarpark        |----------------------------------------------------|
| Houston, Texas  77042 |   opinions < /dev/bab ; flames > /dev/null         |
|-----------------------|----------------------------------------------------|

-----------[000314][next][prev][last][first]----------------------------------------------------
Date:      Thu, 16 Dec 1993 14:31:45 GMT
From:      prati@iitb.ernet.in (Pratima Sethi)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject:   Wattcp write problems ..

I have written an application on top of wattcp, that needs to 
do large data transfers over a tcp socket. ( I am a wattcp version
released possibly im early 1992 ).

I find that the once the application writes data greater than 
tcp_MaxBuffersize, no further data is written to the socket.
This could happen if the acknowledgements are not being recvd,
but a tcpdump on the unix host reveals that acknowledgements are
beiing tarnsimited correctly. Could anyone point out the problem 
may be ?

Secondly how can I get tcp dump on the PChost. I have added the
DEBUG.MODE=ALL to wattcp.cfg, and added dbuginit() before 
sock_init() as instructed.

Please reply by email to
prati@iitb.ernet.in

-----------[000315][next][prev][last][first]----------------------------------------------------
Date:      Thu, 16 Dec 1993 14:33:35 GMT
From:      andy@max.uis.com (Andy Edwards)
To:        comp.protocols.appletalk,comp.protocols.tcp-ip
Subject:   Re: Possible to run tcp/ip over localtalk?

johnson@gluon.physics.wayne.edu (James M. Johnson) writes:

>In article <CI2Fnw.4rB@speakez.com> bob@speakez.com (Robert Crowe) writes:
>>
>>Hi, I was wondering if it is possible to run tcp/ip over localtalk.  Ideally,
>>using MacTCP or some equivilant.  What are the pros and cons?  The reason we
>>would even consider trying is that some of the Macs can't accept ethernet
>>cards, and our only other alternative is to go with a SCSI->Ethernet converter.
>>
>>I am interested in any feedback anyone has regarding this, including hardware
>>and/or software solutions.
>>
 
>	I have recently done this.  We use MacTCP on the Macs and have
>it use Localtalk as the network medium. Another alternative would
>be to use PPP on those machines to connect them via a serial line--
>we've also done that.
 
>	In order to run TCP/IP over localtalk, you'll need a TCP router
>on appletalk.  There are commercial ones available, but we had $0
>budget to work with, so we used PCRoute.  It runs on a PC box (we
>used an old XT) with an ethernet card and an Apple PC localtalk card.
>I was able to borrow all of these parts from elsewhere on campus, so
>there was no cost.  We've been happy with it, although there are
>some problems.  First of all, the router seems to "freeze up" 
>after 5 or 6 days of running, so we power cycle it every few days.
>Secondly, although transfers from ether->localtalk are no problem,
>ftp transfers going the other way seem to hang after 30K or so is
>transfered.  That is not a big concern, since most of the traffic
>is to localtalk.  Finally, although I can connect to Suns on the
>ethernet, I can't seem to find the SGI machines.  This may be
>a routing problem due to my lack of expertise.
 
>	All in all, it works OK for things like POPmail, and we
>are convinced we've gotten our money's worth (since it cost us $0).
 
>	If you have any more questions, feel free to contact me.
 
>		Jimbo


Do you have a pcakage for the Mac that can do lpd-type printer
sharing.  We have a printer in our network that is available as
an lpd host to other systems, but our Mac's are unable to print
to them.

Any suggestions?

        --andy

Andy Edwards
Unix Integration Services, Inc.
(andy@uis.com)

-----------[000316][next][prev][last][first]----------------------------------------------------
Date:      16 Dec 1993 15:05:31 GMT
From:      zeeff@zip.eecs.umich.edu (John Zeeff)
To:        comp.unix.bsd,comp.protocols.tcp-ip
Subject:   virtual hosts based on ip address?

I'd like to take one physical machine (running bsdi) and make it look like
two different machines to the outside world.  In particular, I'd like
people to be able to do things like "gopher machine1.org" and "gopher
machine2.com" and get different menus (I don't want to use non standard 
port numbers for this).  So ideally the one machine would have two ip
addresses and inetd would detect which one was being used and spawn the 
appropriate gopherd.

Any ideas on how I can do this?

-----------[000317][next][prev][last][first]----------------------------------------------------
Date:      Thu, 16 Dec 1993 16:13:50 GMT
From:      dobo@cs.UAlberta.CA (W. Dobosiewicz)
To:        comp.dcom.isdn,comp.protocols.tcp-ip,comp.dcom.cell-relay
Subject:   Re: Why connectionless ?

finn@ISI.EDU (Greg Finn) writes:

>In article <dobo.755838237@swalwell> dobo@cs.UAlberta.CA (W. Dobosiewicz) writes:
 
>   If TCP (and IP) ever pretended to provide a solution for a 1 Gb/s
>   transport of voice/video and data, we would all have a good laugh.
>   But TCP/IP is not for ATM transmission rates (again, consider the sliding
>   window flow control). Even X.25 with D=0 makes more sense, but not
>   enough.
 
>I have a 500 Mb/s per channel TCP/IP based LAN cable coming into my
>office now.  We have performed > 1 Gb/s memory-to-memory transfers
>between workstations using this technology.  We are now designing our
>second generation gigabit interfaces to sustain 500 Mb/s into the
>host-system memory with burst-mode DMA and hardware IP checksum.  It
>fits onto a single-side SBus card area.  We are also designing camera
>and display devices that sit directly on this type of gigabit LAN.
 
>So what's your point exactly?  Should I stop wasting my time?
 
>--- ggf
>--

I don't think so. The discussion I took part in was about wide area
networks, where the delay between sending a packet and receiving an
acknowledgement for it (assuming such an acknowledgement is expected) is
very substabtial in terms of bits: at 1Gb/s, the round-trip delay over a
100km distance is 1Mbit, this makes the sliding window flow control
mechanism inefficient for bursty traffic.

There is nothing in TCP or in IP that makes them unsuitable for high
transmission rates, provided the round-trip delay is small, expressed in
bits (or packets, or whatever). The same 1Gb/s over a 1km link yields a delay
of just 10kbits, i.e. a handful of packets, at most - nothing that would
add significant wait-for-acknowledgement delays.

Wlodek Dobosiewicz
--
Wlodek Dobosiewicz

-----------[000318][next][prev][last][first]----------------------------------------------------
Date:      Thu, 16 Dec 1993 16:23:05 GMT
From:      dobo@cs.UAlberta.CA (W. Dobosiewicz)
To:        comp.dcom.cell-relay,comp.protocols.tcp-ip,comp.dcom.isdn
Subject:   Re: Why connectionless ?

ddean@opus.eng.sc.rolm.com (Drew Dean) writes:

>In article <1993Dec15.090800.7971W@lumina.edb.tih.no>,
>Ketil Albertsen,TIH <ketil@edb.tih.no> wrote:
>[Ketil does math that I did not check to come up with a 300,000 cell window
>needed if doing window-based flow control across 3000km at 2.4 Gb/s]
 
>>Obviously, you can't run a 300,000 slot window (among other things,
>>you can't waste 2*20 bits of the ATM cell for sequence number!), so you
>>would ACK/NAK in much larger units. Do checksum calculation, packet
>>numbering etc. in units of 50 Kbytes, and you are left with "only" a
>>3000 slot window. This wouldn't reduce the requirement for a 15 Mbyte
>>buffer, though!
>>To some people, 100 Mbytes of buffer (and the processing capacity to 
>>manage it) is peanuts. To a lot of others, it is not. Also, to some 
>>mathmaticians, the real world is just a special case of no particular 
>>interrest.
>>
>>ka.
 
>Extra special disclaimer:  despite the affiliation listed above, I'm not
>a telephone engineer; my background is TCP/IP.
 
>You've proposed something a lot like Van Jacobson's window scale option.
>If you're really running 2.4 Gb/s, I don't think the requirement for a 15 MB
>buffer is too extreme -- right now, it takes a LOT of computer to generate
>a 2.4 Gb/s stream, and if you're going to run that across 3000 km (ie. from
>California to Illnois or Ohio), you need ~ $500 of RAM for your network
>buffers.  On a > $1M machine, who cares ?

In ATM networks, you share the net with many other users. So, it does not
take a $1M machine to generate 2.5 Gb/s - all it takes is to have 100
workstations.

>That window-based flow control requires large buffers on long runs is well
>known.  The TCP/IP community accepts this. I remember the days when I
>personally couldn't think of owning 1 MB of RAM.  (Just the chips would have
>cost $3200 or so in 1981).  Now, my notebook computer has 8 MB, and a 10 Mb/s
>Ethernet link can use up most of its CPU....

Clearly, the idea of increasing the window size is a good solution to
increasing network sizes, albeit only a partial one. Sooner or later, we
will get to the point when switching to some other protocol, one not
relying as heavily on end-to-end feedback, will become reasonable.

Another point related to TCP over ATM is that of congestion control in
ATM. When a VC exceeds its guaranteed rate (approaching its peak rate), it
may lose cells. This will make TCP to retransmit the packet when the loss
is detected. When the round-trip feedback is large (as it is in gigabit
wide area networks), you may want a large window size, which will cause
another burst when the source retransmits the packet, again increasing the
risk of cell loss, etc.
The solution of having a fixed capacity assigned to VCs does not appeal to
data people, who claim to have bursty traffic.

Wlodek Dobosiewicz

>-- 
>Drew Dean               (408) 492-5524
>ddean@robadome.com      ROLM, a Siemens company
>Opinions expressed above are my own, not Siemens'.
--
Wlodek Dobosiewicz

-----------[000319][next][prev][last][first]----------------------------------------------------
Date:      Thu, 16 Dec 1993 16:57:59 GMT
From:      bmoss@cbnewsb.cb.att.com (MOSS)
To:        comp.protocols.tcp-ip
Subject:   ping question

If you have a moment, please tell me why this happens:

 > ping -s machineA
PING machineA : 56 data bytes
64 bytes from machineA  (x.x.x.x): icmp_seq=0. time=20. ms
64 bytes from machineA  (x.x.x.x): icmp_seq=0. time=39. ms
64 bytes from machineA  (x.x.x.x): icmp_seq=1. time=18. ms
64 bytes from machineA  (x.x.x.x): icmp_seq=1. time=21. ms
64 bytes from machineA  (x.x.x.x): icmp_seq=2. time=20. ms
64 bytes from machineA  (x.x.x.x): icmp_seq=2. time=45. ms
64 bytes from machineA  (x.x.x.x): icmp_seq=3. time=26. ms
64 bytes from machineA  (x.x.x.x): icmp_seq=3. time=28. ms
64 bytes from machineA  (x.x.x.x): icmp_seq=4. time=46. ms
64 bytes from machineA  (x.x.x.x): icmp_seq=4. time=70. ms
64 bytes from machineA  (x.x.x.x): icmp_seq=5. time=40. ms
64 bytes from machineA  (x.x.x.x): icmp_seq=5. time=43. ms
64 bytes from machineA  (x.x.x.x): icmp_seq=6. time=64. ms
64 bytes from machineA  (x.x.x.x): icmp_seq=6. time=93. ms
^?
----machineA PING Statistics----
7 packets transmitted, 14 packets received, -100% packet loss
round-trip (ms)  min/avg/max = 18/40/93

I don't have enough experience to just "know" why this is happening.  
It seems like there are two machineA's sending an ICMP echo reply 
back to me from my echo request.

Thanks in advance

brad.a.moss@att.com
 


-----------[000320][next][prev][last][first]----------------------------------------------------
Date:      16 Dec 1993 00:43:55 +1100
From:      markd@bushwire.apana.org.au (Mark Delany)
To:        comp.security.misc,comp.protocols.tcp-ip
Subject:   Re: "large security gap in the Internet"

In <2elgbk$aec@panix.com> bet@panix.com (Bennett Todd) writes:

>[Zmailer] will be more secure than a single humongous monolithic
>program that tries to do all these things [sendmail].

I used to believe this, but the latest sendmail clocks in at a mere
13,000 lines of executable code (or thereabouts) which doesn't seem
overly daunting to me for the task at hand. I suspect that it is more
a matter of reputation than reality.


M.

-----------[000321][next][prev][last][first]----------------------------------------------------
Date:      Fri, 17 DEC 93 00:17:07 EST
From:      AEWHALE@delphi.com
To:        comp.protocols.tcp-ip
Subject:   Re: Source codes of TCP/IP for UNIX in public domain?

 
I too would like to know where to find the TCP/IP source(s).  I have been
fighting some lp vs. lpr contentions using the Pacific Data - Direct/Net c
controller (it's not being very direct for the AT&T System V lp interface)
on my Sun SparcCenter 2000.  Any helpful hints?
 
Thanks in advance,
 
Albert E. Whale
 

-----------[000322][next][prev][last][first]----------------------------------------------------
Date:      Thu, 16 Dec 1993 19:52:48 GMT
From:      lawson@netcom.com (Steven Lawson)
To:        comp.protocols.tcp-ip
Subject:   New Stevens Book/Daylight savings time

1) What date should the new Stevens TCP/IP book be on the shelf?

2) Any references to where I can find information on daylight savings
   time calculations?


-----------[000323][next][prev][last][first]----------------------------------------------------
Date:      Thu, 16 Dec 1993 21:27:25 GMT
From:      gabes@seasnake.micro.umn.edu (John Gabriel)
To:        comp.protocols.tcp-ip
Subject:   MacTCP?


Was wondering if anyone had source code for MacTCP. Would be nice to get
some code to Open a connection, send and receive, be a great plus if it can
maintain multiple and separate connections. Any help would be greatly
appreciated. Please respond by mail since I hardly have any time to read my news.

                                            +----------------===============+
\_\_\_  \_\_\_    \_\_   \_\_    \_\_\_     |  JohN GabrieL /\ LeirbaG NhoJ |
     \_      \_  \_  \_  \_  \_        \_   |    University of Minnesota    |
  \_\_\_    \_\_    \_\_  \_\_\_  \_\_  \_  |          612-457-3551         |
   \_          \_  \_  \_  \_  \_  \_   \_  | Lead Consultant EE/CSci 3-166 |
    \_\_\_  \_\_\_  \_\_\_  \_  \_  \_\_\_  |   gabes@mermaid.micro.umn.edu |
                                            +================---------------+

-----------[000324][next][prev][last][first]----------------------------------------------------
Date:      16 Dec 1993 23:01:00 GMT
From:      johnson@gluon.physics.wayne.edu (James M. Johnson)
To:        comp.protocols.appletalk,comp.protocols.tcp-ip
Subject:   Re: Possible to run tcp/ip over localtalk?

In article <CI4trz.EDu@max.uis.com> andy@max.uis.com (Andy Edwards) writes:

>Do you have a pcakage for the Mac that can do lpd-type printer
>sharing.  We have a printer in our network that is available as
>an lpd host to other systems, but our Mac's are unable to print
>to them.
>

	There are packages that allow you to spool to a BSD print
queue from a mac and also print to an appletalk printer from
a UNIX box with BSD spooling.  I made this work once, but don't
remember the details other than the packages are called lpdaemon3.32
and lpr1.2.  I think I got them off the University of Michigan Mac
archives. Hope this helps.

	Jimbo

Jim Johnson                                     Department of Physics
Phone: (313) 577-2739                           Wayne State University
Internet: johnson@gluon.physics.wayne.edu           Detroit, MI  48202
            "Back off man, I'm a scientist"  --Ghostbusters

-----------[000325][next][prev][last][first]----------------------------------------------------
Date:      Fri, 17 Dec 1993 00:10:24 GMT
From:      rstevens@noao.edu (W. Richard Stevens)
To:        comp.protocols.tcp-ip
Subject:   Re: New Stevens Book/Daylight savings time

> 1) What date should the new Stevens TCP/IP book be on the shelf?

The first copies were shipped from the bindery yesterday (Wed. 12/15).
Some bookstores were getting bindery shipments (Computer Literacy, for
example) so I'd guess they'll have them in the next 1-2 weeks.  The
official title is "TCP/IP Illustrated, Volume 1: The Protocols,"
ISBN 0-201-63346-9.

BTW, 2 days ago I created the file "stevens.tcpipiv1.info.tar.Z" in the
directory "aw.prof.comp.series" on the host aw.com that anyone can get
using anonymous FTP.  It contains the table of contents, preface, a
complete sample chapter (Chapter 4: ARP) (all in ascii and PostScript),
and a listing of about 100 bookstores in the U.S. where you can order a
copy before 12/31/93 and get $5 off.  I'll also post the TOC to
misc.books.technical now, in case anyone doesn't have ftp access.

	Rich Stevens  (rstevens@noao.edu)

-----------[000326][next][prev][last][first]----------------------------------------------------
Date:      Fri, 17 Dec 1993 05:29:21 GMT
From:      ginger@hydrus.trl.OZ.AU (Jeremy Ginger)
To:        comp.protocols.tcp-ip
Subject:   discussion groups - algorithms


I am looking for newsgroups and mailing lists that discuss network
algorithms. I am interested in various forms and versions of the 
maximum flow and shortest path algorithms.

Would you please be kind enough to e-mail me details if
you know of such groups.

Jeremy

***********************************************************************
Jeremy Ginger                                E-mail: j.ginger@trl.oz.au
Telecom Research Laboratories                       Tel: +61 3 253 6417
P.O.BOX 249, Clayton, Victoria 3168, Australia.     Fax: +61 3 253 6144
***********************************************************************
Jeremy Ginger                                E-mail: j.ginger@trl.oz.au
Telecom Research Laboratories                       Tel: +61 3 253 6417
P.O.BOX 249, Clayton, Victoria 3168, Australia.     Fax: +61 3 253 6144

-----------[000327][next][prev][last][first]----------------------------------------------------
Date:      17 Dec 1993 15:20:23 -0500
From:      nelson@crynwr.com (Russell Nelson)
To:        comp.protocols.tcp-ip
Subject:   HELP: TCP/IP and BBSs (is this right?!?)

In article <2e84rn@lester.appstate.edu> CA6343@CONRAD.APPSTATE.EDU writes:

   We are trying to set up a BBS on the Internet using VBBS (Ms-Dos)
   We currently     have an Ethernet card and a 486, and we haven't
   had any luck finding software  that will monitor the Ethernet card
   and allow the BBS to answer it like a    modem.

Talk to Brad Clements <bkc@murkworks.com>.  He has a commercial
solution for his problem.

-russ <nelson@crynwr.com>      ftp.msen.com:pub/vendor/crynwr/crynwr.wav
Crynwr Software   | Crynwr Software sells packet driver support.
11 Grant St.      | 315-268-1925 (-9201 FAX)       | Quakers do it in the light
Potsdam, NY 13676 | LPF member - ask me about the harm software patents do.

-----------[000328][next][prev][last][first]----------------------------------------------------
Date:      17 Dec 1993 15:21:17 -0500
From:      nelson@crynwr.com (Russell Nelson)
To:        comp.protocols.tcp-ip
Subject:   Clarkson TCP crashes Windows 3.1 in Enhanced mode. Why?

In article <shwake.756006013@nearside> shwake@nearside.UUCP writes:

           We're using Clarkson TCP/IP through the "ndis shim" driver
   (DIS_PKT.DOS) on clients running StarGroup Lan Manager (mostly basic,
   not enhanced). Clarkson's TELBIN runs rock-solid from the DOS shell
   (tested under both 5.0 and 6.0), and so far seems to run fine when
   called from Windows running in Standard mode. However, if Windows is
   running in 386 Enhanced mode, it'll typically run fine for up to 20
   seconds or so, then completely crash Windows to the point the system
   must be cold booted. It happens whether running EMM386 or not.

You should run winpkt.  Here's howtoget.it:


-- HOWTOGET.IT

                The Crynwr packet driver collection

Availability

The Crynwr packet driver collection is available on CD-ROM, by mail,
by FTP, by email, by UUCP and by modem.  The drivers are distributed
in three files: pktd11.zip, which contains most executables and
documentation, pktd11a.zip, which contains the first half of the
remaining files, and pktd11b.zip, which contains the second half of
the remaining files.

Mail:

Columbia University distributes packet drivers on PC diskette by
postal mail.  5.25-inch 360K and 3.5" 720K diskettes are available;
please specify size.  Two diskette sets are available, and two prices
are quoted for each; the first price is for the USA, Canada, and
Mexico; the second price is for shipment to all other countries.  All
prices are in US dollars.  Prepayment by check, MasterCard, or Visa
is accepted.  If your check is not drawn on a US bank, please add 5
check-cashing fee.

  1. Binaries and documentation:        5  /  0
  2. Source code:                       0  /  8

To order by credit card, please specify MasterCard or Visa, your card
number and expiration date, and sign and date your order.  For further
information, call +1 212 854-3703, or write to:

  Kermit Distribution, Dept PD
  Columbia University Academic Information Systems
  612 West 115th Street
  New York, NY  10025

or send e-mail to kermit@columbia.edu (Internet) or KERMIT@CUVMA
(BITNET/CREN/EARN).

FTP/email:

The packet driver collection has its own directory devoted to it in
the SimTel collection, msdos/pktdrvr.  The drivers are there, along
with a number of programs that use the packet drivers.

For security reasons the SimTel Software Repository is located on a
host that is not accessible by Internet users, however its files are
available by anonymous ftp from the primary mirror site OAK.Oakland.Edu
(141.210.10.117) located in Rochester, Michigan, and from the secondary
mirror sites:

   St. Louis, MO: wuarchive.wustl.edu (128.252.135.4)
   Corvallis, OR: archive.orst.edu (128.193.2.13)
Falls Church, VA: ftp.uu.net (192.48.96.9
       Australia: archie.au (139.130.4.6)
         England: src.doc.ic.ac.uk (146.169.2.1)
         Finland: ftp.funet.fi (128.214.6.100)
         Germany: ftp.uni-paderborn.de (131.234.2.32)
          Israel: ftp.technion.ac.il (132.68.1.10)
     Switzerland: ftp.switch.ch (130.59.1.40)
          Taiwan: NCTUCCCA.edu.tw (140.111.1.10)

SimTel files may obtained by e-mail from various ftp-mail servers
or through the BITNET/EARN file servers.  For details see file
/pub/msdos/filedocs/mailserv.inf.  Gopher users can access the
collection through Gopher.Oakland.Edu.  World Wide Web (WWW) and
Mosaic users can connect to the URL http://www.acs.oakland.edu to
access the files on OAK.Oakland.Edu.

Modem:

If you cannot access them via FTP or e-mail, most SimTel MSDOS
files, including the PC-Blue collection, are also available for
downloading from Detroit Download Central (313) 885-3956.  DDC
has multiple lines which support 300/1200/2400/9600/14400 bps
(103/212/V22bis/HST/V32bis/V42bis/MNP).  This is a subscription system
with an average hourly cost of 17 cents.  It is also accessable on
Telenet via PC Pursuit and on Tymnet via StarLink outdial.  New files
uploaded to SimTel are usually available on DDC within 24 hours.

CD-ROM:

Title:  Packet Driver, WinSock & TCP/IP CD-ROM (aka Packet Driver CD)
Price:  US9.95/each

Brochures and order forms for the CD (paper and electronic versions)
will be available from:

Gopher: gopher.CDPublishing.com
FTP:    ftp.CDPublishing.com
E-mail: <info@CDPublishing.com>
FAX:    604-874-1431
Phone:  604-874-1430
        800-333-7565
Postal: CD Publishing Corporation
        4824 Fraser Street
        Vancouver, B.C.  V5V 4H4
        Canada

UUCP:

The packet driver files are available from UUNET's 1-900-GOT-SRCS, in
uunet!~/systems/msdos/simtel20/pktdrvr.  Contact UUNET for more details:

UUNET Technologies, Inc.
3110 Fairview Park Drive, Suite 570
Falls Church, VA 22042
+1 703 204 8000 (voice)
+1 703 204 8001 (fax)
info@uunet.uu.net

UK UUCP:

Steve Kennedy's BBS is on +44 71 483 2454 (Telebit T2500 PEP/V32 ...)
                                                2455 (USR HST/DS+)

Files will be in /pub
there will be an anonymous uucp (nuucp) account.

System name is "marvin"

-- end of HOWTOGET.IT

-russ <nelson@crynwr.com>      ftp.msen.com:pub/vendor/crynwr/crynwr.wav
Crynwr Software   | Crynwr Software sells packet driver support.
11 Grant St.      | 315-268-1925 (-9201 FAX)       | Quakers do it in the light
Potsdam, NY 13676 | LPF member - ask me about the harm software patents do.

-----------[000329][next][prev][last][first]----------------------------------------------------
Date:      17 Dec 93 13:02:38 EST
From:      lee@hsh.com (Lee Havemann)
To:        comp.os.vms,comp.protocols.tcp-ip,comp.sys.dec,comp.sys.m68k
Subject:   Re: KA9Q ported to 68000?

In article <2erpo1$n3g@mips.arb-phys.uni-dortmund.de>, wb@arb-phys.uni-dortmund.de (Wilhelm B. Kloke) writes:
> In article <1993Dec13.155812.138@opo.van.wa.us>,  <evm@opo.van.wa.us> wrote:
>>I've got a few Dec DS200/mc terminal servers floating around that I have been 
>>looking to use in a way other that what they were intended for. They talk lat
>>and need to be downloaded at each boot so they are not too usefull for say a
>>sun or hp shop.
>> [Deleteed...]
> If you manage to program it for support of V32bis/V42bis modem slip or
> ppp support (at 38kBd), I would like to hear from you. The 68k should be
> sufficient to support more than 1 line at full speed. I think it should
> even do all lines, if programmed well.
> 
> The DS200 (as used by DEC) does only support 9600 Bd. Where did you get
> the info about the max speed?
> wbk

From the Terminal Server Commands and Messages Reference Manual pp 2-49:
DECserver 200
DECserver 500

SPEED 

specifies the port speed in bits per second. Permissible values include 50
(DS500 only), 75, 110, 134, 150, 300, 600, 1200, 1800, 2000, 2400, 4800, 
7200 (DS500 only), 9600 (default) 19200, and 38400 (DS500 only)

So the the DS200 supports up to 19200 baud. 


> -- 
> Dipl.-Math. Wilhelm Bernhard Kloke
> Institut fuer Arbeitsphysiologie an der Universitaet Dortmund
> Ardeystrasse 67, D-44139 Dortmund, Tel. 0231-1084-257
-- 

 Lee Havemann, Comp Ops Dir.    HSH Associates      (201) 838-3330 
 Internet: lee@hsh.com    Compuserve: 70410,3507    AOL: HSH Assoc
 "Any opinions expressed are not necessarily those of anyone else, 
  including myself."                     

-----------[000330][next][prev][last][first]----------------------------------------------------
Date:      Fri, 17 Dec 1993 14:58:33
From:      darrin@wmhmis1.wmh.iupui.edu (darrin debard)
To:        comp.protocols.tcp-ip
Subject:   SLIP/PPP software needed for host.


-------------------------------------------------
Darrin A. DeBard     darrin@wmhmis1.wmh.iupui.edu
                     darrin@vax1.iupui.edu

Wishard Memorial Hospital / MIS Technical Support
1001 West 10th Street
Indianapolis, IN 46202        Phone: 317-630-8383
-------------------------------------------------

-----------[000331][next][prev][last][first]----------------------------------------------------
Date:      17 Dec 1993 10:12:38 GMT
From:      gjb@lsil.com (Gary Bridgewater)
To:        comp.dcom.cell-relay,comp.protocols.tcp-ip,comp.dcom.isdn
Subject:   Re: Why connectionless ?

In article <1993Dec15.090800.7971W@lumina.edb.tih.no> ketil@edb.tih.no (Ketil Albertsen,TIH) writes:
>To some people, 100 Mbytes of buffer (and the processing capacity to 
>manage it) is peanuts. To a lot of others, it is not. Also, to some 
>mathmaticians, the real world is just a special case of no particular 
>interrest.

As long as we are on the back of an envelope,  2x64MB SIMMs are ~$6k, figure
a processor and logic at ~$6k, you are talking about a ~$12k card that slides
into my $50k router and gives me a few orders of magnitude better thruput
across the campus.  The cost is not exorbitant for the benefit.
I probably won't be adding this to my home PC, however.
But then, someone like LSI or AMD will build a megacell that has the memory,
processor, decode/encode logic, etc. in one (large) die/package.
Now the price begins to look like, for comparison, a P5 - i.e. ~$1k on a pc or
workstation sized card-du-jour.   I might add that to my PC.
Router-sized cards could have multiple connections for ATM backbones.

(note - this is NOT a product announcement - I have no knowledge of what that
side of the house is working on  and even less influence.)
-- 
Gary Bridgewater (gjb@lsil.com)  LSI Logic, Milpitas, CA - speaking only for me
"As God is my witness - I am that fool!"  Gomez Addams

-----------[000332][next][prev][last][first]----------------------------------------------------
Date:      17 Dec 1993 09:13:53 +0100
From:      wb@arb-phys.uni-dortmund.de (Wilhelm B. Kloke)
To:        comp.os.vms,comp.protocols.tcp-ip,comp.sys.dec,comp.sys.m68k
Subject:   Re: KA9Q ported to 68000?

In article <1993Dec13.155812.138@opo.van.wa.us>,  <evm@opo.van.wa.us> wrote:
>I've got a few Dec DS200/mc terminal servers floating around that I have been 
>looking to use in a way other that what they were intended for. They talk lat
>and need to be downloaded at each boot so they are not too usefull for say a
>sun or hp shop.
>
>	They have 1 AUI connection for ethernet and 8 serial lines 
>with a max speed of 38Kbps. Internally is a 10 MHz 68000, 768 Kb Ram 
>and 128 Kb Eprom.
If you manage to program it for support of V32bis/V42bis modem slip or
ppp support (at 38kBd), I would like to hear from you. The 68k should be
sufficient to support more than 1 line at full speed. I think it should
even do all lines, if programmed well.

The DS200 (as used by DEC) does only support 9600 Bd. Where did you get
the info about the max speed?
wbk
-- 
Dipl.-Math. Wilhelm Bernhard Kloke
Institut fuer Arbeitsphysiologie an der Universitaet Dortmund
Ardeystrasse 67, D-44139 Dortmund, Tel. 0231-1084-257

-----------[000333][next][prev][last][first]----------------------------------------------------
Date:      Fri, 17 Dec 93 12:15:41 GMT
From:      lars@Eskimo.CPH.CMC.COM (Lars Poulsen)
To:        comp.os.vms,comp.protocols.tcp-ip,comp.sys.dec,comp.sys.m68k
Subject:   Re: KA9Q ported to 68000?

In article <1993Dec13.155812.138@opo.van.wa.us>,  <evm@opo.van.wa.us> wrote:
>>I've got a few Dec DS200/mc terminal servers floating around ...
>>	They have 1 AUI connection for ethernet and 8 serial lines 
>>with a max speed of 38Kbps. Internally is a 10 MHz 68000, 768 Kb Ram 
>>and 128 Kb Eprom.

In article <2erpo1$n3g@mips.arb-phys.uni-dortmund.de>
   wb@arb-phys.uni-dortmund.de (Wilhelm B. Kloke) writes:
>If you manage to program it for support of V32bis/V42bis modem slip or
>ppp support (at 38kBd), I would like to hear from you. The 68k should be
>sufficient to support more than 1 line at full speed. I think it should
>even do all lines, if programmed well.
>
>The DS200 (as used by DEC) does only support 9600 Bd. Where did you get
>the info about the max speed?

Based on my work with similar hardware, I assert that a 10MHz 68000
with ordinary double- or triple-buffered UARTs will just barely drive
8 full-duplex 9600 bps ports at full speed. Most of the common UART
components of the vintage in question will support speeds up to 38400
bps. You could probably get away with driving two V.32bis/V.42bis
modems at the same time with only occasional overruns.

Considering the effort required to program this (and reverse-engineer
the programming spec for the board) I don't think it is worth it.
-- 
/ Lars Poulsen			Internet E-mail: lars@CMC.COM
  CMC Network Products		Phone: (011-) +45-31 49 81 08
  Hvidovre Strandvej 72 B	Telefax:      +45-31 49 83 08
  DK-2650 Hvidovre, DENMARK	Internets: designed and built while you wait

-----------[000334][next][prev][last][first]----------------------------------------------------
Date:      Fri, 17 Dec 1993 12:59:03 GMT
From:      ian@unipalm.co.uk (Ian Phillipps)
To:        comp.protocols.tcp-ip
Subject:   Re: Network licence broadcasts: Recommended methods?

howland@us-es.sel.de (Gary Howland US/END 60/1/25) writes:

>Can anybody tell me if there is a recommended approach to enforcing
>a software licence on software by means of network broadcasts?
>ie. suppose I am running some software that wishes to ensure no one else
>is running the same piece of software on the same network.  What is the recommended or "polite" way of doing this?  Is a network broadcast every
>10 minutes considered impolite?

Very impolite. The systems that I know about use a single broadcast
each time the software is booted: this should be quite sufficient.
PC-NFS broadcasts to the UDP "discard" port.

PC/TCP does this without using *any* extra broadcasts - it piggybacks
its licence information on each ARP request, in an otherwise unused
field (destination hardware address).

Having said that, SCO systems do broadcast, and every 30 seconds, too.
For some reason, they haven't had nearly as much net.flamage as FTP
(PC/TCP authors) - well, not on that subject, anyway :-)

You have to multiply one-per-10-minutes by the number of hosts on a
bridged network. I have heard of a bridged network of 40000 hosts, but
that's exceptional (and pretty dumb IMHO).

Ian
-- 
Ian Phillipps. Tech support manager, Unipalm.
Phone +44 223 250103, Fax 250101
Pipex phone +44 223 250120. Internic: IP4.

-----------[000335][next][prev][last][first]----------------------------------------------------
Date:      Fri, 17 Dec 1993 13:13:38 GMT
From:      steven@unipalm.co.uk (Steven Vincent)
To:        comp.protocols.tcp-ip
Subject:   Re: PCs and pings (a dreadfull combination)

kerch@reynaldo.PARC.Xerox.Com (Berry Kercheval) writes:

>>>>>> "Ran" == Ran Atkinson <atkinson@itd.nrl.navy.mil> writes:
>In article <CHtFn2.DIJ@ra.nrl.navy.mil> atkinson@itd.nrl.navy.mil (Ran Atkinson) writes:
>    Ran> In article <mills.755388363@dialup.athena.tay.dec.com>
>    Ran> mills@athena.tay.dec.com (George Mills) writes:
>    >> Now that the hotest things these days is automated network
>    >> topoligy systems (NetView 6000), the PC's are hurting.
>    >> Any Ideas on how to deal with this?
 
>    Ran> Using ping(8) semi-continuously as a tool to determine
>    Ran> network topology is unwise.  It consumes lots of bandwidth
>    Ran> and causes many networking problems.  
 
>Be that as it may, any TCP/IP stack that crashes when it gets a ping 
>is BROKEN.  See rfc1122 (Host Requirements):

That is not disputed. I have joined this thread late but I have seen several
cases of old or limited hardware which while not crashed are effectivly hung
since servicing the flood of pings consumes such a high proportion of the
processor power that all usefull work stops.  Once the pings are turned off
then work resumes. I have also ground remote machines into the dust using
lots of very simple SNMP look ups from a higher powered system that was not
cacheing answers. OK I was doing a silly thing but the user of the target
could not understand what was happening.


>  --berry


>--
 
>Berry Kercheval :: kerch@parc.xerox.com 
>"...start with Plan 9, which is free of sin..." -Mark V. Shaney


-----------[000336][next][prev][last][first]----------------------------------------------------
Date:      Fri, 17 Dec 1993 13:21:30 GMT
From:      ian@unipalm.co.uk (Ian Phillipps)
To:        comp.protocols.tcp-ip
Subject:   Re: How do I get my own IP address?

diego@cs.ualberta.ca (Diego Novillo) writes:

>I am running a Unix box at home and I would want to get my own IP address. I
>would be using SLIP because I just have a regular phone line. Is this possible
>to do? If so, how do I get one?

You'd be best off using a small subnet owned by UA (or whoever). This
is *much* less complicated, all told.  You may be able to get a class C
address, but then you'll discover the interesting problems associated
with it, such as having to apply for NSFnet routing etc.

Consult the network manager at UA for advice. They may have addresses
you can use already. If they won't offer you a subnet, they may also
prove sticky about agreeing to route your private network off-campus.

In general, IP network numbers come from service providers these days -
you're encouraged to obtain one from the provider that you will be (or
are most likely to be) connecting to. This is because of CIDR-announced
routes ("supernetting") where groups of networks are announced as one
address.

Ian
-- 
Ian Phillipps. Tech support manager, Unipalm.
Phone +44 223 250103, Fax 250101
Pipex phone +44 223 250120. Internic: IP4.

-----------[000337][next][prev][last][first]----------------------------------------------------
Date:      Fri, 17 Dec 1993 14:23:16 GMT
From:      atkinson@itd.nrl.navy.mil (Ran Atkinson)
To:        comp.protocols.tcp-ip
Subject:   Re: Experimental Protocols

In article <2en73e$ilo@linus.mitre.org> jfjr@mbunix.mitre.org (Freedman) writes:

>   I have three Suns, SunA, SunB and SunC, all on the same subnet, all
>have one ethernet interface, le0. The swipe pseudo driver is called
>sw0. SunA and SunB are running SWIPE, Sun C is not. I would like, at
>least for my testing purposes to send packets from SunA to SunC by way
>of SunB. The packet from SunA to SunB is a SWIPE packet - an IP packet
>addressed to SunC but encapsulated in another IP packet addressed to
>SunB. When SunB receives the packet I would like it to unpack the
>encapsulated packet and forward it to SunC. This part doesn't happen.
>I can get SunA to send the encapsulated packet to SunB which, I think,
>should relay the packet to SunC. The much hoped for relay doesn't
>happen. SunB unencapsulates the packet and puts in on the ip input
>queue but the packet doesn't get relayed, it just gets dropped.
>
>   I am using ping so the packet in question is an ICMP echo request
>which should get to ICMP which in turn should at least send an ICMP
>redirect (shouldn't it). Is my problem configuration?. Is there
>something I can do to SunB to make it act as a sort of one interface
>gateway?

  Are you sure that you don't need to have _2_ Ethernet cards in Sun
B, one configured to not use swIPe and one configured to use swIPe ??

A dual-homed system configuration would be the more usual
configuration of an IP security gateway.  I don't think I've ever
heard JI talk about supporting a configuration such as yours and I
have talked with him now and anon about swIPe.

Ran
atkinson@itd.nrl.navy.mil

-----------[000338][next][prev][last][first]----------------------------------------------------
Date:      17 Dec 1993 16:06:59 GMT
From:      mjo@iao.ford.com (Mike O'Connor)
To:        comp.security.misc,comp.protocols.tcp-ip,comp.mail.sendmail
Subject:   Re: "large security gap in the Internet"

In article <2en4ar$e9a@bushwire.apana.org.au>
markd@bushwire.apana.org.au (Mark Delany) writes:

:I used to believe this, but the latest sendmail clocks in at a mere
:13,000 lines of executable code (or thereabouts) which doesn't seem
:overly daunting to me for the task at hand. I suspect that it is more
:a matter of reputation than reality.

To me, "mere" means I can cat the code on my 80x24 display rather than
pipe to a pager or read in an editor, obfuscated C contests excluded.

Also, I believe that your 13,000 lines figure is inaccurate.  I just
FTPed sendmail 8.6.4 from ftp.cs.berkeley.edu and did a "wc *.c" in
the src directory and came up with around 25,000 lines.  Granted, a 
good hunk of that probably consists of copyright notices and perhaps
thinly-veiled threats to USL :), but still, I don't think you have
the facts right.  Check out TIS/Marcus Ranum's firewall package,
available via anonymous FTP from ftp.tis.com, for smap/smapd:

        smap - sendmail wrapper.

        the object of this program is to allow us to present an SMTP service
        for people to talk to, which is unprivileged, and runs in a chrooted
        directory. a secondary requirement is that the code be as simple as
        possible, to permit manual review. this code, therefore, contains
        no comments other than this one - comments being an indication that
        code is too complex to be trusted.

-- 
 Michael J. O'Connor           |  Internet:  mjo@jobone.srl.ford.com
 Ford Motor Company, OPEO      |  UUCP:      ...!fmsrl7!opeo!mjo
 20000 Rotunda, Bldg. 1-3001   |  Phone:     +1 (313) 248-1260
 Dearborn, MI  48121           |  Fax:       +1 (313) 323-6277

-----------[000339][next][prev][last][first]----------------------------------------------------
Date:      Fri, 17 Dec 1993 16:14:36 GMT
From:      vjs@calcite.rhyolite.com (Vernon Schryver)
To:        comp.protocols.tcp-ip
Subject:   Re: Network licence broadcasts: Recommended methods?

In article <1993Dec17.125903.12587@unipalm.co.uk> ian@unipalm.co.uk (Ian Phillipps) writes:
>...
>PC/TCP does this without using *any* extra broadcasts - it piggybacks
>its licence information on each ARP request, in an otherwise unused
>field (destination hardware address).

Does this cause no systems any problems? 
A few years ago while looking at "dual-rail ARP" for things like putting
data on both FDDI rings using a dual-MAC interface, I think some people
were concerned that there were systems that would go crazy if those fields
were not zero.


Vernon Schryver    vjs@rhyolite.com

-----------[000340][next][prev][last][first]----------------------------------------------------
Date:      17 Dec 93 16:57:25 GMT
From:      medici@hardees.rutgers.edu (Mark Medici)
To:        comp.protocols.tcp-ip
Subject:   Re: Clarkson TCP crashes Windows 3.1 in Enhanced mode. Why?

shwake@nearside.UUCP (Raymond Shwake) writes:

>... if Windows is
>running in 386 Enhanced mode, it'll typically run fine for up to 20
>seconds or so, then completely crash Windows to the point the system
>must be cold booted. It happens whether running EMM386 or not.
>
>	Microsoft was unable to assist. Can anyone here?

You need to use the WINPKT shim.

Both the CUTCP applications and the packet driver are real-mode DOS
programs.  Once they start talking to each other they don't check to
see if their relative memory locations have changed.  However, Windows
in enhanced mode will shift things around in memory as it desires.
Then an incoming packet arrives, the packet driver tries to write the
information to the real memory address where it expects to find
Telnet, and instead writes into some other application (or the Windows
kernal, a driver, whatever).  This is what causes the crash.

WinPkt acts as an interface between the real-mode packet driver and an
application running in Windows in enhaced mode.  You should be able to
find it in the same place you found your packet drivers.

-- 
_________________________________________________________________________
RUCS     | Mark A. Medici * Telecommunications Analyst II * User Services
User     | Rutgers University Computing Services, New Brunswick, NJ 08903
Services | [medici@gandalf.rutgers.edu]                    [908-932-2412]

-----------[000341][next][prev][last][first]----------------------------------------------------
Date:      17 Dec 93 22:58:59
From:      vixie@vix.com (Paul A Vixie)
To:        comp.unix.bsd,comp.protocols.tcp-ip
Subject:   Re: virtual hosts based on ip address?

> This sounds like a job for a tcp wrapper type program (ie, inetd runs this
> program and it spawns the right process).  Does anyone have one?

log_tcp, posted to comp.sources.misc recently, would be the right starting
point.  you'd end up execing a sh script to make the decision for you, but
at least log_tcp (a "tcp wrapper" meant to be called from inetd) would put
the remote address into an environment variable for you.
--
Paul Vixie
Redwood City, CA
<paul@vix.com>
decwrl!vixie!paul

-----------[000342][next][prev][last][first]----------------------------------------------------
Date:      17 Dec 1993 19:14:34 GMT
From:      gsteckel@harpoon.East.Sun.COM (Geoff Steckel - Sun BOS Hardware CONTRACTOR)
To:        comp.dcom.cell-relay,comp.protocols.tcp-ip,comp.dcom.isdn
Subject:   Re: Why connectionless ?

In article <dobo.756058985@swalwell> dobo@cs.UAlberta.CA (W. Dobosiewicz) writes:
>
>Clearly, the idea of increasing the window size is a good solution to
>increasing network sizes, albeit only a partial one.

It's the best, and only, one we've got now.  (proof by assertion).
It works and has been successfully implemented for very high speed links.

>Sooner or later, we
>will get to the point when switching to some other protocol, one not
>relying as heavily on end-to-end feedback, will become reasonable.

Perhaps, but
  1) the data transfer is part of a system
  2) the system must be reliable, or it's junk (IMHO)
  3) end-to-end feedback is the primary way end-to-end integrity
     is assured

>Another point related to TCP over ATM is that of congestion control in
>ATM. When a VC exceeds its guaranteed rate (approaching its peak rate), it
>may lose cells. This will make TCP to retransmit the packet when the loss
>is detected. When the round-trip feedback is large (as it is in gigabit
>wide area networks), you may want a large window size, which will cause
>another burst when the source retransmits the packet, again increasing the
>risk of cell loss, etc.

We probably need an 'ATM->IP adaption layer' for encapsulating IP reliably
over ATM.  It will require large buffers, but if it is done intelligently
only the failed portion need be retransmitted, not the entire message which
was invalidated.  The problem has been studied somewhat for IP fragmented
message reassembly under conditions of packet loss.

>The solution of having a fixed capacity assigned to VCs does not appeal to
>data people, who claim to have bursty traffic.

Claim?  Measurements (published) show this.  Worse, they follow 1/f statistics
meaning that over time the probability is 1 that any demand limit will be
exceeded.

-- 
	geoff steckel (gwes%om3@trilobyte.com)
Disclaimer: I am not affiliated with Sun Microsystems, despite the From: line.
This posting is entirely the author's responsibility.

-----------[000343][next][prev][last][first]----------------------------------------------------
Date:      17 Dec 1993 20:10:52 GMT
From:      yqian@vt.edu (Yihong Qian)
To:        comp.protocols.tcp-ip
Subject:   PhoneNET and WfW working!--Can't load TCP/IP stack with ODI driver

Dear netters:

Thanks for all responses and answers. I finally got PhoneNET PC and WfW
3.11 running together in windows!! Though the AFP file server is still not
available (SHOULD be able to if can obtain enough memeory?), the PhoneNET's
printer sharing and Timbuktu for file transfers are working --- which is
great! 

The TRICKY thing is to set the network driver type as ODI driver, and load
Phonenet.bat (instead of ABOTH.bat) before WFW's NET START and ODIHLP.EXE.


*NOTE!!! -- STILL NEED HELP ON:
-------------------------------

The other problem I have is that I can't load the MS TCP/IP protocol stack
under the ODI driver type setting (in Network setup). I don't think there
are too many network stuff to be loaded. The problem is probably with the
network configuration again (I hate this!). The message I have got is that:
MS TCP/IP is a real-mode protocol, my network card is set up to use only
protected-mode protocols (ODI driver?), and I need to set up my network
card to work with both real- and protected-mode protocols.

If you have further solutions to the MS TCP/IP & ODI incompatible problem,
please keep me posted. I look forward to making this to work also because I
wish to run the Winsock.dll to get access to Eudora, Gopher and other
wonderful communication applications. 

Special thanks go to Mark Wieder at Farallon Co.

HAVE A MERRY CHRISTMAS and A NICE HOLIDAY!

-----------
Yihong Qian, Programmer/Analyst                           email:
yqian@vt.edu
Virginia Tech

-----------[000344][next][prev][last][first]----------------------------------------------------
Date:      Fri, 17 Dec 1993 20:24:42 GMT
From:      craig@sics.se (Craig Partridge)
To:        comp.protocols.tcp-ip
Subject:   re: New Stevens Book/Daylight savings time

> 1) What date should the new Stevens TCP/IP book be on the shelf?

Hi -

    I just checked with the publisher (Rich and I have the same editor).

    The book has been printed and should be shipping to stores over the next
few weeks.  In general, I'd expect it in your local bookstore around the second
week of January.  I understand that Computer Literacy asked for expedited
delivery of some copies which they should get just before the New Year.

Craig

-----------[000345][next][prev][last][first]----------------------------------------------------
Date:      Fri, 17 Dec 93 21:15:08 GMT
From:      ccg@tcdsp1.mmm.com ("Charles Ganzhorn")
To:        comp.dcom.cell-relay,comp.protocols.tcp-ip,comp.dcom.isdn
Subject:   Re: Why connectionless ?

In article <2eprc4$dfm@disuns2.epfl.ch>, sarkies@ltisun8.epfl.ch (Professeur) writes:
|> In article <2enm8d$ivi@opus.eng.sc.rolm.com>, ddean@opus.eng.sc.rolm.com (Drew Dean) writes:
|> 
|> |> California to Illnois or Ohio), you need ~ $500 of RAM for your network
|> |> buffers.  On a > $1M machine, who cares ?
|> |> 
|> 
|> There have been a lot of posts on this statement, so I may as well add one.
|> Won't these buffers need to be in every switch? If so, it is not so much a
|> question of adding $500 to the network connection of some supercomputer
|> user, but of adding it to everyone's network connection, regardless of whether
|> that person uses it or not. The costs of this buffering will need
|> to be spread over all network users, and as someone pointed out, it will not
|> be the sort of memory in your PC, but high speed high cost stuff, along with
|> all the control and maintenance costs. So if 99.99% of network users make
|> 64K telephone calls needing a few K of buffering, will they be happy with this
|> cost?
|> 

No.  The discussion has been about delays due to a window size which would be
small enough for an end station to have all the data it is allowed to send be in
the pipe.  What people have been talking about is having a window size on the end
stations which would be large enough to ensure that the sending station has
received acknowledgement of some part of the previously sent data BEFORE he has
sent enough data to fill the window that the receiving side had advertised and
thus stops transmitting until he gets an acknowledgement.

The network is going to shuffle packets through as fast as it can:  it doesn't
know about windows 'cuz that's a transport layer concern.  If you're wondering
where all this storage is in the network:  it is literally on the wire.  That was
what the one fellow was talking about in terms of the physical length of a bit at
gigabit speeds.

Charles.
--
Charles Ganzhorn			E/Mail:  ccganzhorn@mmm.com
3M IT Network Services			AT&T:	 +1 612 736 7122
St. Paul, MN				FAX:	 +1 612 736 7689

-----------[000346][next][prev][last][first]----------------------------------------------------
Date:      17 Dec 1993 22:37:38 GMT
From:      jsb@gumby.dsd.TRW.COM (John Bien)
To:        comp.sys.mac.comm,comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject:   MacTCP and BOOTP (RFC1395 or RFC1497 implementations anyone?)

We're investigating using BOOTP to configure all our Macs and PCs.
When I tested this on my Mac (running MacTCP 1.1.1) using
the CMU bootp server (version 2.1) I get all the configuration
data I need except my domain name.  The domain name
is the value that gets appended to every DNS query (ie
a connection to "gumby" will actually go to "gumby.dsd.trw.com").

Do any of the later versions of MacTCP get around this.  I looked
at the BOOTP RFCs (there are now 4 of them), and RFC 1395 defined
a bootp tag for the domain name.  Will MacTCP use this?  Does
anybody know of a bootpd server that implements it (CMU bootpd 2.2alpha
only implements RFC 1084).  I queried Archie, and it looks like
the only bootpd servers available are based on CMU 2.1 or 2.2.

I know there are large sites relying on bootp for configuration.
Do they just live without a default domain name?  Will I have this
same problem with other devices (we have lots of PC's running FTP's PC/TCP)?

Any help would be greatly appreciated..

-John
-- 
	John Bien 				(310) 814-8546
	TRW Space and Electronics Group, Communications services
	jsb@gumby.dsd.TRW.COM			(Internet)

-----------[000347][next][prev][last][first]----------------------------------------------------
Date:      Sat, 18 Dec 1993 03:16:48 GMT
From:      mark@labtam.labtam.oz.au (Mark Treacy)
To:        comp.unix.bsd,comp.protocols.tcp-ip
Subject:   Re: virtual hosts based on ip address?

zeeff@zip.eecs.umich.edu (John Zeeff) writes:
>I'd like to take one physical machine (running bsdi) and make it look like
>two different machines to the outside world.  In particular, I'd like
>people to be able to do things like "gopher machine1.org" and "gopher
>machine2.com" and get different menus (I don't want to use non standard 
>port numbers for this).  So ideally the one machine would have two ip
>addresses and inetd would detect which one was being used and spawn the 
>appropriate gopherd.
The one physical machine can have multiple ip interfaces, be they slip,
ppp, ethernet or whatever.  You typically give each a different address.
You can then name them in the dns (named, bind).
If you only have one network interface, you can assign multiple addresses
to that one interface, e.g.

	ifconfig if0 alias cc.dd.ee.ff

Inetd would however need to be changed if you wanted
to offer different services depending on address used.
You may prefer to change gopherd instead.

 - Mark.

-----------[000348][next][prev][last][first]----------------------------------------------------
Date:      18 Dec 1993 03:52:07 GMT
From:      zeeff@zip.eecs.umich.edu (John Zeeff)
To:        comp.unix.bsd,comp.protocols.tcp-ip
Subject:   Re: virtual hosts based on ip address?

>Inetd would however need to be changed if you wanted
>to offer different services depending on address used.
>You may prefer to change gopherd instead.

This sounds like a job for a tcp wrapper type program (ie, inetd runs this
program and it spawns the right process).  Does anyone have one?


-----------[000349][next][prev][last][first]----------------------------------------------------
Date:      19 Dec 93 04:16:56 PST
From:      cleung2@jupiter.uucp (C Leung)
To:        comp.protocols.tcp-ip
Subject:   Re: Request for a FAQ

Me too :)
Thank you very much !

- Joe Leung email address is cleung2@opus.calstatela.edu

-----------[000350][next][prev][last][first]----------------------------------------------------
Date:      Sat, 18 Dec 93 22:13:51 GMT
From:      tadams@ll.mit.edu ( Tony Adams)
To:        comp.protocols.tcp-ip
Subject:   Seeking papers/books on Ethernet performance analysis


System: Network of Unix machines (Sun's, Convex and PC's)

What are considered to be good books/papers regarding ethernet
performance analysis issues?

We wish to characterize our ethernet performance in detail. We have
several text books which contain scattered bits of information and
are hoping to find one or a few more complete/specific sources of
information.

Thanks for any pointers.



-----------[000351][next][prev][last][first]----------------------------------------------------
Date:      Sat, 18 Dec 1993 23:29:04 GMT
From:      ag129@ucs.cam.ac.uk (Alasdair Grant)
To:        comp.protocols.iso,comp.protocols.tcp-ip
Subject:   Re: Issue for dicussion - Connection Oriented Vs Connectionless  Protocols

In article <1993Dec14.093731.43202@ucl.ac.uk> ucacjon@ucl.ac.uk (Jon Crowcroft) writes:
>however, obviously,m the number of packets to set up and tear down a 
conenction>fro mthe application layer down can be amortized over a number of 
exchanges - >provided the application actually does a number - if its a lot 
of clients for a single>transaction server then you lose very very very 
badly compared with a connectionles>rpc like NFS uses....hence novell and 
nfs dont use iso:-)

Must be why Novell and NFS are a real pig to scale into a wide-area
heterogenous environment.  Also Novell RPC is connection-oriented.
Making an RPC call ab initio to a Novell server involves at least three
exchanges: connection setup, RPC and tear-down.  An authenticated RPC
call is dozens of end-to-end exchanges.  And if the packets are routed,
the MTU is set to 500 bytes coz there's not much else a connectionless
protocol can do.  I wish Novell _did_ use OSI!

-----------[000352][next][prev][last][first]----------------------------------------------------
Date:      19 Dec 1993 20:23:13 GMT
From:      tli@cisco.com (Tony Li)
To:        comp.protocols.tcp-ip
Subject:   Re: supernet/subnet question

In article <40.28.1751.0NE1518A@channel1.com> tom.kauffman@channel1.com
(Tom Kauffman) writes: 
    
    I need to have some kind soul clarify my understanding of subnets and
    supernets (and point me to the RFC on supernets, if possible)?
    
RFC 1519 is a good start.

    We have been assigned a group of 8 class C addresses by the InterNIC:
    199.19.8.0 through 199.19.15.0 (I think - I left the doc at the office).
    
    If I use a netmask of 255.255.248.0 and a subnet mask of 0.0.7.128, do I
    end up with 14 subnets of 126 hosts each, all on a defacto net of
    199.19.8.0? We're about to start playing in the tech support group and
    it would be nice to get the bloody addressing set up right (there are
    many more ways to shoot yourself in the foot that we'll find later :-).
    
Most systems right now won't let you configure things quite that way.  You
can't have a netmask shorter than the natural mask.  But you have the
concept down.  Right now, you would have to use a netmask of 255.255.255.0
or 255.255.255.192.

Tony

-----------[000353][next][prev][last][first]----------------------------------------------------
Date:      20 Dec 93 09:34:22 -0600
From:      pearcedh@rcwusr.bp.com
To:        comp.protocols.tcp-ip
Subject:   Internal BIND Root Servers. How many?

We are in the process of creating an Internal Root BIND Service.
I have found the following book invaluable

DNS and BIND
by Paul Albitz & Cricket Liu
Published by O'Reilly & Associates

However I have found one piece of information seemingly missing. In the log
files of my BIND Servers I am finding the following message:

localhost: 68 named: check_root: 1 root servers after query to root server < min

I presume this means that I should have more than the 1 BIND Root Server in our
network. But what is the minimum that I should have?  I have been told it is 3
but I have not seen this written down anywhere.

Your help would be appreciated?

Additionally any comments about how others have provide an Internal BIND 
Root Service for a company that is geographically spread around the world.
How have you determined how many and where to locate your Internal Root 
Servers?

Thanks for any help you can provide.
-- 
Huw Pearce                   E-mail: pearceh@rcscl1.dnet.bp.com

BP Research & Engineering
Chertsey Road
Sunbury-on-Thames
Middlesex  TW16 7LN
United Kingdom

-----------[000354][next][prev][last][first]----------------------------------------------------
Date:      Sun, 19 Dec 1993 23:52:29 GMT
From:      stevea@lachman.com (Steve Alexander)
To:        comp.protocols.tcp-ip
Subject:   Re: Network licence broadcasts: Recommended methods?

In article <1993Dec17.125903.12587@unipalm.co.uk> ian@unipalm.co.uk (Ian Phillipps) writes:
>Having said that, SCO systems do broadcast, and every 30 seconds, too.
>For some reason, they haven't had nearly as much net.flamage as FTP
>(PC/TCP authors) - well, not on that subject, anyway :-)

Actually, they *were* flamed (justifiably), and I believe that newer (ODT 2.0 &
higher) systems only broadcast at TCP/IP startup time or whenever a new product
that uses the copy-protect code (e.g. NFS) starts up.

-- 
Steve Alexander, Lachman Technology, Inc. | stevea@lachman.com
(708) 505-9555 x256 FAX: (708) 505-9574	  | ...!{sun,ico}!laidbak!stevea

-----------[000355][next][prev][last][first]----------------------------------------------------
Date:      20 Dec 1993 05:36:49 GMT
From:      harri906@crow.csrv.uidaho.edu (Harrington)
To:        comp.protocols.tcp-ip
Subject:   Network TCP/IP

Hi! I am looking for a network that supports TCP/IP packet drivers.
I have two computers with packet drivers that support paralell ports, a
cable between the two and nothing else.  Are there any shareware networks
or even that (FREE??!?!?!) network from Microsoft that I hear so much
about but can never pin anyone down about...
        I would even like an older version of a network that one of you 
already
have upgraded from!
ANYTHING!
        I am just 17 so I don't have much money but we really need a
network between our two pc's for programming etc that my brother and I do.
Thanks a LOT!
And a Merry Christmas!
Dan Harrington


-----------[000356][next][prev][last][first]----------------------------------------------------
Date:      20 Dec 1993 12:59 EST
From:      stern@dftnic.gsfc.nasa.gov (Sterns law - If at first you don't succeed, get a bigger hammer)
To:        comp.protocols.tcp-ip
Subject:   RE:Virtual host, two addresses

zeeff@zip.eecs.umich.edu (John Zeeff) writes:
>I'd like to take one physical machine (running bsdi) and make it look like
>two different machines to the outside world.  In particular, I'd like
>people to be able to do things like "gopher machine1.org" and "gopher
>machine2.com" and get different menus (I don't want to use non standard 
>port numbers for this).  So ideally the one machine would have two ip
>addresses and inetd would detect which one was being used and spawn the 
>appropriate gopherd.

Another option is to handle this the way hosts that have multiple gophers 
often handle it ie put the different gopher daemons on different sockets.
The downside of this is you'll need to let your users know that they either
need to 

%gopher machine.org
   or
%gopher machine.org 71

As an additional feature, you could have gopher menu items pointing back and
forth between the two.

Dave Stern

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
                              Hughes STX
                             301-286-6079
 INTERNET- STERN@DFTNIC.GSFC.NASA.GOV           Goddard Space Flight Center
 DECnet-   DFTNIC::STERN                        Code 933   Bldg 28 Rm W248
                                                Greenbelt, MD 20771
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
     Disclaimer:  The opinions reflected above are not shared by 
                  the late Howard Hughes. In fact, they are probably
                  not shared by any other humanoid. I call this creativity.

-----------[000357][next][prev][last][first]----------------------------------------------------
Date:      Mon, 20 Dec 93 21:17:00 -0500
From:      tom.kauffman@channel1.com (Tom Kauffman)
To:        comp.protocols.tcp-ip
Subject:   supernet/subnet question

Subject: supernet/subnet question

I need to have some kind soul clarify my understanding of subnets and
supernets (and point me to the RFC on supernets, if possible)?

We have been assigned a group of 8 class C addresses by the InterNIC:
199.19.8.0 through 199.19.15.0.

If I use a netmask of 255.255.248.0 and a subnet mask of 0.0.7.192, do I
end up with 30 subnets of 62 hosts each, all on a defacto net of
199.19.8.0? We're about to start playing in the tech support group and
it would be nice to get the bloody addressing set up right (there are
many more ways to shoot yourself in the foot that we'll find later :-).

Does any PC-oriented package support CDIR yet? How about RFC950? We
brought Netmanage's Chameleon in for trial and it assumes all subnet
bits are in the host address - definitely not what we are planning on.

We will NOT be connecting to the Internet in '93; maybe sometime in '94,
although my bet at the office is early '95 - so we'll have the basics
well sorted out before hand.

Tom Kauffman
Senior Systems Programmer
NIBCO, Inc.
---
 þ QMPro 1.51 þ Klein bottle for rent.  Inquire within.

-----------[000358][next][prev][last][first]----------------------------------------------------
Date:      20 Dec 93 14:46:28 GMT
From:      manmetha@gauss.rutgers.edu (Rajesh Malhotra)
To:        comp.unix.aix,comp.unix.questions,comp.protocols.tcp-ip
Subject:   Internet access Question. How To?




Networking Gurus,

	Our environment consists of two networks (ethernet based) 
say NET1 and NET2. These two are independent networks with no access
from one to another. NET1, the larger net has access to the Internet
and I wish to provide the users on NET2 the internet access. However
since NET2 is to be secure, I do not want to provide NET1 and the
outside world access to NET2.

	How would I go about providing this sort of connectivity.
Is there any specialized hardware I need to connect the two nets, or can
I use a PC with some software to provide the connectivity between the
two nets? Is there any PD software available that would do this sort of
thing?

	Any and all responses on this matter greatly appreciated.

Thanx,

Raj.
-- 
===============================================================================
  __  __     .
 /   __/    /                               Raj Malhotra.
/   ( /_   /                                voice : (908)613 4313. 
        __/                                 email : manmetha@gauss.rutgers.edu

===============================================================================

-----------[000359][next][prev][last][first]----------------------------------------------------
Date:      Mon, 20 Dec 1993 18:59:09 GMT
From:      thomasd@tt726.NoSubdomain.NoDomain (Tom Depke)
To:        comp.protocols.tcp-ip
Subject:   FAQ request

Does an FAQ exist ? if so please post or email location

Thank you

-- 
[Tom Depke                    INTERNET: thomasd@tterms.comm.mot.com ]
[Motorola Inc.                Trunking Network Management           ]
[PHONE: (708) 576-3356        FAX: (708) 538-4315                   ] 

-----------[000360][next][prev][last][first]----------------------------------------------------
Date:      20 Dec 1993 19:28:15 GMT
From:      zeeff@dip.eecs.umich.edu (John Zeeff)
To:        comp.unix.bsd,comp.protocols.tcp-ip
Subject:   Re: virtual hosts based on ip address?

So the remaining issue is how does one find the address that the originator
of the connection used to come in on (ie, what interface is being used)
when one is using the ifconfig alias command.

So similar to getpeername(), but for the local side.

I've haven't looked into it yet, but it seems that that information must be
available somewhere.


-----------[000361][next][prev][last][first]----------------------------------------------------
Date:      20 Dec 1993 19:32:43 GMT
From:      nessett@framsparc.ocf.llnl.gov (Dan Nessett)
To:        sci.crypt,alt.security,comp.protocols.tcp-ip,comp.security.misc
Subject:   2nd Announcement - Symposium on Network and Dist. Sys. Security

ISOC Symposium on Network and Distributed System Security
---------------------------------------------------------

Program
-------

Wednesday, February 2

6:00 P.M. - 8:00 P.M.
  Registration and Reception 

Thursday, February 3

7:30 A.M.
  Continental Breakfast 
8:30 A.M.
  Opening Remarks 
9:00 A.M.
  Session 1:  Electronic Mail Security
                       Chair: Steve Kent (BBN)
  Certified Electronic Mail, Alireza Bahreman (Bellcore) and Doug Tygar 
    (Carnegie Mellon University), USA
  Privacy Enhanced Mail Modules for ELM, Selwyn Russell and Peter 
    Craig, Queensland University of Technology, Australia
  Management of PEM Public Key Certificates Using X.500 Directory 
    Service: Some Problems and Solutions, Terry Cheung, Lawrence 
    Livermore National Laboratory, USA
10:30 A.M.
  Break
11:00 A.M.
  Session 2: Panel: Public Key Infrastructure, Santosh Chokhani (MITRE), 
    Michael Roe (Cambridge University), Richard Ankney (Fischer, Intl.)
                       Chair: Miles Smid (NIST)
12:30 P.M.
  Lunch
2:00 P.M.
  Session 3:  Protocols
                       Chair: Tom Berson (Anagram Labs)
  Paving the Road to Network Security, or The Value of Small Cobblestones, 
    H. Orman, S. O'Malley, R. Schroeppel, and D. Schwartz, University of 
    Arizona, USA
  A Complete Secure Transport Service in the Internet, Francisco Jordan 
    and Manuel Medina, Polytechnical University of Catalunya, Spain
3:00 P.M.
  Break
3:30 P.M.
  Session 4:  Internet Firewall Design and Implementation
                       Chair: Jim Ellis (CERT)
  Inter-LAN Security and Trusted Routers, Pal Hoff, Norwegian Telecom 
    Research, Norway
  Trusted to Untrusted Network Connectivity:  Motorola Authenticatd 
    Internet Access -- MANIAC(TM), Bill Wied, Motorola, USA
  BAfirewall: A Modern Firewall Design, Ravi Ganesan, Bell Atlantic, USA
  A Network Perimeter With Secure External Access, Frederick Avolio and
     Marcus Ranum, Trusted Information Systems, USA
7:00 P.M.
  Banquet

Friday, February 4

7:30 A.M.
  Continental Breakfast
8:30 A.M.

  Session 5:  Panel: All Along the Watchtower: Experiences and Firefights 
    Managing Internet Firewalls, Bryan Boyle (Exxon Research), Brent 
    Chapman (Great Circle Consulting), Bill Cheswick (AT&T Bell Labs), 
    Allen Leibowitz (Warner-Lambert), Paul Vixie (Vixie Enterprises)
                       Chair: Marcus Ranum (TIS)
10:00 A.M.
  Break
10:30 A.M.
  Session 6:  Issues in Distributed System Security
                       Chair: Cliff Neuman (USC-ISI)
  CA-Browsing System -- A Supporting Application for Global Security 
    Services, Denis Trcek, Tomas Klobucar, Borka Jerman-Blazic, and Franc 
    Bracun, Jozef Stefan Institute, Slovenia
  The X.509 Extended File System, Robert Smart, CSIRO Division of 
    Information Technology, Australia
  Auditing in Distributed Systems, Shyh-Wei Luan (VDG, Inc.) and Robert 
    Weisz (IBM Canada Laboratory), USA/Canada
12:00 Noon
  Lunch
1:30 P.M.
  Session 7:  Authentication
                       Chair: Dave Balenson (TIS)
  The S/KEY(tm) One-Time Password System, Neil Haller, Bellcore, USA
  A Technique for Remote Authentication, William Wulf, Alec Yasinsac, 
    Katie Oliver, and Ramesh Peri, University of Virginia, USA
  Remote Kerberos Authentication for Distributed File Systems:  As 
    Applied to a DCE DFS-to-NFS File System Translator, Thomas Mistretta 
    and William Sommerfeld, Hewlett-Packard, USA
3:00 P.M.
  Break
3:30 P.M.
  Session 8:  Panel:  IP Security Alternatives, K. Robert Glenn (NIST), Paul 
    Lambert (Motorola), David Solo (BBN), James Zmuda (Hughes)
                       Chair: Russell Housley (Xerox)


PROGRAM CO-CHAIRS

Russell Housley, Xerox Special Information Systems
Robert Shirey, The MITRE Corporation

GENERAL CHAIR

Dan Nessett, Lawrence Livermore National Laboratory

PROGRAM COMMITTEE

Dave Balenson, Trusted Information Systems
Tom Berson, Anagram Laboratories
Matt Bishop, University of California, Davis
Ed Cain, U.S. Defense Information Systems Agency
Jim Ellis, CERT Coordination Center
Steve Kent, Bolt, Beranek and Newman
John Linn, OpenVision Technologies 
Clifford Neuman, Information Sciences Institute
Michael Roe, Cambridge University
Robert Rosenthal, U.S. National Institute of Standards and 
           Technology
Ravi Sandhu, George Mason University
Jeff Schiller, Massachusetts Institute of Technology
Peter Yee, U.S. National Aeronautics and Space
           Administration

BEAUTIFUL SAN DIEGO

The Symposium venue is the Catamaran Resort Hotel, providing 7 acres of  
gorgeous surroundings, facing Mission Bay and only 100 yards from 
beautiful Pacific Ocean beaches. Spouses and family members can catch a  
convenient Harbor Hopper for a quick trip to Sea World. After the 
Symposium, plan to spend  the weekend  visiting La Jolla, the world 
famous San Diego Zoo or Mexico, only  30 minutes by car or Trolley.

A limited number of rooms have been reserved at the Catamaran for the 
very special rate of $77 single, $87  double. Reservations, on a space 
available basis, can be made by calling (800) 288-0770 and indicating you are  
attending the ISOC Symposium. Reservations must be made before Jan. 1, 
1994 to ensure  this rate.

CLIMATE

February weather in San Diego is normally very pleasant. Early morning 
temperatures average 51 degrees while afternoon temperatures average 67
degrees. Generally, a light jacket or sweater is adequate during February;
although, occasionally it rains.

TRANSPORTATION

San Diego International Airport is 10 miles (15 minutes) from the 
Catamaran  Hotel. Supershuttle operates a continuous service between the 
airport and the hotel: fare is $6.00. When you arrive at the airport, use the 
free Supershuttle phone. Taxi fare between the airport and the hotel is $20. 
The Catamaran charges $6 per day for parking.

REGISTRATION FEES

Postmarked        Subsequent
by Jan. 1         registration

$305              $350

No refunds after Jan. 20.

REGISTRATION INCLUDES

- Attendance    - Symposium Proceedings
- Reception     - Banquet
- Luncheons     - Coffee Breaks

On-site registration is available Wednesday evening at the reception, and 
Thursday morning at the Symposium. For more information on 
registration and local arrangements contact Dan Nessett at (510) 422-4033 
or nessett@llnl.gov.

SYMPOSIUM REGISTRATION FORM

Name ________________________________________________

Affiliation__________________________________________

Name on Badge _______________________________________

Vegetarian Meals?____________________________________

Mailing Address _____________________________________

_____________________________________________________

_____________________________________________________


(Area Code)Phone # ___________________________________

Email Address _______________________________________

Make check (credit cards not accepted) payable to SNDSS94. (Registration is 
not effective until payment is  received). Mail to: ISOC Symposium, C/O 
Belinda  Gish, L-68, Lawrence Livermore National Laboratory,  Livermore, 
CA. 94550.



-----------[000362][next][prev][last][first]----------------------------------------------------
Date:      Mon, 20 Dec 1993 20:07:01 GMT
From:      richard@cogsci.ed.ac.uk (Richard Tobin)
To:        comp.unix.bsd,comp.protocols.tcp-ip
Subject:   Re: virtual hosts based on ip address?

In article <2f4ucf$l1u@zip.eecs.umich.edu> zeeff@dip.eecs.umich.edu (John Zeeff) writes:
>So the remaining issue is how does one find the address that the originator
>of the connection used to come in on

getsockname()

-- Richard
-- 
Richard Tobin, HCRC, Edinburgh University                 R.Tobin@ed.ac.uk

"We demand guaranteed rigidly defined areas of doubt and uncertainty" - HHGTTG

-----------[000363][next][prev][last][first]----------------------------------------------------
Date:      Mon, 20 Dec 1993 21:59:06 GMT
From:      evansmp@mb48026.aston.ac.uk (Mark Evans)
To:        comp.security.misc,comp.protocols.tcp-ip
Subject:   Re: "large security gap in the Internet"

John Chambers (jc@minya.UUCP) wrote:

: For most of the last decade, it has been a mystery to  me  why  people
: are foolish enough to allow sendmail to run on their machine. It's not
: like there's a shortage of SMTP mailers out there;  your  neighborhood
: archive likely has at least half a dozen replacements. I once wrote an
: SMTP server in half a day, and none of my neighbors even noticed  that
: I wasn't running sendmail. It's easy to replace sendmail. Why don't we
: all do it, and be done with its problems?

The server is a fairly trivial piece of program all it has to do
is hang off the port (inetd can do the hard work for this)
and process the incoming mail.

It does get complex if you want your mail daemon to do forwarding, however.
(simplist way round this don't)

-----------[000364][next][prev][last][first]----------------------------------------------------
Date:      Tue, 21 Dec 1993 00:24:05 GMT
From:      ctkosti@afterlife.ncsc.mil (Chris Kostick)
To:        comp.protocols.tcp-ip
Subject:   Re: uping - simple echo/reply program

In article <2eaiti$1ib@smurf.noris.de>,
Matthias Urlichs <urlichs@smurf.sub.org> wrote:
>In comp.protocols.tcp-ip, article <1993Dec6.151306.25213@afterlife.ncsc.mil>,
>  ctkosti@afterlife.ncsc.mil (Chris Kostick) writes:
>> 
>> On almost every host that I have uping'd, the replying device only sends
>> back at most 1024 octets of the orignal message.
>
>ECHO is implemented by inetd. If inetd is using only a 1024-character buffer 
>for the message, you're going to see only 1024 bytes coming back.
>

Is that a function of the inetd buffer or the recvfrom() call?

>> sending 1464 octets to host shaiton
>> 1024 octets received, seq = 0   time = 15.73 ms
>> -1 octets received, seq = 0     time = 998.08 ms
>> 1024 octets received, seq = 1   time =  9.01 ms
>> 
>Huh? The -1 is an error. Look at errno to see what the error message is.

EMSGSIZE - Message too long.

I don't get it either. I have a feeling sendto() is generating it.

>
>-- 
>COUVIER'S OBSERVATION:
>There's nothing more frightening than ignorance in action.
>-- 
>Matthias Urlichs        \ XLink-POP Nürnberg   | EMail: urlichs@smurf.sub.org
>Schleiermacherstraße 12  \  Unix+Linux+Mac     | Phone: ...please use email.
>90491 Nürnberg (Germany)  \   Consulting+Networking+Programming+etc'ing      42

--
chris


-----------[000365][next][prev][last][first]----------------------------------------------------
Date:      21 Dec 1993 01:50:55 GMT
From:      jes@mti.sgi.com (John E. Schimmel)
To:        comp.sys.sun.admin,comp.sys.sun.wanted,comp.protocols.tcp-ip,comp.unix.admin,comp.sys.sun.misc
Subject:   Re: dynamic IP allocation with rarpd (or similar)

Colin Panisset (colinp@nms.otc.com.au) wrote:
: Greetings,
 
:   I'm after a version of rarpd to handle dynamic IP allocation for a network
:   of PCs. Local conditions preclude me running a RARP server on a PC or on
:   a Novell fileserver, but I have a need to be able to dynamically allocate
:   an IP number from a range of defined addresses. 
 
:   Such a server would run under SunOS 4.1.x, and need not be capable of
:   handling other (plain) RARP requests. It need not be clever.
 
:   Is there such a beast? If there is, I'd prefer one that didn't use 
:   the bpf device, since that involves kernel mods and I'm trying to 
:   standardise things as much as possible; if its the only option, though,
:   then I'll take it.
 
:   Replies by email preferred, but I'll read posts as well.
 
:   TIA,
:     -- Colin.
 
: --
:   Colin Panisset *:^) +61 2 339 3938 | Log! Log! it's big, it's heavy, it's
:         colinp@nms.otc.com.au        | wood! Log! Log! it's better than bad,
:   So There.      Fax: +61 2 339 3818 | it's good!           -- Ren & Stimpy
:   ------------------ PGP 2.3 key available on request. ----------------


There is a protocol specification called DHCP which is an extension to 
bootp.  I don't know if there is an implementation for SunOS yet, but
there probably is.  Try searching archie.

John
-----------------------------------------------
John E. Schimmel           jes@sgi.com         
Sr. Programmer/Analyst     Voice: (415)390-4116
Silicon Graphics Inc.      Fax:   (415)390-6174
-----------------------------------------------

-----------[000366][next][prev][last][first]----------------------------------------------------
Date:      21 Dec 93 02:37:07 GMT
From:      avalon@cairo.anu.edu.au (Darren Reed)
To:        comp.unix.internals,comp.protocols.tcp-ip
Subject:   passive sockets -> active


Can anyone suggest a way of solving this problem ?

	fd = socket(...);
	listen(fd, x);
	fd2 = dup(fd);
	connect(fd2, ...);

What is the problem ?  Well, the above will fail when it gets
to the connect() which will return -1, errno == EOPNOTSUPP.

I'd prefer not to have to do something like
	fd = socket();
	lfd = dup(fd);
	listen(lfd, x);
	fd2 = dup(fd);
	connect(fd2, ...);
and well, I'm not sure if that will work either (haven't tested it yet).

Oh, the purpose is to be able to listen on a socket but have all connections
made on a peer-peer basis use the same port # (obvious advantage when it
comes to firewalling).  This restricts the number of these pairs to one,
but that isn't a problem.

Comments ?

Thanks,
Darren

-----------[000367][next][prev][last][first]----------------------------------------------------
Date:      Tue, 21 Dec 93 03:18:25 GMT
From:      ftlofaro@unlv.edu (Frank Lofaro)
To:        comp.unix.bsd,comp.protocols.tcp-ip
Subject:   Re: virtual hosts based on ip address?

In article <2f4ucf$l1u@zip.eecs.umich.edu> zeeff@dip.eecs.umich.edu (John Zeeff) writes:
>So the remaining issue is how does one find the address that the originator
>of the connection used to come in on (ie, what interface is being used)
>when one is using the ifconfig alias command.
>
>So similar to getpeername(), but for the local side.
>
>I've haven't looked into it yet, but it seems that that information must be
>available somewhere.
>

I think getsockname() is what you are looking for.
Same format as getpeername, but returns info for the local side, not the remote.

I am not sure if it will necessarily give the right interface the other side 
used to connect (it should, IHMO, but, try it first :)


-----------[000368][next][prev][last][first]----------------------------------------------------
Date:      21 Dec 1993 04:24:28 GMT
From:      torban@csuvax1.csu.murdoch.edu.au (Torban Bennett)
To:        comp.protocols.tcp-ip
Subject:   Network print problem


Hello World,

	I must publically admit defeat!  I have two print servers (running
under FTP's TCP/IP package) set up identically (To the best of my knowledge)
one with a SHARP JK-9600 and the other a HP LaserJet 4 hanging off them.
The SHARP works perfectly, but the HP prints a banner before each job.  I
have tried everything I can think of to turn the banner off, but have
failed.  The print servers are old XT's that just run the TCP/IP package,
both share their lpt1: port's as either \NET_PS1 or \NET_HP1 (The SHARP isn't
working in postscript mode, unless the Mac's use it) and both actual print
from any PC on the network.  It is just a waste of paper printing the
banners so I've been told (neumerous times in fact;-) to get rid of it.  If
anyone knows how to turn the pesky banners off I would love to hear from
you, and if you come to Geraldton will buy you a beer or two.

	Please send any help to torban@csuvax1.murdoch.edu.au and I'll read
it over the XMAS break.

Living in Hope,
--
Corey Banks, Computer Systems Officer
Department of Agriculture, Geraldton Regional Office
email: Torban@csuvax1.murdoch.edu.au

-----------[000369][next][prev][last][first]----------------------------------------------------
Date:      Tue, 21 Dec 1993 08:59:05 GMT
From:      hmchen@fcom.ee.ntu.edu.tw (Hung-ming Chen)
To:        comp.protocols.tcp-ip
Subject:   [Q] how to break "connect" function in Socket

dear netters,

  When I wrote some programs to communicate between two
machines, I got a problem that the servcer site was not power, 
the client site would connect the server until SOCKET time
out. It was a long time. In UNIX I can solve it by using
alarm, but the same method was not effective in UCX of DEC
VAX/VMS. Could anybody suggest me a good method to solve it,
event changing some system configuration is O.K.? In the
programs I used a self-defined port number.

Fred Chen

-----------[000370][next][prev][last][first]----------------------------------------------------
Date:      Tue, 21 Dec 1993 12:56:09 GMT
From:      scvicato@uts.uni-c.dk (Claus Cato)
To:        comp.protocols.tcp-ip,bit.listserv.tcpip-l
Subject:   Where do I find platform independent TCP/IP C source code?

Hello World,

I'm looking for TCP/IP sources that may be compiled on a number of
platforms, like: PC, Mac(Intosh) and Unix (SunSparc). I've been
told that there is some PD code somewhere out there but not where
it is!

Do You know? Please let me know!

Thank You

Andrew

Andrew, using the company account. I may also be reached at:
andrew@uts.uni-c.dk (my own private account); Scanview A/S,
Meterbuen 6, 2740 Skovlunde, Denmark; Phone: +45 4453 6100.

-----------[000371][next][prev][last][first]----------------------------------------------------
Date:      21 Dec 1993 13:15:10 -0000
From:      barryf@iol.ie (Barry Flanagan)
To:        biz.sco.general,comp.protocols.tcp-ip
Subject:   telnetd hanging on 3.2.4.0 - HELP!



Hi,

We're running SCO 3.2.4.0 and TCPIP 1.20h, and are having problems with
telnetd hanging leaving a rouge telnetd process and all further telnet
connections fail until this rouge telnetd is killed, after which things
start working again.

The problem appears quite random. netstat -m reveals nothing, nor does
syslog. I'm at a loss and really don't know where to begin!

The only other strange happening is that INN1.4 hangs once and a while,
although apart from today I wasn't aware of these two events occurring
together.

As this is a very serious problem for a system which must be available
to telnet 24 hours, any suggestions as to where to start would be most
gratefully received.

Thanks in advance.
-- 
Barry Flanagan - <barryf@iol.ie>
 ----
| Ireland On-Line, West Wing, Udaras Complex, Furbo, Galway,Ireland
| Tel/Fax : +353 91 92727 / 26 * BBS : +353 91 92722 (4 Lines)

-----------[000372][next][prev][last][first]----------------------------------------------------
Date:      Tue, 21 Dec 93 13:53:26 GMT
From:      tadams@ll.mit.edu ( Tony Adams)
To:        comp.protocols.tcp-ip
Subject:   Ethernet performance analysis information


System: Network of Unix machines (Sun's, Convex and PC's)

What are considered to be good books/papers regarding ethernet
performance analysis issues?

We wish to characterize our ethernet performance in detail. We have
several text books which contain scattered bits of information and
are hoping to find one or a few more complete/specific sources of
information.

Thanks for any pointers.


-----------[000373][next][prev][last][first]----------------------------------------------------
Date:      Tue, 21 Dec 1993 22:13:29 -0500
From:      76440.1221@compuserve.com (Bob Bowman)
To:        comp.protocols.misc,comp.protocols.tcp-ip
Subject:   What transport protocols exist?

I need to know what commercially available industry standard
transport protocols are available, beside TCP.  The need is for
a package that can be ported to various systems, not necessarily
Unix based, preferably with source code, complete specifications,
and testing suite.  Probably this is asking too much.  What is
available?

Please reply by e-mail.  Thanks.

--
Bob Bowman
76440.1221@compuserve.com

-----------[000374][next][prev][last][first]----------------------------------------------------
Date:      Tue, 21 Dec 1993 16:41:10 GMT
From:      bowling@cebaf4.cebaf.gov (Bruce Bowling)
To:        comp.protocols.tcp-ip
Subject:   REQ: Socket source code for PC


I am trying to locate source code for ALL of 
the layers to implement Berkeley sockets on
a IBM PC.  I am eventually going to EPROM
this on a motherboard.

I will forever be in one's debt for info
on this (either commercial or free).

If you can, please E-mail me at bowling@cebaf.gov

thank you in advance.

-----------[000375][next][prev][last][first]----------------------------------------------------
Date:      Tue, 21 Dec 1993 17:33:20 GMT
From:      mwr@eng.tridom.com (Mark Reardon)
To:        comp.os.vms,comp.protocols.tcp-ip,comp.sys.dec,comp.sys.m68k
Subject:   Re: KA9Q ported to 68000?

In article <1993Dec17.121541.18689@Eskimo.CPH.CMC.COM>, lars@Eskimo.CPH.CMC.COM (Lars Poulsen) writes:
|> In article <1993Dec13.155812.138@opo.van.wa.us>,  <evm@opo.van.wa.us> wrote:
|> >>I've got a few Dec DS200/mc terminal servers floating around ...
|> >>	They have 1 AUI connection for ethernet and 8 serial lines 
|> >>with a max speed of 38Kbps. Internally is a 10 MHz 68000, 768 Kb Ram 
|> >>and 128 Kb Eprom.
|> 
|> In article <2erpo1$n3g@mips.arb-phys.uni-dortmund.de>
|>    wb@arb-phys.uni-dortmund.de (Wilhelm B. Kloke) writes:
|> >If you manage to program it for support of V32bis/V42bis modem slip or
|> >ppp support (at 38kBd), I would like to hear from you. The 68k should be
|> >sufficient to support more than 1 line at full speed. I think it should
|> >even do all lines, if programmed well.
|> >
|> >The DS200 (as used by DEC) does only support 9600 Bd. Where did you get
|> >the info about the max speed?
|> 
|> Based on my work with similar hardware, I assert that a 10MHz 68000
|> with ordinary double- or triple-buffered UARTs will just barely drive
|> 8 full-duplex 9600 bps ports at full speed. Most of the common UART
|> components of the vintage in question will support speeds up to 38400
|> bps. You could probably get away with driving two V.32bis/V.42bis
|> modems at the same time with only occasional overruns.
|> 
|> Considering the effort required to program this (and reverse-engineer
|> the programming spec for the board) I don't think it is worth it.
|> 

The last time I saw the inside of the DS200, it had 68681 duarts.
These are able to run at 38400 bps. I worked on a terminal server
several years ago that used the same setup, 10Mhz 68k, 8 68681s,
512K of RAM and a LANCE or Serial trunk using a Z80 and a DUSCC for
the trunk.  The other engineer wrote the port driver
but I assisted in the tesing and we were able to achieve all 16
ports at 9600 bps or 14 at 19200 bps.  After a little tweaking he
was able to all 16 at 19200.  Since we couldn't test it any higher
we backed off and quoted to marketing 16 at 9600 or 8 at 19200.

As for would I do it again, sure.  Just give me time and money and
I will do almost anything :-).

Mark

-- 
_____________________________________________
Mark Reardon   AT&T Tridom   (404-514-3383)
email: mwr@tridom.eng.tridom.com, attmail!tridom!mwr

-----------[000376][next][prev][last][first]----------------------------------------------------
Date:      Tue, 21 Dec 1993 19:29:57 GMT
From:      lawson@netcom.com (Steven Lawson)
To:        comp.os.vms,comp.protocols.tcp-ip,comp.sys.dec,comp.sys.m68k
Subject:   Re: KA9Q ported to 68000?

Mark Reardon (mwr@eng.tridom.com) wrote:
: The last time I saw the inside of the DS200, it had 68681 duarts.
: These are able to run at 38400 bps. I worked on a terminal server
: several years ago that used the same setup, 10Mhz 68k, 8 68681s,
: 512K of RAM and a LANCE or Serial trunk using a Z80 and a DUSCC for
: the trunk.  The other engineer wrote the port driver
: but I assisted in the tesing and we were able to achieve all 16
: ports at 9600 bps or 14 at 19200 bps.  After a little tweaking he
: was able to all 16 at 19200.  Since we couldn't test it any higher
: we backed off and quoted to marketing 16 at 9600 or 8 at 19200.
 
: As for would I do it again, sure.  Just give me time and money and
: I will do almost anything :-).

If they are 68681 DUARTS they can be set up to perform receiver
handshaking, thus if you can't process the interrupts fast enough
the chip will toggle (RTS?) for you.


-----------[000377][next][prev][last][first]----------------------------------------------------
Date:      Tue, 21 Dec 1993 21:41:12 GMT
From:      evansmp@mb48026.aston.ac.uk (Mark Evans)
To:        comp.protocols.tcp-ip
Subject:   Re: IP Header IDENTIFICATION field

Ross Lillie (lillie@comm.mot.com) wrote:
: Is the IDENTIFICATION field of the IP header utilized *only* for packet
: reassembly in the event of fragmentation?  Do any higher layer protocols
: rely upon the IDENTIFICATION field for any type of event notification?

It is possible for TCP to take note of this when doing a retransmission.
So that fragments from either send can be used.
This is an implimentation specific use.
Many TCP's will NOT do this.

: For example, ICMP inserts its own IDs into control message bodies when it
: is required to uniquely identify some network event.  However I need to know
: if applications/protocols exist (and are widely used) that use this field in
: any (ugly) manner for their own purposes.

You will likely find that this field is ignored by the recieving process.

-----------[000378][next][prev][last][first]----------------------------------------------------
Date:      21 Dec 1993 21:44:43 GMT
From:      valdis@black-ice.cc.vt.edu (Valdis Kletnieks)
To:        comp.protocols.tcp-ip
Subject:   Re: PCs and pings (a dreadfull combination)

In article <1993Dec17.131338.13055@unipalm.co.uk> steven@unipalm.co.uk (Steven Vincent) writes:
>That is not disputed. I have joined this thread late but I have seen several
>cases of old or limited hardware which while not crashed are effectivly hung
>since servicing the flood of pings consumes such a high proportion of the
>processor power that all usefull work stops.  Once the pings are turned off

Well.. please note that Netview/6000 generates on the order of
1 ping every 5 *MINUTES* or so.  I hope even a brain-dead PC can
keep up with THAT. ;)

ObFolklore:  I know this for a fact because I once accidentally
left a test copy of netview/6000 running in 'host discovery' mode
all weekend - and it discovered most of Suranet (I estimate some
87,000 machines) - and it kept status info on all of them.

And nobody noticed the bandwidth.  Seeing as how our Suranet
connection was 56KB at the time, I don't think thre were any major
ping floods. ;)

				Valdis Kletnieks
				Computer Systems Engineer
				Virginia Tech

-----------[000379][next][prev][last][first]----------------------------------------------------
Date:      Tue, 21 Dec 1993 22:11:11 GMT
From:      klein@mars.rowan.edu (BRUCE KLEIN)
To:        comp.protocols.tcp-ip
Subject:   Re: Richard Stevens book in Wayne's World 2

In article <1993Dec16.004657.17322@oucsace.cs.ohiou.edu> sadkins@bigbird.cs.ohiou.edu (Scott W. Adkins) writes:
>From: sadkins@bigbird.cs.ohiou.edu (Scott W. Adkins)
>Subject: Re: Richard Stevens book in Wayne's World 2
>Date: Thu, 16 Dec 1993 00:46:57 GMT


>Did you notice his shirt when he said that?  I do believe it had a picture
>of the Amiga Video Toaster... :-)  (if you have heard of it...) :-)  That
>was definitely a great scene!

I don't if this is the truth or not, but I once read that Dana Carvey has a 
brother who developed the video toaster. Garth is supposedly based on him.

Bruce Klein
Rowan College


-----------[000380][next][prev][last][first]----------------------------------------------------
Date:      Tue, 21 Dec 1993 22:20:53 GMT
From:      dowd@acsu.buffalo.edu (Patrick Dowd)
To:        comp.protocols.tcp-ip
Subject:   Call for Papers - SIGCOMM'94




			   Call for Papers
		      ACM SIGCOMM'94 CONFERENCE
       Communications Architectures, Protocols and Applications
				   
		      University College London
			      London, UK
				   
		    August 31 to September 2, 1994
		 (Tutorials and Workshop, August 30)

An  international forum  on  communication  network  applications  and
technologies, architectures, protocols, and algorithms.

Authors are invited to submit  full  papers concerned with both theory
and practice. The areas of interest include, but are not limited to:
   --  Analysis and  design  of  computer  network  architectures  and
       algorithms, 
   --  Innovative results in local area networks,
   --  Mixed-media networks,
   --  High-speed networks, routing and addressing, support for mobile
       hosts, 
   --  Resource sharing in distributed systems,
   --  Network management,
   --  Distributed operating systems and databases,
   --  Protocol specification, verification, and analysis.

A   single-track,   highly  selective  conference   where   successful
submissions   typically  report   results  firmly   substantiated   by
experiment,  implementation,  simulation,  or  mathematical  analysis.
Papers must be less than 20 double-spaced pages long, have an abstract
of  100-150  words,  and  be  original  material  that  has  not  been
previously  published  or  be  currently  under  review  with  another
conference or journal.

In addition to its high  quality technical  program, SIGCOMM '94  will
offer  tutorials by  noted  instructors  such  as  Paul  Green and Van
Jacobson (tentative), and a workshop  on  distributed systems  led  by
Derek McAuley.

Important Dates:

          Paper submissions: 1 February 1994
         Tutorial proposals: 1 March 1994
 Notification of acceptance: 2 May 1994
    Camera ready papers due: 9 June 1994

All  submitted papers will  be  judged  based  on  their  quality  and
relevance through double-blind reviewing where  the  identities of the
authors are  withheld from  the  reviewers.  Authors names should  not
appear on the paper.  A cover letter  is  required that identifies the
paper title and lists the name, affiliation, telephone  number, email,
and fax number of all authors.

Authors of accepted papers need to sign an ACM copyright release form.
The  Proceedings will  be published as a  special issue of ACM SIGCOMM
Computer Communication  Review. The program committee will also select
a few papers for possible publication in the IEEE/ACM  Transactions on
Networking.

Submissions from North America should be sent  to:
     Craig Partridge
     BBN
     10 Moulton St
     Cambridge MA 02138

All  other submissions  should  be sent to:
     Stephen Pink
     Swedish Institute of Computer Science
     Box 1263
     S-164 28 Kista
     Sweden

Five copies are required for paper submissions. Electronic submissions
(uuencoded,  compressed  postscript) should be sent  to  each  program
chair. Authors should also e-mail the title, author names and abstract
of their  paper  to  each  program  chair  and  identify  any  special
equipment that will be required  during its  presentation. Due to  the
high number  of  anticipated  submissions,  authors are  encouraged to
strictly  adhere  to the  submission  date.  Contact  Patrick  Dowd at
dowd@eng.buffalo.edu or +1 716 645-2406 for more information about the
conference.

Student  Paper Award:  Papers  submitted  by  students  will  enter  a
student-paper award contest.  Among the  accepted papers, a maximum of
four outstanding  papers  will be awarded full conference registration
and  a travel grant of $500  US dollars.   To  be eligible the student
must be the  sole author, or the first author and primary contributor.
A  cover  letter  must  identify  the  paper as  a candidate  for this
competition.


Mail and E-mail Addresses:

General Chair
-------------
    Jon Crowcroft
    Department of Computer Science
    University College London
    London WC1E 6BT United Kingdom

    Phone: +44 71 380 7296
    Fax: +44 71 387 1397
    E-Mail: J.Crowcroft@cs.ucl.ac.uk


Program Chairs
--------------
    Stephen Pink (Program Chair)
    Swedish Institute of Computer Science
    Box 1263
    S-164 28 Kista
    Sweden

    Phone: +46 8 752 1559
    Fax: +46 8 751 7230
    E-mail: steve@sics.se

    Craig Partridge (Program Co-Chair for North America)
    BBN
    10 Moulton St
    Cambridge MA 02138

    Phone: +1 415 326 4541
    E-mail: craig@bbn.com


-----------[000381][next][prev][last][first]----------------------------------------------------
Date:      Wed, 22 Dec 1993 06:19:06 GMT
From:      ismo@cs.tut.fi (Salonen Ismo)
To:        comp.protocols.tcp-ip
Subject:   public domain ethernet sniffer


	We have some problems with our internet gateway,
there is a cisco router that send garbage for icmp echo request
it also looks like it may collide packets ( hardware problems ?)
It would be nice if we had some kind of a dumper of sniffer 
to see what goes in that wire. Is there any public domain or shareware
utility ? ( we have 3C503,3c505 and xircom adapters if that matters)
Please help us
tnx in advance
-- 
Ismo Salonen  ismo@cs.tut.fi
or amateur network : OH3LKU@OH3RBR.FIN.EU
or OH3LKU@OH3LKU.AMPR.ORG
Tel : Home 931-184734, car 949-313752, work 931-165287

-----------[000382][next][prev][last][first]----------------------------------------------------
Date:      22 Dec 1993 08:27:15 GMT
From:      hunen@brc.medtronic.com (Roger Hunen)
To:        comp.protocols.tcp-ip
Subject:   Re: Internal BIND Root Servers. How many?

In article <1993Dec20.093422.538@rcwusr> pearcedh@rcwusr.bp.com writes:
>I presume this means that I should have more than the 1 BIND Root Server in our
>network. But what is the minimum that I should have?  I have been told it is 3
>but I have not seen this written down anywhere.

I'd say 2 is usually enough to provide the desired redundancy. You also want
to make sure that a common cause failure in accessing the root servers is
unlikely, ie. don't put them on the same network segment or even in the same
building if possible. Of course your possibilities to do so depend on your 
situation. Careful planning is the key to successful DNS operation.

Regards,
-Roger

-----------[000383][next][prev][last][first]----------------------------------------------------
Date:      Wed, 22 Dec 1993 08:34:06 GMT
From:      heilbron@Informatik.TU-Muenchen.DE (Stephen Heilbronner)
To:        comp.protocols.tcp-ip
Subject:   Connecting 2 Win-PC's directly using SLIP ?

Has anybody succeeded in connecting two PC's directly via
the serial port and SLIP. Or maybe over the parallel port?
(I'd prefer that since I already have a cable for InterSrv.)
What software could do it? (maybe Trumpet WinSock)

Please also let me know IF it NOT possible by design of SLIP.
Thx a lot,

Stephen

-----------[000384][next][prev][last][first]----------------------------------------------------
Date:      Wed, 22 Dec 1993 15:13:34 GMT
From:      brownje@ncifcrf.gov (Janet E. Brown)
To:        comp.protocols.tcp-ip
Subject:   Re: Network TCP/IP

If the pcs are in the same room, I just saw a really nifty package at 
Comp USA - I can't remember the name, but it allowed you to connect 
several devices (Pcs and printers) without a card. The connections were 
via the parallel port. The cost was about $150 a 'package' and you needed 
a package per device. You could also just run a cable between the two - 
with software (TCP/IP) and network card, the cost would run about the same. 
17 years old? hmmmmmm....... there are a LOT of people like me who 
would pay dearly for a babysitter. You couldn't drive to DC for a 
weekend, could you? 
Hope this helps ....



-----------[000385][next][prev][last][first]----------------------------------------------------
Date:      Wed, 22 Dec 1993 17:25:43 GMT
From:      leo@elmail.co.uk (E.J.Leoni-Smith)
To:        comp.protocols.tcp-ip
Subject:   LPR client for SCO Unix?

There is a PD source for this somewhere? Does anyone know where? 

Basically I want to send a print job to a Unix running Berekely LPD
(or possibly Netware and FLEX/IP) from a SCO UNIX machine.

I believe that Cayman used to give this away with their GatorBox.

Any clues?

Thank you

Leo


-----------[000386][next][prev][last][first]----------------------------------------------------
Date:      Wed, 22 Dec 1993 17:32:22 GMT
From:      leo@elmail.co.uk (E.J.Leoni-Smith)
To:        biz.sco.general,comp.protocols.tcp-ip
Subject:   Re: telnetd hanging on 3.2.4.0 - HELP!

In article <2f6ssu$m3b@ulysses.iol.ie> barryf@iol.ie (Barry Flanagan) writes:
>
>
>Hi,
>
>We're running SCO 3.2.4.0 and TCPIP 1.20h, and are having problems with
>telnetd hanging leaving a rouge telnetd process and all further telnet
>connections fail until this rouge telnetd is killed, after which things
>start working again.

Ah Barry: Those are like the rouge elephants that you see after the 98th pint
of genius ;-);-);-)

Over here we call them 'pink'


-----------[000387][next][prev][last][first]----------------------------------------------------
Date:      22 Dec 1993 19:14:25 GMT
From:      yan@orion.oac.uci.edu (Yan Or)
To:        comp.protocols.tcp-ip
Subject:   Telnet options

i'm writing an pc application that proves a command
line interface (similar to a command shell).  if i
were to provide a remote interface via an implementation
of telnet server, what options should i consider
implementing?

thanks,
yan
yan@orion.oac.uci.edu

-----------[000388][next][prev][last][first]----------------------------------------------------
Date:      22 Dec 1993 21:47:02 GMT
From:      koert@access.digex.net (Koert Zeilstra)
To:        comp.protocols.tcp-ip
Subject:   Re: SLIP/PPP software needed for host.

FTP to merit.edu; under /ppp there is the stuff you want.

Koert

--
-------------------------------------------------------------------
 Koert Zeilstra                  | Internet: koert@digex.net
 Comsearch                       | Voice: 703-476-2743
 11720 Sunrise Valley Drive      | Fax: 703-476-2772
 Reston, VA 22091                |
-------------------------------------------------------------------

-----------[000389][next][prev][last][first]----------------------------------------------------
Date:      Wed, 22 Dec 1993 22:10:06 GMT
From:      cooker@ci.ua.pt (Fernando Cozinheiro)
To:        comp.protocols.tcp-ip
Subject:   Intercom card (ETHER-16)


Hello!

Have anyone any  experience to install the Ethernet  card ETHER-16  from
INTERCOM?  I want to install  IPXODI, in order to use  TCP/IP and Novell
simultaneously, using PC/TCP from FTP software-house.


I've tried already several configurations, but I don't succeeded never.
The documentation to install the card is very poor...

What can I do without any other information?
Maybe, waiting for your help...

Thanks in advance.

--
Fernando Cozinheiro
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Universidade de Aveiro        Phone: +351 34 25085 * Ext. 2254 (before 6 p.m.)
Centro de Informatica                +351 34 381265 (after 6 p.m.)
3800 Aveiro                   Fax:   +351 34 28600
Portugal                      Email: cooker@ci.ua.pt

-----------[000390][next][prev][last][first]----------------------------------------------------
Date:      23 Dec 1993 10:47:04 -0600
From:      ucacjon@ucl.ac.uk (Jon Crowcroft)
To:        comp.protocols.tcp-ip
Subject:   Re: Richard Stevens book in Wayne's World 2

i'm curious that we havnt seen the Internet featured big yet in any major film.

how come the kids in jurassic park didn't just say 'oh unix, with the sendmail bug - i can
 hack that from  mums internet account from home'?

happy winter solstice and may all your IP headers be white...

-- 
jon crowcroft (hmmm...)

-----------[000391][next][prev][last][first]----------------------------------------------------
Date:      23 Dec 1993 01:43:42 GMT
From:      Kiran.Gop@launchpad.unc.edu (kiran gop)
To:        comp.protocols.tcp-ip
Subject:   tricky address: 127.0.0.1


the address 127.0.0.1 refers to ur local host!!!!!
finger this address, and u get the list of usrs at ur machine.//.
whats the catch behind this??? why does this address always refer to
*your* machine??

Cound anyone mail me the reason?
Have a decent year ahead.
Adios, Kiran.
/

--
   The opinions expressed are not necessarily those of the University of
     North Carolina at Chapel Hill, the Campus Office for Information
        Technology, or the Experimental Bulletin Board Service.
           internet:  laUNChpad.unc.edu or 152.2.22.80

-----------[000392][next][prev][last][first]----------------------------------------------------
Date:      23 Dec 1993 01:46:22 GMT
From:      Kiran.Gop@launchpad.unc.edu (kiran gop)
To:        comp.protocols.tcp-ip
Subject:   Remote execution server


One of the original aims of internet was to provide remote program execution..
and printing. Is any such software for any machine, available?
How's security implemented in such a server?
IKIRAN,
KIRAN@CS.OLEMISS.EDU
O

--
   The opinions expressed are not necessarily those of the University of
     North Carolina at Chapel Hill, the Campus Office for Information
        Technology, or the Experimental Bulletin Board Service.
           internet:  laUNChpad.unc.edu or 152.2.22.80

-----------[000393][next][prev][last][first]----------------------------------------------------
Date:      23 Dec 1993 07:48:04 GMT
From:      jel@xerver.icl.fi (Jerry Lahti)
To:        comp.protocols.tcp-ip
Subject:   Re: LPR client for SCO Unix?

leo@elmail.co.uk (E.J.Leoni-Smith) writes:

>There is a PD source for this somewhere? Does anyone know where? 
 
>Basically I want to send a print job to a Unix running Berekely LPD
>(or possibly Netware and FLEX/IP) from a SCO UNIX machine.

LPR support is standard part of the SCO TCP/IP starting with version 1.2.0.
It does not have all the features which you have on Bsd UNIX, but it works.
We have used it with both SunOS and FLeX/IP servers.

/Jerry Lahti
-- 
Jerry Lahti             !  tel. +358-0-567 3639
ICL Personal Systems Oy !  fax. +358-0-567 5670
P.O.Box 780             !  Email: jel@xerver.icl.fi (Internet) 
00101 Helsinki, Finland !  X400:  C=FI A=MAILNET P=ICL O=ICL S=LAHTI G=JERRY

-----------[000394][next][prev][last][first]----------------------------------------------------
Date:      23 Dec 1993 13:24 EDT
From:      prasad@nssdca.gsfc.nasa.gov (Prasad Erabelli)
To:        comp.protocols.tcp-ip
Subject:   What are Threads

Hi all,

I am wondering any knowledgeable netter on Threads could write as to 
what they do, how they relate to multitasking, how different are they 
from processes (from fork, for example), are they supported by 
different versions of unix.

Thanks in advance,

- Prasad
erabelli@killians.gsfc.nasa.gov

-----------[000395][next][prev][last][first]----------------------------------------------------
Date:      23 Dec 1993 12:13:24 GMT
From:      wjh@godel.denver.ssds.com (W. Joe Hewitt (Raleigh))
To:        comp.protocols.tcp-ip
Subject:   Net Analyzer Software for Mac?


	I am looking for network packet analyzer program for
	a Macintosh.  Specifically, it needs to be able to 
	capture and decode IP traffic.

	I know there are a number of software packages for UNIX
	and DOS, but I am looking for one for my PowerBook.
	Is there anything like this available?

	--Joe


   )       (         / \               )   )             _/__/_
   \   ^   /       _/__/___    _      /__ / _  _    _ o  /  /
    \_/ \_/   o   (_/   (__)__(/__   /   / (/__(_/\_)_(_(__(__  
W. Joe Hewitt, Senior Network Engineer, SSDS, Inc., wjh@ssds.com

-----------[000396][next][prev][last][first]----------------------------------------------------
Date:      Thu, 23 Dec 1993 12:38:08 GMT
From:      mark@cyantic.com (Mark T. Dornfeld)
To:        comp.protocols.tcp-ip
Subject:   Re: LPR client for SCO Unix?

In article <CIG5qw.4rB@elmail.co.uk> leo@elmail.co.uk (E.J.Leoni-Smith) writes:
>There is a PD source for this somewhere? Does anyone know where? 
>
>Basically I want to send a print job to a Unix running Berekely LPD
>(or possibly Netware and FLEX/IP) from a SCO UNIX machine.
>
>I believe that Cayman used to give this away with their GatorBox.
>
>Any clues?

I don't think you need anything beyond what SCO ships.  Have a look at the
SCO docs for setting up a remote printer on the network.  Since 3.2v2, the
information has been either in the docs or on SCO's dialup BBS.  You just
have to set up host equivalency and get the right rcmd/rsh/remsh command to
run to do this.

I regularly print from our SCO box to my NeXT workstation using this
method.
-- 

Mark T. Dornfeld, CYANTIC Systems             Voice: (416) 234-9048
101 Subway Crescent Suite 2103                Facsimile: (416) 234-0477
Etobicoke, Ontario, M9B 6K4 CANADA            Email: mark@cyantic.com

-----------[000397][next][prev][last][first]----------------------------------------------------
Date:      23 Dec 93 15:27:31 GMT
From:      suma@fedfil.UUCP (Suma Vasudevan)
To:        comp.protocols.tcp-ip
Subject:   SLIP/PPP software needed


Hello,


Some one please send me the ftp site where I can get 
public domain SLIP and PPP (to run on Sun Solaris 2.2).


Please email to suma@fedfil.com


Thanks in advance

Suma.




-----------[000398][next][prev][last][first]----------------------------------------------------
Date:      23 Dec 1993 15:56:16 GMT
From:      koert@access3.digex.net (Koert Zeilstra)
To:        comp.protocols.tcp-ip
Subject:   Re: SLIP/PPP software needed

Try dp-3.0 in /ppp/dp at merit.edu

BTW: I couldn't mail to your address, not in domain or something.

Koert
--
-------------------------------------------------------------------
 Koert Zeilstra                  | Internet: koert@digex.net
 Comsearch                       | Voice: 703-476-2743
 11720 Sunrise Valley Drive      | Fax: 703-476-2772
 Reston, VA 22091                |
-------------------------------------------------------------------

-----------[000399][next][prev][last][first]----------------------------------------------------
Date:      23 Dec 1993 16:47:15 -0000
From:      barryf@iol.ie (Barry Flanagan)
To:        biz.sco.general,comp.protocols.tcp-ip
Subject:   Re: telnetd hanging on 3.2.4.0 - HELP!

E.J.Leoni-Smith (leo@elmail.co.uk) wrote:
: In article <2f6ssu$m3b@ulysses.iol.ie> barryf@iol.ie (Barry Flanagan) writes:
: >
: >
: >Hi,
: >
: >We're running SCO 3.2.4.0 and TCPIP 1.20h, and are having problems with
: >telnetd hanging leaving a rouge telnetd process and all further telnet
: >connections fail until this rouge telnetd is killed, after which things
: >start working again.
 
: Ah Barry: Those are like the rouge elephants that you see after the 98th pint
: of genius ;-);-);-)
 
: Over here we call them 'pink'

Ahhh...._that_ explains it!

Happy Christmas all!
-- 
Barry Flanagan - <barryf@iol.ie>
 ----
| Ireland On-Line, West Wing, Udaras Complex, Furbo, Galway,Ireland
| Tel/Fax : +353 91 92727 / 26 * BBS : +353 91 92722 (4 Lines)

-----------[000400][next][prev][last][first]----------------------------------------------------
Date:      Thu, 23 Dec 1993 17:00:20 GMT
From:      hoang1@litwin.com (Ted Hoang)
To:        comp.protocols.tcp-ip
Subject:   raw interface to Ethernet (SCO Unix)

Hi,

I would like to know that SCO has any facility which composed of several
STREAMS modules and drives and is similar like "nit" of SUN OS or 
"packetfilter" of DEC Ultrix. Also I am very appreciate if you let me know the
name of this raw Ethernet interface device and any books or manuals explain how
to program it.

Thanks in advance
Ted Hoang
Email: hoang1@litwin.com


-----------[000401][next][prev][last][first]----------------------------------------------------
Date:      Thu, 23 Dec 1993 17:46:37 GMT
From:      yadav@cse.iitb.ernet.in (Yadav Navneet )
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject:   Wireless PC to PC communication

hi,
	can i have any info on wireless communication between pcs using
tcpip protocol. is there already any implentation of the same and if so
where can i get details on it. i need to know both hardware and software
details. if not tcpip then is there any implementation using some other
protocols ?  

thanks and cheers,

							yadav

						email:yadavn@cc.iitb.ernet.in



-----------[000402][next][prev][last][first]----------------------------------------------------
Date:      Thu, 23 Dec 1993 17:52:06 GMT
From:      leo@elmail.co.uk (E.J.Leoni-Smith)
To:        comp.protocols.tcp-ip
Subject:   Re: LPR client for SCO Unix?

In article <1993Dec23.123808.697@cyantic.com> mark@cyantic.com (Mark T. Dornfeld) writes:
>In article <CIG5qw.4rB@elmail.co.uk> leo@elmail.co.uk (E.J.Leoni-Smith) writes:
>>There is a PD source for this somewhere? Does anyone know where? 
>>
>>Basically I want to send a print job to a Unix running Berekely LPD
>>(or possibly Netware and FLEX/IP) from a SCO UNIX machine.
>>
>>I believe that Cayman used to give this away with their GatorBox.
>>
>>Any clues?
>
>I don't think you need anything beyond what SCO ships.  Have a look at the
>SCO docs for setting up a remote printer on the network.  Since 3.2v2, the
>information has been either in the docs or on SCO's dialup BBS.  You just
>have to set up host equivalency and get the right rcmd/rsh/remsh command to
>run to do this.
Er. Flex/IP doesn't understand rsh/rcmd. It speaks LPD speak. That's the
problem. Let me rephrase the question.

I want code to make SCO talk LPR/LPD protocols. not workarounds
to avoid having to use them (I got that far on my own ;-))


Leo


-----------[000403][next][prev][last][first]----------------------------------------------------
Date:      23 Dec 93 18:08:14 GMT
From:      donb@crash.cts.com (Donald Bowen)
To:        comp.protocols.tcp-ip
Subject:   DICOM

	We are about to imppplement the DICOM 3.0 file transfer protocol
in our system.  Has anyone out there had any experience with this?

	DonB

-----------[000404][next][prev][last][first]----------------------------------------------------
Date:      24 Dec 1993 05:55:50 -0600
From:      roberts@decus.arc.ab.ca (Rob Slade, Ed. DECrypt & ComNet, VARUG rep, 604-984-4067)
To:        comp.protocols.tcp-ip
Subject:   "Communications for Cooperating Systems" by Cypser

BKCMCOOP.RVW  931014
 
Addison-Wesley Publishing Co.
Kelly Ford, Promotion/Publicity Coordinator
P.O. Box 520
26 Prince Andrew Place
Don Mills, Ontario
M3C 2T8
416-447-5101
fax: 416-443-0948
or
Tiffany Moore, Publicity  72203.642@compuserve.com
1 Jacob Way
Reading, MA   01867-9984
800-527-5210
617-944-3700
5851 Guion Road
Indianapolis, IN   46254
800-447-2226
"Communications for Cooperating Systems", Cypser, 1991
 
The subtitle of this book is "OSI, SNA and TCP/IP," thus giving a nice, neutral
alphabetic ordering to the systems.  In reality this is "SNA with OSI and
TCP/IP."  The organization, examples and slant to the material is all
unmistakably IBM: not altogether surprising, given that they sponsored the
Systems Programming Series from which it comes.
 
Regardless of the generalities given in the preface, the intent seems to be to
prove that SNA can "fit in" with OSI and TCP/IP.  That it does need not be
surprising:  both systems are quite flexible.  However, please do note the
emphasis here.  You *can* learn about OSI and TCP/IP from this book, but it
will be, as it were, through IBM-coloured glasses.  The structure of the book
itself follows the SNA/SAA (systems network/application architecture) model,
with a four-layer model which only fits the OSI (open systems interconnection)
seven-layer or TCP/IP (transmission control protocol/internet protocol) five-
layer model after some degree of work.
 
Part one comprises an overview and introduction, with three chapters listing
the usual platitudes regarding the needs and desires for open systems.  Part
two describes "Application - Services," which is "above the top" of both the
OSI and TCP/IP models, and has no parallel structures other than application
programs.  Part three discusses the "End-to-End Data-Exchange Facilities" which
relates to the applications layer on both OSI and TCP/IP diagrams.  Part four
talks of "Transport Inter-Subnetwork Facilities" relevant to the presentation
and session layers of OSI (and subsumed within the application layer in
TCP/IP).  Part five deals with "Link/Subnetwork-Access Facilities" which
comprise the bottom four layers of both models.  (Notable here is chapter
seventeen which, somewhat surprisingly, gives an excellent overview of local
area networks and all component parts.)
 
While the book is fair and accurate as far as it goes, the IBM bias is deeply
entrenched, mostly in terms of what is *not* covered.  It is instructive to
note that neither OSI nor TCP/IP are defined in the glossary (or anywhere
else).  As only one example, in discussions of presentation, ASCII and EBCDIC
are listed but not Unicode, and there is no mention of MIME at all.
 
An attempt has been made to present the book as a possible course text. 
"Exercises" are found at the end of each chapter.  They are simple queries
taken from the bottom of the questioning taxonomy.  To answer all correctly you
need only read the chapter and recognize a few key words.  The "technical
references" are of use only if you work within an SNA/SAA environment.  The two
bibliographies could have been compiled by collating "Books in Print" with a
periodical index.
 
There is a very definite need for this book.  SNA/SAA, although by no means an
"open" system, has a large installed base, and one that is still expanding. 
Those both inside the IBM camp and without have requirements to "cooperate"
with each other.  This work serves as a valuable guide not to the
implementation of gateways, but to the IBM mindset and jargon.  Those on both
sides will find it a helpful introduction to "how the other half lives."
 
copyright Robert M. Slade, 1993   BKCMCOOP.RVW  931014
Permission granted to distribute with unedited copies of the Digest
======================
DECUS Canada Communications, Desktop, Education and Security group newsletters
Editor and/or reviewer ROBERTS@decus.ca, RSlade@sfu.ca, Rob Slade at 1:153/733
DECUS Symposium '94, Vancouver, BC, Mar 1-3, 1994, contact: rulag@decus.ca

-----------[000405][next][prev][last][first]----------------------------------------------------
Date:      Thu, 23 Dec 1993 20:42:52 GMT
From:      stevea@lachman.com (Steve Alexander)
To:        biz.sco.general,comp.protocols.tcp-ip
Subject:   Re: telnetd hanging on 3.2.4.0 - HELP!

In article <2f6ssu$m3b@ulysses.iol.ie> barryf@iol.ie (Barry Flanagan) writes:
>We're running SCO 3.2.4.0 and TCPIP 1.20h, and are having problems with
>telnetd hanging leaving a rouge telnetd process and all further telnet
>connections fail until this rouge telnetd is killed, after which things
>start working again.

I think SLS NET363A fixes this.

-- 
Steve Alexander, Lachman Technology, Inc. | stevea@lachman.com
(708) 505-9555 x256 FAX: (708) 505-9574	  | ...!{sun,ico}!laidbak!stevea

-----------[000406][next][prev][last][first]----------------------------------------------------
Date:      Thu, 23 Dec 1993 23:07:32 GMT
From:      ssykes@netcom.com (Steve Sykes)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject:   Re: Wireless PC to PC communication

In article <1993Dec23.174637.3499@cse.iitb.ernet.in> yadav@cse.iitb.ernet.in (Yadav Navneet ) writes:
>Xref: netcom.com comp.protocols.tcp-ip:22812 comp.protocols.tcp-ip.ibmpc:22016
>Newsgroups: comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
>Path: netcom.com!csus.edu!decwrl!nic.hookup.net!swrinde!cs.utexas.edu!uunet!sangam!iitb!arjun.cse!yadav
>From: yadav@cse.iitb.ernet.in (Yadav Navneet )
>Subject: Wireless PC to PC communication
>Message-ID: <1993Dec23.174637.3499@cse.iitb.ernet.in>
>Sender: usenet@cse.iitb.ernet.in (news dummy user)
>Organization: Dept. of CompSc & Engg. IIT Bombay
>Date: Thu, 23 Dec 1993 17:46:37 GMT
>Lines: 14


>hi,
>        can i have any info on wireless communication between pcs using
>tcpip protocol. is there already any implentation of the same and if so
>where can i get details on it. i need to know both hardware and software
>details. if not tcpip then is there any implementation using some other
>protocols ?  

How about packet radio?

-----------[000407][next][prev][last][first]----------------------------------------------------
Date:      Thu, 23 Dec 1993 23:45:26 GMT
From:      dboyes@is.rice.edu (David E Boyes)
To:        comp.protocols.tcp-ip
Subject:   Re: tricky address: 127.0.0.1

In article <2fat4e$l4n@samba.oit.unc.edu> Kiran.Gop@launchpad.unc.edu (kiran gop) writes:
>the address 127.0.0.1 refers to ur local host!!!!!
>finger this address, and u get the list of usrs at ur machine.//.
>whats the catch behind this??? why does this address always refer to
>*your* machine??
>Cound anyone mail me the reason?

Because the specification for IP says to. 127.0.0.1 is the
loopback address and should never actually generate anything on
the wire.

-- 
David Boyes      | This signature modified to be inoffensive to any race,
dboyes@rice.edu  | color, creed, sexual orientation, or programming limitation.
My opinion is my | Sober pursuit of truth and to all high ideals consecrated?
own.             | Look, it says so right on the box, next to the Vitamin A.

-----------[000408][next][prev][last][first]----------------------------------------------------
Date:      Fri, 24 Dec 1993 09:12:59 +0000
From:      alistair@ichthya.demon.co.uk (Alistair Bell)
To:        comp.protocols.tcp-ip
Subject:   Re: Gateways, EGP, etc.

Well, the consensus appeared to be that if EGP is not already as dead as a dodo,
it soon will be. So why on earth the IAB still give it Standard state and
Recommended status I don't know; I presume it's because the new version of RFC
1009 is so delayed. I've had immense trouble getting my hands on that; the most
recent draft has expired, it's therefore been deleted from the archive sites,
and I've mailed the author but he's not replied. Anywhere I _can_ get my hands
on a copy of the most recent draft (as far as I know,
draft-ietf-rreq-iprouters-04) would be appreciated. (Don't mail it to me
directly; my current Internet connection is a 9600 baud dialup link, and if ten
people mail it to me it's going to cost loadsamoney. Just tell me that you've
got it or an ftp site I can get it from)

So what replaces EGP? Well, by the sound of it, BGP for external gatewaying and
OSPF for internal gatewaying. I haven't yet had a chance to wade through the
OSPF spec (400K of text or 900K of PostScript), but it looks useful. Note all
the new stuff about CIDR and supernetting, which a draft version of BGP
supports.

For those people implementing gateways above something roughly POSIX-ish, the
recommended way to implement BGP and OSPF appears to be to use gated, which is a
standard implementation, sources of which are available from gated.cornell.edu .
Quite what restrictions are imposed on how you can use it I don't know; I've not
done much more than connect to Cornell and look at what files are there.

The recommended book seems to be "Interconnections: Bridges and Routers" by
Radia Perlman, published by Addison-Wesley (ISBN 0-201-56332-0), US price about
$45, British price about #40. (Standard moan about technical books being so much
more expensive over here...) I finally tracked a copy down after even the
biggest mainstream bookshops had never heard of it! Again, it seems worthwhile.

And although RFC 1180 doesn't look promising from the outside, it's a good Noddy
introduction to routing.

Thanks to Andrew Heybey, Steve Heimlich, Jonathan Stone and Martin Stitt for all
their help.

--
Alistair Bell,                                  You know the disclaimers.
Brown's Operating System Services Ltd.,
St. Agnes House,
Cresswell Park,
Blackheath,
London
SE3 9RD.
Tel. 081-852 3299.

-----------[000409][next][prev][last][first]----------------------------------------------------
Date:      24 Dec 93 14:51:28
From:      billw@glare.cisco.com (William )
To:        comp.protocols.tcp-ip
Subject:   Re: tricky address: 127.0.0.1

    >the address 127.0.0.1 refers to ur local host!!!!!
    >Cound anyone mail me the reason?

    Because the specification for IP says to. 127.0.0.1 is the loopback
    address and should never actually generate anything on the wire.

Actually, it's because the original BSD Unix implementation of IP
decided to implement 127.0.0.1 as a loopback mechanism for debugging
and whatnot purposes.

This became so widespread that anyone trying to use 127 for anything
else was hopelessly out of luck (and besides, net 127 was "reserved".)
It wasn't until late 1986 (RFC990) that 127.0.0.0 was designated as
being assigned the lopoback function.

In retrospect a number of people are annoyed that an entire class A net
was "wasted" to provide a single address...

BillW


-----------[000410][next][prev][last][first]----------------------------------------------------
Date:      24 Dec 1993 10:47:17 GMT
From:      tli@cisco.com (Tony Li)
To:        comp.protocols.tcp-ip
Subject:   Re: Gateways, EGP, etc.

In article <756724379snz@ichthya.demon.co.uk> alistair@ichthya.demon.co.uk
writes: 

    I presume it's because the new version of RFC 1009 is so delayed.  I've
    had immense trouble getting my hands on that; the most recent draft has
    expired, it's therefore been deleted from the archive sites, and I've
    mailed the author but he's not replied. Anywhere I _can_ get my hands
    on a copy of the most recent draft (as far as I know,
    draft-ietf-rreq-iprouters-04) would be appreciated. (Don't mail it to
    me directly; my current Internet connection is a 9600 baud dialup link,
    and if ten people mail it to me it's going to cost loadsamoney. Just
    tell me that you've got it or an ftp site I can get it from)
    
ftp.cisco.com:tli/rreq.doc

Tony

-----------[000411][next][prev][last][first]----------------------------------------------------
Date:      24 Dec 93 19:06:50 +0100
From:      diro@edison.Phone.North.DE (Dirk Rode)
To:        comp.protocols.tcp-ip
Subject:   Re: DICOM

Shalom,

donb@crash.cts.com (Donald Bowen) writes:

>	We are about to imppplement the DICOM 3.0 file transfer protocol
>in our system.  Has anyone out there had any experience with this?

refer to:
-comp.protocols.dicom

 We implemented the European Test Knode for Dicom (European CTN).
Send a mail to
peter.jensch@informatik.uni-oldenburg.de
or
hewett@informatik.uni-Oldenburg.de

mfG Dirk
-- 
*  Dipl.Inform. Dirk Rode - Zwischenahner Str. 64 - D-26655 Howiek         *
*  OFFIS Kommunikation      E-Mail: diro@edison.phone.North.DE             *
*   Fuer Veroeffentlichungen _AUSSERHALB_ des Newssystemes gelten _MEINE_  *
*  Geschaeftsbedingungen. Nichtbeachtung wird in der Regel zivil- und      *
*  strafrechtliche Folgen nach sich ziehen.       gez. Dirk Rode           *

-----------[000412][next][prev][last][first]----------------------------------------------------
Date:      Sat, 25 Dec 93 00:35:15 GMT
From:      cliffb@cjbsys.bdb.com (cliff bedore)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject:   Re: Wireless PC to PC communication

In article <ssykes.43.2D1A24B4@netcom.com> ssykes@netcom.com (Steve Sykes) writes:
>In article <1993Dec23.174637.3499@cse.iitb.ernet.in> yadav@cse.iitb.ernet.in (Yadav Navneet ) writes:
>>Xref: netcom.com comp.protocols.tcp-ip:22812 comp.protocols.tcp-ip.ibmpc:22016
>>Newsgroups: comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
>>Path: netcom.com!csus.edu!decwrl!nic.hookup.net!swrinde!cs.utexas.edu!uunet!sangam!iitb!arjun.cse!yadav
>>From: yadav@cse.iitb.ernet.in (Yadav Navneet )
>>Subject: Wireless PC to PC communication
>>Message-ID: <1993Dec23.174637.3499@cse.iitb.ernet.in>
>>Sender: usenet@cse.iitb.ernet.in (news dummy user)
>>Organization: Dept. of CompSc & Engg. IIT Bombay
>>Date: Thu, 23 Dec 1993 17:46:37 GMT
>>Lines: 14
>
>
>>hi,
>>        can i have any info on wireless communication between pcs using
>>tcpip protocol. is there already any implentation of the same and if so
>>where can i get details on it. i need to know both hardware and software
>>details. if not tcpip then is there any implementation using some other
>>protocols ?  
>
>How about packet radio?

I was at FedUNIX here in Washington a couple of weeks ago and got some info
from NCR about their WaveLAN product.  The demo with a portable PC was quite
impressive.

Has ISA, Microchannel and PCMCIA cards. Supports IPX, ODI, NDIS, Lantastic, and
Banyon Vines. 

2 Mb/s with a range of up to 800 feet.

Above from spec sheet.  Only saw the one demo but it did look nice.

Unfortunately the spec sheet did not have a phone number

Cliff


-- 
Cliff Bedore
7403 Radcliffe Dr. College Park MD 20840
cliffb@cjbsys.bdb.com


-----------[000413][next][prev][last][first]----------------------------------------------------
Date:      24 Dec 1993 23:11:34 +1030
From:      miff@apanix.apana.org.au (Michael Smith)
To:        comp.os.vms,comp.protocols.tcp-ip,comp.sys.dec,comp.sys.m68k
Subject:   Re: KA9Q ported to 68000?

wb@arb-phys.uni-dortmund.de (Wilhelm B. Kloke) writes:

>In article <1993Dec13.155812.138@opo.van.wa.us>,  <evm@opo.van.wa.us> wrote:
>>I've got a few Dec DS200/mc terminal servers floating around that I have been 
>>looking to use in a way other that what they were intended for. They talk lat
>>and need to be downloaded at each boot so they are not too usefull for say a
>>sun or hp shop.

I saw some code in comp.sys.dec a while ago for doing MOP downloads... 
why not ask them?

>>	They have 1 AUI connection for ethernet and 8 serial lines 
>>with a max speed of 38Kbps. Internally is a 10 MHz 68000, 768 Kb Ram 
>>and 128 Kb Eprom.
>If you manage to program it for support of V32bis/V42bis modem slip or
>ppp support (at 38kBd), I would like to hear from you. The 68k should be
>sufficient to support more than 1 line at full speed. I think it should
>even do all lines, if programmed well.

I very much doubt it.  Also, 'tis worth bearing in mind that, if the DS200 
is anything like the DS100 (where most of my experience lies), 
you will have to bring the handshake line out and buffer them yourself, as 
they go nowhere on the board, as well as adding the software support.

>The DS200 (as used by DEC) does only support 9600 Bd. Where did you get
>the info about the max speed?

Hmm. I was farily sure the DS100 would do 19k2, but I'm happy to be corrected.

We junked ours and bought an annex - much nicer 8)

>wbk
 
-- 
# mike smith : miff@apanix.apana.org.au - Silicon grease monkey        #
# "The question 'why are the fundamental laws of nature mathematical'  #
# then invites the trivial response 'because we define as fundamental  #
# those laws which are mathematical'". Paul Davies, _The_Mind_of_God_. #

-----------[000414][next][prev][last][first]----------------------------------------------------
Date:      Sun, 26 Dec 1993 03:32:18 GMT
From:      dboyes@is.rice.edu (David E Boyes)
To:        comp.protocols.tcp-ip
Subject:   Re: tricky address: 127.0.0.1

In article <BILLW.93Dec24145128@glare.cisco.com> billw@glare.cisco.com (William ) writes:
>Actually, it's because the original BSD Unix implementation of IP
>decided to implement 127.0.0.1 as a loopback mechanism for debugging
>and whatnot purposes.

Good point. I had forgotten that this was a BSDism. Thanks for
the correction.

>In retrospect a number of people are annoyed that an entire class A net
>was "wasted" to provide a single address...

Sigh. And at least one other major implementation uses 14.0.0.0
as it's loopback address, thus confusing the picture even
further. 

-- 
David Boyes      | This signature modified to be inoffensive to any race,
dboyes@rice.edu  | color, creed, sexual orientation, or programming limitation.
My opinion is my | Sober pursuit of truth and to all high ideals consecrated?
own.             | Look, it says so right on the box, next to the Vitamin A.

-----------[000415][next][prev][last][first]----------------------------------------------------
Date:      26 Dec 1993 03:35:20 GMT
From:      harri906@crow.csrv.uidaho.edu (Harrington)
To:        comp.protocols.tcp-ip
Subject:   Two PC Network... :-((

HELP ME!
	I am having trouble with networking my two computers here at our 
home...
I have a paralell ports connected by a paralell cable, the CRYNWR PLIP 
driver (paralell port packet driver that supports ETERNET CODING) and 
little else... 
I know about things such as CUTCP, WATTCP etc but HOW do you set it up???
all they are talking about are things like "ask your sysadmin about 
nameservers and ip addresses"....
WHAT IF I AM THE "SYSADMIN"????
HELP!
Thanks a LOT!
Dan Harrington


-----------[000416][next][prev][last][first]----------------------------------------------------
Date:      Sun, 26 Dec 1993 04:04:30 GMT
From:      sobi0268@mary.cs.fredonia.edu (Kevin V. Sobilo)
To:        comp.protocols.tcp-ip
Subject:   Telnet Question...


Here's one for all the telecom gurus out there... I am trying to impliment
a version of telnet in C++ as a 1st step in a project I am workin on.
Well, I have read a lot about the telnet protocl in various RFCs etc...
but I am unable to see how a "login" is instantiated... I understand
how to negotiate a connection, but do not see how to initiate the login.

Any help toward clueing me in is greatly appreciated...




--

/					   				  \ 
|					  \\				   |
|					   \\                              |
|	Kevin V. Sobilo			    \\                             |
|	sobi0268@mary.cs.fredonia.edu        \\  //   "Only Amiga Makes    |
|					      \\//     It Possible"        |
|					       \/                          |
|									   |
|									   |
|		      "BEWARE OF BURPS WITH CHASERS" 			   |
|									   |
\==========================================================================/

-----------[000417][next][prev][last][first]----------------------------------------------------
Date:      Sun, 26 Dec 1993 07:42:04 GMT
From:      dan@gandalf (Dan Romascanu)
To:        comp.protocols.tcp-ip
Subject:   Multiple IP Addresses on the Same Interface

Hello,
I would like to know what are the UNIX machines that
support multiple IP addresses on the same physical
interface.
Thanks in advance
dan@lannet.com
Dan Romascanu, LANNET Data Communications Ltd.,

-----------[000418][next][prev][last][first]----------------------------------------------------
Date:      Sun, 26 Dec 93 19:28:49 EST
From:      epimntl@cybmondo.atl.ga.us (Ed Pimentel)
To:        comp.protocols.tcp-ip
Subject:   Why is PPP a better solution over SLIP?

I have read that ppp is to replace slip.
But what are theh real benefits of ppp vs slip?
How does it handle security, thruput, link setup, etc.....
 
Thanks In Advance

ed

-----------[000419][next][prev][last][first]----------------------------------------------------
Date:      Mon, 27 Dec 1993 00:12:45 GMT
From:      stevea@lachman.com (Steve Alexander)
To:        comp.protocols.tcp-ip
Subject:   Re: LPR client for SCO Unix?

In article <CII1Mv.A2I@elmail.co.uk> leo@elmail.co.uk (E.J.Leoni-Smith) writes:
>I want code to make SCO talk LPR/LPD protocols. not workarounds
>to avoid having to use them (I got that far on my own ;-))

Releases of ODT >= 2.0 or TCP/IP >= 1.2.0 have support for the BSD lpr protocol.
It is integrated in a somewhat strange way, in order to appear similar to the
System V printer software.  This turns out to be the worst of both worlds ;->,
since the lpr protocol does not support all of the System V functionality, which
annoys System V-heads, and BSD-heads who are used to lpr/lprm/lpq are annoyed
since those commands are not present.  Can't please everybody, I guess.

Having said that ;->, it works.  I use it every day to print to printers
attached to our SparcServer.

If you are running older software and cannot upgrade, site 

	dribble.c-mols.siu.edu 

has an lpr port in pub/sco-ports/odt_1.0-2.0/lpr.

I haven't used this, but I believe other people are using it with no problems.
-- 
Steve Alexander, Lachman Technology, Inc. | stevea@lachman.com
(708) 505-9555 x256 FAX: (708) 505-9574	  | ...!{sun,ico}!laidbak!stevea

-----------[000420][next][prev][last][first]----------------------------------------------------
Date:      Mon, 27 Dec 93 14:13:10 EST
From:      alhajery@newstand.syr.edu (Eyas S. Al-Hajery)
To:        comp.protocols.tcp-ip
Subject:   TCP/IP in Unix



I have posted a question long time ago, about the implementation of TCP/IP in
a Unix-based system (such as Sun's Sparc stations).  I understood based on
my reading in Clark's book, "Internetworking with TCP/IP, Vol II"  that TCP is
implemented as a running process, so when an application process wants to send (or
receive) data through the network, it would call the socket interface, which then
call the TCP process. So the OS will context switch between the application process and the TCP.  I received then from someone who said that the implementation of TCP/IP as a process is an old approach, it is not used nowadays,
but he didn't mentioned what is the "new" approach in implementing TCP/IP.

So, if anyone has information on the implementation of TCP/IP within the existing
systems, I'd appreciate if he (or she) would help me in that regard ...
Thanks.

  E. Alhajery


-----------[000421][next][prev][last][first]----------------------------------------------------
Date:      Mon, 27 Dec 1993 15:01:53
From:      hruska@bmcwest.com (Paul Hruska)
To:        comp.os.ms-windows.apps,comp.os.ms-windows.misc,comp.protocols.ppp,comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc,comp.windows.ms
Subject:   WYSE-50 Terminal Emulation w/ TCP/IP Support

I am looking for a terminal emulation program for Windows 3.1 that supports 
Wyse-50 escape sequences and will operate with TCP/IP (Winsock).

I hope there is such a critter out there.

If you know of one can you let me know?

Thanks,
	Paul


======================================================================
 Paul Hruska                  |      Phone: (208) 387-4384 
 BMC West Corporation         |        Fax: (208) 387-4367 
 1475 Tyrell Ln               |   Internet: Hruska@BMCWest.Com
 Boise, ID 83707              |
----------------------------------------------------------------------
  Truth is like a diamond.
    You cannot fully appreciate it's beauty from only one facet.

-----------[000422][next][prev][last][first]----------------------------------------------------
Date:      Mon, 27 Dec 1993 10:32:37 GMT
From:      lep@gbg.icl.se (Lasse Petterson)
To:        comp.protocols.tcp-ip
Subject:   TCP/IP on AIX

I have a problem with TCP/IP on AIX 3.2.
My customer runs PS/2's (IBM Dos 5.00, Win 3.1) and
BWNFS ver 3.02.

PC's will hang after timing out after 15 minutes,
an error message "time out (900 secs) - lost connection"
is shown.

I have not been able to find any timeout parameter 
in smit or anywhere else on the RS/6000.

Anyone out there who has seen this problem before 
and know how to set the timeout value?

Called IBM, they could not help.


-----------[000423][next][prev][last][first]----------------------------------------------------
Date:      27 Dec 93 14:40:45 EDT
From:      mckee@pacs.sunbelt.net
To:        comp.protocols.tcp-ip
Subject:   Post Office Protocols on RS6000

Does anyone have working POP2, POP3 and IMAPD clients on an
IBM RS6000?  A client is in need of them.

Thanks,

Tim McKee
Manager, SunBelt.Net

-----------[000424][next][prev][last][first]----------------------------------------------------
Date:      Mon, 27 Dec 1993 12:35:44 GMT
From:      pac@oberon.inesc.pt (Pedro Correia)
To:        comp.windows.x.apps,comp.protocols.tcp-ip
Subject:   TANDEM emulator

	Hello. I would like to know if there are any good Tandem terminal
emulators for Unix/X11. I need to access a Tandem running Guardian and TCP/IP
on a LAN.
	Please reply directly by e-mail to pac@oberon.inesc.pt
	Thank you for your help.

Pedro Alexandre Correia					pac@oberon.inesc.pt
Instituto de Engenharia de Sistemas e Computadores	Tel +351(1)3100345
R. Alves Redol, 9, 1000 LISBOA, Portugal		Fax +351(1)525843

	Research is what I'm doing when I don't know what I'm doing.
			-- Wernher von Braun


-----------[000425][next][prev][last][first]----------------------------------------------------
Date:      Mon, 27 Dec 1993 13:42:45 GMT
From:      nori-d@is.aist-nara.ac.jp (Noritoshi Demizu)
To:        comp.protocols.tcp-ip
Subject:   typos in ds.internic.net:/rfc/rfc-index.txt

I found typos in new rfc-index.txt retrieved from ds.internic.net:/rfc.
Since I don't know the correct place to send this patch, I will post the
patch here.  If you knew more appropriate place, please tell me.

It is important for me to have corret rfc-index.txt, because I'm using
a filter which generates bibtex data from rfc-index.txt,

Thanks.

*** rfc-index.txt-ds.internic.net	Fri Dec 24 22:35:00 1993
--- rfc-index.txt	Mon Dec 27 21:51:21 1993
***************
*** 3109,3116 ****
  1093 NSFNET routing architecture. H.W. Braun. Feb-01-1989. (Format:
       TXT=20629 bytes)
  
! 1094 NFS: Network File System Protocol specification. Inc. Sun
!      Microsystems. Mar-01-1989. (Format: TXT=51454 bytes)
  
  1095 Common Management Information Services and Protocol over TCP/IP
       (CMOT). U.S. Warrier, L. Besaw. Apr-01-1989. (Format: TXT=157506
--- 3109,3116 ----
  1093 NSFNET routing architecture. H.W. Braun. Feb-01-1989. (Format:
       TXT=20629 bytes)
  
! 1094 NFS: Network File System Protocol specification. Sun
!      Microsystems, Inc. Mar-01-1989. (Format: TXT=51454 bytes)
  
  1095 Common Management Information Services and Protocol over TCP/IP
       (CMOT). U.S. Warrier, L. Besaw. Apr-01-1989. (Format: TXT=157506
***************
*** 3273,3279 ****
  1142 OSI IS-IS Intra-domain Routing Protocol. D. Oran. Feb-01-1990.
       (Format: TXT=425379, PS=1204297 bytes)
  
! 1143 Q method of implementing Telnet option negotiation. D.J.
       Bernstein. Feb-01-1990. (Format: TXT=23331 bytes)
  
  1144 Compressing TCP/IP headers for low-speed serial links. V.
--- 3273,3279 ----
  1142 OSI IS-IS Intra-domain Routing Protocol. D. Oran. Feb-01-1990.
       (Format: TXT=425379, PS=1204297 bytes)
  
! 1143 The Q method of implementing Telnet option negotiation. D.J.
       Bernstein. Feb-01-1990. (Format: TXT=23331 bytes)
  
  1144 Compressing TCP/IP headers for low-speed serial links. V.
***************
*** 3294,3300 ****
       Mar-01-1990. (Format: TXT=194292 bytes) (Updates RFC0822, RFC0987,
       RFC1026, RFC1138)
  
! 1149 Standard for the transmission of IP datagrams on avian carriers.
       D. Waitzman. Apr-01-1990. (Format: TXT=3329 bytes)
  
  1150 F.Y.I. on F.Y.I.: Introduction to the F.Y.I. notes. G.S. Malkin,
--- 3294,3300 ----
       Mar-01-1990. (Format: TXT=194292 bytes) (Updates RFC0822, RFC0987,
       RFC1026, RFC1138)
  
! 1149 A Standard for the transmission of IP datagrams on avian carriers.
       D. Waitzman. Apr-01-1990. (Format: TXT=3329 bytes)
  
  1150 F.Y.I. on F.Y.I.: Introduction to the F.Y.I. notes. G.S. Malkin,
***************
*** 3332,3338 ****
  1159 Message Send Protocol. R. Nelson. Jun-01-1990. (Format: TXT=3957
       bytes)
  
! 1160 Internet Activities Board. V. Cerf. May-01-1990. (Format:
       TXT=28182 bytes) (Obsoletes RFC1120)
  
  1161 SNMP over OSI. M.T. Rose. Jun-01-1990. (Format: TXT=16036 bytes)
--- 3332,3338 ----
  1159 Message Send Protocol. R. Nelson. Jun-01-1990. (Format: TXT=3957
       bytes)
  
! 1160 The Internet Activities Board. V. Cerf. May-01-1990. (Format:
       TXT=28182 bytes) (Obsoletes RFC1120)
  
  1161 SNMP over OSI. M.T. Rose. Jun-01-1990. (Format: TXT=16036 bytes)
***************
*** 3342,3348 ****
       Intermediate System (ISO 9542) Management Information Base. G. Satz.
       Jun-01-1990. (Format: TXT=109893 bytes) (Obsoleted by RFC1238)
  
! 1163 Border Gateway Protocol (BGP). K. Lougheed, Y. Rekhter.
       Jun-01-1990. (Format: TXT=69404 bytes) (Obsoletes RFC1105) (Obsoleted
       by RFC1267)
  
--- 3342,3348 ----
       Intermediate System (ISO 9542) Management Information Base. G. Satz.
       Jun-01-1990. (Format: TXT=109893 bytes) (Obsoleted by RFC1238)
  
! 1163 A Border Gateway Protocol (BGP). K. Lougheed, Y. Rekhter.
       Jun-01-1990. (Format: TXT=69404 bytes) (Obsoletes RFC1105) (Obsoleted
       by RFC1267)
  
***************
*** 3371,3381 ****
  1170 Public key standards and licenses. R.B. Fougner. Jan-01-1991.
       (Format: TXT=3144 bytes)
  
! 1171 Point-to-Point Protocol for the transmission of multi-protocol
       datagrams over Point-to-Point links. D. Perkins. Jul-01-1990.
       (Format: TXT=92321 bytes) (Obsoletes RFC1134)
  
! 1172 Point-to-Point Protocol (PPP) initial configuration options. D.
       Perkins, R. Hobby. Jul-01-1990. (Format: TXT=76132 bytes)
  
  1173 Responsibilities of host and network managers: A summary of the
--- 3371,3381 ----
  1170 Public key standards and licenses. R.B. Fougner. Jan-01-1991.
       (Format: TXT=3144 bytes)
  
! 1171 The Point-to-Point Protocol for the transmission of multi-protocol
       datagrams over Point-to-Point links. D. Perkins. Jul-01-1990.
       (Format: TXT=92321 bytes) (Obsoletes RFC1134)
  
! 1172 The Point-to-Point Protocol (PPP) initial configuration options. D.
       Perkins, R. Hobby. Jul-01-1990. (Format: TXT=76132 bytes)
  
  1173 Responsibilities of host and network managers: A summary of the
***************
*** 3405,3411 ****
  1179 Line printer daemon protocol. L. McLaughlin. Aug-01-1990.
       (Format: TXT=24324 bytes)
  
! 1180 TCP/IP tutorial. T.J. Socolofsky, C.J. Kale. Jan-01-1991.
       (Format: TXT=65494 bytes)
  
  1181 RIPE terms of reference. R. Blokzijl. Sep-01-1990. (Format:
--- 3405,3411 ----
  1179 Line printer daemon protocol. L. McLaughlin. Aug-01-1990.
       (Format: TXT=24324 bytes)
  
! 1180 A TCP/IP tutorial. T.J. Socolofsky, C.J. Kale. Jan-01-1991.
       (Format: TXT=65494 bytes)
  
  1181 RIPE terms of reference. R. Blokzijl. Sep-01-1990. (Format:
***************
*** 3423,3439 ****
  1185 TCP extension for high-speed paths. V. Jacobson, R.T. Braden, L.
       Zhang. Oct-01-1990. (Format: TXT=49508 bytes)
  
! 1186 MD4 message digest algorithm. R.L. Rivest. Oct-01-1990. (Format:
       TXT=35391 bytes)
  
  1187 Bulk table retrieval with the SNMP. M.T. Rose, K. McCloghrie,
       J.R. Davin. Oct-01-1990. (Format: TXT=27220 bytes)
  
! 1188 Proposed standard for the transmission of IP datagrams over FDDI
       networks. D. Katz. Oct-01-1990. (Format: TXT=22424 bytes) (Obsoletes
       RFC1103)
  
! 1189 Common Management Information Services and Protocols for the
       Internet (CMOT and CMIP). U.S. Warrier, L. Besaw, L. LaBarre, B.D.
       Handspicker. Oct-01-1990. (Format: TXT=32928 bytes) (Obsoletes
       RFC1095)
--- 3423,3439 ----
  1185 TCP extension for high-speed paths. V. Jacobson, R.T. Braden, L.
       Zhang. Oct-01-1990. (Format: TXT=49508 bytes)
  
! 1186 The MD4 message digest algorithm. R.L. Rivest. Oct-01-1990. (Format:
       TXT=35391 bytes)
  
  1187 Bulk table retrieval with the SNMP. M.T. Rose, K. McCloghrie,
       J.R. Davin. Oct-01-1990. (Format: TXT=27220 bytes)
  
! 1188 A Proposed standard for the transmission of IP datagrams over FDDI
       networks. D. Katz. Oct-01-1990. (Format: TXT=22424 bytes) (Obsoletes
       RFC1103)
  
! 1189 The Common Management Information Services and Protocols for the
       Internet (CMOT and CMIP). U.S. Warrier, L. Besaw, L. LaBarre, B.D.
       Handspicker. Oct-01-1990. (Format: TXT=32928 bytes) (Obsoletes
       RFC1095)
***************
*** 3450,3463 ****
  1193 Client requirements for real-time communication services. D.
       Ferrari. Nov-01-1990. (Format: TXT=61540 bytes)
  
! 1194 Finger User Information Protocol. D.P. Zimmerman. Nov-01-1990.
       (Format: TXT=24626 bytes) (Obsoletes RFC0742) (Obsoleted by RFC1288,
       RFC1196)
  
  1195 Use of OSI IS-IS for routing in TCP/IP and dual environments.
       R.W. Callon. Dec-01-1990. (Format: TXT=187866, PS=362052 bytes)
  
! 1196 Finger User Information Protocol. D.P. Zimmerman. Dec-01-1990.
       (Format: TXT=24799 bytes) (Obsoletes RFC1194) (Obsoleted by RFC1288)
  
  1197 Using ODA for translating multimedia information. M. Sherman.
--- 3450,3463 ----
  1193 Client requirements for real-time communication services. D.
       Ferrari. Nov-01-1990. (Format: TXT=61540 bytes)
  
! 1194 The Finger User Information Protocol. D.P. Zimmerman. Nov-01-1990.
       (Format: TXT=24626 bytes) (Obsoletes RFC0742) (Obsoleted by RFC1288,
       RFC1196)
  
  1195 Use of OSI IS-IS for routing in TCP/IP and dual environments.
       R.W. Callon. Dec-01-1990. (Format: TXT=187866, PS=362052 bytes)
  
! 1196 The Finger User Information Protocol. D.P. Zimmerman. Dec-01-1990.
       (Format: TXT=24799 bytes) (Obsoletes RFC1194) (Obsoleted by RFC1288)
  
  1197 Using ODA for translating multimedia information. M. Sherman.
***************
*** 3466,3472 ****
  1198 FYI on the X window system. R.W. Scheifler. Jan-01-1991. (Format:
       TXT=3629 bytes) (Also FYI0006)
  
! 1199 Request for Comments Summary Notes: 1100-1199. J. Reynolds.
       Dec-01-1991. (Format: TXT=46443 bytes)
  
  1200 IAB official protocol standards. Defense Advanced Research
--- 3466,3472 ----
  1198 FYI on the X window system. R.W. Scheifler. Jan-01-1991. (Format:
       TXT=3629 bytes) (Also FYI0006)
  
! 1199 Request for Comments Summary RFC Numbers: 1100-1199. J. Reynolds.
       Dec-01-1991. (Format: TXT=46443 bytes)
  
  1200 IAB official protocol standards. Defense Advanced Research
***************
*** 3497,3506 ****
       "experienced Internet user" questions. G.S. Malkin, A.N. Marine, J.K.
       Reynolds. Feb-01-1991. (Format: TXT=33385 bytes) (Also FYI0007)
  
! 1208 Glossary of networking terms. O.J. Jacobsen, D.C. Lynch.
       Mar-01-1991. (Format: TXT=41156 bytes)
  
! 1209 Transmission of IP datagrams over the SMDS Service. D.M.
       Piscitello, J. Lawrence. Mar-01-1991. (Format: TXT=25280 bytes)
  
  1210 Network and infrastructure user requirements for transatlantic
--- 3497,3506 ----
       "experienced Internet user" questions. G.S. Malkin, A.N. Marine, J.K.
       Reynolds. Feb-01-1991. (Format: TXT=33385 bytes) (Also FYI0007)
  
! 1208 A Glossary of networking terms. O.J. Jacobsen, D.C. Lynch.
       Mar-01-1991. (Format: TXT=41156 bytes)
  
! 1209 The Transmission of IP datagrams over the SMDS Service. D.M.
       Piscitello, J. Lawrence. Mar-01-1991. (Format: TXT=25280 bytes)
  
  1210 Network and infrastructure user requirements for transatlantic
***************
*** 3521,3527 ****
  1214 OSI internet management: Management Information Base. L. LaBarre.
       Apr-01-1991. (Format: TXT=172564 bytes)
  
! 1215 Convention for defining traps for use with the SNMP. M.T. Rose.
       Mar-01-1991. (Format: TXT=19336 bytes)
  
  1216 Gigabit network economics and paradigm shifts. P. Richard, P.
--- 3521,3527 ----
  1214 OSI internet management: Management Information Base. L. LaBarre.
       Apr-01-1991. (Format: TXT=172564 bytes)
  
! 1215 A Convention for defining traps for use with the SNMP. M.T. Rose.
       Mar-01-1991. (Format: TXT=19336 bytes)
  
  1216 Gigabit network economics and paradigm shifts. P. Richard, P.
***************
*** 3530,3536 ****
  1217 Memo from the Consortium for Slow Commotion Research (CSCR). V.G.
       Cerf. Apr-01-1991. (Format: TXT=11079 bytes)
  
! 1218 Naming scheme for c=US. North American Directory Forum..
       Apr-01-1991. (Format: TXT=42698 bytes) (Obsoleted by RFC1255,
       RFC1417)
  
--- 3530,3536 ----
  1217 Memo from the Consortium for Slow Commotion Research (CSCR). V.G.
       Cerf. Apr-01-1991. (Format: TXT=11079 bytes)
  
! 1218 A Naming scheme for c=US. North American Directory Forum..
       Apr-01-1991. (Format: TXT=42698 bytes) (Obsoleted by RFC1255,
       RFC1417)
  
***************
*** 3585,3591 ****
  1234 Tunneling IPX traffic through IP networks. D. Provan.
       Jun-01-1991. (Format: TXT=12333 bytes)
  
! 1235 Coherent File Distribution Protocol. J. Ioannidis, Jr. Maguire,
       G.Q.. Jun-01-1991. (Format: TXT=29345 bytes)
  
  1236 IP to X.121 address mapping for DDN. Jr. Morales, L.F., P.R.
--- 3585,3591 ----
  1234 Tunneling IPX traffic through IP networks. D. Provan.
       Jun-01-1991. (Format: TXT=12333 bytes)
  
! 1235 The Coherent File Distribution Protocol. J. Ioannidis, Jr. Maguire,
       G.Q.. Jun-01-1991. (Format: TXT=29345 bytes)
  
  1236 IP to X.121 address mapping for DDN. Jr. Morales, L.F., P.R.
***************
*** 3652,3657 ****
--- 3652,3658 ----
  
  1254 Gateway Congestion Control Survey. A. Mankin, K. Ramakrishnan.
       Jul-01-1991. (Format: TXT=67609 bytes)
+ % August??
  
  1255 A Naming Scheme for c=US. The North American Directory Forum.
       Sep-01-1991. (Format: TXT=51103 bytes) (Obsoletes RFC1218) (Obsoleted
***************
*** 3670,3676 ****
  
  1260 ( Never Issued). .. (Format: TXT=29 bytes)
  
! 1261 Transiton of NIC services. S. Williamson, L. Nobile. Sep-01-1991.
       (Format: TXT=4244 bytes)
  
  1262 Guidelines for internet measurement activities. V.G. Cerf.
--- 3671,3677 ----
  
  1260 ( Never Issued). .. (Format: TXT=29 bytes)
  
! 1261 Transition of NIC services. S. Williamson, L. Nobile. Sep-01-1991.
       (Format: TXT=4244 bytes)
  
  1262 Guidelines for internet measurement activities. V.G. Cerf.
***************
*** 3689,3695 ****
  1266 Experience with the BGP protocol. Y. Rekhter. Oct-01-1991.
       (Format: TXT=21938 bytes)
  
! 1267 Border Gateway Protocol 3 (BGP-3). K. Lougheed, Y. Rekhter.
       Oct-01-1991. (Format: TXT=80724 bytes) (Obsoletes RFC1163)
  
  1268 Application of the Border Gateway Protocol in the Internet. Y.
--- 3690,3696 ----
  1266 Experience with the BGP protocol. Y. Rekhter. Oct-01-1991.
       (Format: TXT=21938 bytes)
  
! 1267 A Border Gateway Protocol 3 (BGP-3). K. Lougheed, Y. Rekhter.
       Oct-01-1991. (Format: TXT=80724 bytes) (Obsoletes RFC1163)
  
  1268 Application of the Border Gateway Protocol in the Internet. Y.
***************
*** 3709,3715 ****
  1272 Internet accounting: Background. C. Mills, D. Hirsh, G.R. Ruth.
       Nov-01-1991. (Format: TXT=46562 bytes)
  
! 1273 Measurement study of changes in service-level reachability in the
       global TCP/IP Internet: Goals, experimental design, implementation,
       and policy considerations. M.F. Schwartz. Nov-01-1991. (Format:
       TXT=19949 bytes)
--- 3710,3716 ----
  1272 Internet accounting: Background. C. Mills, D. Hirsh, G.R. Ruth.
       Nov-01-1991. (Format: TXT=46562 bytes)
  
! 1273 A Measurement study of changes in service-level reachability in the
       global TCP/IP Internet: Goals, experimental design, implementation,
       and policy considerations. M.F. Schwartz. Nov-01-1991. (Format:
       TXT=19949 bytes)
***************
*** 3814,3821 ****
  1304 Definitions of Managed Objects for the SIP Interface Type. T.
       Cox, K. Tesink, Editors. February 1992. (Format: TXT=52491 bytes)
  
! 1305 Network Time Protocol (Version 3) Specification, Implementation.
!      David L. Mills. March 1992. (Format: TXT=307085 bytes)
  
  1306 Experiences Supporting By-Request Circuit-Switched T3 Networks.
       A. Nicholson, J. Young. March 1992. (Format: TXT=25788 bytes)
--- 3815,3822 ----
  1304 Definitions of Managed Objects for the SIP Interface Type. T.
       Cox, K. Tesink, Editors. February 1992. (Format: TXT=52491 bytes)
  
! 1305 Network Time Protocol (Version 3) Specification, Implementation and
!      Analysis. David L. Mills. March 1992. (Format: TXT=307085 bytes)
  
  1306 Experiences Supporting By-Request Circuit-Switched T3 Networks.
       A. Nicholson, J. Young. March 1992. (Format: TXT=25788 bytes)
***************
*** 3855,3862 ****
  1317 Definitions of Managed Objects for RS-232-like Hardware Devices.
       B. Stewart. April 1992. (Format: TXT=30442 bytes)
  
! 1318 Definitions of Managed Objects for Parallel-printer-like. B.
!      Stewart. April 1992. (Format: TXT=19570 bytes)
  
  1319 The MD2 Message-Digest Algorithm. B. Kaliski. April 1992.
       (Format: TXT=25661 bytes)
--- 3856,3863 ----
  1317 Definitions of Managed Objects for RS-232-like Hardware Devices.
       B. Stewart. April 1992. (Format: TXT=30442 bytes)
  
! 1318 Definitions of Managed Objects for Parallel-printer-like Hardware Devices.
!      B. Stewart. April 1992. (Format: TXT=19570 bytes)
  
  1319 The MD2 Message-Digest Algorithm. B. Kaliski. April 1992.
       (Format: TXT=25661 bytes)
***************
*** 3877,3883 ****
       (Format: TXT=24988 bytes)
  
  1325 FYI on Questions and Answers Answers to Commonly asked "New
!      Internet Us\. G. Malkin,A. Marine. May 1992. (Format: TXT=91884
       bytes) (Obsoletes RFC 1206)
  
  1326 Mutual Encapsulation Considered Dangerous. P. Tsuchiya. May 1992.
--- 3878,3884 ----
       (Format: TXT=24988 bytes)
  
  1325 FYI on Questions and Answers Answers to Commonly asked "New
!      Internet User" Questions. G. Malkin,A. Marine. May 1992. (Format: TXT=91884
       bytes) (Obsoletes RFC 1206)
  
  1326 Mutual Encapsulation Considered Dangerous. P. Tsuchiya. May 1992.
***************
*** 3911,3917 ****
  1334 PPP Authentication Protocols. B. Lloyd, W. Simpson. October 1992.
       (Format: TXT=33248 bytes)
  
! 1335 A Two-Tier Address Structure for the Internet:A Solution to the.
       Z. Wang,J. Crowcroft. May 1992. (Format: TXT=15418 bytes)
  
  1336 Who's Who in the Internet: Biographies of IAB, IESG and IRSG
--- 3912,3919 ----
  1334 PPP Authentication Protocols. B. Lloyd, W. Simpson. October 1992.
       (Format: TXT=33248 bytes)
  
! 1335 A Two-Tier Address Structure for the Internet: A Solution to the
!      Problem of Address Space Exhaustion.
       Z. Wang,J. Crowcroft. May 1992. (Format: TXT=15418 bytes)
  
  1336 Who's Who in the Internet: Biographies of IAB, IESG and IRSG
***************
*** 3945,3951 ****
  1344 Implications of MIME for Internet Mail Gateways. N. Borenstein.
       June 1992. (Format: TXT=25872, PS=51812 bytes)
  
! 1345 Character Mnemonics and Character Sets. K. Simonsen. June 1992.
       (Format: TXT=249737 bytes)
  
  1346 Resource Allocation, Control, and Accounting for the Use of
--- 3947,3953 ----
  1344 Implications of MIME for Internet Mail Gateways. N. Borenstein.
       June 1992. (Format: TXT=25872, PS=51812 bytes)
  
! 1345 Character Mnemonics & Character Sets. K. Simonsen. June 1992.
       (Format: TXT=249737 bytes)
  
  1346 Resource Allocation, Control, and Accounting for the Use of
***************
*** 3970,3977 ****
  1352 SNMP Security Protocols. J. Galvin,K. McCloghrie,J. Davin. July
       1992. (Format: TXT=95732 bytes)
  
! 1353 Definitions of Managed Objects. K. McCloghrie,J. Davin,J. Galvin.
!      July 1992. (Format: TXT=59556 bytes)
  
  1354 IP Forwarding Table MIB. F. Baker. July 1992. (Format: TXT=24905
       bytes)
--- 3972,3979 ----
  1352 SNMP Security Protocols. J. Galvin,K. McCloghrie,J. Davin. July
       1992. (Format: TXT=95732 bytes)
  
! 1353 Definitions of Managed Objects for Administration of SNMP Parties.
!      K. McCloghrie,J. Davin,J. Galvin. July 1992. (Format: TXT=59556 bytes)
  
  1354 IP Forwarding Table MIB. F. Baker. July 1992. (Format: TXT=24905
       bytes)
***************
*** 4000,4006 ****
  1361 Simple Network Time Protocol (SNTP). D. Mills. August 1992.
       (Format: TXT=23812 bytes) (Also RFC1305)
  
! 1362 Novel IPX over Various WAN Media (IPXWAN). M. Allen. September
       1992. (Format: TXT=30219 bytes)
  
  1363 A Proposed Flow Specification. C. Partridge. September 1992.
--- 4002,4008 ----
  1361 Simple Network Time Protocol (SNTP). D. Mills. August 1992.
       (Format: TXT=23812 bytes) (Also RFC1305)
  
! 1362 Novell IPX over Various WAN Media (IPXWAN). M. Allen. September
       1992. (Format: TXT=30219 bytes)
  
  1363 A Proposed Flow Specification. C. Partridge. September 1992.
***************
*** 4018,4024 ****
  1367 Schedule for IP Address Space Management Guidelines. C. Topolcic.
       October 1992. (Format: TXT=4780 bytes) (Obsoleted by RFC1467)
  
! 1368 Definition of Managed Objects for IEEE 802.3 Repeater Devices. D.
       McMaster, K. McCloughrie. October 1992. (Format: TXT=83905 bytes)
  
  1369 Implementation Notes and Experience for the Internet Ethernet
--- 4020,4026 ----
  1367 Schedule for IP Address Space Management Guidelines. C. Topolcic.
       October 1992. (Format: TXT=4780 bytes) (Obsoleted by RFC1467)
  
! 1368 Definitions of Managed Objects for IEEE 802.3 Repeater Devices. D.
       McMaster, K. McCloughrie. October 1992. (Format: TXT=83905 bytes)
  
  1369 Implementation Notes and Experience for the Internet Ethernet
***************
*** 4083,4095 ****
  1388 RIP Version 2 Carrying Additional Information. G. Malkin. January
       1993. (Format: TXT=16227 bytes)
  
! 1389 RIP Version 2 MIB Extensions. G. Malkin, F. Baker. January 1993.
       (Format: TXT=23569 bytes)
  
  1390 Transmission of IP and ARP over FDDI Networks. D. Katz. January
       1993. (Format: TXT=22077 bytes)
  
! 1391 The Tao of the IETF: A Guide for New Attendees of the Internet
       Engineering Task Force. G. Malkin. January 1993. (Format: TXT=41892
       bytes)
  
--- 4085,4097 ----
  1388 RIP Version 2 Carrying Additional Information. G. Malkin. January
       1993. (Format: TXT=16227 bytes)
  
! 1389 RIP Version 2 MIB Extension. G. Malkin, F. Baker. January 1993.
       (Format: TXT=23569 bytes)
  
  1390 Transmission of IP and ARP over FDDI Networks. D. Katz. January
       1993. (Format: TXT=22077 bytes)
  
! 1391 The Tao of IETF: A Guide for New Attendees of the Internet
       Engineering Task Force. G. Malkin. January 1993. (Format: TXT=41892
       bytes)
  
***************
*** 4106,4116 ****
       (Format: TXT=16314 bytes) (Obsoletes RFC1084, RFC1048) (Obsoleted by
       RFC1497) (Updates RFC951)
  
! 1396 The Process for Organization of Internet Standards Working. S.
       Crocker. January 1993. (Format: TXT=22096 bytes)
  
! 1397 Default Route Advertisement In BGP2 and BGP3 Version of The. D.
!      Haskin. January 1993. (Format: TXT=4124 bytes)
  
  1398 Definitions of Managed Objects for the Ethernet-Like Interface
       Types. F. Kastenholz. January 1993. (Format: TXT=36684 bytes)
--- 4108,4118 ----
       (Format: TXT=16314 bytes) (Obsoletes RFC1084, RFC1048) (Obsoleted by
       RFC1497) (Updates RFC951)
  
! 1396 The Process for Organization of Internet Standards Working Group (POISED). S.
       Crocker. January 1993. (Format: TXT=22096 bytes)
  
! 1397 Default Route Advertisement In BGP2 and BGP3 Version of The Border
!      Gateway Protocol. D. Haskin. January 1993. (Format: TXT=4124 bytes)
  
  1398 Definitions of Managed Objects for the Ethernet-Like Interface
       Types. F. Kastenholz. January 1993. (Format: TXT=36684 bytes)
***************
*** 4121,4131 ****
  1400 Transition and Modernization of the Internet Registration
       Service. S. Williamson. March 1993. (Format: TXT=13008 bytes)
  
! 1401 Correspondence between the IAB and DISA on the use of DNS.
       Internet Architecture Board. January 1993. (Format: TXT=12528 bytes)
  
! 1402 There's Gold in them thar Networks! Searching for Treasure in. J.
!      Martin. January 1993. (Format: TXT=71176 bytes) (Obsoletes RFC 1290)
  
  1403 BGP OSPF Interaction. K. Varadhan. January 1993. (Format:
       TXT=36173 bytes) (Obsoletes RFC 1364)
--- 4123,4133 ----
  1400 Transition and Modernization of the Internet Registration
       Service. S. Williamson. March 1993. (Format: TXT=13008 bytes)
  
! 1401 Correspondence between the IAB and DISA on the use of DNS throughout the Internet.
       Internet Architecture Board. January 1993. (Format: TXT=12528 bytes)
  
! 1402 There's Gold in them thar Networks! Searching for Treasure in
!      all the Wrong Places. J. Martin. January 1993. (Format: TXT=71176 bytes) (Obsoletes RFC 1290)
  
  1403 BGP OSPF Interaction. K. Varadhan. January 1993. (Format:
       TXT=36173 bytes) (Obsoletes RFC 1364)
***************
*** 4159,4168 ****
  1412 Telnet Authentication: SPX. K. Alagappan. January 1993. (Format:
       TXT=6952 bytes)
  
! 1413 Identification Protocol. M. StJohns. January 1993. (Format:
       TXT=16291 bytes) (Obsoletes RFC931)
  
! 1414 Identification MIB. M. StJohns & M. Rose. January 1993. (Format:
       TXT=14165 bytes)
  
  1415 FTP-FTAM Gateway Specification. J. Mindel & R. Slaski. January
--- 4161,4170 ----
  1412 Telnet Authentication: SPX. K. Alagappan. January 1993. (Format:
       TXT=6952 bytes)
  
! 1413 Identification Protocol. M. St. Johns. February 1993. (Format:
       TXT=16291 bytes) (Obsoletes RFC931)
  
! 1414 Identification MIB. M. St. Johns & M. Rose. February 1993. (Format:
       TXT=14165 bytes)
  
  1415 FTP-FTAM Gateway Specification. J. Mindel & R. Slaski. January
***************
*** 4239,4245 ****
  
  1436 The Internet Gopher Protocol (a distributed document search and
       retrieval protocol). F. Anklesaria, M. McCahill, P. Lindner, D.
!      Johnson, D. Torrey & B. Albert. March 1993. (Format: TXT=36493 bytes)
  
  1437 The Extension of MIME Content-Types to a New Medium. N.
       Borenstein & M. Linimon. 1 April 1993. (Format: TXT=13356 bytes)
--- 4241,4247 ----
  
  1436 The Internet Gopher Protocol (a distributed document search and
       retrieval protocol). F. Anklesaria, M. McCahill, P. Lindner, D.
!      Johnson, D. Torrey & B. Alberti. March 1993. (Format: TXT=36493 bytes)
  
  1437 The Extension of MIME Content-Types to a New Medium. N.
       Borenstein & M. Linimon. 1 April 1993. (Format: TXT=13356 bytes)
***************
*** 4336,4343 ****
       (Format: TXT=27811 bytes) (Also FYI0020)
  
  1463 FYI on Introducing the Internet-- A Short Bibliography of
!      Introductory Internetworking Readings. E. Hoffman & L. Jackson. May
!      1993. (Format: TXT=7116 bytes) (Also FYI0019)
  
  1464 Using the Domain Name System To Store Arbitrary String
       Attributes. R. Rosenbaum. May 1993. (Format: TXT=7953 bytes)
--- 4338,4346 ----
       (Format: TXT=27811 bytes) (Also FYI0020)
  
  1463 FYI on Introducing the Internet-- A Short Bibliography of
!      Introductory Internetworking Readings for the Network Novice.
!      E. Hoffman & L. Jackson. May 1993. (Format: TXT=7116 bytes)
!      (Also FYI0019)
  
  1464 Using the Domain Name System To Store Arbitrary String
       Attributes. R. Rosenbaum. May 1993. (Format: TXT=7953 bytes)
***************
*** 4382,4388 ****
  1475 TP/IX: The Next Internet. R. Ullmann. June 1993. (Format:
       TXT=77854 bytes)
  
! 1476 RAP: Internet Route Access Protoco. R. Ullmann. June 1993.
       (Format: TXT=45560 bytes)
  
  1477 IDPR as a Proposed Standard. M. Steenstrup. July 1993. (Format:
--- 4385,4391 ----
  1475 TP/IX: The Next Internet. R. Ullmann. June 1993. (Format:
       TXT=77854 bytes)
  
! 1476 RAP: Internet Route Access Protocol. R. Ullmann. June 1993.
       (Format: TXT=45560 bytes)
  
  1477 IDPR as a Proposed Standard. M. Steenstrup. July 1993. (Format:

--
;  DEMIZU Noritoshi <nori-d@is.aist-nara.ac.jp>
;  Graduate School of Information Science
;  Nara Institute of Science and Technology

-----------[000426][next][prev][last][first]----------------------------------------------------
Date:      Mon, 27 Dec 1993 14:40:47 GMT
From:      brownje@ncifcrf.gov (Janet E. Brown)
To:        comp.protocols.tcp-ip
Subject:   Re: Telnet Question...

After TELNET has negotiated its environment, i.e., WILL/WONT stuff,
it steps back and simply handles connection activity.  LOGON Screens
are handled by the native system just as if you are at the terminal or 
work station; TELNET is not responsible for logon. For example, 
in IBM's VM TCP/IP, after TELNET negotiates it's environment, it notifies 
the application (in this instance, VM/CMS) that it is ready to accept 
information. CMS then 'sends' its first screen of data - the logon screen. 
To TELNET, the logon screen, and the subsequent password response from 
the client, is merely data to be passed back and forth between the client 
and the server application. 




-----------[000427][next][prev][last][first]----------------------------------------------------
Date:      Mon, 27 Dec 1993 16:51:18 +0000
From:      ian@g3nrw.demon.co.uk (Ian Wade)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP/IP on AIX

In article <lep.5@gbg.icl.se> lep@gbg.icl.se writes:

>I have a problem with TCP/IP on AIX 3.2.
>PC's will hang after timing out after 15 minutes,
>an error message "time out (900 secs) - lost connection"
>is shown.
>
Get your system administrator to look at the ftp entry in /etc/inted.conf.
The "-T" option on the ftp daemon (ftpd) may be set to 900 seconds in
that file.

Good luck.

Ian
-- 
+---------------------------------+----------------------------------------+
|  Ian Wade                       | e-mail:  ian @ g3nrw.demon.co.uk       |
|  7 Daubeney Close, Harlington,  | AMPRnet: g3nrw.ampr.org [44.131.5.147] |
|  Dunstable, Beds, LU5 6NF, UK.  | AX.25:   G3NRW @ GB7BIL.#27.GBR.EU     |
+---------------------------------+----------------------------------------+

-----------[000428][next][prev][last][first]----------------------------------------------------
Date:      Tue, 28 Dec 1993 10:40:18 -0800
From:      Mark Crispin <mrc@Ikkoku-Kan.Panda.COM>
To:        comp.protocols.tcp-ip, mckee@pacs.sunbelt.net
Subject:   re: Post Office Protocols on RS6000

Pine can operate as an IMAP2bis client, and runs on an IBM RS/6000.  Look on
ftp.cac.washington.edu, file mail/pine.tar.Z

Also, the IMAP toolkit has IMAP2bis, POP2, and POP3 servers.  mail/imap.tar.Z
on the ftp.cac.washington.edu server.


-----------[000429][next][prev][last][first]----------------------------------------------------
Date:      Mon, 27 Dec 1993 22:56:22 GMT
From:      jeffb@world.std.com (Jeffrey T Berntsen)
To:        comp.os.ms-windows.apps,comp.os.ms-windows.misc,comp.protocols.ppp,comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc,comp.windows.ms
Subject:   Re: WYSE-50 Terminal Emulation w/ TCP/IP Support

hruska@bmcwest.com (Paul Hruska) writes:

>I am looking for a terminal emulation program for Windows 3.1 that supports 
>Wyse-50 escape sequences and will operate with TCP/IP (Winsock).
 
>I hope there is such a critter out there.
 
>If you know of one can you let me know?
 
>Thanks,
>	Paul

You didn't mention if you were looking for free, shareware, or commercial
programs.  I don't know of any free or shareware packages that will do what
you want but I know of two commercial programs that claim to.  One is Century
Software's Term for Windows and the other is Falco's Pipeline.  Both are seen
advertised in Unix Review magazine.

Jeff Berntsen
jeffb@world.std.com


-----------[000430][next][prev][last][first]----------------------------------------------------
Date:      Mon, 27 Dec 93 23:17:23 GMT
From:      ftlofaro@unlv.edu (Frank Lofaro)
To:        comp.protocols.tcp-ip
Subject:   Re: tricky address: 127.0.0.1

In article <CIIHzr.D4G@rice.edu> dboyes@is.rice.edu (David E Boyes) writes:
>In article <2fat4e$l4n@samba.oit.unc.edu> Kiran.Gop@launchpad.unc.edu (kiran gop) writes:
>>the address 127.0.0.1 refers to ur local host!!!!!
>>finger this address, and u get the list of usrs at ur machine.//.
>>whats the catch behind this??? why does this address always refer to
>>*your* machine??
>>Cound anyone mail me the reason?
>
>Because the specification for IP says to. 127.0.0.1 is the
>loopback address and should never actually generate anything on
>the wire.
>

Umm, isn't 127.x.x.x with x anything supposed to be loopback??
What does the spec say?
Although most people just use 127.0.0.1.

Some TCP/IP implementations will send out over the net a 127.0.0.2, for example!

I pinged 127.0.0.2 from a system here in Las Vegas, and it made it all the way 
to San Diego before getting chucked with an ICMP Unreachable!

That is weird.

Is that a bug? I think it should never have gotten out, it should've been 
looped back.

Linux treats all 127.x.x.x addresses as loopback, IMHO the correct behavior.
Most other un*xes do not.

BTW: PC/TCP's telnet client will send 127.0.0.1 over the net! I did a telnet 
127.0.0.1 from an PC a while back, and got connected to the login prompt of 
a router just a couple of hops from the backbone! So much for PC/TCP! 


-----------[000431][next][prev][last][first]----------------------------------------------------
Date:      Tue, 28 Dec 1993 03:15:49 GMT
From:      mat@phx.mcd.mot.com (mat)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP/IP in Unix

In article <1993Dec27.141310.28639@newstand.syr.edu> alhajery@newstand.syr.edu (Eyas S. Al-Hajery) writes:
>
>
>I have posted a question long time ago, about the implementation of TCP/IP in
>a Unix-based system (such as Sun's Sparc stations).  I understood based on
>my reading in Clark's book, "Internetworking with TCP/IP, Vol II"  that TCP is
>implemented as a running process, so when an application process wants to send (or
>receive) data through the network, it would call the socket interface, which then
>call the TCP process. So the OS will context switch between the application process and the TCP.  I received then from someone who said that the implementation of TCP/IP as a process is an old approach, it is not used nowadays,
>but he didn't mentioned what is the "new" approach in implementing TCP/IP.
>
>So, if anyone has information on the implementation of TCP/IP within the existing
>systems, I'd appreciate if he (or she) would help me in that regard ...
>Thanks.
>
>  E. Alhajery
>

  All of the Unix implementations I've been exposed to (or ones that
have exposed themselves to me) are kernel based (part of the O/S).  Non-
SVR4 systems usually have function call interfaces between the protocol
modules.  SVR4 usually uses STREAMS protocol modules and drivers.  The
socket interface can be in a user-level library, or part of the kernel
resident portion.

Mat Cucuzella
mat@phx.mcd.mot.com

[ My opinions are my own (like... whose else would they be!) ]

-----------[000432][next][prev][last][first]----------------------------------------------------
Date:      Tue, 28 Dec 1993 03:33:29 GMT
From:      james@kaiwan.com (James - The Keeper)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject:   Re: Wireless PC to PC communication

In article <1993Dec25.003515.1705@cjbsys.bdb.com>,
cliff bedore <cliffb@cjbsys.bdb.com> wrote:
=In article <ssykes.43.2D1A24B4@netcom.com> ssykes@netcom.com (Steve Sykes) writes:
=>In article <1993Dec23.174637.3499@cse.iitb.ernet.in> yadav@cse.iitb.ernet.in (Yadav Navneet ) writes:
=>>hi,
=>>        can i have any info on wireless communication between pcs using
=>>tcpip protocol. is there already any implentation of the same and if so
=>>where can i get details on it. i need to know both hardware and software
=>>details. if not tcpip then is there any implementation using some other
=>>protocols ?  
=>
=>How about packet radio?
=
=I was at FedUNIX here in Washington a couple of weeks ago and got some info
=from NCR about their WaveLAN product.  The demo with a portable PC was quite
=impressive.
=
=Has ISA, Microchannel and PCMCIA cards. Supports IPX, ODI, NDIS, Lantastic, and
=Banyon Vines. 
=
=2 Mb/s with a range of up to 800 feet.

I use a pair of them and a pair of NE2000 clone to build remote bridges.
Their ping time is 4 ms and FTP bandwidth test is 56K(in the closed
office space, about 100 feet apart.

The only problem during my testing is it needs to be reboot every couple
days. Have not figure out the problems yet.

You can request the info from 800-422-1627.

It costs about $600.00 each and ~$300.00 for a line of sight
directional antenna(5 miles).

=
=Above from spec sheet.  Only saw the one demo but it did look nice.
=
=Unfortunately the spec sheet did not have a phone number
=
=Cliff
=
=
=-- 
=Cliff Bedore
=7403 Radcliffe Dr. College Park MD 20840
=cliffb@cjbsys.bdb.com
=


-- 
info@kaiwan.com,Anonymous FTP,Telnet kaiwan.com(192.215.30.2)FAX#714-638-0455 
DATA# 714-539-0829,830-6061,310-527-4279 818-579-6701 16.8k/14.4k 8-N-1
ZyXEL U-1496E 16.8K: $279.00, U-1496E+ 19.2K: $389.00 Voice/FAX/Data Modems
AT&T DATA Port 14.4K: $189.00(Int) $209(Ext) w/ QuickLink II, FAX/DATA Modems

-----------[000433][next][prev][last][first]----------------------------------------------------
Date:      Tue, 28 Dec 1993 04:02:35 GMT
From:      jsaker@cwis.unomaha.edu (James R. Saker Jr.)
To:        misc.forsale.computers.other,comp.protocols.tcp-ip
Subject:   Wanted: NCR Tower 5000 TCP/IP and Ethernet

I've got a NCR Tower 5000 (actually a Sperry 5000/50, but apparently
a NCR tower underneath) which despite it's slow 68020, would make
a nice firewall/communications server/coat-rack in our TCP/IP
network. However, the installation does not have TCP/IP software 
nor ethernet hardware present. 

Since the system is well past the decommissioning point for many
folks, I'm curious if someone would have the software and hardware
off of a used system available for a reasonable price so that we
might find some use for the system.

JRS

.  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .
.  Jamie Saker					jsaker@cwis.unomaha.edu    .
.  Chief Operating Officer			Business/IS Major	   .
.  Synergistic Communications			Univ. Nebraska at Omaha    .
.  voice: (402) 680-8280						   .
.  fax: (402) 451-1530							   .
.  Disclaimer: The opinions expressed here are mine and not my employers,  .
.              nor the University of Nebraska at Omaha's. 		   .
.  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .





-----------[000434][next][prev][last][first]----------------------------------------------------
Date:      28 Dec 1993 09:09:57 GMT
From:      jeg@gronja.kymmene.fi
To:        comp.protocols.tcp-ip
Subject:   CompuServe access

Sorry if this is FAQ or in wrong group (which probably is the 
case :). Is it possible access CompuServe-network from Internet. 
And I don't mean mail, I want files. Can we use FTP (on what 
IP-address) ? What kind of uid's we'd use in this case (we have 
already some uid's to CompuServe, used with phone access) ?

Thanks in Andvance,
jeg

Jan-Erik Gron           E-mail: kymmene.kh.gronja@elvi.vtkk.fi
Kymmene Corporation     Fax:    +358-51-402 2241
Finland, Europe         Phone:  +358-51-402 2314

-----------[000435][next][prev][last][first]----------------------------------------------------
Date:      28 Dec 1993 15:17:56 GMT
From:      csfed@mrcnext.cso.uiuc.edu (Frank Doss)
To:        comp.protocols.tcp-ip
Subject:   Re: Post Office Protocols on RS6000

mckee@pacs.sunbelt.net wrote:
: Does anyone have working POP2, POP3 and IMAPD clients on an
: IBM RS6000?  A client is in need of them.
 
: Thanks,
 
: Tim McKee
: Manager, SunBelt.Net

Try ftp.cts.eiu.edu in the subdir /pub/rs6000.  The binary there
works under 3.2.  Also, you will find installation notes and source
in case you wish to compile it for yourself.  If you have problems
with it, you can let me know and I'll do what I can.  No promises.

-Frank
csfed@mrcnext.cso.uiuc.edu


-----------[000436][next][prev][last][first]----------------------------------------------------
Date:      Tue, 28 Dec 1993 17:26:36 GMT
From:      vjs@calcite.rhyolite.com (Vernon Schryver)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP/IP in Unix

>In article <1993Dec27.141310.28639@newstand.syr.edu> alhajery@newstand.syr.edu (Eyas S. Al-Hajery) writes:
>>
>>I have posted a question long time ago, about the implementation of TCP/IP in
>>a Unix-based system (such as Sun's Sparc stations).  I understood based on
>>my reading in Clark's book, "Internetworking with TCP/IP, Vol II that TCP is
>>implemented as a running process, so when an application process wants to send (or
>>receive) data through the network, it would call the socket interface, which then
>>call the TCP process. So the OS will context switch between the
>>application process and the TCP.  I received then from someone who
>>said that the implementation of TCP/IP as a process is an old
>>approach, it is not used nowadays,
>>but he didn't mentioned what is the "new" approach in implementing TCP/IP.
>> ...

In article <1993Dec28.031549.12802@phx.mcd.mot.com> mat@phx.mcd.mot.com (mat) writes:
>  All of the Unix implementations I've been exposed to (or ones that
>have exposed themselves to me) are kernel based (part of the O/S).  Non-
>SVR4 systems usually have function call interfaces between the protocol
>modules.  SVR4 usually uses STREAMS protocol modules and drivers.  The
>socket interface can be in a user-level library, or part of the kernel
>resident portion.

Maybe the other person was asking about the equivalent of the splnet()
soft or psuedo interrupt in BSD stacks and the STREAMS scheduler
in STREAMS implementations.

The word "context switch" is somewhat ambiguous.  It might refer to 
what happens when an interrupt happens, what happens
when the system switches from one official process to another, 
or what happens when the splnet or queue-service function is restarted.

Note that one reseasonably fast 4.3BSD system sometimes uses a "kernel
process" instead of straight splnet() to improve MP parallelism and reduce
"real-time" process latency.  I understand that another vendor that used
to ship 4.2BSD based TCP/IP once used a process instead of the simplest
netisr().  (By "kernel process" I mean an ordinary user process that has
executed a system call that never returns, something like the common buffer
cache flushers, pagers, or NFS daemons.)


Vernon Schryver    vjs@rhyolite.com

-----------[000437][next][prev][last][first]----------------------------------------------------
Date:      28 Dec 1993 21:29:18 GMT
From:      vbrard@frene (Vincent BRARD )
To:        comp.protocols.tcp-ip
Subject:   DOS TCP/IP as an IP GATEWAY ?

  I would like to use a PC under DOS to act as an IP GATEWAY between 2 networks
(an Ethernet network and an ISDN network). I have to use this PC as a normal
one. I cannot use it as a dedicated IP router.

  It seems that commercial DOS TCP/IP products cannot handle 2 networks
simultaneously ?

  Are there commercial, shareware or freeware products to do that ?

  Thanks, Damien.

  Please answer to dbillon@ireste.fr


-----------[000438][next][prev][last][first]----------------------------------------------------
Date:      Wed, 29 Dec 1993 03:18:41 GMT
From:      dyer@spdcc.com (Steve Dyer)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject:   Re: Wireless PC to PC communication

In article <CIq77u.In3@kaiwan.com>,
James - The Keeper <james@kaiwan.com> wrote:
>=I was at FedUNIX here in Washington a couple of weeks ago and got some info
>=from NCR about their WaveLAN product.  The demo with a portable PC was quite
>=impressive.
>=Has ISA, Microchannel and PCMCIA cards. Supports IPX, ODI, NDIS, Lantastic, and
>=Banyon Vines. 
>=2 Mb/s with a range of up to 800 feet.
>
>I use a pair of them and a pair of NE2000 clone to build remote bridges.
>Their ping time is 4 ms and FTP bandwidth test is 56K(in the closed
>office space, about 100 feet apart.
>The only problem during my testing is it needs to be reboot every couple
>days. Have not figure out the problems yet.

I'm using a pair of PCs with ethernet and WAVElan cards to connect a friend
who lives two (short) blocks away from me to the Internet.  They are running
PC-ROUTE and the PCs have never to my knowledge crashed (I set them up several
months ago, and turned the PC monitor off.)

Right now they're using the supplied mini-antennas, but the link is
occasionally somewhat lossy (unpredictably).  We plan to switch to
roof antennas RSN.

arktos.spdcc.com# ping -s ASTRUD.IECC.COM
PING astrud.iecc.com: 56 data bytes
64 bytes from ASTRUD.IECC.COM (140.186.80.9): icmp_seq=0. time=2. ms
64 bytes from ASTRUD.IECC.COM (140.186.80.9): icmp_seq=1. time=1. ms
64 bytes from ASTRUD.IECC.COM (140.186.80.9): icmp_seq=2. time=1. ms
64 bytes from ASTRUD.IECC.COM (140.186.80.9): icmp_seq=3. time=1. ms
64 bytes from ASTRUD.IECC.COM (140.186.80.9): icmp_seq=4. time=1. ms
64 bytes from ASTRUD.IECC.COM (140.186.80.9): icmp_seq=5. time=1. ms
^C
----ASTRUD.IECC.COM PING Statistics----
6 packets transmitted, 6 packets received, 0% packet loss
round-trip (ms)  min/avg/max = 1/1/2

-- 
Steve Dyer
dyer@ursa-major.spdcc.com

-----------[000439][next][prev][last][first]----------------------------------------------------
Date:      29 Dec 93 04:06:32 GMT
From:      jeff@athena.tay.dec.com (Jeff S. Tyler)
To:        comp.protocols.tcp-ip
Subject:   Looking for slip/ppp for ISC 2.2

I have ISC 2.2 with TCP/IP 1.2 installed.  I am trying to find a working
ppp or slip implementation (free or at least cheap :-) for it.  The
ethernet based tcp/ip is ok (not real fast but it serves) but the slip
included appears to be totally broken.  If anyone out there has been
successful in getting this version of ISC slip to work I'd like to hear
about it.  If someone is knows of a PD slip or ppp that is buildable on ISC
and it's streams based interface I'd like to know about that also. 

Thanks in advance.......

--
Jeff S. Tyler
Decathena

-----------[000440][next][prev][last][first]----------------------------------------------------
Date:      Wed, 29 Dec 1993 08:41:56 GMT
From:      prati@iitb.ernet.in (Pratima Sethi)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject:   ka9q latest version (Q)

	What is the latest version of ka9q for Xenix ? Where is it available ?
Is there any programming level documentaion available for ka9q ?
I have to port TCP/IP on an old Intel 320 machine with OS Intel Xenix 386.
Is there any other public domain TCP/IP s/w that could be more suitable ?

Thanks,

please reply by mail at
	prati@iitb.ernet.in

--Pratima Sethi.




-----------[000441][next][prev][last][first]----------------------------------------------------
Date:      Wed, 29 Dec 1993 09:06:59 GMT
From:      jar@mikrolog.fi (Jari Artes)
To:        comp.protocols.tcp-ip,comp.unix.sys5.r4
Subject:   bootp 2.2.c & arp & svr4.0

Hello netters,
I need BOOTP 2.2.C code for ICL and Motorola SVR4. The code already has
#ifdefs for SVR4 so I had no problems creating the binary.
But: bootpd couldn't create an entry in the ARP cache. The following
is an example:
 
bootpd: information(6): request from Ethernet address 0000C04A4426
bootpd: information(6): found 192.89.31.123 jar
bootpd: information(6): vendor magic field is 67.77.85.0
bootpd: information(6): sending reply (with CMU options)
bootpd: information(6): setarp 192.89.31.123 0000C04A4426 (l=6)
bootpd: error(3):       ioctl(SIOCSARP): Invalid argument

Here's the code that creates the entry:

/*
 * Setup the arp cache so that IP address 'ia' will be temporarily
 * bound to hardware address 'ha' of length 'len'.
 */
setarp(ia, ha, len)
        struct in_addr *ia;
        byte *ha;
        int len;
{
        struct sockaddr_in *si;
        int d;

    if (debug > 1)
        report(LOG_INFO, "setarp %s %s (l=%d)\n",
               inet_ntoa(*ia), haddrtoa(ha, 1), len);

        bzero((caddr_t)&arpreq, sizeof(arpreq));
    arpreq.arp_flags = ATF_INUSE | ATF_COM;

    /* Set up the protocol address. */
        arpreq.arp_pa.sa_family = AF_INET;
        si = (struct sockaddr_in *) &arpreq.arp_pa;
        si->sin_addr = *ia; 

    /* Set up the hardware address. */
        bcopy(ha, arpreq.arp_ha.sa_data, len);

    /* XXX - Why does this fail on Solaris 2.X ? (ENXIO) */
        if (ioctl(s, SIOCSARP, (caddr_t)&arpreq) < 0) {
            report(LOG_ERR, "ioctl(SIOCSARP): %s\n", get_network_errmsg());
        }
}

There is an alternative way of creating ARP entries but I 
couldn't find it after several RTFM sessions. arp(7) mentions 
the device /dev/arp but it doesn't work with the socket ioctls. 

Jari

--
Jari Artes 	jari.artes@mikrolog.fi

-----------[000442][next][prev][last][first]----------------------------------------------------
Date:      Wed, 29 Dec 1993 12:31:54 GMT
From:      mark@cyantic.com (Mark T. Dornfeld)
To:        comp.protocols.tcp-ip
Subject:   Public domain NFS for SCO UNIX 3.2r2

Is there a PD version of NFS for SCO UNIX 3.2r2?  I have SCO's TCP, but
would like to avoid having to upgrade or purchase an NFS right now.

Thanks
-- 

Mark T. Dornfeld, CYANTIC Systems             Voice: (416) 234-9048
101 Subway Crescent Suite 2103                Facsimile: (416) 234-0477
Etobicoke, Ontario, M9B 6K4 CANADA            Email: mark@cyantic.com

-----------[000443][next][prev][last][first]----------------------------------------------------
Date:      28 Dec 1993 23:35:51 +1030
From:      hart@apanix.apana.org.au (Leigh Hart)
To:        comp.protocols.tcp-ip
Subject:   Re: Telnet Question...

sobi0268@mary.cs.fredonia.edu (Kevin V. Sobilo) writes:


>Here's one for all the telecom gurus out there... I am trying to impliment
>a version of telnet in C++ as a 1st step in a project I am workin on.
>Well, I have read a lot about the telnet protocl in various RFCs etc...
>but I am unable to see how a "login" is instantiated... I understand
>how to negotiate a connection, but do not see how to initiate the login.
 
>Any help toward clueing me in is greatly appreciated...

The telnet login port is 23, establish a connection to that port on the
remote machine, negotiate options, and let the data flow :)

Cheers

Leigh
-- 
                                 Leigh Hart
                               C/- PO Box 758
                          North Adelaide  SA  5006
 hart@eppie.apana.org.au  hart@apanix.apana.org.au  hart@cleese.apana.org.au

-----------[000444][next][prev][last][first]----------------------------------------------------
Date:      Wed, 29 Dec 1993 17:10:06 GMT
From:      perlman@zeno.fit.edu (Marshal Perlman [ARCS])
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject:   Re: ka9q latest version (Q)

The old one seems to work fine for me.
-- 
  |o| Marshal Perlman                     Internet: perlman@zeno.fit.edu |o|
  |o| Academic and Research Computing Services (ARCS)        IRC: Squawk |o|
  |o| Florida Institute of Technology                    FAA: PP-ASEL-IA |o|
  |o| Pager: 407/455-4809          Member: AOPA/AAAE/Goodyear Blimp Club |o|

-----------[000445][next][prev][last][first]----------------------------------------------------
Date:      Wed, 29 Dec 1993 18:36:41 GMT
From:      bvj@novell.com (B.V. Jagadeesh)
To:        comp.protocols.tcp-ip
Subject:   How to connect to internet - Need help!!

Hi -

Sorry, if this was posted before. A friend of mine( small company) wants
to get a connection to internet. He doesn't want a connection like
user_name@netcom.com, instead he wants to user_name@his_company_name.com.

Any help is appreciated.

Thanks
/Jagadeesh

-----------[000446][next][prev][last][first]----------------------------------------------------
Date:      Wed, 29 Dec 1993 21:17:40 GMT
From:      stevea@lachman.com (Steve Alexander)
To:        comp.protocols.tcp-ip,comp.unix.sys5.r4
Subject:   Re: bootp 2.2.c & arp & svr4.0

In article <CIsHBo.uE@mikrolog.fi> jar@mikrolog.fi (Jari Artes) writes:
>There is an alternative way of creating ARP entries but I 
>couldn't find it after several RTFM sessions. arp(7) mentions 
>the device /dev/arp but it doesn't work with the socket ioctls. 

To access /dev/arp, you must use a STREAMS I_STR ioctl (see streamio(7)), which
basically involves packaging the arguments to ioctl in a strioctl structure.
Here's code that retrieves an ARP entry, which should be easily adaptable
to settting the ARP entry.  You'll probably need to change /dev/inet/arp to
/dev/arp.

#include <sys/types.h>
#include <sys/stream.h>
#include <stropts.h>
#include <sys/ioctl.h>
#include <sys/socket.h>
#include <net/if.h>
#include <netinet/in.h>
#include <net/if_arp.h>
#include <arpa/inet.h>
#include <fcntl.h>
#include <stdlib.h>
#include <stdio.h>

error(s)
	char *s;
{
	perror(s);
	exit(1);
}

main(argc, argv)
	int argc;
	char **argv;
/* ARGSUSED */
{
	int s;
	int r;
	struct strioctl si;
	u_char *ap;
	struct arpreq a;
	struct sockaddr_in *ip;
	struct sockaddr *mac;

	s = open("/dev/inet/arp", O_RDWR);

	if (s < 0) {
		error("/dev/inet/arp");
	}

	bzero((char *)&a, sizeof(a));

	ip = (struct sockaddr_in *) &(a.arp_pa);
	mac = (struct sockaddr *) &(a.arp_ha);

	ip->sin_family = AF_INET;
	ip->sin_addr.s_addr = inet_addr("198.242.192.67");
	mac->sa_family = AF_UNSPEC;
	a.arp_flags = 0;

	si.ic_cmd = SIOCGARP;
	si.ic_dp = (char *)&a;
	si.ic_len = sizeof(a);
	si.ic_timout = -1;

	r = ioctl(s, I_STR, (char *)&si);
	if (r < 0) {
		error("ioctl");
	}

	ap = (u_char *)mac->sa_data;
	printf("macaddr = %02x:%02x:%02x:%02x:%02x:%02x\n",
		ap[0], ap[1], ap[2], ap[3], ap[4], ap[5]);

	exit(0);
	/* NOTREACHED */
}
-- 
Steve Alexander, Lachman Technology, Inc. | stevea@lachman.com
(708) 505-9555 x256 FAX: (708) 505-9574	  | ...!{sun,ico}!laidbak!stevea

-----------[000447][next][prev][last][first]----------------------------------------------------
Date:      Thu, 30 Dec 1993 02:20:42 GMT
From:      sysseh@devetir.qld.gov.au (Steve Hocking)
To:        comp.protocols.tcp-ip,comp.unix.sys5.r4
Subject:   Re: bootp 2.2.c & arp & svr4.0

	Isaw similar problems on (of all things)  AIX once, before it was
shipped with bootp. What turned out to be the problem there was that the
address length filed & protocol were not set, and so AIX, which seemed to be
a bit stricter about these things than many other kernels, complained. It'll
probably be 6 in both cases. You can search for the appropraite defines in
the header files, something like IPPROTO or somesuch.
--

	Cheers,

	Stephen

-----------[000448][next][prev][last][first]----------------------------------------------------
Date:      Thu, 30 Dec 1993 03:42:18 GMT
From:      callewis@netcom.com (David Scott Lewis)
To:        comp.protocols.appletalk,comp.protocols.ibm,comp.protocols.iso,comp.protocols.pcnet,comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject:   FREE E-Newsltr on Advances in Compunications

* * *  P R E S S   R E L E A S E  * * *  P R E S S   R E L E A S E  * * *

B R I E F   R E L E A S E

FREE NEWSLETTER

Free, electronic newsletter features article summaries on new generation
computer and communications technologies from over 100 trade magazines
and research journals; key U.S. & international daily newspapers, news
weeklies, and business magazines; and, over 100 Internet mailing lists &
USENET groups.  Each monthly issue includes listings of forthcoming &
recently published technical books and forthcoming shows & conferences. 
Bonus: Exclusive interviews with technology pioneers.  E-mail
subscription requests to: listserv@ucsd.edu  (Leave the "Subject" line
blank.)  In the body of the message, type: SUBSCRIBE HOTT-LIST (do not
include first or last names)


* * *  P R E S S   R E L E A S E  * * *  P R E S S   R E L E A S E  * * *

G E N E R A L   R E L E A S E

HOTT -- Hot Off The Tree -- is a FREE monthly electronic newsletter 
featuring the latest advances in computer, communications, and
electronics technologies.  Each issue provides article summaries on
new & emerging technologies, including VR (virtual reality), neural
networks, PDAs (personal digital assistants), GUIs (graphical user
interfaces), intelligent agents, ubiquitous computing, genetic &
evolutionary programming, wireless networks, smart cards, video phones,
set-top boxes, nanotechnology, and massively parallel processing.  

Summaries are provided from the following sources:

Wall Street Journal, New York Times, Los Angeles Times, Washington Post, 
  San Jose Mercury News, Boston Globe, Financial Times (London) ...
 
Time, Newsweek, U.S. News & World Report ...

Business Week, Forbes, Fortune, The Economist (London), Nikkei Weekly 
  (Tokyo), Asian Wall Street Journal (Hong Kong) ...

over 50 trade magazines, including Computerworld, InfoWorld, Datamation,
  Computer Retail Week, Dr. Dobb's Journal, LAN Times, Communications
  Week, PC World, New Media, VAR Business, Midrange Systems, Byte ...

over 50 research journals, including ** ALL ** publications of the IEEE
  Computer and Communications Societies, plus technical journals
  published by AT&T, IBM, Hewlett Packard, Fujitsu, Sharp, NTT, Siemens,
  Philips, GEC ...

over 100 Internet mailing lists & USENET discussion groups ...

plus ...

* listings of forthcoming & recently published technical books;
  
* listings of forthcoming trade shows & technical conferences; and,

* company advertorials, including CEO perspectives, tips & techniques,
  and new product announcements

BONUS:

Exclusive interviews with technology pioneers ... the next two issues
feature interviews with Mark Weiser (head of Xerox PARC's Computer
Science Lab) on ubiquitous computing, and Nobel laureate Joshua Lederberg
on the information society


TO REQUEST A FREE SUBSCRIPTION, CAREFULLY FOLLOW THE INSTRUCTIONS BELOW

Send subscription requests to:
  listserv@ucsd.edu

Leave the "Subject" line blank

In the body of the message input:
  SUBSCRIBE HOTT-LIST

If at any time you choose to cancel your subscription input:
  UNSUBSCRIBE HOTT-LIST

Note: Do *not* include first or last names following 
      "SUBSCRIBE HOTT-LIST"  or  "UNSUBSCRIBE HOTT-LIST"

The HOTT mailing list is automatically maintained by a computer located
at the University of California at San Diego.  The system automatically
responds to the sender's return path.  Hence, it is necessary to send
subscription requests and cancellations directly to the listserv at UCSD.
(I cannot make modifications to the list ... nor do I have access to the
list.)  For your privacy, please note that the list will not be rented. 
If you have problems and require human intervention, contact:
  hott@ucsd.edu

The next issue of the reinvented HOTT e-newsletter is scheduled for
transmission in late January/early February.

Please forward this announcement to friends and colleagues, and post to
your favorite bulletin boards.  Our objective is to disseminate the
highest quality and largest circulation compunications (computer &
communications) industry newsletter.

I look forward to serving you as HOTT's new editor.  Thank you.
-- 
    ***********************************************************************
    *  David Scott Lewis                                                  *
    *  Editor-in-Chief and Book & Video Review Editor                     *
    *  IEEE Engineering Management Review                                 *
    *   (the world's largest circulation "high tech" management journal)  *
    *  Internet address: d.s.lewis@ieee.org      Tel: +1 714 662 7037     *
    *  USPS mailing address: POB 18438 / IRVINE CA 92713-8438  USA        *
    ***********************************************************************


-----------[000449][next][prev][last][first]----------------------------------------------------
Date:      30 Dec 1993 11:27:29 +0100
From:      zok@popp.ins.de (Andreas Frackowiak)
To:        comp.protocols.tcp-ip
Subject:   Re: DOS TCP/IP as an IP GATEWAY ?

vbrard@frene (Vincent BRARD ) writes:
>  It seems that commercial DOS TCP/IP products cannot handle 2 networks
>simultaneously ?
 
>  Are there commercial, shareware or freeware products to do that ?

I know of KA9Q, Pcroute  and IP-SWITCH as DOS-TCP/IP-Routers, but they
need a dedicated PC. (You may can experiment with some multitaskers).

I have heard of Chamaeleon TCP that routes "in background", but it is
not a DOS but a MS-Windows application.

Andreas

-- 
Andreas                                        Inter Networking Systems
Frackowiak                                     Internet Services & Consulting
af@ins.de                                      FAX: +49-2305-25411
                                               info@ins.de

-----------[000450][next][prev][last][first]----------------------------------------------------
Date:      30 Dec 1993 13:57:00 GMT
From:      jasonh@chineham.euro.csg.mot.com (Jason Haar)
To:        comp.protocols.tcp-ip
Subject:   Australian file transfer program - help?

Hi,

Last year (1992 ;-) I heard about a program some bright spark had written in
Aussie that allowed users to send files to each other without knowing 
passwords (not Email/rcp/...).

Apparently the format is something like "sendfile file.dat usercode@host" - it
was based on some Bitnet package, but was rewritten for TCP/IP, and used a
spooling area on the receiving host where the end user could pick up the files.

At the time I had no use for it, but now it would fix a current problem quite
well...

Anyone know what I'm talking about? (it'll make a change...)


Cheers,

Jason
+------------------------------+------------------------------------------+
| Jason Haar, European SysAdmin   Phone: + 44 (256) 790111                |
| Motorola Cellular Subscriber      Fax: + 44 (256) 817481                |
| Basingstoke, Hampshire                                                  |
| RG24 0GY,  ENGLAND           Internet: jasonh@chineham.euro.csg.mot.com |
 +------------------------------+------------------------------------------+

-----------[000451][next][prev][last][first]----------------------------------------------------
Date:      Thu, 30 Dec 1993 16:01:37 GMT
From:      hacker@patagonia.bellcore.com (Jonathan Hacker 21420)
To:        comp.protocols.tcp-ip
Subject:   Re: DOS TCP/IP as an IP GATEWAY ?

>vbrard@frene (Vincent BRARD ) writes:
>>  It seems that commercial DOS TCP/IP products cannot handle 2 networks
>>simultaneously ?
 
>>  Are there commercial, shareware or freeware products to do that ?


You might want to investigate IBM's TCP/IP 2.0 for
OS/2 as I believe it has support for multiple network cards.

Try 800-IBM-CALL or 800-3-IBM-OS2 for more info (numbers 
only good in U.S.).

-- 
Jon Hacker                         |   OS/2 2.1
Bellcore, Red Bank NJ              |    
hacker@patagonia.bellcore.com      |   

-----------[000452][next][prev][last][first]----------------------------------------------------
Date:      30 Dec 1993 17:39:27 GMT
From:      pascoe@MathWorks.Com (Dave Pascoe)
To:        comp.protocols.tcp-ip
Subject:   Berkeley Packet Filter LANCE driver (Sun)

I'm trying to recompile my kernel to add the BPF enhancements (from
the tcpdump-2.2.1 package obtained from ftp.ee.lbl.gov) on a Sun
SPARC-10 running SunOS 4.1.3.

The problem I have is that I don't seem to have the source for the
link level device driver (if_le.c).  I have all the other pieces,
which seems kind of strange.  Doesn't Sun supply this as part of the
kernel sources?

I wonder how other people have managed to get BPF working in the Sun
kernel (i.e., where they got the right source code or what they
modified to get the link level device driver rebuilt).

Please e-mail responses and I'll summarize if there's enough interest.

==== Dave Pascoe ===================== pascoe@mathworks.com ==========
     The MathWorks, Inc.
     24 Prime Park Way, Natick, MA 01760
==== Tel: 508-653-2452 (x362) ==== Fax: 508-653-2997 =================

-----------[000453][next][prev][last][first]----------------------------------------------------
Date:      Thu, 30 Dec 1993 20:10:12 GMT
From:      jantypas@netcom.com (John Antypas)
To:        comp.protocols.tcp-ip
Subject:   Need appletalk packet driver

Hello again...

I need the old Appletalk localtalk packet driver for NOS/KA9q.  I see
many references to UCDavis but the file is no longer there.  Is there
a new packet driver or a new source for the old one.
-- 
John Antypas / 21st Century Software Walnut Creek CA
jantypas@soft21.s21.com


-----------[000454][next][prev][last][first]----------------------------------------------------
Date:      Thu, 30 Dec 1993 18:13:00 TUR
From:      <BILMIN@TREARN.BITNET>
To:        comp.protocols.tcp-ip
Subject:   A TCP/IP problem

Hello . First of all , I wish you a happy and prosperous new year .

I  have a problem with TCP/IP . I have 2 Alpha chip based workstations
connected by TCP/IP . I want to send some bytes from one to another
using C programming language . How can I do this ?

If possible , may you send a program (or programs) to me ?

Please write e-mail directly .

Thanks for your time and effort .

------------------------------------------------------------------------
-                   Res.Assis. Mustafa INCEOGLU                        -
-                                                                      -
- Ege University             *  Tel    : (90) 232 - 3887221 / 234      -
- Dept. of Computer Engin.   *  Tel    : (90) 232 - 3881080 / 234      -
- 35100 Bornova              *  Fax    : (90) 232 - 3887230            -
- IZMIR                      *  E-Mail : BILMIN AT TREARN.BITNET       -
- TURKEY                     *  E-Mail : BILMIN AT VM3090.EGE.EDU.TR   -
-----------------------------*------------------------------------------

-----------[000455][next][prev][last][first]----------------------------------------------------
Date:      Thu, 30 Dec 1993 22:13:18 GMT
From:      dick@gp.com (Richard Gill)
To:        misc.forsale.computers.other,comp.protocols.tcp-ip
Subject:   Re: Wanted: NCR Tower 5000 TCP/IP and Ethernet

In article <jsaker.757051355@cwis> jsaker@cwis.unomaha.edu (James R. Saker Jr.) writes:
>...
>Since the system is well past the decommissioning point for many
>folks, I'm curious if someone would have the software and hardware
>off of a used system available for a reasonable price so that we
>might find some use for the system.
>
>JRS
>
Give Chuck McDonald at Harwood International a call; 615-870-5500
They specialize in used NCR equipment and know what they are
talking about :-)



-- 
----*----*----*----*----*----*----*----*----*----*----*----*----*----*----*
Dick Gill                                              dick@gp.com
Gill & Piette, Inc                                     uunet!gandp!dick
1568 Spring Hill Road, McLean, VA 22102                 (703)761-1163

-----------[000456][next][prev][last][first]----------------------------------------------------
Date:      Thu, 30 Dec 1993 23:29:57 GMT
From:      leo@elmail.co.uk (E.J.Leoni-Smith)
To:        comp.protocols.tcp-ip
Subject:   Re: How to connect to internet - Need help!!

In article <1993Dec29.183641.14583@novell.com> bvj@novell.com (B.V. Jagadeesh) writes:
>Hi -
>
>Sorry, if this was posted before. A friend of mine( small company) wants
>to get a connection to internet. He doesn't want a connection like
>user_name@netcom.com, instead he wants to user_name@his_company_name.com.
>
>Any help is appreciated.

If he is in Europe, get him to e-mail me. We will advise on commercial Internet
connections. If outside of Europe, we probably can't help.

>
>Thanks
>/Jagadeesh



-----------[000457][next][prev][last][first]----------------------------------------------------
Date:      Fri, 31 Dec 1993 00:20:51 +0000
From:      seamus@fastnsys.demon.co.uk ("Sean K. Sprague")
To:        comp.protocols.tcp-ip
Subject:   KA9Q....



Dear Reader,

I am running AT&T SVR4.3.[01] on an AT&T StarServer E, and would very
much like to hear from anyone who has successfully ported KA9Q to
either this operating system or to generic SVR4, or if anyone knows an
ftp site which either has this or an equivalent product in a form that
would compile up on SVR4 without too much tweaking, as the closest I
have come is sources oriented towards Borland Turbo C, which will take
me until Xmas 1994 to hack.

Many thanks in anticipation,


Seamus.
-- 
===============================================================================
Sean K. Sprague ("Seamus")            E-Mail: seamus@fastnsys.demon.co.uk
    Fastnet Systems PLC
    126-127 Shoreditch High St.       "I'd rather have a full bottle
    London E1 6JE                        in front of me, than a full
    Tel: +44-71-739-3332 (voice)         frontal lobotomy."
         +44-71-739-1566 (fax)
===============================================================================

-----------[000458][next][prev][last][first]----------------------------------------------------
Date:      Fri, 31 Dec 1993 01:45:05 GMT
From:      csmoko@relay.nswc.navy.mil (Chuck Smoko - E81)
To:        comp.protocols.tcp-ip
Subject:   Re: Multiple IP Addresses on the Same Interface

Dan,
I found this posting in my archives.  It describes just what you want.
I have it working, on Sunos 4.1.X w/ some small changes.  If you want
to runs on sunos, I can send the changes on request.

						chuck smoko

PS: I am posting because your e-mail address seems hosed, and I think
others may be interested.

> From ji Mon Feb 17 17:39:51 EST 1992
> From: ji@polaris.ctr.columbia.edu (John Ioannidis)
Subject: Multiple IP addresses on a single Ethernet interface
Date: 13 Feb 92 19:33:56 GMT
Status: OR

This is a topic that comes up once in a while on comp.protocols.tcp-ip
and other newsgroups. The question is, how to get a machine with one
network interface to respond to more than one IP addresses. 

The other day, a colleague forwarded to me a request from the
namedroppers mailing list for exactly that. Here's my response:

> In article <1992Feb1.082712.18549@mahler.ntt.jp> hitoaki@mahler.ntt.jp (Hitoaki Sakamoto) writes:
>    >In article <216@pivot.sbi.com> jordan@pivot.sbi.com (kuo-lin Hu) writes:
>    > >But it is just out of my curiousity that whether it is possible
>    > >I can assign dual IP addresses to a single controller?
 
>    >No,you can't.
> 
> Is this restriction common among UNIX TCP/IP implementations?
> Has anybody tried to modify this?
> 
> -- Kenji
> --
> Kenji Rikitake 
> kenji@macrofield.or.jp // kenji@macrofield.org // ...!uunet!reseau!kenji 

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

-----------[000459][next][prev][last][first]----------------------------------------------------
Date:      Fri, 31 Dec 1993 02:14:09 GMT
From:      demay@pyramid.unr.edu (Mark DeMay)
To:        comp.protocols.tcp-ip
Subject:   << Need Ethernet sniffer. HELP! >>


                        December 21, 1993

Hello,
    I am attempting to used GOBBLER.EXE V2.1 to debug some ethernet
stuff. It appears that V2.1 may have a problem reporting the Sequence
number and ack numbers. Example:

    REAL SEQ #          SEQ NUMBER REPORTED BY GOBBLER V2.1
    -----------         ------------------------------
    002DE601h           11520 = 2D00h

It appears that GOBBLER is pretty old. I found V2.0, and it works 
with respect to the sequence/ack numbers, but it doesn't report
the flags properly.

The 2.0 version is gobbler.zip  85239 bytes
The 2.1 version is gobbler.zip  118934 bytes

I've used archie to search for anything after V2.1. I found nothing.

Can anyone suggest an alternative E-net debugging tool similer to GOBBLER??

FTP software offers LanWatch, but they want about $1000 for it.

Thanks in advance,

    Mark DeMay  demay@cs.unr.edu


-- 
=:-O =:-O =:-O =:-O =:-O =:-O =:-O =:-O =:-O =:-O =:-O =:-O =:-O =:-O =:-O 
USENET News Administrator, University of Nevada, Reno  <news@news.unr.edu>
O-:= O-:= O-:= O-:= O-:= O-:= O-:= O-:= O-:= O-:= O-:= O-:= O-:= O-:= O-:= 

-----------[000460][next][prev][last][first]----------------------------------------------------
Date:      31 Dec 93 13:22:15
From:      dupuy@cs.columbia.edu (Alexander Dupuy)
To:        comp.unix.solaris,comp.unix.sys5.r4,comp.protocols.tcp-ip
Subject:   (not) getting ECONNREFUSED on UDP socket

On almost any system I have used that supports the BSD socket interface, if you
connect()ed your datagram UDP socket, then ICMP destination unreachable errors
would be reflected back as ECONNREFUSED/ENETUNREACH/EHOSTUNREACH errors on the
next recv().  However, on a Solaris 2.3 system, using the socket library, this
seems not to be the case.  Now I'm basically a Solaris fan - not one of those
"if it ain't BSD it's broken" folks, but not getting network errors reflected
up through the API, well, that's really broken!

Is there some trick to making this work on Solaris/SVR4/other sockets over
STREAMS implementations?  Is the problem that my call to select() after the
send won't return when the ICMP error arrives (even though I have the socket fd
in both the read and except fd_masks)?  Is it only possible to get the error if
I make a blocking recv() call?

There's something in the TLI documentation that claims that TLI endpoints will
get these errors, so it doesn't seem like the kernel is totally broken, but I'd
rather not have to use TLI, as the socket API is much more widespread.

Please send repsonses by mail, and I will summarize to the lists.

@alex
--
inet: dupuy@cs.columbia.edu
Member of the League for Programming Freedom -- write to lpf@uunet.uu.net

-----------[000461][next][prev][last][first]----------------------------------------------------
Date:      31 Dec 93 16:22:56
From:      dupuy@cs.columbia.edu (Alexander Dupuy)
To:        comp.unix.solaris,comp.unix.sys5.r4,comp.protocols.tcp-ip
Subject:   Re: (not) getting ECONNREFUSED on UDP socket

I wrote:
> There's something in the TLI documentation that claims that TLI
> endpoints will get these errors, so it doesn't seem like the kernel
> is totally broken, but I'd rather not have to use TLI, as the socket
> API is much more widespread.

I take that back.  I think the kernel really is totally broken!  I just wrote
two simple programs designed to elicit ICMP port unreachable errors; one uses
sockets, and the other uses TLI.  I use nonblocking sockets/TLI endpoints, and
use recv and getsockopt(...SO_ERROR...) to get socket error status, and
t_rcvuderr to get TLI endpoint socket error status.  The only combination of
sockets/TLI and SunOS 4/Solaris 2 that gets any error status is sockets/SunOS.
TLI doesn't see any error (other than EAGAIN) on SunOS or Solaris, and the UDP
TLI support from the TI-RPC unsupported package for SunOS doesn't get any
errors either.

I'm enclosing the two simple UDP datagram programs; I would be interested in
knowing if they can detect errors on other non-Sun systems (especially non-BSD
networking systems).  I would also welcome any pointers telling me what I'm
doing wrong, and that if I just do XYZ, these programs will work correctly.

@alex

p.s. I find it very amusing that the address format for TCP/UDP/IP TLI
endpoints is a sockaddr_in...

#!/bin/sh
: This is a shar archive.  Extract with sh, not csh.
: The rest of this file will extract: 
:
:	sock.c
:	tli.c
:
echo x - sock.c
sed 's/^X//' > sock.c << '//go.sysin dd *'
X#include <sys/types.h>
X#include <sys/socket.h>
X#include <netinet/in.h>
X#include <arpa/inet.h>
X#include <stdio.h>
X#include <fcntl.h>
X#include <errno.h>
X
Xint
Xmain (int argc, char **argv)
X{
X  char message[] = "Hello, World";
X  struct sockaddr_in addr;
X  int s;
X  int flags;
X  int optval;
X  int optlen;
X  int err;
X
X  s = socket (PF_INET, SOCK_DGRAM, 0);
X  if (s < 0)
X    perror ("socket");
X
X  flags = fcntl (s, F_GETFL, 0);
X  if (flags < 0)
X    perror ("fcntl F_GETFL");
X  flags |= O_NONBLOCK;
X  err = fcntl (s, F_SETFL, flags);
X  if (err < 0)
X    perror ("fcntl F_SETFL");
X
X  addr.sin_family = AF_INET;
X  addr.sin_port = 9999;
X  addr.sin_addr.s_addr = inet_addr (argv[1]);
X
X  err = connect (s, (struct sockaddr *) &addr, sizeof (addr));
X  if (err < 0)
X    perror ("connect");
X
X  err = send (s, message, sizeof (message), 0);
X  if (err < 0)
X    perror ("send");
X
X  sleep (1);
X
X  err = recv (s, message, sizeof (message), 0);
X  if (err < 0)
X    perror ("recv");
X
X  optlen = sizeof (optval);
X  err = getsockopt (s, SOL_SOCKET, SO_ERROR, (char *) &optval, &optlen);
X  if (err < 0)
X    perror ("getsockopt");
X
X  if (optval)
X    {
X      errno = optval;
X      perror ("socket error");
X    }
X
X  return 0;
X}
//go.sysin dd *
echo x - tli.c
sed 's/^X//' > tli.c << '//go.sysin dd *'
X#include <stdio.h>
X#include <fcntl.h>
X#include <tiuser.h>
X#include <sys/socket.h>
X#include <netinet/in.h>
X#include <arpa/inet.h>
X
Xint
Xmain (int argc, char **argv)
X{
X  char message[] = "Hello, World";
X  int t;
X  int err;
X  int flags;
X  struct t_unitdata *ud;
X  struct t_uderr *uderr;
X  struct sockaddr_in addr;
X
X  t = t_open ("/dev/udp", O_RDWR, 0);
X  if (t < 0)
X    t_error ("/dev/udp");
X
X  flags = fcntl (t, F_GETFL, 0);
X  if (flags < 0)
X    perror ("fcntl F_GETFL");
X  flags |= O_NONBLOCK;
X  err = fcntl (t, F_SETFL, flags);
X  if (err < 0)
X    perror ("fcntl F_SETFL");
X  
X  addr.sin_family = AF_INET;
X  addr.sin_port = 9999;
X  addr.sin_addr.s_addr = inet_addr (argv[1]);
X
X  err = t_bind (t, 0, 0);
X  if (err < 0)
X    t_error ("t_bind");
X
X  ud = (struct t_unitdata *) t_alloc (t, T_UNITDATA, T_ALL);
X  if (!ud)
X    t_error ("t_alloc");
X
X  ud->addr.maxlen = sizeof (addr);
X  ud->addr.len = sizeof (addr);
X  ud->addr.buf = (char *) &addr;
X
X  ud->opt.maxlen = 0;
X  ud->opt.len = 0;
X  ud->opt.buf = 0;
X
X  ud->udata.maxlen = sizeof (message);
X  ud->udata.len = sizeof (message);
X  ud->udata.buf = message;
X
X  err = t_sndudata (t, ud);
X  if (err < 0)
X    t_error ("t_sndudata");
X
X  sleep (1);
X
X  flags = 0;
X  err = t_rcvudata (t, ud, &flags);
X  if (err < 0)
X    t_error ("t_rcvudata");
X  
X  if (flags)
X    fprintf (stderr, "flags=%#x\n", flags);
X
X  uderr = (struct t_uderr *) t_alloc (t, T_UDERROR, T_ALL);
X  if (!uderr)
X    t_error ("t_alloc");
X
X  uderr->addr = ud->addr;
X  uderr->opt = ud->opt;
X  uderr->error = 0;
X
X  err = t_rcvuderr (t, uderr);
X  if (err < 0)
X    t_error ("t_rcvuderr");
X
X  fprintf (stderr, "error=%d\n", uderr->error);
X
X  return 0;
X}
//go.sysin dd *
exit
--
inet: dupuy@cs.columbia.edu
Member of the League for Programming Freedom -- write to lpf@uunet.uu.net

-----------[000462][next][prev][last][first]----------------------------------------------------
Date:      Fri, 31 Dec 1993 14:47:56 GMT
From:      dowd@acsu.buffalo.edu (Patrick Dowd)
To:        comp.protocols.tcp-ip
Subject:   CFP - ACM SIGCOMM'94




			   Call for Papers
		      ACM SIGCOMM'94 CONFERENCE
       Communications Architectures, Protocols and Applications
				   
		      University College London
			      London, UK
				   
		    August 31 to September 2, 1994
		 (Tutorials and Workshop, August 30)

An  international forum  on  communication  network  applications  and
technologies, architectures, protocols, and algorithms.

Authors are invited to submit  full  papers concerned with both theory
and practice. The areas of interest include, but are not limited to:
   --  Analysis and  design  of  computer  network  architectures  and
       algorithms, 
   --  Innovative results in local area networks,
   --  Mixed-media networks,
   --  High-speed networks, routing and addressing, support for mobile
       hosts, 
   --  Resource sharing in distributed systems,
   --  Network management,
   --  Distributed operating systems and databases,
   --  Protocol specification, verification, and analysis.

A   single-track,   highly  selective  conference   where   successful
submissions   typically  report   results  firmly   substantiated   by
experiment,  implementation,  simulation,  or  mathematical  analysis.
Papers must be less than 20 double-spaced pages long, have an abstract
of  100-150  words,  and  be  original  material  that  has  not  been
previously  published  or  be  currently  under  review  with  another
conference or journal.

In addition to its high  quality technical  program, SIGCOMM '94  will
offer  tutorials by  noted  instructors  such  as  Paul  Green and Van
Jacobson (tentative), and a workshop  on  distributed systems  led  by
Derek McAuley.

Important Dates:

          Paper submissions: 1 February 1994
         Tutorial proposals: 1 March 1994
 Notification of acceptance: 2 May 1994
    Camera ready papers due: 9 June 1994

All  submitted papers will  be  judged  based  on  their  quality  and
relevance through double-blind reviewing where  the  identities of the
authors are  withheld from  the  reviewers.  Authors names should  not
appear on the paper.  A cover letter  is  required that identifies the
paper title and lists the name, affiliation, telephone  number, email,
and fax number of all authors.

Authors of accepted papers need to sign an ACM copyright release form.
The  Proceedings will  be published as a  special issue of ACM SIGCOMM
Computer Communication  Review. The program committee will also select
a few papers for possible publication in the IEEE/ACM  Transactions on
Networking.

Submissions from North America should be sent  to:

     Craig Partridge
     BBN
     10 Moulton St
     Cambridge MA 02138

All  other submissions  should  be sent to:

     Stephen Pink
     Swedish Institute of Computer Science
     Box 1263
     S-164 28 Kista
     Sweden

Five copies are required for paper submissions. Electronic submissions
(uuencoded,  compressed  postscript)  should be  sent  to each program
chair. Authors should also e-mail the title, author names and abstract
of  their  paper  to  each  program  chair  and  identify  any special
equipment that will be  required during its  presentation.  

Due  to the  high  number  of  anticipated  submissions,  authors  are
encouraged to strictly adhere to the submission date.

Student  Paper Award:  Papers  submitted  by  students  will  enter  a
student-paper award contest.  Among the  accepted papers, a maximum of
four outstanding  papers  will be awarded full conference registration
and  a travel grant of $500  US dollars.   To  be eligible the student
must be the  sole author, or the first author and primary contributor.
A  cover  letter  must  identify  the  paper as  a candidate  for this
competition.


Mail and E-mail Addresses:

General Chair
-------------
    Jon Crowcroft
    Department of Computer Science
    University College London
    London WC1E 6BT United Kingdom

    Phone: +44 71 380 7296
    Fax: +44 71 387 1397
    E-Mail: J.Crowcroft@cs.ucl.ac.uk


Program Chairs
--------------
    Stephen Pink (Program Chair)
    Swedish Institute of Computer Science
    Box 1263
    S-164 28 Kista
    Sweden

    Phone: +46 8 752 1559
    Fax: +46 8 751 7230
    E-mail: steve@sics.se

    Craig Partridge (Program Co-Chair for North America)
    BBN
    10 Moulton St
    Cambridge MA 02138

    Phone: +1 415 326 4541
    E-mail: craig@bbn.com






-----------[000463][next][prev][last][first]----------------------------------------------------
Date:      Fri, 31 Dec 1993 21:45:07 GMT
From:      klos@mv.mv.com (Patrick Klos)
To:        comp.protocols.tcp-ip
Subject:   Re: << Need Ethernet sniffer. HELP! >>

In article <1993Dec31.021409.6748@news.unr.edu>,
Mark DeMay <demay@pyramid.unr.edu> wrote:
>
>                        December 21, 1993
>
>Hello,
>    I am attempting to used GOBBLER.EXE V2.1 to debug some ethernet
>stuff. It appears that V2.1 may have a problem reporting the Sequence
>number and ack numbers. Example:
>
>    REAL SEQ #          SEQ NUMBER REPORTED BY GOBBLER V2.1
>    -----------         ------------------------------
>    002DE601h           11520 = 2D00h
>
>It appears that GOBBLER is pretty old. I found V2.0, and it works 
>with respect to the sequence/ack numbers, but it doesn't report
>the flags properly.
>
>The 2.0 version is gobbler.zip  85239 bytes
>The 2.1 version is gobbler.zip  118934 bytes
>
>I've used archie to search for anything after V2.1. I found nothing.
>
>Can anyone suggest an alternative E-net debugging tool similer to GOBBLER??
>
>FTP software offers LanWatch, but they want about $1000 for it.
>
>Thanks in advance,
>
>    Mark DeMay  demay@cs.unr.edu
>
>
>-- 
>=:-O =:-O =:-O =:-O =:-O =:-O =:-O =:-O =:-O =:-O =:-O =:-O =:-O =:-O =:-O 
>USENET News Administrator, University of Nevada, Reno  <news@news.unr.edu>
>O-:= O-:= O-:= O-:= O-:= O-:= O-:= O-:= O-:= O-:= O-:= O-:= O-:= O-:= O-:= 

May I suggest our product called PacketView? It costs $299 and handles
ethernet, token-ring, ARCNET or FDDI.  It runs with either a packet driver
or an ODI driver that support promiscuous mode.  It has capture and dicplay
filters and can decode IPX/SPX/NCP, TCP/UDP/IP, SNMP, some BANYAN VINES, XNS
and AppleTalk.  It also allows the user to create their own protocol decoders,
and and import/export data between PacketView and both the Network General
Sniffer or LANWATCH.

A demo version of PacketView is available from out BBS at (603) 429-0032 or
via anonymous FTP at mv.mv.com:pub/users/klos/pvdemo.zip.

Feel free to call or email us if you have any questions.

Sincerely,

Patrick Klos
-- 
============================================================================
    Patrick Klos                           Internet: klos@mv.mv.com
    Klos Technologies, Inc.                Voice: (603) 424-8300
    604 Daniel Webster Highway             FAX:   (603) 424-9300
    Merrimack, New Hampshire  03054        BBS:   (603) 429-0032
============================================================================

-----------[000464][next][prev][last][first]----------------------------------------------------
Date:      Fri, 31 Dec 1993 22:45:52 +0000
From:      dhaslam@sirius.demon.co.uk (David Haslam)
To:        comp.protocols.tcp-ip
Subject:   TCP References in RFC1122 - where are they?


RFC1122 refers to the following papers:

> [TCP:6] "Round Trip Time Estimation," P. Karn & C. Partridge, ACM
>      SIGCOMM-87, August 1987.
>
>
> [TCP:7] "Congestion Avoidance and Control," V. Jacobson, ACM SIGCOMM-88,
>      August 1988.

Are these papers available by anonymous ftp?
If so, could someone suggest a site.

Thanks.

-- 
David Haslam
dhaslam@sirius.demon.co.uk

END OF DOCUMENT