# The 'Security Digest' Archives (TM)

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

ARCHIVE: TCP-IP Distribution List - Archives (1994)
DOCUMENT: TCP-IP Distribution List for July 1994 (573 messages, 459089 bytes)
SOURCE: http://securitydigest.org/exec/display?f=tcp-ip/archive/1994/07.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 Jul 1994 00:04:14 GMT
From:      rao@acsc.com (Rao Srinivasa)
To:        comp.protocols.tcp-ip
Subject:   Re: Max IP packet length and MTU

In article <2utmev$9o2@cherokee.advtech.uswest.com>, crohrer@advtech.uswest.com (Chris Rohrer) writes:|> Hi all, |> |> |> My real question is more like this: Will "typical" host IP software obey |> this 1500 byte restriction and tell its users (TCP, UDP and possibly other |> entities) that THEIR maximum "block" size is of that same approximate |> value (1500 minus the IP overhead)? Or will this "typical" IP software |> present a 64k-sized interface to its layer 4 users and take the initiative |> to do real header-mediated IP fragmentation down to the 1500 byte size? |> As far as I know IP does the fragmentation and assembling of the packets .... I look at it this way .. If I open an UDP socket and write data which is more than 1500 bytes it reaches the peer without any problem ... So either UDP or IP does this work ... If UDP does this work then it has to done by TCP too ... So I feel( that's not what you want though ..) IP does this work for both UDP and TCP. Lets wait for others say ...Mean while I will dig in to some UDP/IP books .. Rao.  -----------[000001][next][prev][last][first]---------------------------------------------------- Date: Fri, 01 Jul 94 08:32:45 PDT From: katherine.deforest@airdata.com To: misc.jobs.offered,comp.unix.solaris,comp.protocols.tcp-ip Subject: Seattle/Wireless Data Customer Engineer  McCaw Cellular's Wireless Data Division in Kirkland, WA is looking for a Customer Engineer to act as a pre-sales technical resource to leverage our exciting new wireless data products and services. This is an incredible opportunity to be a part of the wireless data revolution. Responsibilities: * Manage the technical customer relationship while actively participating in the design and implementation of a total customer solution. * Act as customer advocate within the customer organization, with hardware and software suppliers, and within McCaw. * Assist customers with application development and porting, as well as application integration, with both systems and networks. * Maintain relationships with multiple hardware and software developers and manufacturers. Qualifications: * Minimum of 5 years experience with computer hardware/software and data communications. * Strong knowledge of packet switching and router-based networking. * Experience with: TCP/IP and OSI protocols Apps development including: C, C++, GUI's, and host-based back-ends Integrating PC-based applications with LANS and WANS * Undergraduate degree in CS or Engineering * Proven customer relations and presentation skills. Salary and benefits are competitive and we will assist you, if necessary, in your move to the Northwest. Please send your resume by one of the following means: Email: katherine.deforest@airdata.com Fax: (206)803-4001 US Mail: Katherine DeForest McCaw Cellular Communications, Inc. 10230 NE Points Drive Kirkland, WA 98033-7869 No phone calls please. Thanks!  -----------[000002][next][prev][last][first]---------------------------------------------------- Date: 1 Jul 1994 15:38:58 -0700 From: lstowell@pyrnova.mis.pyramid.com (Lon Stowell) To: comp.protocols.tcp-ip Subject: Re: CD-ROM and TCP/IP  In article <1994Jun30.185731.23356@moore.com> chris@moore.com (Chris Box) writes: >Does anyone know how I'd attach a CD-ROM to a TCP/IP network as an >independent device? I don't want it attached to anyone's PC, but would >rather it have a direct connection something along the lines of a >printserver device which attaches directly to the ethernet cabling. Sure. Since you don't want to do the obvious and cheapest and most robust thing and just put in on a PC and treat it like any other drive and NFS mount it to the tcp/ip network, the following is pretty much what you are stuck with: o Build a black box which knows how to talk to the CD-ROM drive. o Implement your own file system, i/o drivers, etc. etc. to make that CD-ROM drive look to your TCP/IP and NFS interface exactly as if it were a CD-ROM drive attached to a PC. o Put some type of operating system in your little black box. You can now either write or buy a nice clean TCP/IP UDP protocol stack. If you used the wrong operating system, this is gonna get "highly interesting". o Either write or buy NFS or PC/NFS and put in on that operating system. o Build or buy your own ethernet (or whatever LAN adapter you are using) board. o Buy or write your own LAN driver for your LAN adapter. For the sake of saving maybe a few hundred dollars in off the shelf PC and software, you are likely in for a complete destroyal of your personal life, your sanity, and very likely your user's data. This answer, although somewhat unduly sarcastic is not entirely in jest. You can either attach it to someone's PC or buy a standalone unit and put the CD-ROM on that. These are cheap, pretty reliable, off-the-shelf answers. The alternative, until someone sells a CD-ROM NFS server box, is gonna get pretty ugly.  -----------[000003][next][prev][last][first]---------------------------------------------------- Date: Thu, 30 Jun 1994 15:04:43 +0800 From: peter.lewis@info.curtin.edu.au (Peter N Lewis) To: comp.protocols.tcp-ip Subject: Re: anonymous ftp setup  >I'd be grateful for replies by email. If you don't need them, stay away from fancy servers - obviously the more complex the server, the more places for holes. Never have any directory in ~ftp owned by ftp. Best is owned by a user and group that no one can log in as. Alternatively, owned by you and with a dummy group (a group not including the ftp user). Never allow any directory to be both readable and writeable. If you have a drop folder, make it write and execute, buit not read. Make sure any file put in to that directory does not immediately become world readable. If you allow read&write, people will take the opertunity to set up illicit sites (pirate or x-rated usually) on your host. Obviously ensure that no files or directories are world writeable unless you know exactly what you are doing and why. Perhaps write a script to verify this and run it regularly with cron. Sign on to the CERT mailing list and listen for security problems. Those are probably the main ones, Peter. _______________________________________________________________________ Peter N Lewis <peter.lewis@info.curtin.edu.au> Ph: +61 9 368 2055  -----------[000004][next][prev][last][first]---------------------------------------------------- Date: Fri, 1 Jul 1994 05:35:35 GMT From: gnn@netcom.com (George Neville-Neil) To: comp.protocols.tcp-ip Subject: TCP/IP FAQ Version 1.3 July 1994  OK, folks here's the latest FAQ. Not much changed this time. I may add some more of my own stuff in August. Later, George --- Begin FAQ --- Internet Protocol Frequently Asked Questions Maintained by: George V. Neville-Neil (gnn@netcom.com) Contributions from: Ran Atkinson Stephane Bortzmeyer Phill Conrad Jon Kay William Manning Barry Margolin Jim Muchow W. Richard Stevens Version 1.3 Last Update: July 1, 1994 ************************************************************************ The following is a list of Frequently Asked Questions, and their answers, for people interested in the Internet Protocols, including TCP, UDP, ICMP and others. Please send all additions, corrections, complaints and kudos to the above address. This FAQ will be posted on or about the first of every month. ************************************************************************ Table of Contents: Glossary 1) Are there any good books on IP? 2) Where can I find example source code for TCP/UDP/IP? 3) Are there any public domain programs to check the performance of an IP link? 4) Where do I find RFCs? 5) How can I detect that the other end of a TCP connection has crashed? Can I use "keepalives" for this? 6) Can the keepalive timeouts be configured? 7) Can I set up a gateway to the Internet that translates IP addresses, so that I don't have to change all our internal addresses to an official network? Glossary: I felt this should be first given the plethora of acronyms used in the rest of this FAQ. IP: Internet Protocol. The lowest layer protocol defined in TCP/IP. This is the base layer on which all other protocols mentioned herein are built. IP is often referred to as TCP/IP as well. UDP: User Datagram Protocol. This is a connectionless protocol built on top of IP. It does not provide any guarantees on the ordering or delivery of messages. This protocol is layered on top of IP. TCP: Transmission Control Protocol. TCP is a connection oriented protocol that guarantees that messages are delivered in the order in which they were sent and that all messages are delivered. If a TCP connection cannot deliver a message it closes the connection and informs the entity that created it. This protocol is layered on top of IP. ICMP: Internet Control Message Protocol. ICMP is used for diagnostics in the network. The Unix program, ping, uses ICMP messages to detect the status of other hosts in the net. ICMP messages can either be queries (in the case of ping) or error reports, such as when a network is unreachable. RFC: Request For Comment. RFCs are documents that define the protocols used in the IP Internet. Some are only suggestions, some are even jokes, and others are published standards. Several sites in the Internet store RFCs and make them available for anonymous ftp. SLIP: Serial Line IP. An implementation of IP for use over a serial link (modem). CSLIP is an optimized (compressed) version of SLIP that gives better throughput. Bandwidth: The amount of data that can be pushed through a link in unit time. Usually measured in bits or bytes per second. Latency: The amount of time that a message spends in a network going from point A to point B. Jitter: The effect seen when latency is not a constant. That is, if messages experience a different latencies between two points in a network. RPC: Remote Procedure Call. RPC is a method of making network access to resource transparent to the application programmer by supplying a "stub" routine that is called in the same way as a regular procedure call. The stub actually performs the call across the network to another computer. Marshalling: The process of taking arbitrary data (characters, integers, structures) and packing them up for transmission across a network. MBONE: A virtual network that is a Multicast backBONE. It is still a research prototype, but it extends through most of the core of the Internet (including North America, Europe, and Australia). It uses IP Multicasting which is defined in RFC-1112. An MBONE FAQ is available via anonymous ftp from: ftp.isi.edu" There are frequent broadcasts of multimedia programs (audio and low bandwidth video) over the MBONE. 1) Are there any good books on IP? A) Yes. Please see the following: Internetworking with TCP/IP Volume I (Principles, Protocols, and Architecture) Douglas E. Comer Prentice Hall 1991 This volume covers all of the protocols, including IP, UDP, TCP, and the gateway protocols. It also includes discussions of higher level protocols such as FTP, TELNET, and NFS. Internetworking with TCP/IP Volume II (Design, Implementation, and Internals) Douglas E. Comer / David L. Stevens Prentice Hall 1991 Discusses the implementation of the protocols and gives numerous code examples. Internetworking with TCP/IP Volume III (BSD Socket Version) (Client - Server Programming and Applications) Douglas E. Comer / David L. Stevens Prentice Hall 1993 This book discusses programming applications that use the internet protocols. It includes examples of telnet, ftp clients and servers. Discusses RPC and XDR at length. TCP/IP Illustrated, Volume 1: The Protocols, W. Richard Stevens (c) Addison-Wesley, 1994 An excellent introduction to the entire TCP/IP protocol suite, covering all the major protocols, plus several important applications. Unix Network Programming W. Richard Stevens Prentice Hall 1990 An excellent introduction to network programming under Unix. The Design and Implementation of the 4.3 BSD Operating System Samuel J. Leffler, Marshall Kirk McKusick, Michael J. Karels, John S. Quarterman Addison-Wesley 1989 Though this book is a reference for the entire operating system, the eleventh and twelfth chapters completely explain how the networking protocols are implemented in the kernel. 2) Where can I find example source code for TCP/UDP/IP? A) Code from the Internetworking with TCP/IP Volume III is available for anonymous ftp from: arthur.cs.purdue.edu:/pub/dls Code used in the Net-2 version of Berkeley Unix is available for anonymous ftp from: ftp.uu.net:systems/unix/bsd-sources/sys/netinet and gatekeeper.dec.com:/pub/BSD/net2/sys/netinet Code from Richard Steven's book is available on: ftp.uu.net:/published/books/stevens.* 3) Are there any public domain programs to check the performance of an IP link? A) TTCP: Available for anonymous ftp from.... Host gatekeeper.dec.com Location: /.0/BSD/NetBSD/NetBSD-current/othersrc DIRECTORY dr-xr-xr-x 512 Apr 8 09:57 ttcp Location: /.0/BSD/NetBSD/NetBSD-current/othersrc/ttcp FILE -r--r--r-- 3885 Nov 7 03:35 ttcp.1 FILE -r--r--r-- 19225 Nov 7 03:35 ttcp.c Host world.std.com Location: /src/wuarchive/graphics/graphics/mirrors/sgi.com/sgi/src/ttcp FILE -r--r--r-- 3885 Oct 4 1991 ttcp.1 FILE -r--r--r-- 19170 May 17 1993 ttcp.c FILE -r--r--r-- 13033 Sep 5 1989 ttcp.c-brl On ftp.sgi.com are netperf (from Rick Jones at HP) and nettest (from Dave Borman at Cray). ttcp is also availabel at ftp.sgi.com. There is suite of Bandwidth Measuring programs from gnn@netcom.com. Available for anonymous ftp from ftp.netcom.com in ~ftp/gnn/bwmeas-0.3.tar.Z These are several programs that meausre bandwidth and jitter over several kinds of IPC links, including TCP and UDP. 4) Where do I find RFCs? A) This is the latest info on obtaining RFCs: 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 The response to this mail query is quite long and has been omitted. RFCs can be obtained via FTP from DS.INTERNIC.NET, NIS.NSF.NET, NISC.JVNC.NET, FTP.ISI.EDU, WUARCHIVE.WUSTL.EDU, SRC.DOC.IC.AC.UK, FTP.CONCERT.NET, or FTP.SESQUI.NET. Using Web, WAIS, and gopher: Web: http://web.nexor.co.uk/rfc-index/rfc-index-search-form.html WAIS access by keyword: wais://wais.cnam.fr/RFC Excellent presentation with a full-text search too: http://www.cis.ohio-state.edu/hypertext/information/rfc.html With Gopher: gopher://r2d2.jvnc.net/11/Internet%20Resources/RFC gopher://muspin.gsfc.nasa.gov:4320/1g2go4%20ds.internic.net%2070%201%201/.ds/ .internetdocs 5) How can I detect that the other end of a TCP connection has crashed? Can I use "keepalives" for this? A) Detecting crashed systems over TCP/IP is difficult. TCP doesn't require any transmission over a connection if the application isn't sending anything, and many of the media over which TCP/IP is used (e.g. ethernet) don't provide a reliable way to determine whether a particular host is up. If a server doesn't hear from a client, it could be because it has nothing to say, some network between the server and client may be down, the server or client's network interface may be disconnected, or the client may have crashed. Network failures are often temporary (a thin ethernet will appear down while someone is adding a link to the daisy chain, and it often takes a few minutes for new routes to stabilize when a router goes down), and TCP connections shouldn't be dropped as a result. Keepalives are a feature of the sockets API that requests that an empty packet be sent periodically over an idle connection; this should evoke an acknowledgement from the remote system if it is still up, a reset if it has rebooted, and a timeout if it is down. These are not normally sent until the connection has been idle for a few hours. The purpose isn't to detect a crash immediately, but to keep unnecessary resources from being allocated forever. If more rapid detection of remote failures is required, this should be implemented in the application protocol. There is no standard mechanism for this, but an example is requiring clients to send a "no-op" message every minute or two. An example protocol that uses this is X Display Manager Control Protocol (XDMCP), part of the X Window System, Version 11; the XDM server managing a session periodically sends a Sync command to the display server, which should evoke an application-level response, and resets the session if it doesn't get a response (this is actually an example of a poor implementation, as a timeout can occur if another client "grabs" the server for too long). 6) Can the keepalive timeouts be configured? A) I know they can on many systems, but I don't know the details. 7) Can I set up a gateway to the Internet that translates IP addresses, so that I don't have to change all our internal addresses to an official network? A) There's no general solution to this. Many protocols include IP addresses in the application-level data (FTP's "PORT" command is the most notable), so it isn't simply a matter of translating addresses in the IP header. Also, if the network number(s) you're using match those assigned to another organization, your gateway won't be able to communicate with that organization (RFC 1597 proposes network numbers that are reserved for private use, to avoid such conflicts, but if you're already using a different network number this won't help you). However, if you're willing to live with limited access to the Internet from internal hosts, the "proxy" servers developed for firewalls can be used as a substitute for an address-translating gateway. See the firewall FAQ. --- End FAQ-- -- gnn@netcom.com Law is there to clean up etiquette's failures. Ms. Manners  -----------[000005][next][prev][last][first]---------------------------------------------------- Date: Fri, 1 Jul 94 05:45:27 GMT From: hal9001@panix.com (Robert A. Rosenberg) To: comp.protocols.tcp-ip Subject: Re: Wanted: SLIP for MACs  In Article <2uu6f7$eks$1@heifetz.msen.com>, ssayer@garnet.msen.com (Stephen Sayer) wrote: > > MacPPP 2.0.1 can be found at many FTP sites and on many online >services. It's a public domain package from Merit. > > I've also been very happy with VersaTermSLIP in concert with >VersaTerm Link which rolls POP3/SMTP mail, NNTP, FTP, Telnet, finger >and external clients into one nice little package. You'll want to >contact Synergy about VersaTerm et al. at info@synergy.com. As far as >SLIP on the Mac goes I think it's the easiest to configure and use. > >Later, > ><SS> > >-- >-- > { ssayer@mail.msen.com | ssayer@umcc.umich.edu } >I have a plan... if you need to know, you can finger it out. As you can see, I use VersaTerm Link. If you have MacPPP selected by MacTCP (in lieu of VersaSLIP) VTL is perfectly happy and will work just as well (I'm using MacPPP right now so this is not just theoretical <g>) so those who want/need a PPP instead of a SLIP link can get it. One comment about VTL's News Support. It is neat in that it has support for capturing Articles to your HD and then reading them while you are offline (ie: The Captured Articles serve as a NewsServer). The only short-coming is that the scanning of the Titles (to select which articles to capture) must still be done online in real time (unless you chose to just capture ALL the articles in a newsgroup).  -----------[000006][next][prev][last][first]---------------------------------------------------- Date: 1 Jul 1994 09:04:17 GMT From: pbs@zuunix.zuo.dec.com (Philip Shearer @ZUO-DC EBS-Team) To: comp.unix.programmer,comp.protocols.tcp-ip Subject: Re: Help with UDP Broadcast  bertg@fwi.uva.nl (Bert Gijsbers) writes: : mintz@cup.hp.com (Ken Mintz) writes: : : > That is, __if__ inet_addr returns -1, we merely need to also check to see : > if the parameter is indeed "255...255" and, if so, accept the -1 as a : > valid sin_addr. : : Shouldn't we be testing for INADDR_NONE rather than -1? : Where INADDR_NONE is #defined as ((unsigned long)0xffffffff). The define in the header on OSF1 ALPHA (a 64 bit machine): #ifndef _KERNEL #define INADDR_NONE 0xffffffff /* -1 return */ #endif : I'm also unsure about how this works on 64 bit CPUs. : Do they return (-1) or ((unsigned long)0xffffffff)? YES : : >-- Ken Mintz : : Bert Gijsbers The function returns 0xffffffff if assigned to an int it will be -1, or 0xffffffff if assigned to a long. In my previous posting to this thread I commented on the manual page, the mention of -1 as the return confuses the issue and leads to the danger of: if ( (rtn=inet_addr(var)) < 0 ) printf("This will never print because the < is always false\n"); else printf("This will always appear\n"); Here is the result of a test of 64 and 32 bit sizes on an OSF1 ALPHA. (the display size of size32 at 0xffffffffffffffff happens as soon as the bit shift caused the int overflows the 32 bit boundry. But the xor shows that the number can still be manipulated as expected) TTFN Philip ---------------------------- result --------------------- YES, rtn == 0xffffffff size64 == 0xffffffffffffffff size32 == 0xffffffffffffffff size32 ^ (1 << 31) == 0x7fffffff size32 == 0xffffffff size64 = size32 = 0xffffffff 32 bits from an int assigned to long int on an OSF1 Alpha :-) --------------------X cut here for the source to the above. X------------- #include <stdio.h> main() { const bits = 64 ; unsigned long int rtn; rtn=inet_addr("255.255.255.255") ; printf("---------------------------- result ---------------------\n"); if ( rtn == 0xffffffff ) printf(" YES,") ; else printf(" NO,") ; printf(" rtn = 0x%lx\n\n", rtn); displaysizes(bits) ; } displaysizes(int bits) { int i ; unsigned long size64 = 0 ; unsigned int size32 = 0 ; for ( i = 0 ; i < bits; i++ ) { size64 = size64 << 1 ; size64 |= 1 ; size32 = size32 << 1 ; size32 |= 1 ; } printf("size64 == 0x%lx\n", size64); printf("size32 == 0x%lx \n", size32); printf("size32 ^ (1 << 31) == 0x%lx\n ", size32 ^ (1 << 31) ); printf("size32 == 0x%x\n ", size32); size64 = size32 ; printf("size64 = size32 = 0x%lx\n", size64); printf(" 32 bits from an int assigned to long int on an OSF1 Alpha :-)\n"); }  -----------[000007][next][prev][last][first]---------------------------------------------------- Date: 1 Jul 1994 10:11:54 GMT From: barmar@think.com (Barry Margolin) To: comp.protocols.tcp-ip Subject: Re: Max IP packet length and MTU  In article <2utmev$9o2@cherokee.advtech.uswest.com> crohrer@advtech.uswest.com (Chris Rohrer) writes:
>I'm trying to understand just what the relationship between maximum IP packet
>size and MTU size really is.

RFC 1122 has a section on MTU.

>It had always been by understanding only routers would do fragmentation
>and that hosts would just obey the MTU limitation on their local nets and
>generate packets of the appropriate size with no IP fragmentation
>indicated in the IP header.  And further, that the MTU limitation would be
>"visible" to higher layers, well at least to layer 4.

Hosts aren't REQUIRED to do fragmentation, but they are permitted to;
receivers are required to be able to reassemble, whether the packet
originated on the local net or was routed.  Implementations based on BSD
Unix will fragment anything but a broadcast packet.  My expectation is that
most host implementations that are capable of acting as a router will
fragment packets it originates, since the transmission routine is usually
in a layer that doesn't care whether the packet originated locally.

The next higher layer is supposed to be able to find out the MTU.  TCP
implementations usually use this to compute the MSS option, to try to avoid
fragmented TCP segments.  The layer above UDP should also be able to find
out the MTU, since UDP broadcasts won't be fragmented and the application
may need to take this into account (for instance, routed sends out multiple
packets if the routing table doesn't fit in a single UDP packet).
--
Barry Margolin
System Manager, Thinking Machines Corp.

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


-----------[000008][next][prev][last][first]----------------------------------------------------
Date:      1 Jul 1994 19:51:20 -0500
From:      ucacjon@ucl.ac.uk (Jon Crowcroft)
To:        comp.protocols.tcp-ip
Subject:   Re: OSI vs TCP/IP Question

In article <2uvga0$4eu@clarknet.clark.net>, wwds2@clark.net () writes: |> I am considering building a fault tolerant system containing two (up to |> four) seperate networks (ethernet or FDDI) to allow for failures. Each |> computer in the system will be connected to at least two of the networks. |> I need to establish reliable (as in TCP vs UDP) connections between |> computers. |> |> I have been told that OSI protocols will handle switching between the two or |> more possible networks to establish connections without my writing specific |> code to do so. I have also been told that TCP/IP will not support this. |> |> Can anyone tell me what OSI protocol or service provides this function |> and whether or not similiar operations can be performed using TCP/IP? |> |> I'd like to stay with one protocol and TCP/IP is necessary for the SNMP |> managemment. you need to identify what faults you anticipate mostly to build a fault tolerant network if you believe the links will fail most, then a reduent link network interconnected by routers wil work for OSI TP4/CLNP and TCP/IP however, if you cannot trust routers either then you need multi-homed hosts on your replicated ethers or fddis then you have a problem with TCP, as for each network interface, you have to have a seperate IP address, but if an interface breaks, a TCP connection cannot continue as part of the TCP "connection id" is the IP address.... however ,there are many products that will switch between redundent ethers _below_ the IP level with FDDI, ayo uget the option of DAS (Dual Attached Stations/ring) which again is below the IP level in OSI, the TP4 connectio nis a reference number once made, so the CLNP level can migrate... -- jon crowcroft (hmmm...)  -----------[000009][next][prev][last][first]---------------------------------------------------- Date: 1 Jul 1994 14:23:39 GMT From: bansal@ccrl.nj.nec.com (Vivek Bansal) To: comp.protocols.tcp-ip Subject: STREAMS, TLI ...  TLI or Sockets, what are the (dis)advantages of providing either as APIs to the application. Has there been any comparision done in terms of there performance and functionality ? Secondly I would like to know the performance benefits in implementing of implementing any TCP/IP like protocol in STREAMS as compared to a the way it is implemented in BSD. Any responses that I get to my account, I will post it on the net.... Vivek... bansal@ccrl.nj.nec.com  -----------[000010][next][prev][last][first]---------------------------------------------------- Date: 1 Jul 1994 14:35:34 GMT From: crohrer@advtech.uswest.com (Chris Rohrer) To: comp.protocols.tcp-ip Subject: Re: Max IP packet length and MTU  In article <2uvmhu$k2q@acsc.com>, Rao Srinivasa <rao@acsc.com> wrote:
>In article <2utmev$9o2@cherokee.advtech.uswest.com>, crohrer@advtech.uswest.com (Chris Rohrer) writes:|> Hi all, >|> >|> >|> My real question is more like this: Will "typical" host IP software obey >|> this 1500 byte restriction and tell its users (TCP, UDP and possibly other >|> entities) that THEIR maximum "block" size is of that same approximate >|> value (1500 minus the IP overhead)? Or will this "typical" IP software >|> present a 64k-sized interface to its layer 4 users and take the initiative >|> to do real header-mediated IP fragmentation down to the 1500 byte size? >|> > As far as I know IP does the fragmentation and assembling of the > packets .... > I look at it this way .. > > If I open an UDP socket and write data which is more than 1500 bytes > it reaches the peer without any problem ... > > So either UDP or IP does this work ... > > If UDP does this work then it has to done by TCP too ... > > So I feel( that's not what you want though ..) IP does this work for both UDP and TCP. > > Lets wait for others say ...Mean while I will dig in to some UDP/IP books .. > > >Rao. The consensus of the responses I've received so far indicate that TCP will be "well-behaved" and set its MSS or Maximum Segment Size to a number equal to the datalink layer's MTU limitation minus room for the IP header. So on an Ethernet based system, with an MTU of 1500 bytes, TCP would create segments 1480 bytes in length. In this way, the transmitted IP packets would not be fragmented, they'd be just the right size. However, with a protocol stack based on UDP, things are not so nice. For example, I have oberved NFS PDUs greater than 8000 bytes in length that are chopped up into sequences of Ethernet frames of 1500 bytes each, all having the fragmentation fields used. I would expect that, in general, other applications are going to do the exact same thing when operating over UDP, that is, they'll hand a block of data to IP expecting that it will do this fragmentation operation. I had thought that the applications would have been better behaved and do this chopping up themselves. But if the mechanism exists in IP implementations to perform this useful function, then why not use it? After all, by making use of the fragmentation mechanism for reassembly in the receiver, problems of mis-ordered packets can be taken care of at the network layer where they belong. This thus allows applications to not have to worry about this particular problem. Chris Rohrer  -----------[000011][next][prev][last][first]---------------------------------------------------- Date: 1 Jul 1994 15:31:48 GMT From: Per.Weisteen@hda.hydro.com (Per Weisteen) To: comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc Subject: Re: Microsoft's Windows Internet Name Service?  In article <2utpqi$1b4@usenet.INS.CWRU.Edu>, bq274@cleveland.Freenet.Edu (Andy J. Berkvam) says:
>
>
>In a previous article, phil@lykos.netpart.com (Phil Trubey) says:
>
>>Does anyone have some detailed info about Microsoft's new
>>Windows Internet Name Service that they will be offering in their upcoming
>>TCP/IP products?  I remember reading somewhere that it was similar to DNS, but
>>not, in fact, DNS.  Does this mean that large sites that currently use DNS
>>will have to maintain two machine naming systems?
>>
>>Thanks for any info,
>
>'lo
>
>  As I understand it, another server will be required.  The Wolverine
>TCP stack put out by Microsoft for WfW 3.11 uses it.
>
>  Check out http://www.microsoft.com/wolverine.  There's some
>and read the Windows Help file.  (No need to install, just unzip it and
>load it into Windows Help.)  All sorts of good info on the new name
>resolution, DHCP, etc.
>
>Andy
>

in a real Internet environment.

+-----------------------------------------------------------------------+
| Per Weisteen          Email: Per.Weisteen@hda.hydro.com               |
| Hydro Data            Phone: +47 2273 8227                            |
| Norsk Hydro           "It is better to light a candle,                |
| Norway                 no matter how small, than to curse darkness"   |
|                                                  Kung-fu-tse          |
+-----------------------------------------------------------------------+


-----------[000012][next][prev][last][first]----------------------------------------------------
Date:      1 Jul 1994 15:41:39 GMT
From:      Per.Weisteen@hda.hydro.com (Per Weisteen)
To:        comp.protocols.tcp-ip
Subject:   Re: Looking for dynamic-assignment BOOTP

In article <1994Jun30.160105.6475@ivax>, imhw400@indyvax.iupui.edu (Mark H. Wood) says:
>
>I'm looking for *any* implementation of BOOTP that can dish out cynamically-
>assigned addresses to hosts on subnets other than its own.  I would have
>thought that this was commonplace, but I find now that the only implementation
>of dynamic assignment I can find has no way to express the desire for address
>pools per-subnet.  Yes, I know this presents some nasty problems (someone who
>wonders what they are would do well to start by reading my own analysis), but I
>need the capability anyway if it has been done.  Any pointers would be
>appreciated.
>--
>Mark H. Wood, Lead Systems Programmer    +1 317 274 0749   [@disclaimer@]
>Internet:  MWOOD@INDYVAX.IUPUI.EDU       BITNET:  MWOOD@INDYVAX
>"It's *better* than good -- it's CHEAP!" - Cosmo Spacely

DHCP protocol (RFC 1541  ++) is a new protocol which does exactly
what you want. I know Microsoft has implemented this for NT and I think
SUN has a version out "real soon now" , and yes Novell is also supposed
to have one implemented as a NLM for their 4.x Netware.

I'm desperately looking for a UNIX source. I'd hate to be in the hands of those
PC-guys talking IP.... ;-)

+-----------------------------------------------------------------------+
| Per Weisteen          Email: Per.Weisteen@hda.hydro.com               |
| Hydro Data            Phone: +47 2273 8227                            |
| Norsk Hydro           "It is better to light a candle,                |
| Norway                 no matter how small, than to curse darkness"   |
|                                                  Kung-fu-tse          |
+-----------------------------------------------------------------------+


-----------[000013][next][prev][last][first]----------------------------------------------------
Date:      Fri, 1 Jul 1994 19:41:01 GMT
From:      salman@aplcenmp.apl.jhu.edu (Ashfaq salman (703) 516-7616)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.domains,comp.protocols.tcp-ip.ibmpc,comp.os.ms-windows.networking.tcp-ip,comp.os.ms-windows.networking.windows,comp.os.ms-windows.programmer.networks,comp.sys.ibm.pc.hardware.misc,comp.os.os2.networking
Subject:   WTB: Info on Schneider & Koch ethernet cards

Hello,

I badly need "any info" on the following cards:

They are make by a German company Schneider & Koch and cards are 16-bit
ethernet adapters. The software tries to identify them as SK-Junior
boards.

I am particularly interested in getting Novell, Windows, etc. drivers for it.
I only have netbios software for it. I don't have any other documentation
on it. Any information about its compatibility or the company will be greatly

-Salman
salman@lccinc.com


-----------[000014][next][prev][last][first]----------------------------------------------------
Date:      Fri, 1 Jul 1994 20:53:28 GMT
From:      yuvalt@silver.weizmann.ac.il (Tal Yuval)
To:        comp.protocols.tcp-ip
Subject:   Installing SLIP

Hi,

I am trying to make SLIP work in my site and I have a question: Our
network is class C (ie the subnetmask is 255.255.255.0), our computers are
on network 132.76.80 (wisdom.weizmann.ac.il).

My question is: If I want to connect a SLIP machine to the network
(lets say that the host is 132.76.80.121), do I have to create a new
network (i.e. 132.76.81) and make 132.76.80.121 its gateway or can I
put my SLIP machine on the same IP network?

I succeeded in creating a new subnet but I was wondering if the other
method also works. If it does, what is the configuration of the SLIP
host and the SLIP machine.

Thanks,

-Yuval

--

Yuval Tal, System programmer // Faculty of mathematics
yuvalt@wisdom.weizmann.ac.il // Weizmann Institute Of Science, Rehovot, Israel


-----------[000015][next][prev][last][first]----------------------------------------------------
Date:      Fri, 1 Jul 1994 21:15:24 GMT
From:      John Martinez <martinez@rahul.net>
To:        comp.protocols.tcp-ip
Subject:   Public Domain TCP/IP


I didn't see this in the FAQ, but does anyone know of a public domain/freeware
implementation of TCP/IP for DOS PC's?

Thanks.
--
# John Martinez (martinez@bats.com) UNIX System Administration Consultant
# Bright Apex Technology Services   San Jose, California, USA


-----------[000016][next][prev][last][first]----------------------------------------------------
Date:      1 Jul 1994 21:39:58 GMT
From:      vern@daffy.ee.lbl.gov (Vern Paxson)
To:        comp.protocols.tcp-ip
Subject:   Re: TCPDUMP-3.0

In article <2uucjd$alg@helios.intranet.gr>, Antonis Kyriazis (ext-1122) <antonis@intranet.gr> wrote: # I'm trying to build tcpdump (I made also libpcap->libfl.a) and # ld cannot find _yy_flex_realloc, _yy_flex_free and _yy_flex_alloc. # Does one know what is missing here? You need to upgrade to flex 2.4.6, which you can get from ftp.ee.lbl.gov. Vern  -----------[000017][next][prev][last][first]---------------------------------------------------- Date: Sat, 2 Jul 1994 00:15:32 GMT From: hsm@unislc.slc.unisys.com (Helge Moulding) To: comp.protocols.tcp-ip Subject: Re: Max IP packet length and MTU  Chris Rohrer wrote, : [...asked about IP datagram sizes, and MTU sizes...] IP hosts originating messages try to avoid fragmenting by using the MTU size information. Routers shouldn't have to do a lot of fragmenting, for the same reason. This is done because fragmenting is quite expensive... The MTU size is not just dependent on the network connected to the local interface, but on the smallest frame size of all the frame sizes between the two hosts at the end points, and may even be affected by buffer sizes of intervening routers. TCP protocol implementations try to dynamically adjust the transmitted segment size to account for network load, etc. Try RFCs 1435, 1191, 1063, 879, and 813 for more information. (Heck, you probably already did, right?) -- Helge "Some advice is free" Moulding (Just another guy with a weird name)  -----------[000018][next][prev][last][first]---------------------------------------------------- Date: Sat, 2 Jul 1994 05:45:45 GMT From: aboba@netcom.com (Bernard Aboba) To: comp.protocols.tcp-ip Subject: Round robin DNS?  I am told that the latest version of BIND supports load balancing via "round robin" DNS. I am interested in how well this works, pointers to docs, etc.  -----------[000019][next][prev][last][first]---------------------------------------------------- Date: 2 Jul 94 11:58:00 GMT From: tom.lewis@ftl.mese.com (Tom Lewis) To: comp.protocols.tcp-ip Subject: Slip connection info  Would this be a good newsgroup to ask some basic questions about connecting a W4WG 3.11 network to internet through a Slip connection? If not, I would appreciate it if someone would refer me to a more appropriate area. If someone would just give me a list of WinSock apps that I need to procure and where they can be obtained it would be very helpful. I think I understand how things work. What I need is a simple presentation of the specifics. Thanks... --- . QMPro 1.52 . Internet: tom.lewis@sharpcor.com  -----------[000020][next][prev][last][first]---------------------------------------------------- Date: Sun, 03 Jul 94 00:43:21 cdt From: hgwill@zilker.net To: comp.protocols.tcp-ip.ibmpc,comp.protocols.tcp-ip,comp.os.ms-windows.programmer.networks,comp.os.ms-windows.networking.tcp-ip Subject: Re: NCSA Winsock  In article <9406292355.AA12980@ariake.nwk.cl.nec.co.jp>, <mweiss@nwk.cl.nec.co.jp> writes: > Winsock. Also if anyone knows the email address of its creators, please > let me know. Try: mosaic-win@ncsa.uiuc.edu That's the email address of the creators for Mosaic, and to submit bug reports on the product.  -----------[000021][next][prev][last][first]---------------------------------------------------- Date: 3 Jul 1994 04:07:10 GMT From: frank@vcsun1.tamu.edu (Franklin S. Cheng) To: comp.protocols.tcp-ip Subject: Re: IP Multicast  You can also take a look at a popular doc named IPmulticast.README under /vmtp dir @ havefun.stanford.com , where you will find some programming example and explanations. Regards, Frank -- Franklin S. Cheng | <email>: frank-cheng@tamu.edu Multimedia & Networking Lab | tel: (W) 409-845-5774 Department of Electrical Engineering | (H) 409-268-8293 Texas A&M University , College Station, Texas 77843  -----------[000022][next][prev][last][first]---------------------------------------------------- Date: Sun, 3 Jul 94 04:39:14 GMT From: ftlofaro@unlv.edu (Frank Lofaro) To: comp.protocols.tcp-ip Subject: Annex and general SLIP information needed (soon)  An organization here is going to be soon providing SLIP access. However, they plan to use dynamic IP address assignment on a per-port basis. In other words, connection on a given port gives you a given IP address. They are using Xylogics Annex terminal servers (one of them quite new, supposedly supports both SLIP/CSLIP and PPP). There is going to be authentication of individual users. Unfortunately, dynamic IP address assignment would be a headache for me and many other users. It would make it impossible to run ftp/http and other servers, and would even make it very difficult to find our own machine to telnet back into if we wanted to connect to it through the Internet. It is especially hard for those that have un*x based machines, (e.g. Linux) The justification given is that static IP addresses are harder to set up and that they could run out. Anyone have any pointers to documents and information on static versus dynamic IP address assignment, or on Annex terminal server configuration? Especially information on the benefits of static addressing and how to configure it on a Xylogics Annex. Any information would be appreciated, as soon as possible (things are moving very quickly). Does anyone know why stty fwdtimer x where x is less than 5 (the default) says I can't lower it? Also, if an Annex is in non-SLIP mode, does it hold characters (e.g. use the Nagle algorithm)? Could this be turned off on a port by a regular user for that session? This information might be helpful for another project that I may have to undertake soon. I hope to be able to convince the people in charge of SLIP to use static based IP addressing, but I want to confirm that I have all the relevant facts. Thus any information would be greatly appreciated.  -----------[000023][next][prev][last][first]---------------------------------------------------- Date: 3 Jul 1994 08:27:44 GMT From: barmar@think.com (Barry Margolin) To: comp.protocols.tcp-ip Subject: Re: Max IP packet length and MTU  In article <2v19jm$k2i@cherokee.advtech.uswest.com> crohrer@advtech.uswest.com (Chris Rohrer) writes:
>I had thought that the applications would have been better behaved and do
>this chopping up themselves.  But if the mechanism exists in IP
>implementations to perform this useful function, then why not use it?

Because it can cause problems.

I know of some systems whose ethernet interface can only buffer 2 frames at
a time.  When a Sun sends 6 back-to-back frames as a result of fragmenting
an 8K UDP datagram from NFS, the last two packets are always dropped.
Eventually the request times out, it retries, and the same thing happens on
the retransmission.  When we discovered this was happening we changed this
system's equivalent of the "rsize" parameter.

Even ignoring such pathological situations, it can generally cause
performance problems.  If a datagram is fragmented, loss of one of the
packets will require all of them to be retransmitted.  If you break the
data up in the layer that implements retransmission, it can retransmit only
the lost packet.
--
Barry Margolin
System Manager, Thinking Machines Corp.

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


-----------[000024][next][prev][last][first]----------------------------------------------------
Date:      Sun, 03 Jul 1994  14:51 ET
From:      gmangum@umich.edu  (Gene Mangum)
To:        comp.protocols.tcp-ip
Subject:   Re: Looking for PC/TCP 3.X

In Article <2uptcp$j59@news.CCIT.Arizona.EDU> "feng@bigdog.engr.arizona.edu (Gene Feng)" says: > I heard that the new PCT/CP shareware program had come out. I wonder if > anyone could tell me where it is (I have verson 2.1). Thank you much. First, PC/TCP is not shareware, it's a commercial product. Second, version 3.0 is not out yet. +=================================+=========================================+ | Gene Mangum | OS/2 ver 2 - Increased productivity | | Univ of Michigan Hospitals | through the use of a | | h198@hosp.med.umich.edu | "dead" operating system. | +=================================+=========================================+  -----------[000025][next][prev][last][first]---------------------------------------------------- Date: Sun, 3 Jul 1994 19:49:13 From: karl@cavebear.com (Karl Auerbach) To: comp.protocols.tcp-ip Subject: Re: Max IP packet length and MTU  In article <2v73ru$q7b@hpindda.cup.hp.com> raj@cup.hp.com (Rick Jones) writes:
>
>Poppycock!-) IP framentation is simply a matter of pointer
>manipulation and perhaps some scatter-gather abilities in the DMA
>hardware. IP fragmentation being perceived as "expensive" is more
>likely a function of IP fragmentation being left up to a router's
>(underpowered) main CPU instead of VLSI.

Fragmentation isn't so hard, but you should try your hand at writing a good
solid reassembly engine.  It isn't easy and if done wrong can be a real memory
hog.  There are many implementations out there that don't do it right in all
cases (such as when the first fragment arrives first or when fragments overlap
rather than simply abut one another.)

--karl--


-----------[000026][next][prev][last][first]----------------------------------------------------
Date:      3 Jul 94 23:15:01
From:      billw@glare.cisco.com (William )
To:        comp.protocols.tcp-ip
Subject:   Re: Max IP packet length and MTU

: Routers shouldn't have to do a lot of
: fragmenting, for the same reason. This is done because fragmenting
: is quite expensive...

Poppycock!-) IP framentation is simply a matter of pointer
manipulation and perhaps some scatter-gather abilities in the DMA
hardware. IP fragmentation being perceived as "expensive" is more
likely a function of IP fragmentation being left up to a router's
(underpowered) main CPU instead of VLSI.

Regardless of whether fragmentations "should" be expensive or not, the fact
remains that it \IS/ in most (all?) currently popular routers.  Since
fragmentation is generally considered a bad idea regardless of the expense
in routers, router vendors are not very motivated to improve the state of
affairs.  There are more important things to do...

BillW


-----------[000027][next][prev][last][first]----------------------------------------------------
Date:      3 Jul 1994 19:34:22 GMT
From:      raj@cup.hp.com (Rick Jones)
To:        comp.protocols.tcp-ip
Subject:   Re: Max IP packet length and MTU

Helge Moulding (hsm@unislc.slc.unisys.com) wrote:
: Routers shouldn't have to do a lot of
: fragmenting, for the same reason. This is done because fragmenting
: is quite expensive...

Poppycock!-) IP framentation is simply a matter of pointer
manipulation and perhaps some scatter-gather abilities in the DMA
hardware. IP fragmentation being perceived as "expensive" is more
likely a function of IP fragmentation being left up to a router's
(underpowered) main CPU instead of VLSI.

rick jones
speaking only as rick jones...


-----------[000028][next][prev][last][first]----------------------------------------------------
Date:      4 Jul 1994 11:15:51 -0600
To:        comp.protocols.tcp-ip
Subject:   IP Address

I am having a problem changing a workstations IP address.  The address of
the server is 192.0.0.250 (I think this is the problem) and the address
of the workstation is 192.0.0.122  I want to change the workstation
address to 192.10.10.1  but when I do this the workstation cannot connect
and it hangs up.  I have to do a cold boot to get the PC to work again.
What is wrong with the scheme?

David Wood


-----------[000029][next][prev][last][first]----------------------------------------------------
Date:      4 Jul 1994 13:46:26 -0700
From:      schmidt@tango.ics.uci.edu (Douglas C. Schmidt)
To:        comp.client-server,comp.object,comp.lang.c++,comp.protocols.tcp-ip,comp.unix.solaris
Subject:   Object-oriented network programming components now available

Version 2.14.3 of the ADAPTIVE Communication Environment (ACE)
object-oriented network programming toolkit is now available for
anonymous ftp from the ics.uci.edu (128.195.1.1) host in the
gnu/C++_wrappers.tar.Z file (approximately .5 meg compressed).  This
release contains contains the source code, documentation, and example
test drivers for C++ wrapper libraries and higher-level network
programming frameworks developed as part of the ADAPTIVE project at
the University of Calfornia, Irvine.

o The contents of this release encapsulate the following
user-level BSD and System V Release 4 (SVR4) IPC facilities
via type-secure, object-oriented C++ interfaces:

o Internet and UNIX-domain sockets (including
o Event multiplexing via select and poll
o named pipes (FIFOs) and STREAM pipes (plus connld)
o the mmap family of memory-mapping APIs
o System V IPC (i.e., shared memory, semaphores,
message queues)
o SVR4 explicit dynamic linking facilities (i.e.,
dlopen/dlsym/dlclose)

o In addition, there are also a set of higher-level network
programming frameworks that integrate and enhance the
lower-level C++ wrappers to support the dynamic
configuration of concurrent network daemons composed of
complex distributed application services

Many of the C++ wrappers and higher-level components have been
described in issues of the C++ Report, as well as in the proceedings
of (1) the 2nd C++ World conference, October 1993, (2) the 11th and
12th Annual Sun Users Group Conference in December 1993 and June 1994,
(3) the 2nd International Workshop on Configurable Distributed
Systems, March 1994, the 6th USENIX C++ Conference in April 1994, the
9th OOPSLA Conference to be held in October 1994, and the 3rd C++
World conference in November 1994.

ACE components are currently being used in a number of
commercial products including the AT&T Q.port ATM signaling software
product, the Ericsson EOS family of PBX monitoring applications, and
the network management portion of the Motorola Iridium mobile
communications system.

A relatively complete set of documentation and extensive
examples are included in the release.  The current release has been
tested fairly extensively on Sun workstations running Sun OS 4.1.x and
Solaris 2.x using GNU G++ and Sun C++ 3.x and 4.x.  Portions of the
release have also been ported to SCO UNIX, HP-UX, OSF/1, Windows 3.1
and Windows NT.  I expect that major portions of the release will port
easily to other platforms.  If anyone is willing to help coordinate
ports to other platforms please let me know.

A mailing list is available for discussing bug fixes,
enhancements, and porting issues regarding ACE.  Please send mail to
ace-users-request@ics.uci.edu if you'd like to become part of the
mailing list.

CONTENTS OF THE RELEASE

The following subdirectories are included in this release:

o apps    -- complete applications written using the ACE wrappers
o bin     -- utility programs for building this release
o build   -- a separate subdirectory that keeps links into the main
source tree in order to facilitate multi-platform
build-schemes
o include -- symbolic links to the include files for the release
o lib     -- object archive libraries for each C++ wrapper library
o libsrc  -- the source code for the following C++ wrappers:
ASX -- higher-level C++ network programming framework
Get_Opt -- a C++ version of the UNIX getopt utility
SOCK_SAP -- wrapper for BSD sockets
TLI_SAP -- wrapper for SVR4 TLI
FIFO_SAP -- wrapper for FIFOS (named pipes)
SPIPE_SAP -- wrapper for SVR4 STREAM pipes and connld
Log_Msg -- library API for a local/remote
logging facility
Mem_Map -- wrapper for BSD mmap() memory mapped files
Message_Queues -- wrapper for SysV message queues
Reactor -- a framework for event
demultiplexing and dispatching
Semaphores -- wrapper for SysV semaphores
Service Configurator -- a framework for
Shared_Memory -- wrapper for SysV shared memory
Shared_Malloc -- wrapper for SysV/BSD shared mallocs
o tests -- programs that illustrate how to use the various wrappers

Please refer to the INSTALL file for information on how to build and
test the ACE wrappers.  Due to the large size of the release (~2 Meg)
I'm sorry that I will be unable to distribute the ACE wrappers via
email.  The BIBLIOGRAPHY file contains information on where to obtain
articles that describe the ACE wrappers and the ADAPTIVE system in
more detail.

Also, please note that there are companion tar files called
C++_wrappers_doc.tar.Za[a-c].  These files are in the same ftp/gnu
directory as the source code distribution and contain the following
subdirectories from the ACE release:

o doc     -- LaTeX documentation (in both latex and .ps format)
o papers  -- postscript versions of various papers describing ACE

I used the UNIX "split" command to make sure each of these files is
less than 1.2 Meg in size to accommodate ACE users who only have
file, simply to the following:

% cat C++_wrappers_doc.tar.Za[a-c] doc.tar.Z
% uncompress doc.tar.Z
% tar xvf doc.tar

You are free to do anything you like with this code.  However,
you may not do anything to this code that will prevent it from being
distributed freely in its original form (such as copyrighting it,
etc.).  Moreover, if you have any improvements, suggestions, and or
comments, I'd like to hear about it!  It would be great to see this
distributed evolve into a comprehensive, robust, and well-documented
C++ class library that would be freely available to everyone.
Natually, I am not responsible for any problems caused by using these
C++ wrappers.

Thanks,

Douglas C. Schmidt
(schmidt@ics.uci.edu)
Department of Information and Computer Science
University of California, Irvine
Irvine, CA 92717
Work #: (714) 856-4105
FAX #: (714) 856-4056

ACKNOWLEDGEMENTS

Special thanks to Paul Stephenson for devising the recursive
Makefile scheme that underlies this distribution, as well as for
devoting countless hours to discussing object-oriented techniques for
developing distributed application frameworks.

Thanks to Olaf Kruger for explaining how to instantiate
templates for shared libraries on SunOS 4.
--
Douglas C. Schmidt
Department of Information and Computer Science
University of California, Irvine
Irvine, CA 92717. Work #: (714) 856-4105; FAX #: (714) 856-4056


-----------[000030][next][prev][last][first]----------------------------------------------------
Date:      4 Jul 1994 11:47:31 -0400
From:      berke@panix.com (Wayne Berke)
To:        comp.protocols.tcp-ip
Subject:   Re: Max IP packet length and MTU

In <karl.2.0013D29E@cavebear.com> karl@cavebear.com (Karl Auerbach) writes:

>In article <2v73ru$q7b@hpindda.cup.hp.com> raj@cup.hp.com (Rick Jones) writes: >> >>Poppycock!-) IP framentation is simply a matter of pointer >>manipulation and perhaps some scatter-gather abilities in the DMA >>hardware. IP fragmentation being perceived as "expensive" is more >>likely a function of IP fragmentation being left up to a router's >>(underpowered) main CPU instead of VLSI. >Fragmentation isn't so hard, but you should try your hand at writing a good >solid reassembly engine. It isn't easy and if done wrong can be a real memory >hog. There are many implementations out there that don't do it right in all >cases (such as when the first fragment arrives first or when fragments overlap >rather than simply abut one another.) Reassembly might be considerably more complex than fragmentation, but it only gets done on end-systems, never on routers. And I believe the original reference was to the cost of fragmentation on routers. > --karl--  -----------[000031][next][prev][last][first]---------------------------------------------------- Date: Mon, 4 Jul 1994 10:18:10 From: karl@cavebear.com (Karl Auerbach) To: comp.protocols.tcp-ip Subject: Re: Max IP packet length and MTU  >Reassembly might be considerably more complex than fragmentation, but it only >gets done on end-systems, never on routers. And I believe the original reference >was to the cost of fragmentation on routers. There is a strong argument to be made that when one does fragmentation, that the first fragment which should be sent is the last fragment. The reason for doing this is that the receiver has no idea how big the reassembled packet will be until the last fragment is received. If the receiver is "lucky" enough to get the last fragment first, it has a chance to allocate an appropriate size reassembly buffer. Of course, some commercial implementations have been known to crash if they get the last fragment first. --karl--  -----------[000032][next][prev][last][first]---------------------------------------------------- Date: Mon, 4 Jul 1994 07:55:37 GMT From: albertk@cs.kun.nl (Albert Koppes) To: comp.protocols.tcp-ip Subject: FTP timers modification ?  On a SUN Sparc 10 Solaris 2.3 we are initiating an ftp-session. If the remote host/network is not reachable the ftp application will time out only after 8 times trying to send an SYN-segment to connect to the other control-port. With the exponential backoff timers this takes about 4 minutes. For out operational system this is too long. 1. How does on change the number of retries, or the timer behaviour (preferable via the ndd utility in Solaris 2.3) 2. We have looked at a ftp-implementation (ftp.c, bsd-alike) but this implementation is only issueing one (1) connect()-call. Does somebody know where one can find the source of an ftp-imple mentation that is similar to the Solaris 2.3 one. Thank you in advance , Frank Zeppenfeldt EUMETSAT albertk@zeus.cs.kun.nl tel: +49 6151 950236 fax: +49 6151 950225  -----------[000033][next][prev][last][first]---------------------------------------------------- Date: Mon, 4 Jul 1994 08:06:57 GMT From: wgaige@netcom.com (Wesson E. Gaige) To: comp.protocols.tcp-ip,comp.dcom.isdn Subject: Re: ISDN, Lan-to-Internet & TCP-IP  In article <2usese$euo@www.interramp.com>, fedor@interramp.com wrote:

> In article <mhuff@zilker.net> writes:
>
>
> BTW, PSI does not have an ISDN presence in Austin yet.... hopefully soon.
>
> send mail to info@psi.com if you have any questions...
>

Will you have an ISDN presence in Dallas when SWBell starts offering it
here in the fall?

--
| Wesson E. Gaige                   | wgaige@netcom.com              |
| Manager, PC and Network Support   | WesGaige@aol.com               |
| Parkland Memorial Hospital        | 75046.1461@compuserve.com      |
| Dallas, Tx                        |                                |
|-----------------------------------|--------------------------------|


-----------[000034][next][prev][last][first]----------------------------------------------------
Date:      4 Jul 1994 10:06:33 GMT
From:      reinken@tu-harburg.d400.de
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.domains,comp.protocols.tcp-ip.ibmpc,comp.os.ms-windows.networking.tcp-ip,comp.os.ms-windows.networking.windows,comp.os.ms-windows.programmer.networks,comp.sys.ibm.pc.hardware.misc,comp.os.os2.networking
Subject:   Re: WTB: Info on Schneider & Koch ethernet cards

In <CsA1CD.M3v@aplcenmp.apl.jhu.edu>, salman@aplcenmp.apl.jhu.edu (Ashfaq salman (703) 516-7616) writes:
>Hello,
>
>I badly need "any info" on the following cards:
>
>They are make by a German company Schneider & Koch and cards are 16-bit
>ethernet adapters. The software tries to identify them as SK-Junior
>boards.
>
>I am particularly interested in getting Novell, Windows, etc. drivers for it.
>I only have netbios software for it. I don't have any other documentation
>on it. Any information about its compatibility or the company will be greatly
>
>-Salman
>salman@lccinc.com
>

The adress of the company is :

Siemensstraáe 23
D - 76275 Ettlingen

Voice-Mail : 49 7243 / 502 - 0
Fax : 49 7243 / 502 - 989

You normaly get all drivers with the card. There is a driver packet called SK - UPPS (universal programmel
prtocol stack) you can use to communicate with novell (ipx, spx) and unix-workstation (tcp/ip) at the same
time. This driver packet should be send with your SK-Junior board i think.

Wolfram Reinken

E- Mail : reinken@tu-harburg.d400.de
or rztwr@molly.rz.tu-harburg.de


-----------[000035][next][prev][last][first]----------------------------------------------------
Date:      4 Jul 1994 22:19:52 -0500
From:      mweiss@nwk.cl.nec.co.jp (Michael J. Weiss)
To:        comp.os.ms-windows.networking.tcp-ip,comp.os.ms-windows.programmer.networks,comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject:   PACKET  DRIVER

I am attempting to use WATTCP (in DOS) with an Allied Telesis Ethernet
board (I believe manufactured by FTP inc.)

Can someone please reccomend a good packet driver that is available by ftp?

Thanks,

--Mike


-----------[000036][next][prev][last][first]----------------------------------------------------
Date:      Mon, 4 Jul 1994 10:49:16 +0200
From:      Herbert.Hotz@alcatel.ch (Herbert Hotz)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.domains,comp.protocols.tcp-ip.ibmpc,comp.os.ms-windows.networking.tcp-ip,comp.os.ms-windows.networking.windows,comp.os.ms-windows.programmer.networks,comp.sys.ibm.pc.hardware.misc,comp.os.os2.network
Subject:   Re: WTB: Info on Schneider & Koch ethernet cards

In article <CsA1CD.M3v@aplcenmp.apl.jhu.edu> salman@aplcenmp.apl.jhu.edu (Ashfaq salman (703) 516-7616) writes:

>Hello,
>
>I badly need "any info" on the following cards:
>
>They are make by a German company Schneider & Koch and cards are 16-bit
>ethernet adapters. The software tries to identify them as SK-Junior
>boards.
>
>I am particularly interested in getting Novell, Windows, etc. drivers for it.
>I only have netbios software for it. I don't have any other documentation
>on it. Any information about its compatibility or the company will be greatly
>
>-Salman
>salman@lccinc.com

Would be interested too. Does SK have any drivers for their network products
foor WindowsNT? Do they offer support on the internet?

Kind regards
Herbert

Herbert Hotz (3.278) | Tel: +41-1-465 2249                 Fax: +41-1-465 3525 |
Alctatel STR AG      | INTERNET: Herbert.Hotz@alcatel.ch                       |
Friesenbergstr. 75   | X.25:     PSI%4795123920::H_HOTZ                        |
CH-8055 Zurich       | X.400:    C=ch ADMD=arcom PRMD=Alcatel S=Hotz G=Herbert |


-----------[000037][next][prev][last][first]----------------------------------------------------
Date:      Mon, 4 Jul 1994 15:01:34 GMT
From:      ronald@demon.co.uk (Ronald Khoo)
To:        comp.protocols.tcp-ip
Subject:   Re: HLLAPI TN3270 over Winsock

In article <Jun.28.09.57.53.1994.15307@remus.rutgers.edu>,
Richard Kao <rtkao@remus.rutgers.edu> wrote:

>There are several commercial vendors...
>Attachmate Extra For Windows
>Wall Data's Rumba 3270 for Windows
>DCA's IRMA Workstation for Windows
>These are the more popular ones.

Also NetSoft.  Try chanr@netsoft.mhs.compuserve.com for details.

Disclaimer: In my other life I work for a NetSoft distributor, although I
have nothing to do with that product line


-----------[000038][next][prev][last][first]----------------------------------------------------
Date:      Mon, 4 Jul 1994 20:52:53
From:      karl@cavebear.com (Karl Auerbach)
To:        comp.protocols.tcp-ip
Subject:   Reassembly.  Was: Re: Max IP packet length and MTU


>karl@cavebear.com (Karl Auerbach)
>> There is a strong argument to be made that when one does fragmentation, that
>> the first fragment which should be sent is the last fragment.
>>
>> The reason for doing this is that the receiver has no idea how big the
>> reassembled packet will be until the last fragment is received.  If the
>> receiver is "lucky" enough to get the last fragment first, it has a chance to
>> allocate an appropriate size reassembly buffer.

>There is an argument that allocating a reassembly buffer is a mistake.
>That implies that you are doing extra copying at precisely the worst
>moment - when somebody (likely NFS) is trying to get bulk data across
>the wire.  Or are you talking about the reassembly queue data
>structure?  With some work, you can use the headers for that....

I suspect that you are thinking of Un*x/BSD code constructs.  My concern is
about reassembly in general.  When I say "reassembly buffer" I mean that one
is allocating space to put the packet.  In memory rich environments I would
guess that people could allocate 64K byte buffers in anticipation of even the
largest possible size of IP reassembled packet.  In lesser environments, such
as pre-windows PCs and many embedded controller systems, it is important to
try to be careful about wasted buffer space.

I've made the argument a few times to the IPng folk, but never very strongly,
that whatever happens in IPng, one should be able to know the reassembled size
from any fragment, not just the last one.

(It would also be nice if TCP stacks would have some way to tell the
underlying IP that they are retransmitting an *identical* segment, so that IP
can assign the same IP ID as the original packet.  That way, the fragments
from the first and subsequent retransmissions could be aggregated at the
receiver.  The way it is done today, with different IP ID values, reassembly
is not possible even though all the pieces may be present at the receiver.)

--karl--


-----------[000039][next][prev][last][first]----------------------------------------------------
Date:      4 Jul 1994 16:21:39 GMT
From:      jdam@cs.uml.edu (jack tam)
To:        comp.protocols.tcp-ip
Subject:   Setting slip at home

Hi,
I am looking for pointers on how to set up SLIP at home.
Wonder if the FAQ discusses this. If it does, where is it?
Thank you
Jack


-----------[000040][next][prev][last][first]----------------------------------------------------
Date:      Mon, 4 Jul 1994 16:23:27 GMT
From:      vjs@calcite.rhyolite.com (Vernon Schryver)
To:        comp.protocols.tcp-ip
Subject:   Re: Max IP packet length and MTU

In article <BILLW.94Jul3231501@glare.cisco.com> billw@glare.cisco.com (William ) writes:
>    : Routers shouldn't have to do a lot of
>    : fragmenting, for the same reason. This is done because fragmenting
>    : is quite expensive...
>
>    Poppycock!-) IP framentation is simply a matter of pointer
>    manipulation and perhaps some scatter-gather abilities in the DMA
>    hardware. IP fragmentation being perceived as "expensive" is more
>    likely a function of IP fragmentation being left up to a router's
>    (underpowered) main CPU instead of VLSI.
>
>Regardless of whether fragmentations "should" be expensive or not, the fact
>remains that it \IS/ in most (all?) currently popular routers.  Since
>fragmentation is generally considered a bad idea regardless of the expense
>in routers, router vendors are not very motivated to improve the state of
>affairs.  There are more important things to do...

That is an overstatement based on the prejudices of the designers at a
particular vendor.  It's circular reasoning.  Since fragmentation is
considered unimportant, Cisco does not do it fast, which makes many of
us have those familiar arguments with Cisco people about how hard
fragmentation is and since it is slow, it must be unimportant.

It is also just plain wrong.  For UDP/IP based applications such as NFS,
it makes no sense for FDDI hosts to fragment to 1500 just so that
FDDI-Ethernet routers and bridges won't be stressed.   The usual Cisco
response to that point is to demand hosts implement MTU path discovery,
which is a good thing for TCP, but unreasonable for UDP, what with the
statelessness of NFS, subnetting, and the bad experiences Sun Microsystem's
customers have had recently with bridges and routers that don't handle
the DF bit right.

Consider the speed of Digital's FDDI-Ethernet bridges which can bridge
several Ethernets to an FDDI ring at 100% of the speed of 5 (or 6?)
Ethernets simultaneously, fragmenting as required.  I understand Cisco
has improved things, but a few years ago Cisco's FDDI-Ethernet
fragmentation speed on 4K NFS/UDP/IP/FDDI datagrams at one large customer
was a modest fraction of one Ethernet.  Of course a router is harder
than a bridge, but the fast paths should be similar and the Digital
boxes shows that IP fragmentation need not be such a big deal if one
puts asside prejudices about what is unimportant and necessarily slow.

Vernon Schryver    vjs@rhyolite.com


-----------[000041][next][prev][last][first]----------------------------------------------------
Date:      4 Jul 1994 19:55:41 GMT
From:      micky@namaste.cc.columbia.edu (Micky Liu)
To:        comp.protocols.tcp-ip
Subject:   ttcp_fwd-like program available?

For those of you who don't know ttcp_fwd is a general purpose program
for reading in data over one port and forwarding it to another port.
Both tcp and udp are supported and connections are duplex.  Anyway,

I am looking for a program that can take a socket connection as
input and fan it out to several other ports.  Does such an animal
exist yet?  If you know of any, I would appreciate any pointers
that you may be able to provide.

I know that this sounds like multicast and I have been looking into
using the MBONE software to achieve the same results, but I am
worrysome about having to make system level changes as well as
having to create special MBONE routers to go across LANs.  Basically,
I would be really happy with a 'user-level' multicast ability...

In any case, any guidance would be greatly appreciated.  Please try
to reply by email as I have a difficult time keeping up with netnews ;-)

Micky Liu
micky@ejv.com


-----------[000042][next][prev][last][first]----------------------------------------------------
Date:      4 Jul 94 19:37:54
From:      vanklem@uk.ac.sbu.vax (Mike van Kleef)
To:        comp.protocols.tcp-ip
Subject:   Re: Book Review - TCP/IP Illustrated, Volume 1

an enquiry regarding one of his other books. I've limited this message
to the main chapter headings; for those interested I can email the full
TOC.
Mike.
------------------------------------------------------------------
TCP/IP Illustrated, Volume 1: The Protocols, by W. Richard Stevens
ISBN 0-201-63346-9

Chapter 1.  Introduction      1
Chapter 3.  IP: Internet Protocol     33
Chapter 4.  ARP: Address Resolution Protocol     53
Chapter 5.  RARP: Reverse Address Resolution Protocol     65
Chapter 6.  ICMP: Internet Control Message Protocol     69
Chapter 7.  Ping Program     85
Chapter 8.  Traceroute Program     97
Chapter 9.  IP Routing    111
Chapter 10.  Dynamic Routing Protocols    127
Chapter 11.  UDP: User Datagram Protocol    143
Chapter 12.  Broadcasting and Multicasting    169
Chapter 13.  IGMP: Internet Group Management Protocol    179
Chapter 14.  DNS: The Domain Name System    187
Chapter 15.  TFTP: Trivial File Transfer Protocol    209
Chapter 16.  BOOTP: Bootstrap Protocol    215
Chapter 17.  TCP: Transmission Control Protocol    223
Chapter 18.  TCP Connection Establishment and Termination    229
Chapter 19.  TCP Interactive Data Flow    263
Chapter 20.  TCP Bulk Data Flow    275
Chapter 21.  TCP Timeout and Retransmission    297
Chapter 22.  TCP Persist Timer    323
Chapter 23.  TCP Keepalive Timer    331
Chapter 24.  TCP Futures and Performance    339
Chapter 25.  SNMP: Simple Network Management Protocol    359
Chapter 27.  FTP: File Transfer Protocol    419
Chapter 28.  SMTP: Simple Mail Transfer Protocol    441
Chapter 29.  NFS: Network File System    461
Chapter 30.  Other TCP/IP Applications    481

Appendix A.  The tcpdump Program    491
Appendix B.  Computer Clocks    499
Appendix C.  The sock Program    503
Appendix D.  Solutions to Selected Exercises    507
Appendix E.  Configurable Options    525
Appendix F.  Source Code Availability    539

Bibliography    543
Index    555

=================================================================
+ Mike van Kleef, Comp.& Maths, Southbank University, London, UK  +
+ Voice(071)-8157405 FAX(071)-8157499 EMail:vanklem@uk.ac.sbu.vax +
=================================================================


-----------[000043][next][prev][last][first]----------------------------------------------------
Date:      5 Jul 1994 09:17:30 -0700
From:      lstowell@pyrnova.mis.pyramid.com (Lon Stowell)
To:        comp.protocols.tcp-ip
Subject:   Re: Max IP packet length and MTU

In article <2v73ru$q7b@hpindda.cup.hp.com> raj@cup.hp.com writes: > >Poppycock!-) IP framentation is simply a matter of pointer >manipulation and perhaps some scatter-gather abilities in the DMA >hardware. IP fragmentation being perceived as "expensive" is more >likely a function of IP fragmentation being left up to a router's >(underpowered) main CPU instead of VLSI. Then on the LAN, if fragment 4 out of 23 is lost, the other 22 don't have to be retransmitted? Seems kinda expensive to me.  -----------[000044][next][prev][last][first]---------------------------------------------------- Date: Mon, 4 Jul 1994 22:28:13 GMT From: georgeb@netcom.com (George H. Bosworth) To: comp.infosystems.www,comp.infosystems.www.providers,comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmps Subject: SEF/UniForum Open Systems SIG, Tues. July 12 -- Internet Panel  SEF/UniForum Open Systems SIG (Formerly SEF Unix SIG) "Taxis to the Super Highway" -- An Internet Start-Up Panel -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Our Tuesday July 12 meeting will feature three Internet activists who deliver Internet products and services to businesses, individuals, and government organizations who want to travel on the Information Super Highway, but don't know how and need an expert driver: Andrew Conru, Internet Media Services, conru@netmedia.com Matisse Enzer, Internet Consultant and Educator, matisse@well.sf.ca.us Gary Kremen, Electric Classifieds, info.set@match.com Hear these diverse entrepreneurs talk about the newest in Internet features, about careers in Internet, and about what Internet is and isn't as a target for new business. The world of Internet is changing so rapidly that YOU MUST either devote some time to learn and understand it -- or be left behind. Place: Digital Equipment Corporation 130 Lytton Street, Palo Alto CA (Corner of Alma, 1 block N. of University) Date & Time: Tuesday, July 12, 1994, 7:00-9:00 p.m. Cost:$10; free for SEF and UniForum members and DEC employees

Information:  George Bosworth, Unix consultant, 415/851-3304,
georgeb@netcom.com

The Software Entrepreneurs' Forum and UniForum have combined forces
to co-sponsor what used to be the SEF Unix SIG, and call it the
SEF/UniForum Open Systems SIG. Same time and place, same objectives,
but now backed by two major organizations.

The Software Entrepreneurs' Forum, started in 1983, is a leading
Silicon Valley-based non-profit organization dedicated to software
professionals, with over 900 members. SEF informs and educates its
members on all facets of the software industry.  SEF also sponsors 10
other special interest groups, which meet once a month: Business
Operations, Intelligent Systems, International, Macintosh, Marketing,
Multimedia, Networking, Pen Software, Visual Basic, and Windows. Call
415/854-7219 for more SEF information.

UniForum, The International Association of Open Systems Professionals,
is a vendor-independent, not-for-profit professional association that
helps individuals and their organizations increase their Information
Systems effectiveness through the use of open systems, based on shared
industry standards. Central to UniForum's mission is the delivery of
high quality educations programs, trade shows and conferences,
publications, on-line services, and peer group interactions.  Call
800/255-5620 for more UniForum information.


-----------[000045][next][prev][last][first]----------------------------------------------------
Date:      4 Jul 1994 22:45:25 GMT
From:      micky@bonjour.cc.columbia.edu (Micky Liu)
To:        comp.protocols.tcp-ip
Subject:   Current Status of CMP and TMux?

I've just retrieved the minutes for the last IETF BOF meeting on
tcp connection multiplexing and it is from last year (early 1993).
I am wondering if there was any further work done on either the
CMP (Connection Multiplexing Protocol) or on TMux.  Any pointers
would be greatly appreciated.

Micky Liu
micky@ejv.com


-----------[000046][next][prev][last][first]----------------------------------------------------
Date:      4 Jul 94 23:02:11 GMT
From:      jkay@cs.ucsd.edu (Jon Kay)
To:        comp.protocols.tcp-ip
Subject:   Re: Max IP packet length and MTU

Helge Moulding (hsm@unislc.slc.unisys.com) sez:
> Routers shouldn't have to do a lot of
> fragmenting, for the same reason. This is done because fragmenting
> is quite expensive...

NFS does IP fragmentation because it's cheaper than sending out gobs
of individual small UDP packets (especially if you have to wait for a
response for each one).

This tends to be a win on LANs; across WANs it doesn't work so
well - fragments start getting dropped too frequently, probably
because of the increased number of potentially full queues that must
be crossed.  That drops entire packets, and your congestion control
scheme often ends up backing up so far you lose throughput relative to
the non-fragmented case.

karl@cavebear.com (Karl Auerbach)
> There is a strong argument to be made that when one does fragmentation, that
> the first fragment which should be sent is the last fragment.
>
> The reason for doing this is that the receiver has no idea how big the
> reassembled packet will be until the last fragment is received.  If the
> receiver is "lucky" enough to get the last fragment first, it has a chance to
> allocate an appropriate size reassembly buffer.

There is an argument that allocating a reassembly buffer is a mistake.
That implies that you are doing extra copying at precisely the worst
moment - when somebody (likely NFS) is trying to get bulk data across
the wire.  Or are you talking about the reassembly queue data
structure?  With some work, you can use the headers for that....

Even if you hate traditionally complex network buffer descriptors like
mbufs more than the performance penalty from using a reassembly
buffer, there is an alternative algorithm: allocate a 9k ("likely
max") buffer (on many of the networks I've seen, max NFS requests are
responsible for most of the fragments).  You have to be prepared to be
wrong under your scheme anyway, so this boils down the the same thing
but less harsh on the numerous schemes that hope for FIFO order to get
good performance (or even, as you observed, to work at all, in some
unfortunate instances...).

Jon
--
--
Email:                 jkay@cs.ucsd.edu


-----------[000047][next][prev][last][first]----------------------------------------------------
Date:      Mon, 4 Jul 1994 23:25:53 GMT
From:      rstevens@noao.edu (W. Richard Stevens)
To:        comp.protocols.tcp-ip
Subject:   Re: FTP timers modification ?

> On a SUN Sparc 10 Solaris 2.3 we are initiating
> an ftp-session.
>
> If the remote host/network is not reachable the ftp
> application will time out only after 8 times trying
> to send an SYN-segment to connect to the other control-port.
> With the exponential backoff
> timers this takes about 4 minutes. For out operational
> system this is too long.
>
> 1. How does on change the number of retries, or the timer
> behaviour (preferable via the ndd utility in Solaris 2.3)

Check out Appendix E of my recent book "TCP/IP Illustrated"
(Addison-Wesley, 1994): all the Solaris 2.3 configurable
TCP/IP parameters are in there.  To change this one you need
to execute ndd and change the tcp_ip_abort_cinterval value
(which defaults to 240000 ms, or 4 minutes).

Rich Stevens


-----------[000048][next][prev][last][first]----------------------------------------------------
Date:      Mon, 4 Jul 1994 23:28:27 GMT
From:      rstevens@noao.edu (W. Richard Stevens)
To:        comp.protocols.tcp-ip
Subject:   Re: Book Review - TCP/IP Illustrated, Volume 1

> an enquiry regarding one of his other books. I've limited this message
> to the main chapter headings; for those interested I can email the full
> TOC.

FYI, the entire TOC (ascii and PS), Preface, and complete sample chapter in
PS are available via anonymous ftp from aw.com in the aw.prof.comp.series
directory.

Rich Stevens


-----------[000049][next][prev][last][first]----------------------------------------------------
Date:      5 Jul 1994 12:31:55 -0700
From:      lstowell@pyrnova.mis.pyramid.com (Lon Stowell)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP Keep Alives

In article <773409903snz@paxdata.demon.co.uk> Giles@paxdata.demon.co.uk writes:
>
>I am trying to work out how to handle TCP Keep Alives in my company's ISDN
>bridging products.  RFC1122 states that Keep Alives MUST be defaulted to
>off, be sent at configurable intervals and default to no less than every
>two hours.  This would suggest to me that no specific support for these
>packets is required (i.e. allow them to bring up the ISDN link and be sent
>to the far end which will respond).

You realize you are treading on religious issues.

>
>Imagine my surprise when I found that NCSA Telnet's FTP client sends what
>appears to be a Keep Alive at three minute intervals!  Does this mean that
>I need to "spoof" the Keep Alive (just like an IPX/NCP Keep Alive) so as to
>keep ISDN bills manageable?
>

You would likely want to make this configurable....allow the users
to decide whether to have your black box spoof the keepalives or
indeed pass them thru to the far end.

Some folks tune the keepalive down to very short periods and use
it to detect dead connections...this allows them to use telnet and
other such protocols transparently to an application without
having to put dead-session detection in that application.

Spoofing would pretty much eliminate the ability of those folks to
do this...

Then there are some folks who put all dead session detection in the
application and don't need keepalives at all, even though the
systems administrator has configured keepalives at short
intervals.


-----------[000050][next][prev][last][first]----------------------------------------------------
Date:      5 Jul 1994 10:22:57 -0500
From:      gpalmer@blue.weeg.uiowa.edu (Gary Palmer)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject:   [Q] Pricing for Trumpet winapps

Has anyone read or heard of what the shareware pricing scheme might be
for Peter Tattam's winapps applications?

TELW, FTPW, etc. are all part of a zip file that contain a couple of
simple documentation files--one doc file states that the software will
become shareware.  I also obtained a copy of TRMPTEL.EXE, which wasn't
packaged with anything else.  TRMPTEL is a much improved Telnet program
over TELW.  It seems to lack some things like the ability to remap
backsapce for delete without having to press Ctrl-backspace, but has much
better vt100 terminal emulation than TELW.

I am in a position where I need to make a decision on TCP/IP software
for Windows and would like to consider TRUMPET applications.  I know
the price of Trumpet Winsock, but have never seen what the price is
(or will be) for the suite of apps.


-----------[000051][next][prev][last][first]----------------------------------------------------
Date:      Tue, 5 Jul 1994 03:24:40 GMT
From:      derekt@superior.carleton.ca (Derek Taylor)
To:        comp.protocols.tcp-ip
Subject:   Setting up Trumpet Winsock?


Bonehead, I know, but could someone tell me how to designate IP address,
Name server, Domain Server, Netmask, and Time server. Is there a way of
checking your own address and does it have to be entered numerically?
Thanks, Derek.


-----------[000052][next][prev][last][first]----------------------------------------------------
Date:      05 Jul 1994 03:37:42 GMT
From:      wy1z@elvis.coe.neu.edu (Scott Ehrlich)
To:        comp.protocols.tcp-ip
Subject:   HELP: How to transfer files via telnet?


Although this newsgroup doesn't have a .misc suffix, from the types of
messages posted, I think I'm safe asking this here:

A friend of mine told me he was able to transfer a binary file during
a telnet session (via an Amateur Radio TCP/IP connection to another
Ham TCP/IP station).

I've tried experimenting with this a bit on the Internet, but have not
been successful.  I tried to telnet from one of my accounts to another
account, then transfer a binary file, but no luck.

If anyone has successfully done this or knows how, please e-mail me.

Thanks!

--
Scott Ehrlich, Amateur Radio Callsign: wy1z
How to reach me: wy1z@neu.edu [Internet], wy1z@wa1phy.ma [Packet]
Boston ARC ftp archives: ftp oak.oakland.edu /pub/hamradio
Boston ARC Web page: http://www.acs.oakland.edu/barc.html


-----------[000053][next][prev][last][first]----------------------------------------------------
Date:      5 Jul 1994 04:33:10 GMT
From:      bass@cais.cais.com (Tim Bass (Network Systems Engineer))
To:        comp.protocols.tcp-ip
Subject:   Re: Book Review - TCP/IP Illustrated, Volume 1

This review is too late.  Stevens book, _TCP/IP Illustrated_
is great book.  This books has been out as long as Philadephia
(the movie) or longer.  We certainly don't need a review on
6 month old movies OR 6 month old books.

This goes to show everyone; The Internet is just like the
wild west - every gun trying to make a name for himself.
I guess cowboys with shiny guns always interest kids who
ride ponies.

Danny (danny@cs.su.oz.au) wrote:
:      title: TCP/IP Illustrated, Volume 1
:           : The Protocols
:         by: W. Richard Stevens
:   subjects: computer science, networking
:      other: 576 pages, bibliography, index

: Stevens is well known for his books on Unix programming.  In the first
: volume of _TCP/IP Illustrated_ he deals with the specification and
: behaviour of the protocols that make up the TCP/IP suite.  He begins
: at the bottom of the network stack, with the link layer protocols,
: and works his way upwards, dealing with IP, ARP, ICMP, routing, UDP,
: IGMP, DNS, TFTP, BOOTP, TCP, SNMP, telnet, FTP, SMTP and NFS (among
: others).  Chapters on tools like ping and traceroute are included,
: and a tcpdump program is used throughout (on a real network) to
: allow us to actually watch the protocols in action on the wire;
: we are always kept in touch with what is happening at the link layer.

: The focus is very much on how the protocols work in practice rather
: than on the theory behind them.  So the discussion of RIP includes
: a detailed look at the protocol's behaviour on an example network,
: but only mentions the counting to infinity problem in passing,
: and ASN.1 is only given a brief description, since "the details of
: ASN.1 and BER are only important to implementors of SNMP".  If you
: are primarily interested in the theory behind the algorithms and
: protocols then this will be frustrating, but if you are interested
: in the protocols from an practical perspective then it will probably
: be a welcome simplification.

: _TCP/IP Illustrated_ is not an introductory book: the treatment is more
: systematic than pedagogic and a fair amount of knowledge is assumed.
: (So, for example, SLIP and PPP are discussed in chapter two along with
: the other link layer protocols; this would probably be confusing to
: someone without much networking background.)  This approach does make it
: easy to find things, however, and, together with a thorough index,
: enhances the volume's value as a reference.  There are useful exercises
: at the end of each chapter (with solutions at the back), which make it
: suitable as a textbook for those who already have some acquaintance with
: networking.

: For many years the recommended survey of TCP/IP protocols has
: been Comer's _Internetworking with TCP/IP_.  While I certainly
: wouldn't suggest that that book has been superseded, since it has
: a rather different approach, _TCP/IP Illustrated_ is definitely
: serious competition.  Particularly attractive features of Stevens'
: book are its coverage of different Unix versions (BSD4.3, Sun, SVR4,
: Solaris, BSD4.4 and others), its consideration of what the protocols
: actually mean in terms of "packets on the wire" and its concentration
: on issues of practical importance.  As mentioned, complete beginners
: and those interested in theoretical issues will probably prefer
: other books, but for many people I think _TCP/IP Illustrated_ would
: be the book of choice on TCP/IP.

: -

: %T 	TCP/IP Illustrated, Volume 1 - The Protocols
: %A 	W. Richard Stevens
: %D 	1994
: %O 	hardcover, bibliography, appendices, index
: %G 	ISBN 0-201-63346-9
: %P 	xix,576pp
: %K 	computer science, networking

: Danny Yee (danny@cs.su.oz.au)
: 30 June 1994

:  -----------------------------------------------------------------
:  All book reviews by Danny Yee are available via anonymous FTP to:
:  ftp.anatomy.su.oz.au in /danny/book-reviews (index INDEX) or with
:  http://www.anatomy.su.oz.au/danny/book-reviews/index.html !Enjoy!
:  -----------------------------------------------------------------
:  Copyright (C) Danny Yee 1994 : Comments and criticism are welcome
:  -----------------------------------------------------------------


-----------[000054][next][prev][last][first]----------------------------------------------------
Date:      5 Jul 1994 12:40:04 -0400
From:      goutham@access3.digex.net (S.Goutham)
To:        comp.protocols.tcp-ip
Subject:   Info needed on auto. discovery of nodes in a net.


Can anyone out there please give me some suggestions on how to do
automatic discovery of all the nodes in a subnet and going beyond
the subnet? How is this generally done? I would greatly appreciate
any help on hints/pointers/books. Thanks...Goutham.


-----------[000055][next][prev][last][first]----------------------------------------------------
Date:      5 Jul 1994 06:42:02 GMT
From:      barryf@iol.ie (Barry Flanagan)
To:        comp.protocols.tcp-ip
Subject:   Multiple hosts under 1 hostname - HOW?

Hi,

I need to have connections to a certain hostname work like a huntgroup - if
the first host doesn't respond then the next on the list is tried, until a

Can any kind soul tell me how to do this with (I guess) DNS records?

-Barry

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


-----------[000056][next][prev][last][first]----------------------------------------------------
Date:      5 Jul 1994 06:42:47 GMT
From:      tli@cisco.com (Tony Li)
To:        comp.protocols.tcp-ip
Subject:   Re: Max IP packet length and MTU

In article <CsFC74.8GF@calcite.rhyolite.com> vjs@calcite.rhyolite.com
(Vernon Schryver) writes:

That is an overstatement based on the prejudices of the designers at a
particular vendor.  It's circular reasoning.  Since fragmentation is
considered unimportant, Cisco does not do it fast, which makes many of
us have those familiar arguments with Cisco people about how hard
fragmentation is and since it is slow, it must be unimportant.

As of 10.0, cisco routers with the silicon switch processor now fragment
extremely quickly.  I would post a number, but I haven't been able to get
enough test equipment together to find the top end.

It is also just plain wrong.  For UDP/IP based applications such as NFS,
it makes no sense for FDDI hosts to fragment to 1500 just so that
FDDI-Ethernet routers and bridges won't be stressed.   The usual Cisco
response to that point is to demand hosts implement MTU path discovery,
which is a good thing for TCP, but unreasonable for UDP, what with the
statelessness of NFS, subnetting, and the bad experiences Sun Microsystem's
customers have had recently with bridges and routers that don't handle
the DF bit right.

And just so no one gets confused, hosts should STILL do path MTU discovery.
There's a reason why "Fragmentation considered harmful" is a classic
article.  It still stresses the router, the receiving host, and, when
there's congestion, the network as a whole.

Tony


-----------[000057][next][prev][last][first]----------------------------------------------------
Date:      Tue,  5 Jul 94 18:29:00 -0640
From:      john.will@dscmail.com (John Will)
To:        comp.protocols.tcp-ip
Subject:   Re: Book Review - TCP/IP

SUBJECT:Re: Book Review - TCP/IP Illustrated, Volu

R > Any idea how much the book costs ?

The price I paid was 47.50.

R >What do the followup volumes contain ?

The follow-up volume haven't been written yet, so they don't contain
anything. :-)


-----------[000058][next][prev][last][first]----------------------------------------------------
Date:      Tue,  5 Jul 94 18:31:00 -0640
From:      john.will@dscmail.com (John Will)
To:        comp.protocols.tcp-ip
Subject:   u

Yu>Message-ID: <CsH52z.L5r@epsilon.com>
Yu>Newsgroup: comp.protocols.tcp-ip

Hmm... someone needs to do some work on their configuration! :-)
If you're listing, "Your Name Here", I'd check a few things before
posting any more articles.


-----------[000059][next][prev][last][first]----------------------------------------------------
Date:      5 Jul 94 15:28:28 PDT
From:      tbleakney@hmcvax.ac.hmc.edu
To:        comp.protocols.tcp-ip
Subject:   IP dead on PPP link

I have been trying to get MacPPP to work for weeks, and I am
stumped. I am posting to this group because I think I could have
a problem with the IP layer.

On the Mac I am using MacTCP 2.04 and system 7.1.  On the
other end of the dial-up line is a Datability server on a campus
LAN, with a Class B network with a subnet mask of 255.255.255.0.

I have setup MacTCP with manual IP assignment.  When I dial in,
I give the server a command of:
connect ppp 0.0.0.0
the server is supposed to pick an IP out of the IP pool.  There is only
1 such address, and it is the one I am using. It is on the same subnet
as the server.

MacPPP responds, saying the PPP link is established.  The stats
box shows that some packets were exhanged in setting up the link.
However, when I try a Ping to any IP address on the LAN (including
the server), NOTHING comes back.  The server has an ARP proxy for my
IP address, but this doesn't help.
I am the first person to ever try PPP on this campus network, so
we don't know where to start.  If anyone has a clue to what I should
try next, I would greatly appreciate your help.
Thanks.
--------
tbleakne@chs.cusd.claremont.edu


-----------[000060][next][prev][last][first]----------------------------------------------------
Date:      5 Jul 1994 08:42:06 GMT
From:      mw00378@lime.sbil.co.uk (Malcolm White)
To:        comp.protocols.tcp-ip
Subject:   Re: IP Address

The address you are attempting to change to is a different Class C address and therefore the two devices will not communicate directly. The first three bytes must be the same for a Class C network so you'll have to stick with 192.0.0.x ( or change both! ).

Regards, Malcolm White
Salomon Brothers, London


-----------[000061][next][prev][last][first]----------------------------------------------------
Date:      Tue, 5 Jul 1994 09:04:37 GMT
From:      rsgawera@wg.icl.co.uk (Raj Gawera)
To:        comp.protocols.tcp-ip
Subject:   Re: Book Review - TCP/IP Illustrated, Volu

Hi,
Any idea how much the book costs ? What do the followup volumes
contain ?
cheers,
Raj Gawera
rsgawera@wg.icl.co.uk


-----------[000062][next][prev][last][first]----------------------------------------------------
Date:      5 Jul 1994 09:22:12 GMT
From:      bertg@fwi.uva.nl (Bert Gijsbers)
To:        comp.protocols.tcp-ip
Subject:   Re: Book Review - TCP/IP Illustrated, Volume 1

bass@cais.cais.com (Tim Bass (Network Systems Engineer)) writes:

>This review is too late.  Stevens book, _TCP/IP Illustrated_
>is great book.  This books has been out as long as Philadephia
>(the movie) or longer.  We certainly don't need a review on
>6 month old movies OR 6 month old books.

I cannot agree with this.  Books like these are well worth
reading years after publishing date.  The same holds for
good reviews on them.

>This goes to show everyone; The Internet is just like the
>wild west - every gun trying to make a name for himself.
>I guess cowboys with shiny guns always interest kids who
>ride ponies.

Bert Gijsbers


-----------[000063][next][prev][last][first]----------------------------------------------------
Date:      Tue, 5 Jul 1994 14:54:02 EST
From:      MARCO PACE <MPACE@ESOC.BITNET>
To:        comp.protocols.tcp-ip,comp.unix.solaris
Subject:   TCP anomalous (?) behaviour in application

Hi,

can anybody provide some useful advice on the following problem?

I have two applications (running on a SUN workstation with Solaris 2.3)
communicating using TCP. One is a server, accepting connections; the
other is a client, connecting to the server. The client writes some
data to the server after connecting to it, the server reads the data
after accepting the connection.

The behaviour I can't explain is that, if the server dies (is killed)
after accepting the connection from the client, the client can still
perform successfully its write without realizing the death of the
server. In other words, the write primitive returns successfully.
A second write to the server, on the contrary, fails as expected.

Why this behaviour ? I think it might be related to the connection
status (to be checked with the UNIX utility 'netstat') which appears
to be still existing after the server's death.
How can I detect the server's death immediately ??

Any help will be appreciated.

Thanks,

Marco

-------------------------------------------------------------------------
Marco Pace, Software Engineer                   Tel   : +49 6151 903065
Vitrociset S.p.A.                               Fax   : +49 6151 904065
ESOC, Robert-Bosch-Strasse 5                    e-Mail: mpace@esoc.bitnet


-----------[000064][next][prev][last][first]----------------------------------------------------
Date:      5 Jul 1994 10:09:58 GMT
From:      dmore@gisws3.rtpnc.epa.gov (Duane More)
To:        comp.protocols.tcp-ip,comp.sys.novell
Subject:   APIs for LWP/LWG

I am interested in finding out the development abstractions
(RPC isn't really an API) available for LAN WorkPlace for DOS
and LAN WorkGroup for DOS.

My understanding is that the WINSOCK interface is available
for LW[PG] clients running under MS Windows. The quesiotns are then:
1) Is the ONC RPC (or some variant thereof) available for LW[PG] running
under windows. Preferably something provided by Novell because I know
of DCE vendors whose stuff will run on WINSOCK.
2) What API is available for non-Windows devices. The current environment
I am in has 8000-9000 286 devices which can be rather painful to run
Windows on.
3) Is the RPC abstraction available for the non-Windows devices
running LW[PG].

I am don't regularly read this group so I would appreciate mail responses
if possible. I will post a summary if the response merits it.

--
Duane N. More                       |  In Support of:
dmore@unixmail.rtpnc.epa.gov        |      US EPA


-----------[000065][next][prev][last][first]----------------------------------------------------
Date:      Tue, 5 Jul 1994 16:38:45
To:        comp.protocols.tcp-ip
Subject:   Re: Info needed on auto. discovery of nodes in a net.

In article <2vc2d4$nka@access3.digex.net> goutham@access3.digex.net (S.Goutham) writes: >Can anyone out there please give me some suggestions on how to do >automatic discovery of all the nodes in a subnet and going beyond >the subnet? How is this generally done? I would greatly appreciate >any help on hints/pointers/books. Thanks...Goutham. Well, I just ping all all of the addresses on the subnet and record those that respond. "Active monitoring" is the polite term but it is really a " daemon-pinger". Port connection attempts with record of those accepted follow. I roll my own but understand that ATT has just released "PingWare" to do the same thing is you have a spare four grand (six with consultation). If you want a pointer to get started, try reading up on ARPs. A. Padgett Peterson, P.E. Cybernetic Psychophysicist We also walk dogs PGP 2.4 Public Key Available  -----------[000066][next][prev][last][first]---------------------------------------------------- Date: 5 Jul 1994 11:51:26 GMT From: carlson@Xylogics.COM (James Carlson) To: comp.protocols.tcp-ip Subject: Re: Annex and general SLIP information needed (soon)  In article <1994Jul3.043914.29871@unlv.edu>, ftlofaro@unlv.edu (Frank Lofaro) writes: |> An organization here is going to be soon providing SLIP |> access. However, they plan to use dynamic IP address assignment on a |> per-port basis. In other words, connection on a given port gives you a |> given IP address. They are using Xylogics Annex terminal servers (one |> of them quite new, supposedly supports both SLIP/CSLIP and PPP). There |> is going to be authentication of individual users. We've supported both [C]SLIP and PPP since October 1992. |> Unfortunately, dynamic IP address assignment would be a |> headache for me and many other users. It would make it impossible to |> run ftp/http and other servers, and would even make it very difficult |> to find our own machine to telnet back into if we wanted to connect to |> it through the Internet. It is especially hard for those that have |> un*x based machines, (e.g. Linux) Btw: in our documentation, this is called "static IP addressing," since the IP address is fixed per port. "Dynamic IP addressing" is assigning addresses by user name or any other metric. (The default security daemon is able to assign addresses by user name, but any other data may be used.) |> The justification given is that static IP addresses are harder |> to set up and that they could run out. Well, they do cause a *lot* of problems. The first problem, of course, is what to do if you have more users than you have addresses from the NIC. It's quite likely that the number of ports you have is much smaller than the number of users, so assigning addresses by port will conserve this resource better than by assigning by user. The second problem is more serious. There is a routing problem associated with allowing users with unique IP addresses to "roam" among a set of gateways. If you use one large subnet (not an option for many Internet providers who have boxes in several locations), then a user hanging up and dialing in again on a different line will experience trouble due to stale data in the host (or router) ARP cache. If you break up the Annexes across subnets, then you need to use RIP to reassign the routes, and everything gets even *more* complex, because not everyone honors host routes. In general, rapidly changing topologies are a "bad" thing when using Internet protocols. |> Anyone have any pointers to documents and information on |> static versus dynamic IP address assignment, or on Annex terminal |> server configuration? Especially information on the benefits of static |> addressing and how to configure it on a Xylogics Annex. Any |> information would be appreciated, as soon as possible (things are |> moving very quickly). By "static" I assume you mean per-user assignment. You can set this up quite easily by turning on the "port dialup_address" switch and entering a user-name/IP-address pair in the acp_dialup file. |> Does anyone know why stty fwdtimer x where x is less than 5 |> (the default) says I can't lower it? Also, if an Annex is in non-SLIP |> mode, does it hold characters (e.g. use the Nagle algorithm)? Could |> this be turned off on a port by a regular user for that session? This |> information might be helpful for another project that I may have to |> undertake soon. The "fwdtimer" parameter has nothing to do with the Nagle algorithm. It controls the behavior of the serial port itself, not the network layers. You can't set it below the value configured in "port forwarding_timer" for security reasons. Administrators don't like users taking more bandwidth than allotted. The Nagle algorithm is enabled on all Annex TCP connections. There is currently no way for the administrator to control this. (Based on your questions, I should warn you that timing is in NO way guaranteed by TCP. If your "other project" requires that some special relationship exists between the timing of characters and the delivery of them to your application, you may need to rethink that project.) -- James Carlson <carlson@xylogics.com> Tel: +1 617 272 8140 Annex Software Support / Xylogics, Inc. +1 800 225 3317 53 Third Avenue / Burlington MA 01803-4491 Fax: +1 617 272 2618  -----------[000067][next][prev][last][first]---------------------------------------------------- Date: 5 Jul 1994 18:38:13 -0400 From: barr@pop.psu.edu (David Barr) To: comp.protocols.tcp-ip Subject: Re: Round robin DNS?  In article <abobaCsAtC9.Hzr@netcom.com>, Bernard Aboba <aboba@netcom.com> wrote: >I am told that the latest version of BIND supports load balancing >via "round robin" DNS. I am interested in how well this works, >pointers to docs, etc. It works as well as to be expected with a round-robin algorithm. It doesn't take much thought to realize the limitations of round-robin. A good source of docs would be the BIND docs itself. However, I'm told ever since the root nameservers all switched to using round-robin versions of BIND, mail load on big equal-preference-MX sites like uunet.uu.net became much more uniform. --Dave -- "Opera is when a guy gets stabbed in the back and instead of bleeding he sings." - Ed Gardner  -----------[000068][next][prev][last][first]---------------------------------------------------- Date: Tue, 5 Jul 1994 12:05:03 +0000 From: giles@paxdata.demon.co.uk (Giles Heron) To: comp.protocols.tcp-ip Subject: TCP Keep Alives  Hi I am trying to work out how to handle TCP Keep Alives in my company's ISDN bridging products. RFC1122 states that Keep Alives MUST be defaulted to off, be sent at configurable intervals and default to no less than every two hours. This would suggest to me that no specific support for these packets is required (i.e. allow them to bring up the ISDN link and be sent to the far end which will respond). Imagine my surprise when I found that NCSA Telnet's FTP client sends what appears to be a Keep Alive at three minute intervals! Does this mean that I need to "spoof" the Keep Alive (just like an IPX/NCP Keep Alive) so as to keep ISDN bills manageable? Any help with this would be much appreciated... -- | Giles Heron | Phone: +44 442 236336 | | Paxdata Networks Limited | Fax: +44 442 236343 | | Frogmore Road, Hemel Hempstead, | Email: giles@paxdata.demon.co.uk | | HERTS HP3 9RW, United Kingdom. | Opinions are of course my own... |  -----------[000069][next][prev][last][first]---------------------------------------------------- Date: Tue, 5 Jul 1994 12:50:59 GMT From: btl@hogpf.ho.att.com (-B.LING) To: comp.protocols.tcp-ip,comp.protocols.nfs Subject: Help with PC-NFS - unable to register (PCNFSDPROG...)  folks, i'm running a SUN 630 server which has pc-nfs running on it. at least, it used to. all of a sudden, for some unknown reason, when trying to run the rpc.pcnfsd daemon, i'm getting: machname pcnfsd[165]: unable to register (PCNFSDPROG, PCNFSDVERS, udp). can anyone help me with this? does PC-NFS has a license which can expire? any ideas would be greatly appreciated.... thanx in advance, -- %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% %% The Linguistic Tongue, AT&T %% C Code. C Code Run. Run, Code, RUN! %% %% btl@hogpf.att.com %% PLEASE!!!! %% %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%  -----------[000070][next][prev][last][first]---------------------------------------------------- Date: 5 Jul 1994 19:31:57 -0400 From: jhawk@panix.com (John Hawkinson) To: comp.dcom.sys.cisco,comp.protocols.tcp-ip,comp.dcom.servers Subject: [draft TWO] comp.dcom.sys.cisco Frequently Asked Questions (FAQ)  Archive-name: cisco-faq Last-modified: 5 July 1994 Version: Beta 0.2 This is the DRAFT frequently asked questions (FAQ) list for comp.dcom.sys.cisco. There should evntually be an html version of this FAQ available. Question should also be numbered, and perhaps divided into subcategories for large things (like ntp...) Please contribute answers to the questions in the Todo section! If your answer is somewhat complicated, posting would probably be best (to comp.dcom.sys.cisco). Otherwise, e-mail it to cisco-faq@panix.com. I meant to get some of these todos done, but I've just been too busy, so I'm posting this as-is now. This draft FAQ is in RFC1153 digest format, so you can follow each question with your newsreader. I suppose that question-numbers should be moved to the From: field. Note that Date: fields represent last-modification times for the questions. Table of Contents 1. How can I contact cisco? 2. What is this newsgroup? 3. What's the first letter in cisco''? 4. How do I save the configuration of a cisco? 5. Where can I get ancillary software for my cisco? 6. Is there a World-Wide-Web (www) information source? 7. How can I get my cisco to talk to a third party router over 8. How can I get my cisco to talk to a 3rd-party router over Frame Relay? 9. How can I use debugging? 10. How can I use NTP (Network Time Protocol) with my cisco? 10a. Sample NTP configurations 11. Presence of cisco employees here 12. How do I avoid the annoying DNS lookup if I have misspelled a command? 13. Tracing bad routing information 14. Acknowledgements. todo: ---- * How to configure TACACS * What is SNMP and how can I use it? What software is available and how do I use Cisco enterprise MIBs? * Pointers to other s/w that's particularly useful in this sort of routing environment (like Charley Kline's VLSM program). * Sample configurations of complicated things, like NTP. Also routing protocols samples, but care should be taken not to just duplicate the docs. * Pointers to other net resources, like comp.protocols.tcp-ip, RFCs, the firewalls mailing list, etc (bgpd?[or is it cidrd now? :-)]). * Hints about confusing and not-well documented things like xtacacs... * Comments on interoperability issues WRT other vendors. * What's SMARTnet, why should I subscribe, how much does it cost, and what do I get? * What should I name my router, my interfaces, etc.? * How should I restrict access to my router? * What can I do about source routing? * Where can I buy Cisco equipment. mail order used turnkey (much hand-holding/pre-setup) etc? * Should we adjust the buffer parameters on the routers? What should be the indicator before tunning the buffer parameters? How should one fine tune the buffer parapeters? * discribtions of "show buffer" output, how should one read these output? * what routing protocol should I use? * what is the real purpose of the network subcommand of router commands? When do I not want to include a network I know about? * What is a VLSM and why would I want one? What supports them? * What are some methods for conserving IP addresses for serial lines? * Is there a block of private network numbers I can use within my organization only? When should I use them? How do I access them from outside? * What do I do if I have to partition a network number? * Questions and answers about access lists The Real Stuff: ------------------------------ From: cisco-faq Date: 5 July 1994 Subject: How can I contact cisco? The following phone numbers are available: Technical Assistance Center (800) 553-6387 (800) 553-2447 (553-24HR) Training Services (415) 903-7290 Protocol Interface (cisco Systems Training Partner) (415) 491-8950 Customer Service (Documentation, Warranty & (800) 553-6387 Contract Services, Order Status Order Processing (415) 903-7231 Engineering (800) 553-2447 (553-NETS) On-site Services, Time & Materials Service (800) 829-2447 (829-NETS) cisco can also be contacted via e-mail to tac@cisco.com -- please follow the directions available on CIO before doing this. cisco provides an on-line service for information about their routers and other products, called CIO (cisco Information Online?). telnet to cio.cisco.com for more details. ------------------------------ From: cisco-faq Date: 5 July 1994 Subject: What is this newsgroup? [anyone have a copy of the charter?] comp.dcom.sys.cisco, which is gatewayed to the mailing list cisco@spot.colorado.edu, is a newsgroup for discussion of cisco hardware and related issues. Remember that you can also consult with cisco technical support. ------------------------------ From: cisco-faq Date: 5 July 1994 Subject: What's the first letter in cisco''? Apparently it used to be a lowercase c (cisco Systems), but rumor has it that it has now becmome a more convetional and less-pleasing uppercase C. ------------------------------ From: cisco-faq Date: 5 July 1994 Subject: How do I save the configuration of a cisco? If you have a tftp server available, you can create a file on the server for your router to write to, and then use the write network command: mytftpserver$ touch /var/spool/tftpboot/myconfig
mytftpserver$chmod a+w /var/spool/tftpboot/myconfig myrouter#write net Remote host [10.7.0.63]? 10.7.0.2 Name of configuration file to write [myrouter-confg]? foobar Write file foobar on host 10.7.0.2? [confirm] y Additionally, you can also use an expect, available from: ftp://ftp.uu.net/languages/tcl/expect/expect.tar.gz ftp://ftp.cme.nist.gov/expect/expect.tar.gz script to telnet to the router and do a write terminal''. ------------------------------ From: cisco-faq Date: 5 July 1994 Subject: Where can I get ancillary software for my cisco? Try ftping to ftp://ftp.cisco.com/pub It's a hodgepodge collection of useful stuff, some maintained and some not. ------------------------------ From: cisco-faq Date: 5 July 1994 Subject: Is there a World-Wide-Web (www) information source? You can try the www homepage of this FAQ http://www.panix.com/cisco-faq [no, it's not there yet] or the cisco Systems homepage http://sunsite.unc.edu/cisco/cisco-home.html ------------------------------ From: cisco-faq Date: 5 July 1994 Subject: How can I get my cisco to talk to a third party router over a serial link? You need to tell your cisco to use the same link-level protocol as the other router; by default, ciscos use a rather bare variant of HDLC (High-level Data Link Control) all link-level protocols use at some level/layer or another. To make your cisco operate with most other routers, you need to change the encapsulation from HDLC to PPP on the relevant interfaces. For instance: sewer-cgs#conf t Enter configuration commands, one per line. Edit with DELETE, CTRL/W, and CTRL/U; end with CTRL/Z interface serial 1 encapsulation ppp ^Z sewer-cgs#sh int s 1 Serial 1 is administratively down, line protocol is down Hardware is MCI Serial MTU 1500 bytes, BW 1544 Kbit, DLY 20000 usec, rely 255/255, load 1/255 Encapsulation PPP, loopback not set, keepalive set (10 sec) ^^^^^^^^^^^^^^^^^^^^^^^^^^^ [...] If you're still having trouble, you might wish to turn on serial interface debugging: sewer-cgs#ter mon sewer-cgs#debug serial-interface ------------------------------ From: cisco-faq Date: 5 July 1994 Subject: How can I get my cisco to talk to a 3rd-party router over Frame Relay? You should tell your cisco to use encapsulation frame-relay ietf'' (instead of encapsulation frame-relay'') on your serial interface that's running frame relay if your frame relay network contains a diverse set of manufacturers' routers. The keyword ietf'' specifies that your cisco will use RFC1294-compliant encapsulation, rather than cisco's optimized version (which only talks to other ciscos). If only a few routers in your frame relay cloud are other brands, then you can use optimized cisco encapulsation on everything and specify the exceptions with the frame-relay map command: frame-relay map ip 10.1.2.3 56 broadcast ietf ^^^^ (ietf stands for Internet Engineering Task Force, the body which evaluates Standards-track RFCs). ------------------------------ From: cisco-faq Date: 5 July 1994 Subject: How can I use debugging? [Could someone please comment on what an appropriate scheduler-interval is?] The terminal monitor'' command directs your cisco to send debugging output to the current session. It's necessary to turn this on each time you telnet to your router to view debugging information. After that, you must specify the specific types of debugging you wish to turn on; please note that these stay on or off until changed, or until the router reboots, so remember to turn them off when you're done. Debugging messages are also logged to a host if you have trap logging enabled on your cisco. You can check this like so: sl-panix-1>sh logging Syslog logging: enabled (0 messages dropped, 0 flushes, 0 overruns) Console logging: level debugging, 66 messages logged Monitor logging: level debugging, 0 messages logged Trap logging: level debugging, 69 message lines logged Logging to 198.7.0.2, 69 message lines logged sl-panix-1> If you have syslog going to a host somewhere and you then set about a nice long debug session from a term your box is doing double work and sending every debug message to your syslog server. Additionally, if you turn on something that provides copious debugging output, be careful that you don't overflow your disk (debug ip-rip'' is notorious for this). One solution to this is to only log severity info'' and higher: sl-panix-1#conf t Enter configuration commands, one per line. End with CNTL/Z. logging trap info The other solution is to just be careful and remember to turn off debugging. This is easy enough with: sl-panix-1#undebug all If you have a heavily loaded box, you should be aware that debugging can load your router. The console has a higher priority than a vty so don't debug from the console; instead, set a scheduler interval in the box, to allows the processor to check other processes periodically: cix-west.cix.net#conf t Enter configuration commands, one per line. End with CNTL/Z. scheduler-interval 750 Then always debug from a vty. If the box is busy and you are a little too vigorous with debugging and the box is starting to sink, quickly run, don't walk to your console and kill the session on the vty. If you are on the console your debugging has top prioority and then the only way out is the power switch. This of course makes remote debugging a real sweaty palms adventure especially on a crowded box. Caveat debugger! Also, if you for some reason forget what the available debug commands are and don't have a manual handy, remember that's what on-line help is for. Under pre 9.21 versions, debug ?'' lists all commands. Under 9.21 and above, that gives you general categories, and you can check for more specific options by specifying the category: debug ip ?''. Lastly, if you're not sure what debugging criteria you need, you can try debug all''. BE CAREFUL! It is way useful, but only in a very controlled environment, where you can turn off absolutely everything you're not interested in. Saves a lot of thinking. Turning it on on a busy box can quickly cause meltdown. ------------------------------ From: cisco-faq Date: 5 July 1994 Subject: How can I use NTP (Network Time Protocol) with my cisco? >What level of software is required for NTP support in >a Cisco router? 9.21 or above. >Which Cisco routers support NTP? It is a software feature exclusively. Anything that supports 9.21 or 10 will run NTP (when running that s/w). >How do I set it up? The basic hook is: ntp server <host> [version n] or ntp peer <host> [version n] depending on whether you want a client/server or peer relationship. There's a bunch of other stuff available for MD5 authentication, broadcast, access control, etc. You can also use the context-sensitive help feature to puzzle it out; try "ntp ?" in config mode. You'll also want to play with the SHOW NTP * router commands. Here are two examples. EXAMPLE 1: router# show ntp assoc address ref clock st when poll reach delay offset disp +~128.9.2.129 .WWVB. 1 109 512 377 97.8 -2.69 26.7 *~132.249.16.1 .GOES. 1 309 512 357 55.4 -1.34 27.5 * master (synced), # master (unsynced), + selected, - candidate, ~ configured EXAMPLE 2: router#show ntp stat Clock is synchronized, stratum 2, reference is 132.249.16.1 nominal freq is 250.0000 Hz, actual freq is 249.9981 Hz, precision is 2**19 reference time is B1A8852D.B69201EE (12:36:13.713 PDT Tue Jun 14 1994) clock offset is -1.34 msec, root delay is 55.40 msec root dispersion is 41.29 msec, peer dispersion is 28.96 msec For particular cisco NTP questions, feel free to ask in comp.dcom.sys.cisco. For broader NTP info, see ftp://louie.udel.edu:pub/ntp/doc. The file clock.txt in that directory has info about various public NTP servers. There is also information on radio time receivers that can be connected to an NTP server (this is handy on private networks, if you have an entire campus to get chiming, or if you become a hard core chimer). The "ntp clock-period" command is added automagically to jump-start the NTP frequency compensation when the box is rebooted. This is essentially a representation of the frequency of the crystal used as the local timebase, and may take several days to calculate otherwise. (Do a "write mem" after a week or so to save a good value.) Caveat: Note that the CS-500 will not be able to achieve quite the same level of accuracy as other platforms, since its hardware clock resolution is roughly 242Hz instead of the 1MHz available on other platforms. In practice this shouldn't matter for anyone other than true time geeks. ---------------------------------------------------------------------- From: cisco-faq Date: 5 July 1994 Subject: Sample Cisco NTP Configurations You will need to substitute your own NTP peers, timezones, and GMT offsets into the examples below, of course. Example 1 is in US Central Time Zone, while example 3 is in US Pacific Time Zone. Both account for normal US Daylight Savings Time practices. EXAMPLE 1 (Charley Kline): ... clock timezone CST -6 clock summer-time CDT recurring ntp source eth 0 ntp peer <host1> ntp peer <host2> ntp peer <host3> ... EXAMPLE 2 (Tony Li): ... ntp source Ethernet0/0 ntp update-calendar ntp peer <host1> ntp peer <host2> prefer ... EXAMPLE 3 (Dave Katz): ... service timestamps debug datetime localtime service timestamps log datetime localtime clock timezone PST -8 clock summer-time PDT recurring interface Ethernet0 ip address <mumble> ntp broadcast ntp clock-period 17180319 ntp source Ethernet0 ntp server <host1> ntp server <host2> ntp server <host3> COMMENTS ON EXAMPLE 3: The config file is commented with date and time (and user id, if TACACS is enabled) when the system thinks the clock is accurate. I've enabled timestamping of debug and syslog messages. I send NTP broadcast packets out onto the local ethernet. I'm in Pacific Standard Time, with U.S. standard daylight saving time rules. I use the IP address of the ethernet as the source for all NTP packets. ------------------------------ From: cisco-faq Date: 5 July 1994 Subject: Presence of cisco employees here or: Why are there so many obnoxious Cisco people flaming on this newsgroup when someone discusses a competitor? Cisco does not own this newsgroup or mailing list. They have no control (and no right to control) the content here. Most of the people there know this. Periodically new people are hired who think that it is a service provided by Cisco and send inappropriate mail. They are soon educated. ------------------------------ From: cisco-faq Date: 5 July 1994 Subject: How do I avoid the annoying DNS lookup if I have misspelled a command? By default, all lines are configured to automatically try a telnet connection if the first word in a input line is not recognized as a valid command. You can disable this by setting "transport preferred none" on every line (con, aux and vty). For instance: sl-panix-1#conf t Enter configuration commands, one per line. End with CNTL/Z. line vty 0 10 transport preferred none You can see the number of vty's currently configuered with show lines'' ------------------------------ From: cisco-faq Date: 5 July 1994S Subject: Tracing bad routing information or: How do I find out which non-Cisco systems on my networks generate IP-RIP information without letting them mess up my routing tables. Here you could work with a default administrative distance. Administrative distance is the basis upon which the cisco prefers routing information of one protocol over another. In this example: router rip network 192.125.254.0 distance 255 distance 80 192.125.254.17 ! list all valid RIP suppliers [...] the value 255 has the implicit meaning of not putting this information into the routing table. Therefore, setting an administrative distance of 255 means that all RIP suppliers are by default accepted but their information is not put into the routing table. The administrative distance for the router 192.125.244.17 has been reset to the default (for RIP) of 80, causing its routes to be accepted into the routing table. Then you can look them up with show ip protocols'' and restore the original administrative distance for the ones you want to fill in the routing table. The same results can be acheived with an ip access-list, but with that, "show ip protocols" will only show the valid ones. But often it is more useful to see which systems were generating routing information at all. This trick works for other routing protocols as well, but please select the proper adminstrative distance (rather than 80) for the protocol you're using. ------------------------------ From: cisco-faq Date: 5 July 1994 Subject: How to use access lists Frequently Asked Questions contributed by Howard C. Berkowitz PSC International hcb@world.std.com @clark.net [probably will be my permanent personal account] PSC's domain is in mid-setup Where in the router are access lists applied? In general, Basic access lists are executed as filters on outgoing interfaces. Newer releases of the Cisco code, such as 9.2 and 10, do have increased ability to filter on incoming ports. Certain special cases, such as broadcasts and bridged traffic, can be filtered on incoming interfaces in earlier releases. There are also special cases involving console access. Rules, written as ACCESS-LIST statements, are global for the entire Cisco box; they are activated on individual outgoing interfaces by ACCESS-GROUP subcommands of the INTERFACE major command. Filters are applied after traffic has entered on an incoming interface and gone through a routing process; traffic that originates in a router (e.g., telnets from the console port) is not subject to filtering. +-------------------+ | GLOBAL | | | | Routing | | ^ v Access | | ^ v Lists | +-^--v--------^---v-+ | ^ v ^ v | | ^ v ^ v | A----------->|-| |>>>>Access >>----------->B |1 Group 2 | <------------| |<----------- | | | | +-------------------+ Some types of "filter," using "filter" as a broader class than ACCESS-LIST, can operate on incoming traffic. For example, the INPUT- SAP-FILTER used for Novell networks is applied to Service Advertisement Packets (SAP) seen at incoming interfaces. In general, incoming filtering can only be done for "system" rather than user traffic. Rules of thumb in defining access lists. First, define what you want to do and in which directions. An informal drawing is a good first step. As opposed to the usual connectivity drawings among routers, it's often convenient to draw unidirectional links between routers. Second, informally write out your filtering rules. In general, it is best to go from most specific to least specific. Modify the order of writing things to minimize the number of rules needed. Third, determine which rules need to be on which routers. Explicitly consider the direction of flow, and the possible existence of additional paths that could inadvertently bypass a filter. Can a Cisco router be a "true" firewall? This depends on the definition of firewall. Some writers (e.g., Gene Spafford in _Practical UNIX Security_) define a firewall as a host on which an "inside" and/or an "outside" application process run, with application-level code linking the two. For example, a firewall might provide FTP access to the outside world, but it would not also provide direct FTP service to the inside world. To place a file on the FTP external server, a designated user would explicitly log onto the FTP server, transfer a file to the server, and log off. The firewall prevents direct FTP connectivity between the inside and outside networks; only indirect, application-level connectivity is allowed. Firewalls of this sort are complemented by chokes, which filter on network addresses and/or port numbers. Cisco routers cannot do application-level control with access control lists. Other authors do not distinguish between chokes and filters. Using the loose definition that a firewall is anything that selectively blocks access from the inside to the outside, routers can be firewalls. IP Specific ----------- Can the "operand" field be used with a protocol keyword of IP to filter on protocol ID? No. Operand filtering only works for TCP and UDP port numbers. How can I prevent traffic for a certain Internet application to flow in one direction but not the other? Remember that Internet applications flow from client port to server port. Denying traffic from port 23, for example, blocks flow from the client to the server. +-------------------+ | | A----------->| |----------->B |1 2| <------------| |<----------- | | +-------------------+ If we deny traffic to Port 23 of address B by placing a filter at interface 2, we have blocked A's ability to telnet to B, but not B's ability to telnet to A. A second filter at interface A would be needed to block telnet in both directions. Assume that we only have the filter at interface 2. Telnets to A from B will not be affected because the filter at 2 does not check incoming traffic. ------- What really happens when a Cisco router boots, from boot start to live interfaces? powercycle Does some delay stuff to let the power settle. Goto I. reload (from the EXEC) Goto I. ------------------------------ From: cisco-faq Date: 5 July 1994 Subject: Acknowledgements. The following people contributed to this FAQ, and their contributions are greatly appreciated, both questions and answers "Ronnie B. Kon" <ronnie@cisco.com> Charley Kline <cvk@uiuc.edu> Dave Katz <dkatz@cisco.com> John Wright Pete Siemsen <siemsen@skat.usc.edu> Sanjay Rungta~ <srungta@sedona.intel.com> Steve Cunningham <steve@vf.ge.com> atkinson@sundance.itd.nrl.navy.mil (Ran Atkinson) jerry@ksu.ksu.edu (Jerry Anderson) jhawk@panix.com (John Hawkinson) john@gulfa.ods.gulfnet.kw (John Temples) peter@ulisse.rhein-main.de (Peter Radig) tli@cisco.com (Tony Li) tom@park.uvsc.edu (Thomas R. Kimpton) Howard C. Berkowitz, PSC International, <hcb@world.std.com>  -----------[000071][next][prev][last][first]---------------------------------------------------- Date: 5 Jul 1994 21:38:23 -0500 From: mweiss@nwk.cl.nec.co.jp (Michael J. Weiss) To: comp.os.ms-windows.networking.tcp-ip,comp.os.ms-windows.programmer.networks,comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc Subject: Packet Drivers II  I am interested in learning about packet drivers and how they work. From the little I was able to find out, it seems as if they have a standard interface for dealing with applications. Who defined this interface? Is there a standard document which is available? Where can I learn more about what they work, how they do? I would also warmly welcome any insight that you might have on the topic. Thanks, --Mike  -----------[000072][next][prev][last][first]---------------------------------------------------- Date: Tue, 5 Jul 1994 15:02:38 GMT From: s2929773@techst02.technion.ac.il (Yosefi Ori ) To: comp.protocols.tcp-ip Subject: Connecting Appletalk+ethernet+SLIP internet  Hi, I wanted to know if there is any way I can connect an existing Appletalk network (consisting of an EtherTalk Zone and A localtalk zone) to the Internet Over a SLIP connection (Dial Up). I installed MacTCP on the computer with the modem and I can use the internet OK, but I can't manage to use the internet from another Mac (Not having a modem) Is there any way to cause Macs to sends their Packets throuhgh another one? Thank a lot for any help, Ori Yosefi.  -----------[000073][next][prev][last][first]---------------------------------------------------- Date: 6 Jul 1994 00:06:26 -0500 From: mweiss@nwk.cl.nec.co.jp (Michael J. Weiss) To: comp.os.ms-windows.networking.tcp-ip,comp.os.ms-windows.programmer.networks,comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc Subject: Coding Conventions  Is there any widespread standard for coding conventions, such as nameing functions, variables, uppercase, lowercase, etc., or is this too personal and non-urgent a matter for such a standard to be accepted?  -----------[000074][next][prev][last][first]---------------------------------------------------- Date: 5 Jul 1994 12:56:47 +0200 From: casper@fwi.uva.nl (Casper H.S. Dik) To: comp.protocols.tcp-ip Subject: Re: How do you get TCP/IP address by program ?  zi@cli51jo.der.edf.fr (Zixiong Wang) writes: > I must get my local host's address by program, I can >of cause read in /etc/hosts, but I don't think it is the best >way to do that. > I'v tried gethostbyname(), which returns a hostname >and a pointer to an address, the hostname is always the same >than the one that I'v passed to the function, so not at all >informative. The Sun Solaris manual says that the address is >of form of in_addr, which can be manipulated by inet... >system calls, so I call inet_ntoa(), but what I get is >not my address: There's a bug in Solaris 2.x which causes the argument to gethostbyname to be returned as the h_name field. >struct hostent *ent = gethostbyname("cli51jo"); >struct in_addr in; >memcpy(&in, ent->h_addr_list, sizeof(struct in_addr)); >cout << inet_ntoa(in) << endl; >this code gives me: >0.3.104.252 The h_addr_list is an array of pointers to addresses. (The Solaris manual misses a crucial '*' in the h_addr_list type) The address you want is ent->h_addr_list[0]. Casper  -----------[000075][next][prev][last][first]---------------------------------------------------- Date: 6 Jul 1994 00:47:09 -0500 From: mweiss@nwk.cl.nec.co.jp (Michael J. Weiss) To: comp.os.ms-windows.networking.tcp-ip,comp.os.ms-windows.programmer.networks,comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc Subject: Packet Drivers, Wattcp, Mobile Computing  Maybe you have seen my previous posts on the TCP/IP groups about how I am trying to implement a TCP/IP variant scheme designed to cater to the needs of mobile computing. My original plan was to add code to WATTCP, probably at the point just before it calls the packet driver. What do you think of this other approach? Leave WATTCP intact and the packet driver intact. Write a software layer in between to do the following: It would act like the packet driver on one end, so that WATTCP will call it instead of the real packet driver. It will take outgoing packets from WATTCP and modify them to conform with our mobile computing IP scheme, then send them to the packet driver as if they came from WATTCP. It will take packets from the packet driver and change them back to regular TCP/IP, and hand them to WATTCP as the packet driver would in a conventional case. I think this idea may work. I think the packet driver stuff is exciting, so if it sounds like a decent idea from a feasibility point of view, it seems like a good way to go about things, since it can be used with standard TCP/IP and a standard packet driver. What is your evaluation of this idea? Does it seem feasible? Please let me know what you think. --Mike  -----------[000076][next][prev][last][first]---------------------------------------------------- Date: 6 Jul 1994 00:57:19 -0400 From: jhawk@panix.com (John Hawkinson) To: comp.protocols.tcp-ip Subject: Re: Unbalanced routing -- How to detect?  In <1994Jul5.211423.22685@noao.edu> rstevens@noao.edu (W. Richard Stevens) writes: >> I would like a tool which showed me the full round trip routing for IP >> packets, so I could detect if there are unbalanced routes. I can use >> traceroute in one direction, but then again, I don't see which route >> the reply packets take. >> Any hints on how to detect unbalanced routing? Thanks, >Yes, put in the loose source routing option and then you can see the >round trips (assuming enough routers in the path support the LSRR >option). Check out Section 8.5 of my recent book "TCP/IP Illustrated" >(Addison-Wesley, 1994) for some examples. The source code for a version >of traceroute that supports the LSRR option is available in the tar file >for this book (ftp.uu.net:/published/books/stevens.tcpipiv1.tar.Z). This is the -g option, BTW, and it only works if all the routers in your path do not have source-routing disabled (not always a safe bet in our firewalled world). You can also get such atraceroute w/o associated Stevens' stuff from ftp.uu.net:/networking/ip/trace/ - traceroute_pkg.tar.Z. Here's an example; if my regular path to swidir.switch.ch is: [panix!jhawk] /tmp% traceroute swidir.switch.ch traceroute to swidir.switch.ch (130.59.72.10), 30 hops max, 40 byte packets 1 transit.nyc.access.net (198.7.0.126) 9 ms 3 ms 3 ms 2 sl-dc-1-S12-T1.sprintlink.net (144.228.2.193) 19 ms 11 ms 15 ms 3 icm-dc-1-F0/0.icp.net (144.228.20.101) 36 ms 23 ms 18 ms 4 washington2.dante.net (192.41.177.220) 30 ms 15 ms 24 ms 5 Geneva3.Dante.net (192.77.157.2) 103 ms 106 ms 108 ms 6 swice1.switch.ch (192.65.185.130) 106 ms 104 ms 111 ms 7 swiEL2.switch.ch (130.59.92.1) 147 ms 112 ms 109 ms 8 swidir.switch.ch (130.59.72.10) 108 ms 122 ms 111 ms And the roundtrip looks like this: [panix!jhawk] /tmp% traceroute -g swidir.switch.ch panix.com traceroute to panix.com (198.7.0.2), 30 hops max, 40 byte packets 1 transit.nyc.access.net (198.7.0.126) 4 ms 3 ms 4 ms 2 sl-dc-1-S12-T1.sprintlink.net (144.228.2.193) 75 ms 109 ms 116 ms 3 icm-dc-1-F0/0.icp.net (144.228.20.101) 17 ms 105 ms 115 ms 4 washington2.dante.net (192.41.177.220) 119 ms 100 ms 21 ms 5 Geneva3.Dante.net (192.77.157.2) 111 ms 107 ms 114 ms 6 swice1.switch.ch (192.65.185.130) 110 ms 115 ms 109 ms 7 swiEL2.switch.ch (130.59.92.1) 117 ms 110 ms 117 ms 8 swidir.switch.ch (130.59.72.10) 112 ms 115 ms 130 ms 9 swiEL2.switch.ch (130.59.72.2) 158 ms 123 ms 118 ms 10 swiCE1.switch.ch (130.59.92.2) 134 ms 112 ms 111 ms 11 geneva3.Dante.net (192.65.185.204) 116 ms 143 ms 119 ms 12 Washington2.Dante.net (192.77.157.1) 143 ms 116 ms 123 ms 13 sl-dc-2-E1.sprintlink.net (192.41.177.239) 116 ms 112 ms 112 ms 14 sl-dc-1-F0.sprintlink.net (144.228.20.1) 117 ms 220 ms 354 ms 15 sl-panix-1-S0-T1.sprintlink.net (144.228.2.194) 167 ms 133 ms 127 ms 16 panix (198.7.0.2) 143 ms 116 ms 114 ms [panix!jhawk] /tmp% Just remember that not all interfaces on a router have the same naming, so don't be mislead. For instance, hops 15 and 1 in the above traceroute are the same router. In the case of people who have source-routing turned off, you can often used the next-hop back. For instance: traceroute to panix.com (198.7.0.2), 30 hops max, 40 byte packets 1 transit.nyc.access.net (198.7.0.126) 4 ms 3 ms 3 ms 2 sl-dc-1-S12-T1.sprintlink.net (144.228.2.193) 12 ms 11 ms 12 ms 3 sl-dc-6-F0/0.sprintlink.net (144.228.20.6) 13 ms 160 ms 18 ms 4 Boone1.VA.ALTER.NET (192.157.65.227) 21 ms 20 ms 21 ms 5 Falls-Church4.VA.ALTER.NET (137.39.43.97) 21 ms 159 ms 34 ms 6 IBMpc01.UU.NET (137.39.8.20) 28 ms !S That fails at one of uunet's internal routers. So if we take the backwards path from just before it: [panix!jhawk] /tmp% traceroute -g 137.39.43.97 panix.com traceroute to panix.com (198.7.0.2), 30 hops max, 40 byte packets 1 transit.nyc.access.net (198.7.0.126) 4 ms 5 ms 5 ms 2 sl-dc-1-S12-T1.sprintlink.net (144.228.2.193) 16 ms 22 ms 29 ms 3 sl-dc-6-F0/0.sprintlink.net (144.228.20.6) 18 ms 14 ms 14 ms 4 Boone1.VA.ALTER.NET (192.157.65.227) 48 ms 29 ms 16 ms 5 Falls-Church4.VA.ALTER.NET (137.39.43.97) 25 ms 18 ms 28 ms 6 Boone1.VA.ALTER.NET (137.39.43.66) 25 ms 26 ms 23 ms 7 sl-dc-6-E3/5.sprintlink.net (192.157.65.228) 42 ms 25 ms 25 ms 8 sl-dc-1-F0.sprintlink.net (144.228.20.1) 31 ms 35 ms 30 ms 9 sl-panix-1-S0-T1.sprintlink.net (144.228.2.194) 26 ms 29 ms 27 ms 10 panix (198.7.0.2) 34 ms 24 ms 27 ms [panix!jhawk] /tmp% You can get a fairly good idea of what the path is, but you should remember this is just a guess. Additionally, don't forget that these paths change all the time as route info changes, so today's path may not be tomorrow's. -- John Hawkinson jhawk@panix.com  -----------[000077][next][prev][last][first]---------------------------------------------------- Date: 6 Jul 1994 01:00:52 -0400 From: jhawk@panix.com (John Hawkinson) To: comp.protocols.tcp-ip Subject: Re: Round robin DNS?  In <2vcncl$pe6@bosnia.pop.psu.edu> barr@pop.psu.edu (David Barr) writes:

>However, I'm told ever since the root nameservers all switched to
>using round-robin versions of BIND, mail load on big equal-preference-MX
>sites like uunet.uu.net became much more uniform.

How could this be? The root nameservers don't return RRs for such
domain names, unless they cache them, which seems unlikely. It's
merely a question of when the servers for the zone that uunet.uu.net
is in started running round robin.

--
John Hawkinson
jhawk@panix.com


-----------[000078][next][prev][last][first]----------------------------------------------------
Date:      Tue, 5 Jul 1994 19:15:05 GMT
From:      skov@ilx.com (John Skovron)
To:        comp.protocols.tcp-ip
Subject:   Re: Looking for dynamic-assignment BOOTP

In article <2v1dfj$s4p@vkhdib01.hda.hydro.com>, Per Weisteen <Per.Weisteen@hda.hydro.com> wrote: >In article <1994Jun30.160105.6475@ivax>, imhw400@indyvax.iupui.edu (Mark H. Wood) says: >> >>I'm looking for *any* implementation of BOOTP that can dish out cynamically- >>assigned addresses to hosts on subnets other than its own. I would have >> ... > >DHCP protocol (RFC 1541 ++) is a new protocol which does exactly >what you want. I know Microsoft has implemented this for NT and I think >SUN has a version out "real soon now" , and yes Novell is also supposed >to have one implemented as a NLM for their 4.x Netware. > >I'm desperately looking for a UNIX source. I'd hate to be in the hands of those >PC-guys talking IP.... ;-) > On this note, is _anybody_ actually shipping a DHCP server yet? Microsoft NTAS (that's the Windows NT Application Server, in case you haven't learned their corpo-babble yet) v3.5 still seems to be stuck in a tightly controlled beta, and the other commercial implementations seem to be in the same place at best. Microsoft was kind enough to include a DHCP client with their latest TCPIP protocol stack, but there's no server to test it against. Is there anything - whether Unix or not - that I could actually put my hands on today? -- ----------------------------------------------------------------------------- John Skovron ILX Systems Inc. skov@ilx.com  -----------[000079][next][prev][last][first]---------------------------------------------------- Date: 5 Jul 1994 19:27:53 GMT From: rao@acsc.com (Rao Srinivasa) To: comp.protocols.tcp-ip Subject: Re: Installing SLIP  In article <1994Jul1.205328.13600@wisipc.weizmann.ac.il>, yuvalt@silver.weizmann.ac.il (Tal Yuval) writes: |> Hi, |> |> I am trying to make SLIP work in my site and I have a question: Our |> network is class C (ie the subnetmask is 255.255.255.0), our computers are |> on network 132.76.80 (wisdom.weizmann.ac.il). |> According to the IP address you have class B IP address. ( 128 to 191 of first byte. ) Your subnetmask shows that the last 16 bits that are allocated for you by the class B address are divided in to 8bits for subnets and remaining 8bits for hosts within the subnets. |> My question is: If I want to connect a SLIP machine to the network |> (lets say that the host is 132.76.80.121), do I have to create a new |> network (i.e. 132.76.81) and make 132.76.80.121 its gateway or can I |> put my SLIP machine on the same IP network? |> You can connect a host by SLIP without wasting a subnet number for it ... 130.76.79 ------------------------------------- | | 130.76.80.126 | 130.76.79.100 --------- ---------- --------- Host | SLIP | | | | to |---------------| M1 | | M2 | connect | | | | | -------- --------- --------- 130.76.80.125 |130.76.80.66 | 130.76.80.65 ------------------------------------- Here we are using variable length subnet mask. 8 bits for subnet mask. 8bits that are remaining for hosts are divided in to 2 bits for subnets within the subnet and 6 bits for hosts. So in this topolozy you are sacrificing the number of hosts that you can connect to 64 just to avoid the usage of one more subnet. <-------16bits----------><---8bits------><2 bits><6bits for hosts> ---------------------------------------------------------- 130.76 | (79 and 80 in | | this field) | ---------------------------------------------------------- SubnetMask: <----all 1s-------------------------------------><- Last 6bits 0s --> = 0xffffffc0 = 255.255.255.192 |> I succeeded in creating a new subnet but I was wondering if the other |> method also works. If it does, what is the configuration of the SLIP |> host and the SLIP machine. |> IP address SubnetMask SubnetID HOST M2: 130.76.79.100 255.255.255.0 130.76.79 100 130.76.80.65 255.255.255.192 130.76.80.64 1 M1: 130.76.80.66 255.255.255.192 130.76.80.64 2 130.76.80.126 255.255.255.192 130.76.80.124 2 SLIP: 130.76.80.125 255.255.255.192 130.76.80.124 1 Good luck ... Rao.  -----------[000080][next][prev][last][first]---------------------------------------------------- Date: 5 Jul 1994 19:53:58 GMT From: adiwan@siacbbn.com (Arif Diwan (BBN)) To: comp.protocols.tcp-ip Subject: Re: Best way to change IP addresses for a group of systems  In article <2v1902$8km@ccnet.ccnet.com>,
jantypas@ccnet.com (John Antypas) writes:
...
a) is there a way I can give my hosts TWO IP addresses on their interfaces?
(Old IP and New IP) for say, a month.
(Thery're BSDI boxes)

b) If this isn't the way to do it, what is the best way?
...
<<<

You can assign multiple IP addresses to an interface. I know of three ways:

a) Probably requires a kernel hack:

where lo1 is an extension to the loopback interface (lo0). BSD 4.4
might have a better way to do this.

b) You can get MorningStar Technologies PPP software and use their
IP tunnel drivers to create pseudo interface du0, du1, etc and
create multiple IP addresses to a host.

c) This might work:
Create arp entries for the new IP addresses and then use gated
to propagate the route to the new address via the old address.
You may need to hack gated.

--

617-873-6274


-----------[000081][next][prev][last][first]----------------------------------------------------
Date:      Tue, 5 Jul 1994 20:00:30 GMT
From:      lichtin@olsen.ch (Martin Lichtin)
To:        comp.protocols.tcp-ip
Subject:   Unbalanced routing -- How to detect?


I would like a tool which showed me the full round trip routing for IP
packets, so I could detect if there are unbalanced routes. I can use
traceroute in one direction, but then again, I don't see which route

Any hints on how to detect unbalanced routing? Thanks,

Martin Lichtin                            Olsen & Associates AG (info@olsen.ch)
lichtin@olsen.ch                       Research Institute for Applied Economics
T +411-386-4848  F +411-422-2282   Seefeldstr. 233, CH-8008 Zurich, Switzerland


-----------[000082][next][prev][last][first]----------------------------------------------------
Date:      Tue, 5 Jul 1994 20:40:13 GMT
From:      wag@swl.msd.ray.com (William Gianopoulos {84718})
To:        comp.protocols.tcp-ip
Subject:   MS-DOS TCP/IP question

This is probably a dumb question, but a coworker asked me to post this for him.
He is looking for a MS-DOS TCP/IP implementation which allows multiple
simultaneous FTP and Telnet servers.  He is trying to implement a TCP/IP
based buletin board type system on an MS-DOS PC.

--
William A. Gianopoulos; Raytheon Missile Systems Division
wag@sccux1.msd.ray.com


-----------[000083][next][prev][last][first]----------------------------------------------------
Date:      5 Jul 1994 20:56:58 GMT
From:      raj@cup.hp.com (Rick Jones)
To:        comp.protocols.tcp-ip
Subject:   Re: Max IP packet length and MTU

Lon Stowell (lstowell@pyrnova.mis.pyramid.com) wrote:
:    Then on the LAN, if fragment 4 out of 23 is lost, the other 22
:    don't have to be retransmitted?

:    Seems kinda expensive to me.

Ah, but the question is should one be optimizing for the "error" case
and not work as fast as one might in the "error-free" case, or the
error-free case, and not work as well as one might in the error case?

Of course, the answer to the question is likely to be "it depends..."
:) :( :) ... on how many errors happen in the error case, how often
one hits the error case, and such. I imagine that most people (myself
included) would say that sending packets that have to be fragmented
into 23 parts might be a bit excessive (or perhaps a contrived
example, or NFS V3?  :), but sending packets that have to be fragmented
into say 8 parts isn't the root of all evil.

Just was is the typical frame loss rate these days? I expect that if a
network had a loss rate of 1 in 23 frames, or even one in 230, 2300,
or perhaps even 23,000 (perhaps that's a stretch?), that very little
would work well - independent of the presence of IP fragments - and
people would be dispatched to fix that network in short order.

I was not there, I was too young, but I expect that a lot of the "IP
fragments are evil" thinking was generated back when networks did have
higher error rates, and we did have more interfaces which could not
handle back to back packets - now that we can get "back to back"
packets without IP fragments, those interfaces are being replaced, now
we now have links which are less susceptible to noise, we have a
better understanding of how to avoid and recover from congestion.

If our congestion is based on number of bytes, don't we actually
transmit more bytes in the no fragment case, than in the fragmented
case because we replicate the upper level headers?

In short, our technology is evolving - our thinking should evolve with
it.

rick jones
speaking only as rick jones...
everything in moderation, nothing in excess...

#really arcane drift...

Here is a side track - Path MTU discovery is a way to make our
networks run better by avoiding intermediate node fragmentation. I can
see where if one was running TCP, and trying at all cost to avoid IP
fragments, that Path MTU discovery would be happiness and joy. My
question is "Is it good when you know that you are going to be sending
fragments in the first place?" In other words, do we even want to try
and fragment down to the lowest common segment size at the sending
host for something like NFS? I would think that we would be better-off
*not* doing that when we know that we are going to fragment anyway.
The reasoning is this - by not fragmenting down to the smallest size
along the path, we reduce the total number of frames transmitted,
thereby reducing the likelihood that any one or more of the frames are
going to be lost. This is predicated on the assumption that the unit
queued in intermediate nodes is a "packet" and not a number of bytes,
and that intermediate nodes are at least as good as the end nodes in
fragmenting IP datagrams, and that the primary cause of lost fragment
is congestion.

I imagine that the counter argument would be that when fragmenting IP
fragments in an intermediate node, one ends-up creating more IP
fragments than fragmenting to the smallest size in the first place.

I wonder which is correct, in which cases? In the FDDI to Ethernet
fragments on the fibre, each of which would be further fragmented into
3 fragments on the Ethernet, giving 6. Total fragments transmitted
would be 8. If we fragment to Ethernet size in the first place, we
would put 6 fragments on the fibre, and 6 on the Ethernet, for a total
of 12.


-----------[000084][next][prev][last][first]----------------------------------------------------
Date:      Tue, 5 Jul 1994 21:14:23 GMT
From:      rstevens@noao.edu (W. Richard Stevens)
To:        comp.protocols.tcp-ip
Subject:   Re: Unbalanced routing -- How to detect?

> I would like a tool which showed me the full round trip routing for IP
> packets, so I could detect if there are unbalanced routes. I can use
> traceroute in one direction, but then again, I don't see which route
> Any hints on how to detect unbalanced routing? Thanks,

Yes, put in the loose source routing option and then you can see the
round trips (assuming enough routers in the path support the LSRR
option).  Check out Section 8.5 of my recent book "TCP/IP Illustrated"
(Addison-Wesley, 1994) for some examples.  The source code for a version
of traceroute that supports the LSRR option is available in the tar file
for this book (ftp.uu.net:/published/books/stevens.tcpipiv1.tar.Z).

Rich Stevens


-----------[000085][next][prev][last][first]----------------------------------------------------
Date:      Tue, 5 Jul 1994 21:27:22 GMT
From:      mark@wizard.pilot.dmg.ml.com (Mark Hahn)
To:        comp.protocols.tcp-ip
Subject:   Lastest info on Next Generation IP

Does any one know where I can get information about the
proposals for the next version of IP.  I believe that there
are two current proposals under review, and that the IETF
has descriptions available some where, but I cannot find
the reference.  Please send reponsed via E-Mail (and to
prevent the me-too's,)  I'll post the answers.
--

---------------------------------------------------------
Mark P. Hahn                  | E-Mail: mark@ml.com
Systems & Technology Audit    |  Phone: 212-236-7280
Merrill Lynch, South Tower    |    Fax: 212-236-7282
New York, New York 10080-6114 |


-----------[000086][next][prev][last][first]----------------------------------------------------
Date:      Wed, 6 Jul 1994 13:20:02 -0700 (PDT)
From:      David L Miller <dlm@cac.washington.edu>
To:        comp.protocols.tcp-ip,comp.os.ms-windows.networking.tcp-ip,comp.mail.smail,comp.mail.sendmail,comp.mail.misc,comp.mail.mime martin bowman <mbowman@sita.int>
Subject:   Re: POP on SCO


Are you looking for a client or server?  If a server, then try the ipop2d
and/or ipop3d servers from the UW IMAP Toolkit, available from
ftp.cac.washington.edu in the file mail/imap.tar.Z.

|\ |  |\/|  David L. Miller    dlm@cac.washington.edu  (206) 685-6240
|/ |_ |  |  Software Engineer, Pine Development Team   (206) 685-4045 (FAX)
University of Washington, Networks & Distributed Computing, JE-20
4545 15th Ave NE, Seattle WA 98105, USA

On Wed, 6 Jul 1994, martin bowman wrote:

>
> Does anyone have any information on implementing the POP protocol on SCO UNIX?
>
>


-----------[000087][next][prev][last][first]----------------------------------------------------
Date:      Wed, 6 Jul 1994 07:06:07
From:      jlamia@skypoint.nat
To:        comp.protocols.tcp-ip
Subject:   115200 baud with Trumpet TCP Manger

I am unable to set a abud rate of over 57600 with Trumpet's TCP Manger 1.0A. I
would like to use a 28.8 modem with compression and acheive 115200 baud. Is
there a newer version of this sfotware or is there a way to configure this
baud rate through the dialing script and override the setup settings?

Any help will be greatly appreciated.

--
J.R. Lamia          jlamia@skypoint.net
SHL Systemhouse
Minneapolis, MN


-----------[000088][next][prev][last][first]----------------------------------------------------
Date:      Wed, 6 Jul 1994 02:59:25 GMT
From:      sar@prologic.com (Steve Rago)
To:        comp.protocols.tcp-ip
Subject:   Re: Using SIGIO on socket with Esix ??

In article <Cs8CEw.IH7@afp.com> erick@afp.com writes:
>
>Hi.
>
>I don't kown how to make the "Interrupt Driven Socket I/O" work on Esix 4.1-2

[ stuff deleted ]

>With the program listed:
>
>	/* set the process receiving SIGIO/SIGURG signals to us. */
>	if (fcntl(ISocket, F_SETOWN, getpid()) < 0) {
>		perror("fcntl F_SETOWN");
>		exit(1);
>	}
>
>	/* allow receipt of asynchronous I/O signals. */
>	if (fcntl(ISocket, F_SETFL, FASYNC) < 0) {
>		perror("fcntl F_SETFL");
>		exit(1);
>	}
>
>it always does a "invalid argument" on the F_SETOWN fcntl.
>Why ?

[ source deleted ]

libraries:	-lc -lsocket -lnsl

If you remove the "-lc" and recompile, the programs work as expected
because, on SVR4, the F_SETOWN emulation is handled in the socket
library, and you are explicitly forcing ld to resolve the fcntl symbol
from the C library instead of the socket library.

Steve Rago
sar@prologic.com


-----------[000089][next][prev][last][first]----------------------------------------------------
Date:      Wed, 6 Jul 1994 08:15:39
To:        comp.protocols.tcp-ip
Subject:   Re: MS-DOS TCP/IP question

In article <1994Jul5.204013.15421@swlvx2.msd.ray.com> wag@swl.msd.ray.com (William Gianopoulos {84718}) writes:
>This is probably a dumb question, but a coworker asked me to post this for him.
>He is looking for a MS-DOS TCP/IP implementation which allows multiple
>simultaneous FTP and Telnet servers.  He is trying to implement a TCP/IP
>based buletin board type system on an MS-DOS PC.

I have been able to have at least two simultaineous FTP connections to a PC
using FTP Software's PCTCP FTPSRV (800.282.4387). Haven't tried more though.

Cybernetic Psychophysicist
We also walk dogs
PGP 2.4 Public Key Available


-----------[000090][next][prev][last][first]----------------------------------------------------
Date:      Wed, 6 Jul 1994 03:19:57 GMT
From:      gnb@bby.com.au (Gregory Bond)
To:        comp.protocols.tcp-ip
Subject:   Re: Book Review - TCP/IP Illustrated, Volume 1

In article <2vanq6$g7e@sun.cais.com> bass@cais.cais.com (Tim Bass (Network Systems Engineer)) writes: This review is too late. Stevens book, _TCP/IP Illustrated_ is great book. This books has been out as long as Philadephia (the movie) or longer. We certainly don't need a review on 6 month old movies OR 6 month old books. Speak for yourself, yankee. This is the other side of the world, and books take forever to get out here. -- Gregory Bond <gnb@bby.com.au> Burdett Buckeridge & Young Ltd Melbourne Australia Atilla The Hun's Maxim: If you're going to rape, pillage and burn, be sure to do things in that order. -- P. J. Plauger, Programming On Purpose, p147  -----------[000091][next][prev][last][first]---------------------------------------------------- Date: 6 Jul 94 12:19:17 From: zhao@crl.nmsu.edu (Z. Zhao) To: comp.sys.mac.comm,comp.sys.mac.misc,comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc,comp.protocols.ppp Subject: where can I get the interSLIP for MAC?  Can anybody here tell me where the interSLIP for MAC is hidden ? Is it a freeware or shareware or commercial package? Thanks in advance, ZZ  -----------[000092][next][prev][last][first]---------------------------------------------------- Date: Wed, 6 Jul 1994 13:31:00 From: loss@husky.bloomu.edu (Doug Loss) To: comp.protocols.tcp-ip Subject: Re: CD-ROM and TCP/IP  In article <2v25u2$d1q@pyrnova.mis.pyramid.com> lstowell@pyrnova.mis.pyramid.com (Lon Stowell) writes:
>In article <1994Jun30.185731.23356@moore.com> chris@moore.com (Chris Box)
>writes:
>>Does anyone know how I'd attach a CD-ROM to a TCP/IP network as an
>>independent device?  I don't want it attached to anyone's PC, but would
>>rather it have a direct connection something along the lines of a
>>printserver device which attaches directly to the ethernet cabling.

>  Sure.  Since you don't want to do the obvious and cheapest and most
>  robust thing and just put in on a PC and treat it like any other
>  drive and NFS mount it to the tcp/ip network, the following is
>  pretty much what you are stuck with:

[description of do-it-yourself file server deleted]

>  This answer, although somewhat unduly sarcastic is not entirely
>  in jest.  You can either attach it to someone's PC or buy a
>  standalone unit and put the CD-ROM on that.  These are cheap, pretty
>  reliable, off-the-shelf answers.  The alternative, until someone
>  sells a CD-ROM NFS server box, is gonna get pretty ugly.

Actually, DEC does sell such a box.  It's called an InfoServer, as I recall,
and it allows you to hang lots of different mass storage devices on your net.
It costs about $2000 US, I think. Doug Loss Only a sadistic scoundrel Data Network Coordinator --or a fool-- Bloomsburg University tells the bald truth loss@husky.bloomu.edu on social occasions. Voice (717) 389-4797  -----------[000093][next][prev][last][first]---------------------------------------------------- Date: 6 Jul 1994 15:35:52 -0400 From: barr@pop.psu.edu (David Barr) To: comp.protocols.tcp-ip Subject: Re: Round robin DNS?  In article <2vddq4$nst@panix.com>, John Hawkinson <jhawk@panix.com> wrote:
>In <2vcncl$pe6@bosnia.pop.psu.edu> barr@pop.psu.edu (David Barr) writes: > >>However, I'm told ever since the root nameservers all switched to >>using round-robin versions of BIND, mail load on big equal-preference-MX >>sites like uunet.uu.net became much more uniform. > >How could this be? The root nameservers don't return RRs for such >domain names, unless they cache them, which seems unlikely. When doing cross-root-domain lookups (.edu to .com, .uk to .gr), lookups involve the root nameservers. (which are thus cached) >It's >merely a question of when the servers for the zone that uunet.uu.net >is in started running round robin. that too. (true, most of the effect is gained there) --Dave -- "Opera is when a guy gets stabbed in the back and instead of bleeding he sings." - Ed Gardner  -----------[000094][next][prev][last][first]---------------------------------------------------- Date: 6 Jul 1994 17:22:52 -0500 From: sulistio@futon.sfsu.edu (Sulistio Muljadi) To: comp.protocols.tcp-ip Subject: Connecting to Internet  Hello, I am trying to set up Internet conection (full IP) for my company. It will be on 56kbps leased line. I am trying to figure out what kind of hardware needed to set the connection. We are using many flavor of UNIXes. Please send me e-mail, and possibly the prices w/ the phone number to contact. Thanks. -- Mul | Alt. address: sulistio@chop.isca.uiowa.edu sulistio@futon.sfsu.edu | Compu$erve id 73232,1324
#include "std/disclaimer.h" |
>Genius is one per cent inspiration and ninety-nine per cent perspiration.
>					  Thomas Alva Edison (1847-1931)


-----------[000095][next][prev][last][first]----------------------------------------------------
Date:      Wed, 6 Jul 1994 14:45:44
To:        comp.protocols.tcp-ip
Subject:   FTP Software Kernel API

Would someone please point me to the FTP Software PCTCP Kernel System Calls
API. I have looked on ftp.ftp.com but may have just missed it.

Called FTP and they said "send $400 for the SDK and the API is included". Since the SDK is all C modules and I program in assembly this does not seem reasonable. Am about ready to revert to programming the driver directly (have the driver API v111) but since we purchased PCTCP v2.3 & have the kernel this seems like a lot of bother. Assistance would be appreciated. A. Padgett Peterson, P.E. Cybernetic Psychophysicist We also walk dogs PGP 2.4 Public Key Available  -----------[000096][next][prev][last][first]---------------------------------------------------- Date: 6 Jul 94 10:20:57 GMT From: jkay@cs.ucsd.edu (Jon Kay) To: comp.protocols.tcp-ip Subject: Re: Max IP packet length and MTU  >karl@cavebear.com (Karl Auerbach) > I suspect that you are thinking of Un*x/BSD code constructs. My concern is > about reassembly in general. When I say "reassembly buffer" I mean that one > is allocating space to put the packet. I don't understand what you're trying to say here. Perhaps you could elaborate? In BSD, to a first approximation, the only place allocation gets done is in the driver, for space for individual incoming packets. So my question is, how does your environment work, and where does the reassembly buffer fit in? > In memory rich environments I would > guess that people could allocate 64K byte buffers in anticipation of even the > largest possible size of IP reassembled packet. In lesser environments, such > as pre-windows PCs and many embedded controller systems, it is important to > try to be careful about wasted buffer space. The idea here is that if you guess that a frame is 8k+epsilon (8336) long (a sophisticated version might have incestuous knowledge of NFS rsize/wsize), you'll usually be right. You'll be right so often that relatively little memory is lost. In my trace, 70% of the fragmented packets were 8k NFS packets. Nearly all the rest were 4k NFS packets. Thus, 4k of memory would be wasted on 30% of the packets. Thus, in this environment, my algorithm would waste (0.3 * 4k) / 8k = 15% of the memory Many memory allocators do worse than this. > I've made the argument a few times to the IPng folk, but never very strongly, > that whatever happens in IPng, one should be able to know the reassembled size > from any fragment, not just the last one. Well, here's your chance to convince us...a start. I think you'd need an inevitable structural reason or a noticeable savings in overall implementation or processing time for a lot of people to convince people to add to an already noticeably more complex protocol than IP itself when lots of people will have to implement it, and TCP/IPcurrent processing latency is already high. My opinion, of course - I am in no present danger of becoming an IPng designer. Jon -- WWW/Mosaic Home Page: http://www-cse.ucsd.edu/users/jkay Email: jkay@cs.ucsd.edu  -----------[000097][next][prev][last][first]---------------------------------------------------- Date: Wed, 6 Jul 1994 10:30:04 GMT From: jhalpin@netcom.com (Joe Halpin) To: comp.os.ms-windows.networking.tcp-ip,comp.os.ms-windows.programmer.networks,comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc Subject: Re: Coding Conventions  In article <9407060505.AA24165@ariake.nwk.cl.nec.co.jp> mweiss@nwk.cl.nec.co.jp (Michael J. Weiss) writes: >Is there any widespread standard for coding conventions, such as nameing >functions, variables, uppercase, lowercase, etc., or is this too >personal and non-urgent a matter for such a standard to be accepted? You might be interested in a book called "Writing Solid Code" published by Microsoft press. It's about the internal practices of Microsoft, and contains some good ideas that are widely applicable. -- -------------------------------------------------------------------------- Joe Halpin | Centex Real Estate Corp jhalpin@netcom.com | Dallas TX Programmer/Analyst/Whatever | Standard Disclaimer Applies ---------------------------------------------------------------------------  -----------[000098][next][prev][last][first]---------------------------------------------------- Date: Wed, 6 Jul 1994 10:47:16 GMT From: atkinson@sundance.itd.nrl.navy.mil (Ran Atkinson) To: comp.protocols.tcp-ip Subject: Re: Max IP packet length and MTU  In article <2vcheq$71f@hpindda.cup.hp.com> raj@cup.hp.com writes:

>Of course, the answer to the question is likely to be "it depends..."
>:) :( :) ... on how many errors happen in the error case, how often
>one hits the error case, and such. I imagine that most people (myself
>included) would say that sending packets that have to be fragmented
>into 23 parts might be a bit excessive (or perhaps a contrived
>example, or NFS V3?  :), but sending packets that have to be fragmented
>into say 8 parts isn't the root of all evil.

I'm not sure that I'd want to be trying to defend intentional
fragmentation.  Certainly older versions of NFS/UDP have a history of
causing problems because of fragmentation.  One of the advantages of
NFS/TCP is that it can easily take advantage of Path MTU Discovery and
thereby avoid fragmentation in routers.

Fragmentation can be expensive throughout the whole distributed
system.  It can be expensive in hosts (both fragmentation and
reassembly) and it can also increase the load on routers (whose load
is more nearly proportional to packets/second than bits/second).  As a
relatively minor side effect, subnets with much fragmentation appear
often to have relatively low channel bandwidth utilisation.

It isn't an accident that the IP/ATM MTU is larger than an older ~8K
NFS/UDP packet.  There was a strong desire to avoid having to fragment
NFS/UDP over homogeneous IP/ATM subnets.  There are other reasons for
the chosen IP/ATM MTU, but NFS/UDP was definitely a major
consideration.

>I was not there, I was too young, but I expect that a lot of the "IP
>fragments are evil" thinking was generated back when networks did have
>higher error rates, and we did have more interfaces which could not
>handle back to back packets - now that we can get "back to back"
>packets without IP fragments, those interfaces are being replaced, now
>we now have links which are less susceptible to noise, we have a
>better understanding of how to avoid and recover from congestion.

Hmmm.  This originated a bit before my time as well.  However I can
say from implementation experience that fragmentation/reassembly in
hosts is not free.  Also, technologies such as Path MTU Discovery
exist and can significantly reduce fragmentation.  At least one of
the IPng proposals is requiring implementation of Path MTU Discovery
because the principals concluded that fragmentation remains evil
in the modern day.

discussions about congestion avoidance and control.  The congestion
avoidance and control problems were solved by Van Jacobson after
careful study (see his paper in SIGCOMM for more details).

>Here is a side track - Path MTU discovery is a way to make our
>networks run better by avoiding intermediate node fragmentation. I can
>see where if one was running TCP, and trying at all cost to avoid IP
>fragments, that Path MTU discovery would be happiness and joy. My
>question is "Is it good when you know that you are going to be sending
>fragments in the first place?" In other words, do we even want to try
>and fragment down to the lowest common segment size at the sending
>host for something like NFS? I would think that we would be better-off
>*not* doing that when we know that we are going to fragment anyway.

No.  Consider the impact on routers, for example.  Also, it matters
whether you are talking about NFS/TCP or NFS/UDP.  I strongly favour
the former for several reasons, not least of which is that the client
can know when the server goes down and take appropriate action.
Having a stateless file service protocol does NOT imply that is can
not or should not use a stateful transport protocol (there is a common


-----------[000099][next][prev][last][first]----------------------------------------------------
Date:      Wed, 6 Jul 1994 18:15:31 -0400
From:      "Bryan J. Ischo" <bi04+@andrew.cmu.edu>
To:        comp.protocols.tcp-ip
Subject:   Getting Remote Host Address Before Accept()


This is more of a UNIX question than tcp-ip, but ... does anyone know how to
get the address of the next remote host on the listener queue BEFORE calling
accept()?  Basically, I want to know who is trying to connect so I know
whether or not to accept the connection.  I could accept the connection,
the check the remote address in the struct sockaddr filled in by accept(),
then disconnect the remote host is not on my access list ... but as far as I
know, the connect() call on the other end would succeed, and I don't want that.

Any responses should be sent to this account as well as to this bboard.

Thank you very much,
Bryan
bji+@cs.cmu.edu (preferred), bi04+@andrew.cmu.edu


-----------[000100][next][prev][last][first]----------------------------------------------------
Date:      6 Jul 1994 12:44:13 GMT
From:      ckingsbu@mason1.gmu.edu (Christopher E Kingsbury)
To:        comp.protocols.tcp-ip
Subject:   Help Tuning FTP...

What can I do to tweak the transfer rate of FTP (i.e. packet size,
process priority, ...).  Currently, I am having to transfer very large
files between UNIX boxes across dedicated lines, a local ethernet
network, and the internet.  If somebody could recommend some books,
electronic documents, or has some ideas I would be very grateful.

Christopher Kingsbury


-----------[000101][next][prev][last][first]----------------------------------------------------
Date:      Wed, 6 Jul 94 13:41:59 GMT
From:      waghani@elof.acc.iit.edu (Anita Waghani)
To:        comp.sys.novell,comp.protocols.tcp-ip.ibmpc,comp.protocols.tcp-ip,comp.os.ms-windows.networking.tcp-ip
Subject:   Which protocol ? IP or IPX?


Which is a better choice of protocol IP or IPX ? for a Novell Network
of PC compatibles.
If both protocols are required what would be the ideal mix ?
The LAN may require to network with other networks hence IP would be
necessary, but what percentage of nodes should have IP capability ?
Only one ? or all ?
would the size of network would have any influence on decision ?

I do remember IP vs IPX discussion on the net . Is there a FAQ, archives,
technical papers, books etc which discusses this issue ?

I will post a summary if there's enough intrest.

--aw


-----------[000102][next][prev][last][first]----------------------------------------------------
Date:      Wed, 6 Jul 1994 13:42:03 GMT
From:      wjw@pt.com (Wald Wojdak)
To:        comp.protocols.tcp-ip
Subject:   LLA for the HP-UX network interface driver.

Hi there,

Is anyone out there who is familiar with the HP-UX rev 9.0x A 9000/747?
I am in a process of writing a VME FDDI network interface driver for
the HP-UX 9.0x. The device driver interfaces to the TCP/IP and also needs to
provide a Link Level Access (LLA) interface which allows application to talk
directly to the driver. This LLA is the HP invention. I have been working with
the HP Technical Support located in Chelmsford, Massachusetts for the last
two months trying to get some information regarding this LLA interface but
they are not of any help.

Is anyone out there who knows how to implement the LLA interface for
the HP-UX 9.0x network interface driver?

Waldemar Wojdak
Performance Computer                 --    --   --    Phone: (716) 256-0200
A Performance Technologies Company     |  |    |      Fax:   (716) 256-0791
315 Science Parkway                  --   |    |      Internet:  wjw@pt.com
Rochester, NY 14620                 |      --   --
--
__
Wald Wojdak, Performance Technologies Incorporated	wjw@pt.com
315 Science Parkway, Rochester, New York 14620            uupsi!ptsys1!wjw


-----------[000103][next][prev][last][first]----------------------------------------------------
Date:      Wed, 6 Jul 1994 14:54:14 GMT
From:      rstevens@noao.edu (W. Richard Stevens)
To:        comp.protocols.tcp-ip
Subject:   Re: Help Tuning FTP...

> What can I do to tweak the transfer rate of FTP (i.e. packet size,
> process priority, ...).  Currently, I am having to transfer very large
> files between UNIX boxes across dedicated lines, a local ethernet
> network, and the internet.  If somebody could recommend some books,
> electronic documents, or has some ideas I would be very grateful.

The best reference I've found on this is Jeff Mogul's chapter:

%T IP Network Performance
%A J. C. Mogul
%B Internet System Handbook
%E D. C. Lynch and M. T. Rose
%P 575-675
%D 1993

My first idea is for you to find out the window size used by your two
hosts.  (If the transfer is always unidirectional, then all you really
simple way to find that out.  Then calculate the bandwidth-delay product
for your pipe between the two hosts (ping can help here to measure the
RTT), and compare.  If there's a big difference then you can probably

Rich Stevens


-----------[000104][next][prev][last][first]----------------------------------------------------
Date:      Wed, 6 Jul 1994 17:01:25 GMT
From:      Bob Smith <bsmith@rahul.net>
To:        comp.protocols.tcp-ip
Subject:   RFD: comp.dcom.cdpd

************************************************************************
REQUEST FOR DISCUSSION (RFD)
comp.dcom.cdpd
************************************************************************

(This is **NOT** a Call For Votes.  A Call For Votes will be issued in
the groups to which this message is posted 21 to 30 days from the date
that this message first appears. Voting is to be recorded by a neutral
third party.)

Group Name:     comp.dcom.cdpd
Status:         Unmoderated
Summary:        Discussion of all aspects of Cellular Digital Packet
Data (CDPD), including discussions of carriers, services,
applications, specifications, and noteworthy events.
Distribution:   World

CHARTER
-------

CDPD is wireless protocol which offers low cost and ubiquitous radio
coverage to TCP-IP networks.  The technology uses the idle voice channels
available in the existing cellular telephone system for packet data
transmission. Application interface to CDPD can be via telnet, SLIP, UDP,
or TCP.  A CDPD modem uses the AT command set and has an IP address which
is assigned by the local cellular company (just as your cellular carrier
assigned the phone number to your cellular phone). CDPD may be the
preferred remote/mobile WAN since the time and cost overhead of a cellular
call establishment is not present.

The aim of comp.dcom.CDPD would be to provide an informal electronic
conference for anyone curious about, or involved with CDPD. It is hoped
that the group may further the understanding and awareness of CDPD.

CDPD's success requires the cooperation and coordination of many diverse
players: application developers, system integrators, cellular carriers,
infrastructure manufacturers, and modem manufactures. A newsgroup where
ideas, suggestions, and questions can be freely exchanged is needed to
help tie these players into an industry.

The FAQs would be an important part of the newsgroup and would include
as a minimum:
FAQs about the nature and scope of CDPD
a list of CDPD carriers and services offered
a list of CDPD modem manufacturers
a list of other CDPD products available

This newsgroup would allow the rapid and timely discussion of CDPD
related issues and events which might otherwise never be fully
disseminated.

Topics for discussion would include :-

Product announcements
Press releases of interest to the CDPD community
Innovative CDPD applications
CDPD deployment issues and plans
Interpretation of the CDPD specification
Infrastructure hardware: NMS, MDBS, MD-IS, ...
Infrastructure software: NMS, MDBS, MD-IS, ...
Modems - specifications, opinions, etc.
New product ideas
Databases, lists of...
CDPD security, encryption, and firewalls
Announcements/reviews of papers/conferences
Comparisons to alternatives such as RAM, Ardis
General discussion/opinions/questions.
Positions vacant
Professional news
Economic issues

We hope that you will support this group, and look forward to your
comments and participation in the discussions in news.groups.

This RFD has been posted to:
comp.dcom.lans.misc
comp.dcom.modems
comp.dcom.telecom
comp.os.ms-windows.networking.tcp-ip
comp.os.ms-windows.programming.networks
comp.protocols.misc
comp.protocols.tcp-ip
comp.std.wireless
news.announce.newgroups
sci.geo.satellite-nav

Thank you.

The Process of Creating a Newsgroup
------------------------------------

(a) RFD: Request for Discussion, i.e.., public hearing to take place in
the newsgroup news.groups on Internet for approximately one
month
(b) CFV: Call for votes (the voting period will be about 25 days)
(d) Announcement of new newsgroup

discussion.
(c)-->(d) assumes that the vote is favorable, i.e., Y > N+100 .and.
Y > (2/3)(Y+N)

Y being the number of YES votes, N being the number of NO votes for the
creation of the proposed newsgroup.

--
Bob Smith <bsmith@rahul.net>


-----------[000105][next][prev][last][first]----------------------------------------------------
Date:      7 Jul 1994 02:07:29 -0500
From:      mweiss@nwk.cl.nec.co.jp (Michael J. Weiss)
To:        comp.os.ms-windows.networking.tcp-ip,comp.os.ms-windows.programmer.networks,comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject:   DNS

Can someone explain what DNS is?

Also, what does it have to do with DHCP?

Thanks,

--Mike


-----------[000106][next][prev][last][first]----------------------------------------------------
Date:      Wed, 6 Jul 1994 18:25:39 GMT
From:      philippe@gull.cfmu.eurocontrol.be (Philippe Waroquiers)
To:        comp.protocols.tcp-ip,comp.unix.programmer,comp.sys.hp.hpux
Subject:   changing route gives TCP problem


We have +- 30 workstations connected to a server via two Ethernet LANs.
TCP/IP is used between the server and the workstations.
When there is a problem on one LAN, we want to have the other LAN used
transparently by the applications in less than 60 seconds.

The IDEA we are looking is :
if we cannot contact the server via the lan1 then
first: add another route to the server via the other address of the
server (the internal IP router of the server will route the packets).

second: on the server, add a route to our workstation via the second
address (again, the internal IP router of the ws will route the packets).
The lan problem is simulated by disconnecting the cable.

To do this, we have a SHELL SCRIPT running on each ws. The shell script
does an infinite loop :

while true
then
fi

After changing the routes, we obtain the following NICE results :
1) new tcp/ip connections can be opened without any problems between

2) idle connections (i.e. with no traffic on it when disconnection)
works after changing the routes.

BUT PROBLEM :
3) non-idle connections (i.e. traffic going on when disconnection) seems
to behave erratic :

some small number of packets are transmitted at very large interval
(typically 1 min). After a few minutes, connection is closed (reset).

or
nothing happens anymore on this connection. After a few minutes,
connection is closed (reset).

Is there an explanation for this behaviour ?
Is there a solution to this behaviour ?

Many thanks in advance for any help/idea/suggestion/explanation.

--
Philippe WAROQUIERS             Eurocontrol - Central Flow Management Unit
philippe@cfmu.eurocontrol.be    Rue de la fusee, 96
Tel: +32 2 729 97 35            1130 Brussels
Fax: +32 2 729 90 22            Belgium


-----------[000107][next][prev][last][first]----------------------------------------------------
Date:      6 Jul 1994 19:28:53 GMT
From:      jimrush@indirect.com (Jim Rush)
To:        comp.protocols.tcp-ip
Subject:   Re: Book Review - TCP/IP Illustrated, Volume 1

W. Richard Stevens (rstevens@noao.edu) wrote:
: > an enquiry regarding one of his other books. I've limited this message
: > to the main chapter headings; for those interested I can email the full
: > TOC.

: FYI, the entire TOC (ascii and PS), Preface, and complete sample chapter in
: PS are available via anonymous ftp from aw.com in the aw.prof.comp.series
: directory.

: 	Rich Stevens
My 2cents,

Thanks Rich.  I have found the book to be very usefull.

Jim


-----------[000108][next][prev][last][first]----------------------------------------------------
Date:      6 Jul 1994 19:35:35 GMT
From:      ken@jazz.concert.net (Ken Whitfield)
To:        comp.protocols.tcp-ip
Subject:   IP Routing

Fellow Netters:

Looking for software thay allows a MAC or PC to route or bridge IP packets from
an ethernet interface through a serial port.

PC/Mac          PC/Mac
Router 		Router
or		  or
Bridge		Bridge
_____	_____		_____	_____
|   |	|   | Serial	|   |   |   |
|   |   |   |-----------|   |   |   |
|   |   |   |           |   |   |   |
-----   -----           -----	-----
|       |		  |       |
============		==============

--
-------------------------------------------------------------------------------
Ken Whitfield				MCNC Information Technologies Division
(919)248-1998				RTP, NC 27709-2889


-----------[000109][next][prev][last][first]----------------------------------------------------
Date:      6 Jul 94 18:52:28 BST
From:      udaa055@bay.cc.kcl.ac.uk (Andy Harper, KCL Systems Manager)
To:        comp.protocols.tcp-ip
Subject:   Implementing IP address extensions

An oft discussed question is how the IP addresses used on Internet can be
extended now that the explosion in personal computers and connectivity has left
the 32-bit address space looking a bit sick! Rumour has it that, if growth
increases at the same rate as currently, we'll run out of addresses in the near
future.

Clearly, there a number of ways it COULD be done and many are being examined by
the powers that be to decide on a way forward. What concerns me though, is how
to implement any of them without incurring significant cost and inconvenience
to our existing users! Isn't it the case that all of the mechanisms so far
proposed will require changes to routers and/or the IP software (if you're
going to have any kind of address extension then software and routers need to
be aware of it).

I had considered that changes might be localised to the external connections of
a site, leaving all internal systems as they are, but those internal systems
would still need the ability to specify an extended address if they want to get
elsewhere. Some clever mapping techniques might be possible but I can't see one
that is totally effective.

So, what options are there that don't require all and sundry who use Internet
to spend wads of cash and/or find upgraded network applications that understand

Thanks

Andy Harper
Kings College London


-----------[000110][next][prev][last][first]----------------------------------------------------
Date:      06 Jul 1994 20:49:13 GMT
From:      lee@netspace.students.brown.edu (Lee J. Silverman)
To:        comp.protocols.tcp-ip,comp.os.ms-windows.networking.tcp-ip,comp.mail.smail,comp.mail.sendmail,comp.mail.misc,comp.mail.mime
Subject:   Re: POP on SCO


There's a POP server (and source) for Linux, available on
server and recompile it for SCO.

Lee

--
Lee Silverman, Brown class of '94, Brown GeoPhysics ScM '95
Email to: Lee_Silverman@brown.edu
Phish-Net Archivist: phish-archives@phish.net
"Nonsense - you only say it's impossible because nobody's ever done it."


-----------[000111][next][prev][last][first]----------------------------------------------------
Date:      Thu,  7 Jul 94 08:01:00 -0640
From:      john.will@dscmail.com (John Will)
To:        comp.protocols.tcp-ip
Subject:   FTP Software Kernel API

P >Called FTP and they said "send $400 for the SDK and the API is included". P >Since the SDK is all C modules and I program in assembly this does not P >seem reasonable. I think it might be time to learn C... :-)  -----------[000112][next][prev][last][first]---------------------------------------------------- Date: Thu, 7 Jul 94 08:03:00 -0640 From: john.will@dscmail.com (John Will) To: comp.protocols.tcp-ip Subject: Re: CD-ROM and TCP/IP  L >> This answer, although somewhat unduly sarcastic is not entirely L >> in jest. You can either attach it to someone's PC or buy a L >> standalone unit and put the CD-ROM on that. These are cheap, pretty L >> reliable, off-the-shelf answers. The alternative, until someone L >> sells a CD-ROM NFS server box, is gonna get pretty ugly. L > L >Actually, DEC does sell such a box. It's called an InfoServer, as I recall, L >and it allows you to hang lots of different mass storage devices on your net. L >It costs about$2000 US, I think.

You bet, and when you take the covers off that box, I'll bet you find a
pretty standard PC inside!


-----------[000113][next][prev][last][first]----------------------------------------------------
Date:      Wed, 6 Jul 1994 21:32:23 GMT
From:      martin bowman <mbowman@sita.int>
To:        comp.protocols.tcp-ip,comp.os.ms-windows.networking.tcp-ip,comp.mail.smail,comp.mail.sendmail,comp.mail.misc,comp.mail.mime
Subject:   POP protocol on SCO


Does anyone have any information about implementing the POP protocol on SCO
UNIX?


-----------[000114][next][prev][last][first]----------------------------------------------------
Date:      Wed, 6 Jul 1994 21:38:06 GMT
From:      martin bowman <mbowman@sita.int>
To:        comp.protocols.tcp-ip,comp.os.ms-windows.networking.tcp-ip,comp.mail.smail,comp.mail.sendmail,comp.mail.misc,comp.mail.mime
Subject:   POP on SCO


Does anyone have any information on implementing the POP protocol on SCO UNIX?


-----------[000115][next][prev][last][first]----------------------------------------------------
Date:      6 Jul 1994 22:22:50 GMT
From:      raj@cup.hp.com (Rick Jones)
To:        comp.protocols.tcp-ip
Subject:   Re: Max IP packet length and MTU

Ran Atkinson (atkinson@sundance.itd.nrl.navy.mil) wrote:
: Fragmentation can be expensive throughout the whole distributed
: system.  It can be expensive in hosts (both fragmentation and
: reassembly) and it can also increase the load on routers (whose load
: is more nearly proportional to packets/second than bits/second).  As a
: relatively minor side effect, subnets with much fragmentation appear
: often to have relatively low channel bandwidth utilization.

First - perhaps that low utilization is the result of not having to
replicate transport headers, and fewer acknowledgements?-) (Or did you
mean effective utilization, but the real utilization was high?)

"Can be" and "Must be (is)" are different statements. It is just as
easy I should think to have "expensive" support for receiving out of
implementations support this feature and do it without people claiming
that it was expensive.

When I look at a profile of a kernel being exercised by the SPEC SFS
(LADDIS) benchmark, the IP fragmentation and reassembly routines are
*way* far down on the list - below fortieth and beyond. Of course,
this could be used as reasoning to go ahead and do the fragmentation
all the way down to the smallest path's size in the host, but it also
indicates (along with the post from the fellow at Cisco) that
fragmentation in the routers does not have to be all that expensive.

While the act of generating IP fragments itself is not "expensive" in
terms of instruction cycles, fragmenting all the way down to the
smallest size will increase the CPU used on the originating host
because it will force more trips through the interface driver. Would
you rather go through an ATM driver and card firmware once, or six
times?

When you say that a router's load is more nearly proportional to
packets/second than bits/second, doesn't that imply that it would be
less "loadful" on the router to send it two larger fragments on the
FDDI ring rather than six smaller fragments? The first case would seem
to place 1/3 the load on the router.

: Perhaps I wouldn't choose to couple discussions about link noise with
: discussions about congestion avoidance and control.  The congestion
: avoidance and control problems were solved by Van Jacobson after
: careful study (see his paper in SIGCOMM for more details).

I wasn't really looking to couple them. However, the only reason that
I can see as being valid for stating that IP fragmention should be
avoided at most cost is the argument that when you loose one IP
fragment, you effectively loose them all. It is also the argument that
I would agree with (modulo the number of fragments you wish to
generate per datagram) The two causes of packet loss with which I am
familiar are congestion, and corruption.

: >Here is a side track - Path MTU discovery is a way to make our
: >networks run better by avoiding intermediate node fragmentation. I can
: >see where if one was running TCP, and trying at all cost to avoid IP
: >fragments, that Path MTU discovery would be happiness and joy. My
: >question is "Is it good when you know that you are going to be sending
: >fragments in the first place?" In other words, do we even want to try
: >and fragment down to the lowest common segment size at the sending
: >host for something like NFS? I would think that we would be better-off
: >*not* doing that when we know that we are going to fragment anyway.

: No.  Consider the impact on routers, for example.  Also, it matters

But it was just said that the load on a router is proportional to the
number of packets, and PathMTU has already been shown to *increase*
the number of packets (in one very common case anyhow) that a (first
hop) router will be sent when the packet has to be fragmented in the
first place.

It would definitely increase the number of packets when that router is
routing NFS V2 from ATM to Ethernet or FDDI because the datagram can
arrive unfragmented, in *one* packet on the ATM interface as opposed
to six.

I wonder which is more expensive in the new Cicso routers - receiving
six packets as opposed to one, or receiving one and having to
fragment it into six? (The ATM to Ethernet case)

Running NFS over TCP would have the same effect then of increasing the
load on the router because it increases the number of packets it
processes (both pseudo fragmentation *and* ACK's I'd imagine ;-)
However, I can agree on advantages in running NFS over TCP in a WAN
case that would outweigh that.

Lest anyone think that I am trying to ferment revolution and start
flooding the Internet with IP fragments, as much as what I've been
saying has been to challenge assumptions to ascertain their validity.
Particularly the one that says that IP Fragmentation is "expensive"
(an unfortunately vague term) I know that I've learned some things
from it (such as the now improved IP fragmenting ability of new Cisco
routers), and I hope that others have too.

rick jones
speaking only as rick jones...

I've always liked the phrase "Don't raise the bridge, lower the
river!"


-----------[000116][next][prev][last][first]----------------------------------------------------
Date:      7 Jul 1994 02:40:15 GMT
From:      tli@cisco.com (Tony Li)
To:        comp.protocols.tcp-ip
Subject:   Re: Max IP packet length and MTU

In article <2vfarq$562@hpindda.cup.hp.com> raj@cup.hp.com writes: I wonder which is more expensive in the new Cicso routers - receiving six packets as opposed to one, or receiving one and having to fragment it into six? (The ATM to Ethernet case) Fragmenting. I wasn't able to improve it THAT much. ;-) Tony  -----------[000117][next][prev][last][first]---------------------------------------------------- Date: Thu, 7 Jul 1994 03:34:23 GMT From: dkaye@rds.com (Doug Kaye) To: comp.sys.novell,comp.protocols.tcp-ip.ibmpc,comp.protocols.tcp-ip,comp.os.ms-windows.networking.tcp-ip Subject: Re: Which protocol ? IP or IPX?  In article <1994Jul6.134159.2175@iitmax.iit.edu> waghani@elof.acc.iit.edu (Anita Waghani) writes: >Which is a better choice of protocol IP or IPX ? for a Novell Network >of PC compatibles. >If both protocols are required what would be the ideal mix ? Oooh! Not an easy question, Anita. At this point in time it is easier to make NetWare adapt to TCP/IP than it is to make "other" things adapt to IPX. That's primarily because TCP/IP is found on a wider range of platforms than is IPX. If you're primarily a NetWare shop, there are a number of opportunities to linke to other systems using IPX, but they are not universal. OTOH, while it takes some extra effort (and$$) to run NetWare using TCP/IP, you then have access tomost non-NetWare systems. I fyou could be more specific, we could probably give you better advice. TO what must you connect othern than NetWare? ...doug ================================= Doug Kaye <dkaye@rds.com> Rational Data Systems, Novato, CA Tel:415-382-8400 FAX:415-382-8441 =================================  -----------[000118][next][prev][last][first]---------------------------------------------------- Date: 7 Jul 1994 10:16:32 -0400 From: jmb@kryten.atinc.com (Jonathan M. Bresler x346) To: comp.protocols.tcp-ip Subject: slip--must be 2 nets  i have just installed a terminal server with slip capabilities. the vendor chase iolan informs me that the two endpoints of the slip connection must be either on different networks or on different subnets of a single network. i checked the rfc1055 and did not find this addressed. or is the limitation of different nets/subnets, a routing limitation? thanks, jmb -- Jonathan M. Bresler jmb@kryten.atinc.com | Analysis & Technology, Inc. | 2341 Jeff Davis Hwy play go. | Arlington, VA 22202 ride bike. hack FreeBSD.--ah the good life | 703-418-2800 x346  -----------[000119][next][prev][last][first]---------------------------------------------------- Date: 7 Jul 1994 10:26:19 -0400 From: imatex@CAM.ORG (Imatex Communications Inc.) To: comp.protocols.tcp-ip Subject: How to use UDP in interrupt manner with SCO sV r3.2 v4.0?  I want to acheive communications between many servers (that don't communicate to each other) and many clients (that don't communicate to each other neither) using UDP protocol. I would prefer to work in asynchronous communication, since each clients must wait for their stdin to receive data to be transmitted on the lan. I tought to use SIGIO as described by Richard Stevens in Unix Network Programming. Since I am developping on SCO Unix System V release 3.4 version 4.0, SIGIO is not available. I also took a look to streams, but I have not found how to implement interrupts. So far, as I've seen, the only way to use streams in TCP/IP communication is via TLI. Tell me I am wrong! Any sugestion, with C code examples, will be VERY helpfull. Many thanks in advance. Daniel Beaudry -- Imatex Communications Inc. imatex@cam.org.ca  -----------[000120][next][prev][last][first]---------------------------------------------------- Date: 7 Jul 1994 12:13:19 -0500 From: claird@Starbase.NeoSoft.COM (Cameron Laird) To: comp.os.vms,comp.protocols.tcp-ip,alt.culture.internet Subject: What's the metric of your space? (was: VMS and (bundled) TCP/IP)  In article <1994Jul4.130746.1@spcvxb.spc.edu>, Terry Kennedy, Operations Mgr. <terry@spcvxb.spc.edu> wrote: >In article <1994Jul2.013658.5866@pinet.aip.org>, boswell@pinet.aip.org (jonathan_boswell) writes: >> Yes, but the SMTP "conversation" is still layered on top of TCP, which is in >> turn layered on top of IP, and those darn packets are going to travel all >> over the country and (possibly) around the world, before they reach their >> destination. I think this was the point of the original post, was it not? > > The situation today is that there are a variety of Internet providers in >most areas. This is a Good Thing - it lets customers shop based on price, per- >formance, or whatever else makes them happy. However, it means that a site >that was "real close" one day may be somewhat further away the next day if one >or both of the parties changes providers. For example, this traceroute (be- >tween SPC and Stevens Tech, sites only a few miles apart in NJ) goes via Cal- >ifornia: > > 1 gw2-nj.new-york.net (192.107.46.1) 2.2 ms 3.5 ms 2.1 ms > 2 gw1-nj.new-york.net (165.254.21.2) 5.8 ms 2.8 ms 2.8 ms . . . >15 stevens-gateway.jvnc.net (130.94.7.50) 299.6 ms * 235.6 ms >16 vaxc.stevens-tech.edu (155.246.1.4) 207.8 ms * 197.3 ms . . . > Unless you have a great deal of traffic destined for a single host or net- >work that is really suboptimally routed, you should probably ignore this. If >you do have a lot of traffic, consider a point-to-point link between your >nets. Of course, you'll have to justify the cost of that, which may not make >the existing route seem so bad 8-) . . . This conversation has me confused. I understand everything you wrote, Mr. (?) Kennedy--in fact, this was an outstanding article, being both entertaining and informative--but I don't know whether it bears on the question (whose? I've lost track) of how silly it is for those darn little packets to bounce around as they do. I say, there's nothing inherently wrong in taking a shortcut through California to get from Delaware to NYC, although it does inspire ruminations on The Essence of the Post-Industrial World. Does someone believe that such a situation inherently involves a call to action? -- Cameron Laird claird@Neosoft.com (claird%Neosoft.com@uunet.uu.net) +1 713 267 7966 claird@litwin.com (claird%litwin.com@uunet.uu.net) +1 713 996 8546  -----------[000121][next][prev][last][first]---------------------------------------------------- Date: 7 Jul 1994 12:03:08 -0400 From: tal@Warren.MENTORG.COM (Tom Limoncelli) To: comp.protocols.tcp-ip Subject: Re: Book Review - TCP/IP Illustrated, Volume 1  In <2vanq6$g7e@sun.cais.com> bass@cais.cais.com (Tim Bass (Network Systems Engineer)) writes:

>This review is too late.  Stevens book, _TCP/IP Illustrated_
>is great book.  This books has been out as long as Philadephia
>(the movie) or longer.  We certainly don't need a review on
>6 month old movies OR 6 month old books.

----------------------------- by Tom Limoncelli
I thought the movie Philadelphia was excellent and brought a very
hidden (but pervasive) issue to an audience that would usually not deal
with, nor appreciate, such issues until they were facing them head-on.
(at which time it may be too late to deal with the issue rationally).
I can ignore the minor cultural and acting mistakes, but I was
disappointed to find that the ending is not consistent with the actual
laws in Philadelphia, PA.  To me it was a "suprize ending" because I
was expecting the ending to be consistent with the actual current law.
Though I am not a legal expert, I believe the judge's decision would be
legally consistent with reality if the movie took place elsewhere, for
example New Jersey, where the anti-discrimination laws are different.
I'm not much of an audiophile, but I thought the soundtrack was
excellent.

-Tom
--
S ******************* I do not speak for Mentor Graphics Corp ********
W    Anonymous FTP: vector.casti.com /pub/QRD/events/stonewall25
2  WWW/Mosaic/Lynx: http://vector.casti.com/QRD/Stonewall25.html
5    gopher: vector.casti.com select 10, 1, 24, 29.  or call +1-212-242-7366


-----------[000122][next][prev][last][first]----------------------------------------------------
Date:      7 Jul 94 06:40:00 GMT
From:      paul@alantec.com (G. Paul Ziemba)
To:        comp.protocols.ppp,comp.protocols.tcp-ip
Subject:   why no more than 3 interfaces with cslip-2.7?

Software:	LBL cslip-2.7
Hardware:	Sun4
OS:		SunOS 4.1.2

I recently tried increasing NSL from 2 to 4. When I tried loading
(I used the -v argument) but eventually snarked with "invalid argument".

Reducing NSL to 3 eliminated the problem.

How can I get more than 3 slip interfaces?

many thanks,

~!paul
--
Paul Ziemba, software archaeologist: paul@alantec.com	alantec!paul
"The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore, all progress
depends on the unreasonable man." - George Bernard Shaw


-----------[000123][next][prev][last][first]----------------------------------------------------
Date:      Thu, 7 Jul 1994 12:08:59 UNDEFINED
From:      mojoski@mindspring.com (Warren D. Simmons)
To:        rec.autos.marketplace,comp.protocols.tcp-ip,alt.winsock
Subject:   Re: Internet Technical Survey ( less than a page )

In article <940707120510.B31800@news.nbnet.nb.ca> davidd@nbnet.nb.ca (David Delaney) writes:

>>Thank You for your time I will post a summary if there is enough responses or

I beleive this was supposed to be e-mailed, not posted!
-Del Simmons


-----------[000124][next][prev][last][first]----------------------------------------------------
Date:      Thu, 07 Jul 1994 15:59:35 -0500
From:      messina@mcs.com (David Messina)
To:        comp.sys.mac.comm,comp.sys.mac.misc,comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc,comp.protocols.ppp
Subject:   Re: where can I get the interSLIP for MAC?

In article <ZHAO.94Jul6121917@crl.crl.nmsu.edu>, zhao@crl.nmsu.edu (Z.
Zhao) wrote:

> Can anybody here tell me where the interSLIP for MAC is hidden ?
> Is it a freeware or shareware or commercial package?

It's free, and available on many archives (info-mac, e.g.)  It also should
be at

ftp://ftp.tidbits.com/pub/tidbits/tisk/tcp/inter-slip-installer-101.hqx

--
David Messina
messina@mcs.com


-----------[000125][next][prev][last][first]----------------------------------------------------
Date:      Thu, 07 Jul 1994 12:05:10 AST
From:      davidd@nbnet.nb.ca (David Delaney)
To:        rec.autos.marketplace,comp.protocols.tcp-ip,alt.winsock
Subject:   Re: Internet Technical Survey ( less than a page )

On Fri, 24 Jun 1994 09:10:38 GMT,  tomw@netcom.com writes:
>
>This is a short questionaire to find out usage trends for various internet
>connectivity issues, If you have time please fill it out and E-mail to
>tomw@netcom.com ( no flames please! ). I will post a summary.
>
>How do you currently connect to the internet: ( use an X to fill in field )
>-------------------------------------------------------------------------------
>Raw Serial ( TTY ):Slip:x
>PPP:
>Direct Connection ( via ethernet or other "direct" meachanism ):
>Other:
>Don't know (??):
>
>If you are not directly connected:
>do you use an internet provider ( netcom, delphi... ):x
>do you use a bbs ( any bbs or america online, compuserve ... ):
>are you a university student:
>do you consider PPP or Slip Difficult to set up:
>
>What kind of host machine do you use:
>PC (windows):x
>Sun:
>Other Unix Vendor:
>Mac:
>Other:
>
>Do you read more than 10 news groups:xx
>Do you use telnet:x
>Do you use Ftp:x
>Do you use a Gopher client: x
>Do you use a Wais client:
>Do you use a www client ( like mosaic ):x
>
>If you never have used a mosaic like client do you think you might?:
>do you know what the world wide web is:x
>
>If it was safe, would you use internet shopping or other "non-intrusive" ( you
>must ask ) services : xx
>
>Do you see the Internet as a way to propagate published documents or other
>media:x
>-------------------------------------------------------------------------------
>Thank You for your time I will post a summary if there is enough responses or
>you may ask me via E-mail ( in about a week or so ).
>
>
>
>


-----------[000126][next][prev][last][first]----------------------------------------------------
Date:      7 Jul 1994 08:25:38 GMT
From:      bubgo@alf.uib.no (Bjarte Johnsen)
To:        comp.os.ms-windows.networking.tcp-ip,comp.os.ms-windows.programmer.networks,comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject:   Re: DNS

DNS = Doman Name Server (Cryptic :)

Well basicly it's like this:

All TCP/IP networks relies on ip addresses 129.177.34.221, you get the idea, this however is kinda hard
to remember for a long period, therefor they have made up a sceme that maps this ip number to a address like
this : flie.ifi.uib.no.

So unless you have this mapping stated in your own HOSTS file, wich basicly says that whenever you use
FLIE.IFI.UIB.NO you really mean 129.177.34.221.
You have to have a sentral machine who does this for you and sends the right translation back to your application.

I don't think I will go any closer into the subject on HOW a DNS server work, doing so would probably make me yet
another author of a "How DNS work" book.

DHCP = Dynamic Host Configuration Protocol

This doesn't really have anything to do with DNS.

It's "just" a automatic network configurator.
When you put a new pc in a lan, you might have a server who runs DHCP, the network installation program enquires the

Yours

Bjarte Johnsen
Engineer
Inst. for Informationscience
Uni. of Bergen, Norway.


-----------[000127][next][prev][last][first]----------------------------------------------------
Date:      7 Jul 1994 16:49:34 -0400
From:      alberg@pipeline.com (Al Berg)
To:        comp.protocols.tcp-ip
Subject:   Routers, packet size, and RFC 1122 (a query)

A client of mine has made some changes to their LAN recently
with interesting results...

The LAN used to be one big segment with 130 users. In an effort
to segment traffic, we put a router in and broke the LAN up
into 6 segments.  In general, performance is good.  FTP between
the PC clients and the UNIX hosts (1 IBM AIX and 1 SCO) has
gotten really slow, however.

We put a protocol analyzer on the net and found that:

When FTPs happen between the UNIX boxes and a PC on the same
segment, the maximum packet size is about 1500 bytes and
performance is good.

When FTPs happen between a host on segment A and a client on
segment B, maximum packet size drops to 576 bytes and speed
drops by a factor of 5 or more.

When we put up a Chameleon FTP server on a PC on segment A and
do an FTP from a PC on segment B, maximum packet size stays at
1500 bytes and performance is good.

The IBM rep sent us info saying that RFC 1122 basically says
that when IP packets cross a router, IP decides to throttle
back the max packet size to 576 since any router or gateway
along the path to the destination will be able to handle that
size packet.

Some questions:

So, NetManage is breaking the rules here, no?  (Not that I am
complaining...)

Has anyone "solved" this problem on their net?

Al Berg
NETLAN Inc.
al_berg@netlan.com


-----------[000128][next][prev][last][first]----------------------------------------------------
Date:      Thu, 07 Jul 94 22:16:09 -0700 (PDT)
To:        comp.protocols.tcp-ip
Subject:   Small and Compact TCP/IP/PPP


How small and compact, in terms of memory requirements, can you
make a TCP/IP and PPP implementation?

The thought here is to support a particular application that
allows users to dial-up a paging system and to send a page to
another user. Future services in paging will support sending
pages to users with PDAs and laptops that can receive pages.
This will allow sending binary data (e.g., spreadsheet data) to
someone with a pager equipped PDA or laptop.

People using Macs or PCs should be able to connect to the
paging service to send pages using basic TCP/IP (through local
networks or PPP) packages for these platforms. PDAs and similar
small devices may not (do not?) have TCP/IP packages, so the
page entry application on these platforms needs a custom
dial-up protocol or a very small TCP/IP/PPP implementation that
can be bundled with the application.

So, the question is how small can you make such an
implementation? It can be "shrink wrapped" with the application
and just support one application (i.e., one TCP connection) on
one port using only the serial port. It must be able to do
dial-up and accept IP address assignment from the remote
system. The remote end will fully support TCP and IP and PPP,
but the local end need only implement enough to support its
application and still establish a working link to the remote
end.

Any and all thoughts are welcomed. If there is a good response,
I will summarize back to the net. Pointers to other references
are also welcomed.

Bob

+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+


-----------[000129][next][prev][last][first]----------------------------------------------------
Date:      Thu, 07 Jul 94 22:18:57 -0700 (PDT)
To:        comp.protocols.tcp-ip
Subject:   Choosing TCP or UDP


I am looking for detailed information that will help us decide
whether to use TCP or UDP for some new features we want to
implement.

We currently ship data between our terminals using a serial
based protocol at up to 9600 bps (there may be several such
ports on each terminal). We are moving to TCP/IP over a single
Ethernet port. We are debating whether to use TCP or UDP.

We can model our data in two ways:
1 - like a transaction system where the application sends an
APDU to another terminal and the terminal responds.

2 - like a stream, where one application is sending a number
of these APDUs back to back, but the responses, which are
much smaller, may have some gaps between them.

I like TCP for its realiability. We need to be sure the data
gets where its going, and we really don't want to build TCP
type reliability into our application. Further, TCP does some
congestion avoidance, which UDP does not.

Others favor UDP for its reduced overhead, no need to manage
connections, supports the transaction model in 1 above, and may
provide better throughput.

Our current throughput requirements are not great, but new
features involving the real-time movement of compressed voice
are being planned. I should indicate that the networks are wide
area, not LANs, some will be nationwide. Current estimates are
that we will need 1.5 Mbps throughput rates (sustained) into and
out of our equipment.

So we need the best protocol for reliable, high-bandwidth,
real-time applications (actually only the voice data movement
has a real-time requirement). We want to avoid congestion
problems during peak usage periods.

So I need pointers to references for the use of UDP and TCP in
high bandwidth real-time applications. I would also like to
correspond with anyone who has experience in this area. I would
UDP. Posted or email responses are welcomed, and I will
summarize back to this group.

+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+


-----------[000130][next][prev][last][first]----------------------------------------------------
Date:      Thu, 7 Jul 1994 10:39:11 GMT
From:      rstevens@noao.edu (W. Richard Stevens)
To:        comp.protocols.tcp-ip
Subject:   Re: Getting Remote Host Address Before Accept()

> This is more of a UNIX question than tcp-ip, but ... does anyone know how to
> get the address of the next remote host on the listener queue BEFORE calling
> accept()?  Basically, I want to know who is trying to connect so I know
> whether or not to accept the connection.  I could accept the connection,
> the check the remote address in the struct sockaddr filled in by accept(),
> then disconnect the remote host is not on my access list ... but as far as I
> know, the connect() call on the other end would succeed, and I don't want that.

You cannot do this with the typical (i.e., Berkeley-derived) Unix TCP/IP.
Period.  (Well, I guess you could *if* you used something like BPF or
DLPI to look at every SYN that arrives, but I don't think that's what
you're asking ...)  Solaris 2.x has an "experimental" tcp_eager_listeners
variable that was intended for this capability, but as I hear they found
enabling it broke certain applications (FTP).

Also, don't be fooled into thinking TLI can do this for you, and that
it's a sockets problem.  I'm not familiar with a single Unix TCP/IP
TLI stack that gives you this capability either.

Berkeley actually provide a way to do this with sockets but only for the
OSI protocols.  Van Jacobson posted the following note on this same topic
a few weeks ago.

> Message-Id: <9406271419.AA08874@rx7.ee.lbl.gov>
> To: Ian Heavens <ian@spider.co.uk>
> Cc: end2end-interest@charm.isi.edu
> Subject: Re: half baked anycastoff idea...
> Date: Mon, 27 Jun 94 07:19:38 PDT
> From: Van Jacobson <van@ee.lbl.gov>
>
> > The market demands conformance to Berkeley TCP/IP semantics and
> > API, but I thought the RFCs and not the damn Berkeley code was
> > the standard!
>
> RFCs typically do a detailed description of the protocol and a
> cursory description of the API.  Berkeley sockets actually
> follow the API sketched in RFC793 very closely (compare the
> description of "OPEN" on p.45 with the semantics of "accept")
> and if you know the early BBN-to-Berkeley history of the BSD
> code, you know that this similarity is no accident.
>
> It's fairly easy to extend the Berkeley API, in a backwards
> compatible way, to allow a defered accept.  Here is part of the
> accept(2) manual page from 4.4BSD:
>
>      For protocols marked as requiring an explicit confirmation, such as ISO
>      or DATAKIT, accept() can be thought of as merely dequeueing the next con-
>      nection request and does not imply confirmation.  Confirmation is im-
>      plied by a normal read or write on the new file descriptor, and rejection
>      is implied by closing the new socket.
>
>      One can obtain user connection request data without confirming the con-
>      nection by issuing a recvmsg(2) call with an msg_iovlen of 0 and a non-
>      zero msg_controllen, or by issuing a getsockopt(2) request.  Similarly,
>      one can provide user connection rejection information by issuing a
>      sendmsg(2) call with providing only the control information, or by call-
>      ing setsockopt(2).
>
> The 'lazy accept' on first read/write is compatible with almost
> all the existing programs.  Work was planned to add a sockopt to
> set/reset the "explicit confirmation" option on a per-listen-socket
> basis for TCP and to do the minor surgery on tcp_input &
> tcp_usrreq needed to implement the option.  Berkeley CSRG died
> from lack of funding before this work was completed.
>
>  - Van


-----------[000131][next][prev][last][first]----------------------------------------------------
Date:      7 Jul 1994 18:26:57 -0400
From:      zbig@junior.wariat.org (Zbigniew J. Tyrlik)
To:        comp.protocols.tcp-ip
Subject:   Re: slip--must be 2 nets

In <2vh2oe$gr1@kryten.atinc.com> jmb@kryten.atinc.com (Jonathan M. Bresler x346) writes: >i have just installed a terminal server with slip capabilities. >the vendor chase iolan informs me that the two endpoints of the slip >connection must be either on different networks or on different subnets >of a single network. I know I am using ( and selling to my customers :-) Livingstone routers for some reasons.. >i checked the rfc1055 and did not find this addressed. >or is the limitation of different nets/subnets, a routing limitation? Using Livingstone PM series I use one C class to service a dozen hosts on Ethernet, and 2 PM's with dial-up lines; no problems assiging IP's from this same network, no subnetting in use... >thanks, >jmb _zjt ( wannabe in training ) -- ******************************************************************** Zbigniew J. Tyrlik DoD# 0759 VF700C '84 zbig@wariat.org APK Public Access UNI* Cleveland, (216)-481-9436 Feeds, shell, FTP, telnet, IRC, MUD Uniboard distribution point ********************************************************************  -----------[000132][next][prev][last][first]---------------------------------------------------- Date: 7 Jul 1994 23:37:24 -0700 From: pls@crl.com (Paul Schauble) To: comp.protocols.tcp-ip Subject: Book recommendation? IP routing  Would anyone care to recommend a book that covers the tcp/ip protocols with particular emphasis on ip routing? I believe that some work has been done by DoD on IP routing over radio links. I would be very interested in information on this. Thanks, ++PLS  -----------[000133][next][prev][last][first]---------------------------------------------------- Date: Fri, 8 Jul 94 00:34:00 -0700 From: philip.burton@spacebbs.com (Philip Burton) To: comp.protocols.tcp-ip Subject: Re: THE winsock??  [stuff deleted] >The big change/addition is expanding the spec to include other networks >such as IPX/SPX and OSI based networks. >There is no mystery that both Chicago and Daytona will include a >finished version of the TCP/IP stack that's now in beta. >Short term, I don't know if Chicago will include a fully compliant >WinSock 2.0 DLL right out of the gate. It would be an incredible feat >if they could get all that work done on time [Plus I have no idea >where MS would get something like an OSI stack !!!] But why use OSI? Why should MS spend resource to do this? (Don't they have other things to do with their money?) Although it seemed say 5 years ago that OSI would displace TCP/IP in the marketplace, in part due to US Government pressure (GOSIP), that displacement hasn't happened. In fact, even in parts of Europe, TCP/IP is displacing OSI! And, OSI still has the (silly, unnecessary) problem of the two incompatible transport stacks: TP4/CLNS vs. TP0/X.25. Plus, plus, plus. Damn shame, though. There are some good parts of OSI. Too bad the purists didn't design the OSI applications to run on top of the TCP layer. -- Phil Burton -- philip.burton@spacebbs.com - Palo Alto, CA - --- þ CMPQwk #1.4þ UNREGISTERED EVALUATION COPY  -----------[000134][next][prev][last][first]---------------------------------------------------- Date: Thu, 7 Jul 1994 13:12:04 GMT From: vjs@calcite.rhyolite.com (Vernon Schryver) To: comp.protocols.tcp-ip Subject: Re: Max IP packet length and MTU  In article <2vfpuf$q03@cronkite.cisco.com> tli@cisco.com (Tony Li) writes:
>In article <2vfarq$562@hpindda.cup.hp.com> raj@cup.hp.com writes: > > I wonder which is more expensive in the new Cicso routers - receiving > six packets as opposed to one, or receiving one and having to > fragment it into six? (The ATM to Ethernet case) > >Fragmenting. I wasn't able to improve it THAT much. ;-) > >Tony A few years ago Network Systems' FDDI-Cray adapters achieved what at the time was a very impressive TCP/IP/FDDI speed of about 32Mbit/sec by using an IP MTU and TCP MSS much larger than 4352. I think they like something like 32KBytes. As I understand it, the FDDI adapters fragment and reassemble on the fly, so that the host only sees big IP datagrams. Owners of Crays continue to pester my daytime employer, a high performance workstation vendor, about using a giant TCP MSS over FDDI. My point is that although when everything else is equal, IP fragments are considered harmful, sometimes everything else is not equal. What turns out to be equal depends a lot on how you think about things. Vernon Schryver vjs@rhyolite.com  -----------[000135][next][prev][last][first]---------------------------------------------------- Date: 7 Jul 1994 13:21:17 GMT From: cacciam@xsft5.ico.olivetti.com (Marco Caccia) To: comp.protocols.tcp-ip Subject: TCP extension for High Performance  I'm implementing the new tcp options explained in the RFC1323 "TCP Extensions for High Performance". In the RFC is referenced the document: Jacobson V.,"Modified TCP congestion avoidance algorthm", Message to end2end-interest mailing list, April 1990. Does anyone have any information about how to get this document ?  -----------[000136][next][prev][last][first]---------------------------------------------------- Date: 7 Jul 1994 13:39:36 GMT From: cacciam@xsft5.ico.olivetti.com (0000-Admin(0000)) To: comp.protocols.tcp-ip Subject: TCP extension for High Performance  I'm implementing the new tcp options explained in the RFC1323 "TCP Extensions for High Performance". In the RFC is referenced the document: Jacobson V.,"Modified TCP congestion avoidance algorthm", Message to end2end-interest mailing list, April 1990. Does anyone have any information about how to get this document ?  -----------[000137][next][prev][last][first]---------------------------------------------------- Date: 7 Jul 1994 14:11:19 GMT From: mjr@tis.com (Marcus J Ranum) To: comp.protocols.tcp-ip Subject: Re: HELP: How to transfer files via telnet?  >A friend of mine told me he was able to transfer a binary file during >a telnet session (via an Amateur Radio TCP/IP connection to another >Ham TCP/IP station). I do it the stupid way: otter-> script Script started, file is typescript otter-> telnet sol Trying 192.33.112.100 ... Connected to sol.tis.com. Escape character is '^]'. SunOS UNIX (sol) login: mjr Password: Last login: Wed Jul 6 11:16:03 from otter OS/MP 4.1A.3 Export(SOL/root)#0: Wed May 12 14:57:21 1993 sol-> sol-> uuencode .profile .profile begin 600 .profile M(V)A<VEC<PI004=%4CTG+W5S<B]L;V-A;"]B:6XO;&5S<R<*141)5$]2/2<O
K='1E<B(@73L@=&AE;@H)97AE8R O=7-R+V)I;B]8,3$O<W1A<G1X"F9I"B)O end sol-> ^D Connection closed by foreign host. otter-> ^D Script done, file is typescript otter-> vi typescript otter-> uudecode typescript otter-> the 'vi typescript' is where you edit the ^M off the lines. mjr.  -----------[000138][next][prev][last][first]---------------------------------------------------- Date: Thu, 7 Jul 1994 14:17:22 GMT From: tony@mpg.phys.hawaii.edu (Antonio Querubin) To: comp.protocols.tcp-ip Subject: router recommendations?  Need to connect two IP subnets separated by about two miles via either dedicated high-speed modems or a DDS line using DSU/CSUs. The line will probably be upgraded to fiber in about two years. What kind of routing equipment would I need to make the initial connection now and be upgradeable to a fiber connection several years from now? If the routers could handle Banyan Vines packets also that would be a plus. -- Antonio Querubin tony@mpg.phys.hawaii.edu / ah6bw@uhm.ampr.org / querubin@hawaii.bitnet  -----------[000139][next][prev][last][first]---------------------------------------------------- Date: Thu, 7 Jul 1994 14:20:12 GMT From: rstevens@noao.edu (W. Richard Stevens) To: comp.protocols.tcp-ip Subject: Re: TCP extension for High Performance  > I'm implementing the new tcp options explained in the RFC1323 > "TCP Extensions for High Performance". You might want to look at Thomas Skibo's code in the 4.4BSD-Lite release. You can get the source code release on CD-ROM from O'Reilly for$40.  I also see that Bob Braden has made his diffs
for RFC 1323 for SunOS 4.1.x available on ftp.isi.edu in the file
pub/braden/rfc1323.shar.  You might want to go through those diffs.

Also, there was an Internet Draft update to RFC 1323 with a few
clarifications and changes, dated June 21, 1993 by Bob Braden.
Internet Drafts expire 6 months after their release, so this is
now expired, and I don't believe it's been published as an RFC
(yet).  Nevertheless, you should try and track down a copy.

> In the RFC is referenced the document:
>		Jacobson V.,"Modified TCP congestion avoidance algorthm",
>		Message to end2end-interest mailing list, April 1990.
> Does anyone have any information about how to get this document ?

This is Van's description of his fast retransmit, fast recovery
algorithms.  I've attached a copy (seems I repost this every 6
months or so).  You might also want to take a look at my recent
book "TCP/IP Illustrated" (Addison-Wesley, 1994) for some real
examples of these algorithms in action.  The code was implemented
in the BSD Net/1 release in 1989, so it should be in most systems
today.

Rich Stevens

--------------------------------------------------------------------
From van@helios.ee.lbl.gov Mon Apr 30 01:44:05 1990
To: end2end-interest@ISI.EDU
Subject: modified TCP congestion avoidance algorithm
Date: Mon, 30 Apr 90 01:40:59 PDT
From: Van Jacobson <van@helios.ee.lbl.gov>
Status: RO

This is a description of the modified TCP congestion avoidance
algorithm that I promised at the teleconference.

BTW, on re-reading, I noticed there were several errors in
Lixia's note besides the problem I noted at the teleconference.
I don't know whether that's because I mis-communicated the
algorithm at dinner (as I recall, I'd had some wine) or because
she's convinced that TCP is ultimately irrelevant :).  Either
way, you will probably be disappointed if you experiment with
what's in that note.

First, I should point out once again that there are two
completely independent window adjustment algorithms running in
the sender:  Slow-start is run when the pipe is empty (i.e.,
when first starting or re-starting after a timeout).  Its goal
is to get the "ack clock" started so packets will be metered
into the network at a reasonable rate.  The other algorithm,
congestion avoidance, is run any time *but* when (re-)starting
and is responsible for estimating the (dynamically varying)
pipesize.  You will cause yourself, or me, no end of confusion
if you lump these separate algorithms (as Lixia's message did).

The modifications described here are only to the congestion
avoidance algorithm, not to slow-start, and they are intended to
apply to large bandwidth-delay product paths (though they don't
do any harm on other paths).  Remember that with regular TCP (or
with slow-start/c-a TCP), throughput really starts to go to hell
when the probability of packet loss is on the order of the
bandwidth-delay product.  E.g., you might expect a 1% packet
loss rate to translate into a 1% lower throughput but for, say,
a TCP connection with a 100 packet b-d p. (= window), it results
in a 50-75% throughput loss.  To make TCP effective on fat
pipes, it would be nice if throughput degraded only as function
of loss probability rather than as the product of the loss
probabilty and the b-d p.  (Assuming, of course, that we can do
this without sacrificing congestion avoidance.)

These mods do two things: (1) prevent the pipe from going empty
after a loss (if the pipe doesn't go empty, you won't have to
waste round-trip times re-filling it) and (2) correctly account
for the amount of data actually in the pipe (since that's what
congestion avoidance is supposed to be estimating and adapting to).

For (1), remember that we use a packet loss as a signal that the
pipe is overfull (congested) and that packet loss can be
detected one of two different ways:  (a) via a retransmit
timeout or (b) when some small number (3-4) of consecutive
duplicate acks has been received (the "fast retransmit"
algorithm).  In case (a), the pipe is guaranteed to be empty so
we must slow-start.  In case (b), if the duplicate ack
threshhold is small compared to the bandwidth-delay product, we
will detect the loss with the pipe almost full.  I.e., given a
threshhold of 3 packets and an LBL-MIT bandwidth-delay of around
24KB or 16 packets (assuming 1500 byte MTUs), the pipe is 75%
full when fast-retransmit detects a loss (actually, until
gateways start doing some sort of congestion control, the pipe
is overfull when the loss is detected so *at least* 75% of the
packets needed for ack clocking are in transit when
fast-retransmit happens).  Since the pipe is full, there's no
need to slow-start after a fast-retransmit.

For (2), consider what a duplicate ack means:  either the
network duplicated a packet (i.e., the NSFNet braindead IBM
The usual cause of out-of-order packets at the receiver is a
missing packet.  I.e., if there are W packets in transit and one
is dropped, the receiver will get W-1 out-of-order and
(4.3-tahoe TCP will) generate W-1 duplicate acks.  If the
consecutive duplicates' threshhold is set high enough, we can
reasonably assume that duplicate acks mean dropped packets.

generate one in response to a packet arrival.  I.e., a duplicate
ack means that a packet has left the network (it is now cached
at the receiver).  If the sender is limitted by the congestion
window, a packet can now be sent.  (The congestion window is a
count of how many packets will fit in the pipe.  The ack says a
packet has left the pipe so a new one can be added to take its
place.)  To put this another way, say the current congestion
window is C (i.e, C packets will fit in the pipe) and D
duplicate acks have been received.  Then only C-D packets are
actually in the pipe and the sender wants to use a window of C+D
packets to fill the pipe to its estimated capacity (C+D sent -
D received = C in pipe).

So, conceptually, the slow-start/cong.avoid/fast-rexmit changes
are:

- The sender's input routine is changed to set cwnd' to ssthresh'
when the dup ack threshhold is reached.  [It used to set cwnd to
mss to force a slow-start.]  Everything else stays the same.

- The sender's output routine is changed to use an effective window
of min(snd_wnd, cwnd + dupacks*mss)  [the change is the addition
of the dupacks*mss' term.]  Dupacks' is zero until the rexmit
threshhold is reached and zero except when receiving a sequence
of duplicate acks.

The actual implementation is slightly different than the above
because I wanted to avoid the multiply in the output routine
(multiplies are expensive on some risc machines).  A diff of the
old and new fastrexmit code is attached (your line numbers will
vary).

Note that we still do congestion avoidance (i.e., the window is
reduced by 50% when we detect the packet loss).  But, as long as
the receiver's offered window is large enough (it needs to be at
most twice the bandwidth-delay product), we continue sending
packets (at exactly half the rate we were sending before the
loss) even after the loss is detected so the pipe stays full at
exactly the level we want and a slow-start isn't necessary.

Some algebra might make this last clear:  Say U is the sequence
number of the first un-acked packet and we are using a window
size of W when packet U is dropped.  Packets [U..U+W) are in
transit.  When the loss is detected, we send packet U and pull
the window back to W/2.  But in the round-trip time it takes
the U retransmit to fill the receiver's hole and an ack to get
back, W-1 dup acks will arrive (one for each packet in transit).
The window is effectively inflated by one packet for each of
these acks so packets [U..U+W/2+W-1) are sent.  But we don't
re-send packets unless we know they've been lost so the amount
actually sent between the loss detection and the recovery ack is
U+W/2+W-1 - U+W = W/2-1 which is exactly the amount congestion
avoidance allows us to send (if we add in the rexmit of U).  The
recovery ack is for packet U+W so when the effective window is
pulled back from W/2+W-1 to W/2 (which happens because the
recovery ack is new' and sets dupack to zero), we are allowed
to send up to packet U+W+W/2 which is exactly the first packet
we haven't yet sent.  (I.e., there is no sudden burst of packets
as the hole' is filled.)  Also, when sending packets between
the loss detection and the recovery ack, we do nothing for the
first W/2 dup acks (because they only allow us to send packets
we've already sent) and the bottleneck gateway is given W/2
packet times to clean out its backlog.  Thus when we start
sending our W/2-1 new packets, the bottleneck queue is as empty
as it can be.

[I don't know if you can get the flavor of what happens from
this description -- it's hard to see without a picture.  But I
was delighted by how beautifully it worked -- it was like
watching the innards of an engine when all the separate motions
of crank, pistons and valves suddenly fit together and
everything appears in exactly the right place at just the right
time.]

Also note that this algorithm interoperates with old tcp's:  Most
pre-tahoe tcp's don't generate the dup acks on out-of-order packets.
If we don't get the dup acks, fast retransmit never fires and the
window is never inflated so everything happens in the old way (via
timeouts).  Everything works just as it did without the new algorithm
(and just as slow).

If you want to simulate this, the intended environment is:

- large bandwidth-delay product (say 20 or more packets)

connections simultaneously sharing the path).

- average loss rate (from congestion or other source) less than
one lost packet per round-trip-time per active connection.
(The algorithm works at higher loss rate but the TCP selective
ack option has to be implemented otherwise the pipe will go empty
waiting to fill the second hole and throughput will once again
degrade at the product of the loss rate and b-d p.  With selective
ack, throughput is insensitive to b-d p at any loss rate.)

And, of course, we should always remember that good engineering
practise suggests a b-d p worth of buffer at each bottleneck --
less buffer and your simulation will exhibit the interesting
pathologies of a poorly engineered network but will probably
tell you little about the workings of the algorithm (unless the
algorithm misbehaves badly under these conditions but my
simulations and measurements say that it doesn't).  In these
days of $100/megabyte memory, I dearly hope that this particular example of bad engineering is of historical interest only. - Van ----------------- *** /tmp/,RCSt1a26717 Mon Apr 30 01:35:17 1990 --- tcp_input.c Mon Apr 30 01:33:30 1990 *************** *** 834,850 **** * Kludge snd_nxt & the congestion * window so we send only this one ! * packet. If this packet fills the ! * only hole in the receiver's seq. ! * space, the next real ack will fully ! * open our window. This means we ! * have to do the usual slow-start to ! * not overwhelm an intermediate gateway ! * with a burst of packets. Leave ! * here with the congestion window set ! * to allow 2 packets on the next real ! * ack and the exp-to-linear thresh ! * set for half the current window ! * size (since we know we're losing at ! * the current window size). */ if (tp->t_timer[TCPT_REXMT] == 0 || --- 834,850 ---- * Kludge snd_nxt & the congestion * window so we send only this one ! * packet. ! * ! * We know we're losing at the current ! * window size so do congestion avoidance ! * (set ssthresh to half the current window ! * and pull our congestion window back to ! * the new ssthresh). ! * ! * Dup acks mean that packets have left the ! * network (they're now cached at the receiver) ! * so bump cwnd by the amount in the receiver ! * to keep a constant cwnd packets in the ! * network. */ if (tp->t_timer[TCPT_REXMT] == 0 || *************** *** 853,864 **** else if (++tp->t_dupacks == tcprexmtthresh) { tcp_seq onxt = tp->snd_nxt; ! u_int win = ! MIN(tp->snd_wnd, tp->snd_cwnd) / 2 / ! tp->t_maxseg; if (win < 2) win = 2; tp->snd_ssthresh = win * tp->t_maxseg; - tp->t_timer[TCPT_REXMT] = 0; tp->t_rtt = 0; --- 853,864 ---- else if (++tp->t_dupacks == tcprexmtthresh) { tcp_seq onxt = tp->snd_nxt; ! u_int win = MIN(tp->snd_wnd, ! tp->snd_cwnd); + win /= tp->t_maxseg; + win >>= 1; if (win < 2) win = 2; tp->snd_ssthresh = win * tp->t_maxseg; tp->t_timer[TCPT_REXMT] = 0; tp->t_rtt = 0; *************** *** 866,873 **** tp->snd_cwnd = tp->t_maxseg; (void) tcp_output(tp); ! if (SEQ_GT(onxt, tp->snd_nxt)) tp->snd_nxt = onxt; goto drop; } } else --- 866,879 ---- tp->snd_cwnd = tp->t_maxseg; (void) tcp_output(tp); ! tp->snd_cwnd = tp->snd_ssthresh + ! tp->t_maxseg * ! tp->t_dupacks; if (SEQ_GT(onxt, tp->snd_nxt)) tp->snd_nxt = onxt; goto drop; + } else if (tp->t_dupacks > tcprexmtthresh) { + tp->snd_cwnd += tp->t_maxseg; + (void) tcp_output(tp); + goto drop; } } else *************** *** 874,877 **** --- 880,890 ---- tp->t_dupacks = 0; break; + } + if (tp->t_dupacks) { + /* + * the congestion window was inflated to account for + * the other side's cached packets - retract it. + */ + tp->snd_cwnd = tp->snd_ssthresh; } tp->t_dupacks = 0; *** /tmp/,RCSt1a26725 Mon Apr 30 01:35:23 1990 --- tcp_timer.c Mon Apr 30 00:36:29 1990 *************** *** 223,226 **** --- 223,227 ---- tp->snd_cwnd = tp->t_maxseg; tp->snd_ssthresh = win * tp->t_maxseg; + tp->t_dupacks = 0; } (void) tcp_output(tp); From van@helios.ee.lbl.gov Mon Apr 30 10:37:36 1990 To: end2end-interest@ISI.EDU Subject: modified TCP congestion avoidance algorithm (correction) Date: Mon, 30 Apr 90 10:36:12 PDT From: Van Jacobson <van@helios.ee.lbl.gov> Status: RO I shouldn't make last minute 'fixes'. The code I sent out last night had a small error: *** t.c Mon Apr 30 10:28:52 1990 --- tcp_input.c Mon Apr 30 10:30:41 1990 *************** *** 885,893 **** * the congestion window was inflated to account for * the other side's cached packets - retract it. */ ! tp->snd_cwnd = tp->snd_ssthresh; } - tp->t_dupacks = 0; if (SEQ_GT(ti->ti_ack, tp->snd_max)) { tcpstat.tcps_rcvacktoomuch++; goto dropafterack; --- 885,894 ---- * the congestion window was inflated to account for * the other side's cached packets - retract it. */ ! if (tp->snd_cwnd > tp->snd_ssthresh) ! tp->snd_cwnd = tp->snd_ssthresh; ! tp->t_dupacks = 0; } if (SEQ_GT(ti->ti_ack, tp->snd_max)) { tcpstat.tcps_rcvacktoomuch++; goto dropafterack;  -----------[000140][next][prev][last][first]---------------------------------------------------- Date: 7 Jul 1994 14:47:45 GMT From: grpjl@iastate.edu (Paul J Lustgraaf) To: comp.protocols.tcp-ip Subject: Re: Max IP packet length and MTU  In article <2vfarq$562@hpindda.cup.hp.com>, Rick Jones <raj@cup.hp.com> wrote:
...lots deleted...
>
>When you say that a router's load is more nearly proportional to
>packets/second than bits/second, doesn't that imply that it would be
>less "loadful" on the router to send it two larger fragments on the
>FDDI ring rather than six smaller fragments? The first case would seem
>to place 1/3 the load on the router.
>

Except for the fact that some routers do fragmentation with the main CPU
and forwarding with auxiliary processors.  Cisco, for example, does this.

...lots deleted...
>
>But it was just said that the load on a router is proportional to the
>number of packets, and PathMTU has already been shown to *increase*
>the number of packets (in one very common case anyhow) that a (first
>hop) router will be sent when the packet has to be fragmented in the
>first place.
>
>It would definitely increase the number of packets when that router is
>routing NFS V2 from ATM to Ethernet or FDDI because the datagram can
>arrive unfragmented, in *one* packet on the ATM interface as opposed
>to six.
>
>I wonder which is more expensive in the new Cicso routers - receiving
>six packets as opposed to one, or receiving one and having to
>fragment it into six? (The ATM to Ethernet case)
>
>Running NFS over TCP would have the same effect then of increasing the
>load on the router because it increases the number of packets it
>processes (both pseudo fragmentation *and* ACK's I'd imagine ;-)
>However, I can agree on advantages in running NFS over TCP in a WAN
>case that would outweigh that.
>
>Lest anyone think that I am trying to ferment revolution and start
>flooding the Internet with IP fragments, as much as what I've been
>saying has been to challenge assumptions to ascertain their validity.
>Particularly the one that says that IP Fragmentation is "expensive"
>(an unfortunately vague term) I know that I've learned some things
>from it (such as the now improved IP fragmenting ability of new Cisco
>routers), and I hope that others have too.

To illustrate the problem:
NFS throughput from an Alpha 3000/600 to an Alpha 3000/300:

On same ethernet:                                        1,032 KBps
From ethernet through 2 routers across
an FDDI ring and to another ethernet:                      661

FDDI through Cisco 7000 to ethernet:                       501

FDDI through Cisco AGS+ to ethernet:                       361

FDDI through Cisco 7000 to ethernet w/1024 byte mount:     305

FDDI through Cisco 7000 to ethernet w/1500 byte mount:     187

FDDI through Cisco Catalyst switch to ethernet:          1,004

Conclusions:

1. Cisco routers don't fragment very fast.

2. Hosts have no problem fragmenting fast.

3. NFS mounts smaller than 8K cost more than fragmentation.

4. Other devices CAN fragment fast.

Recommendations:

>
>rick jones
>speaking only as rick jones...
>
>I've always liked the phrase "Don't raise the bridge, lower the
>river!"
>
After last summers flooding, most Iowans would agree with you!

--
Paul Lustgraaf             "It's easier to apologize than to get permission."
Network Specialist                                      Grace Hopper
Iowa State University Computation Center                    grpjl@iastate.edu
Ames, IA  50011                                                  515-294-0324


-----------[000141][next][prev][last][first]----------------------------------------------------
Date:      7 Jul 1994 15:02:50 GMT
From:      carlson@Xylogics.COM (James Carlson)
To:        comp.protocols.tcp-ip
Subject:   Re: slip--must be 2 nets

In article <2vh2oe$gr1@kryten.atinc.com>, jmb@kryten.atinc.com (Jonathan M. Bresler x346) writes: |> i have just installed a terminal server with slip capabilities. |> the vendor chase iolan informs me that the two endpoints of the slip |> connection must be either on different networks or on different subnets |> of a single network. |> |> i checked the rfc1055 and did not find this addressed. |> |> or is the limitation of different nets/subnets, a routing limitation? Sort of. This is an IP routing limitation -- you can't have discontiguous subnets. Most terminal servers can also hack around this problem if the other end is a single node. The server can do a proxy-ARP for the remote end- point's address if it's on the same subnet as the server. But, if you have more than one node at the remote end, you'll be forced to use separate nets (or at least a separate unrouted network) for them. -- James Carlson <carlson@xylogics.com> Tel: +1 617 272 8140 Annex Software Support / Xylogics, Inc. +1 800 225 3317 53 Third Avenue / Burlington MA 01803-4491 Fax: +1 617 272 2618  -----------[000142][next][prev][last][first]---------------------------------------------------- Date: Thu, 7 Jul 1994 15:04:23 GMT From: scollins@da_vinci.mtt.it.uswc.uswest.com (Steven Collins) To: comp.object,comp.protocols.tcp-ip,comp.lang.c++ Subject: Wanted: Object Oriented distributed communication toolkit  Looking for an Object Oriented distributed communication toolkit with a C++ interface. CORBA implementations are too heavyweight. I'm interested in something that is much much easier to use than BSD sockets and XDR. Would "like" the product to run on different UNIX flavors plus MAC/PC. I will post a follow-up article detailing replies. Thanks, Steve --  -----------[000143][next][prev][last][first]---------------------------------------------------- Date: 7 Jul 1994 15:16:57 GMT From: crohrer@advtech.uswest.com (Chris Rohrer) To: comp.protocols.tcp-ip Subject: Fake network addresses  Hi all, I was of the understanding that there is a Class A or maybe a Class B address that is reserved and not allocated to anyone on the Internet, The purpose is to alllow private networks that do not/can not/will not connect directly to the Internet the opportunity to have an address space that will not conflict with or confuse anyone's routing tables. Anyone know any more about this and, like, what the number(s) might be? Thanks Chris Rohrer  -----------[000144][next][prev][last][first]---------------------------------------------------- Date: 7 Jul 1994 15:24:07 GMT From: dstoun@garnet.acns.fsu.edu (Douglas Stoun) To: comp.protocols.tcp-ip Subject: Different speeds using WFTPD!!!???  We are testing the shareware version of WFTPD as an ftp server (since WinQvt is so unstable) and for the most part we are pleased with the results and plan on registering. However, we are having inconsistencies in speed between the computers. We have 10 Gateways (9 486DX/33 and 1 486DX2/66V). We also have 3 Dells (486DX/33). All 13 computers have 8 megs of RAM and are connected using winsock, 8003pkdr, and winpkt. The problem is that MOST of the computers will have a transfer rate of 60-100 Kbytes/second while some of them transfer at only 2-3 Kbytes/second !!!!! There is no difference between setups (from what we can see), in fact, all of the network information was put on the computers by way of tape backup! Another interesting aspect is that it only effects 'get'. 'put' seems to work at the fast rate no matter which computer is putting to which. Also, when using ws_ftp, the 'get' from a computer whose rate is slow, does not bring up the progress bar that moves to the right during most transfers. But the 'get' from machines with fast transfer rates, does!? Well, any help would be appreciated..send email to the address below. Doug Stoun stoun_d@cmr.fsu.edu Center for Music Research Florida State University  -----------[000145][next][prev][last][first]---------------------------------------------------- Date: 7 Jul 1994 17:24:59 GMT From: wali@gate.net (Tom Techoueyres) To: comp.protocols.tcp-ip Subject: IP address selection  Hi, My company is getting a 56K dedicated connection to Internet, I got already the IP address that my service provider gave me. It is a class C. this means that the last octet of the IP address is for our company, which gives us 254 addresses. the primary server is a MicroVax running VMS, is there a logical way to assign an address to the primary server? The first three octet are control by the service provider, the last octet by the company, but should it be 1, 37 or 250? I don't know what value I should assign to the primary server? I would appreciate any help, thank you! tom wali@gate.net  -----------[000146][next][prev][last][first]---------------------------------------------------- Date: Thu, 7 Jul 1994 18:36:45 GMT From: morley@suncad.camosun.bc.ca (Mark Morley) To: comp.protocols.tcp-ip Subject: Help on subnetting a class 'C'  Actually, our "class C" is a subnet of a class B network. What I want to do is divide our range of addresses across two physical locations with a SLIP or PPP connection between them. On the one site we'll have only a handful of machines. At the other a lab of 15-20 PC's. The thing I'm not familiar with is how to divide our address range into 2 subnets. Can anyone offer some advice on this? Is it as easy as simply changing the netmask? I doubt it... Mark  -----------[000147][next][prev][last][first]---------------------------------------------------- Date: Thu, 7 Jul 1994 20:13:41 GMT From: donp@novell.com (don provan) To: comp.protocols.tcp-ip Subject: Re: TCP Keep Alives  In article <773409903snz@paxdata.demon.co.uk> Giles@paxdata.demon.co.uk writes: >I am trying to work out how to handle TCP Keep Alives in my company's ISDN >bridging products. RFC1122 states that Keep Alives MUST be defaulted to >off, be sent at configurable intervals and default to no less than every >two hours. RFC-1122 deals with the communications layers. Its recommendations for defaults therefore apply only to the TCP implementation. Not that that matters much, since many, many TCP implementations have much shorter defaults than those suggested by RFC-1122. >Imagine my surprise when I found that NCSA Telnet's FTP client sends what >appears to be a Keep Alive at three minute intervals! Although one cannot say with this information what is really going on, it is possible that the FTP client implementation has overridden TCP's default values to get a shorter keep-alive. I have no idea why anyone would want an FTP *client* to use a short keep-alive -- or any keep-alive at all for that matter -- but since RFC-1122 doesn't apply and RFC-1123 (which involves the application layers) doesn't discuss keep-alives, this behavior is within specs. >Does this mean that I need to "spoof" the Keep Alive (just like an >IPX/NCP Keep Alive) so as to keep ISDN bills manageable? Either that or you assume that a TCP connection that's actively sending keep-alives is likely to come into use at any time so it's worth keeping the connection up. This isn't entirely unreasonable since TCP connections are a little different than NCP connections. A TCP connection is an actual invocation of a specific service, while a NCP connection is just authentication conduit not necessarily reflecting an actual desire for any particular service at any given time. Unfortunately, specific cases will likely make this general observation moot. A statistical argument will not help you molify the customer that left an FTP connection open for two weeks while he was on vacation. Or you could say that anyone using an application that sends this many keep-alives deserves what he gets... I find it somewhat amusing that by spoofing TCP keep-alives, you're making them useless. I hope people that put so much faith in keep-alives and consider them so important will take heed of your actions. don provan donp@novell.com  -----------[000148][next][prev][last][first]---------------------------------------------------- Date: Thu, 7 Jul 1994 20:32:44 GMT From: Debby Koren <deb@radmail.rad.co.il> To: comp.protocols.tcp-ip Subject: addresses on SLIP or PPP links  I'm trying to gather information on the ways that access servers or access routers (like Netblazer and Nethopper, for example) assign IP addresses to the SLIP or PPP interfaces. Suppose such a device has several SLIP or PPP interfaces and a host connected (possibly through dial-up or temporary connection) to each one. Is each link considered a separate subnet? Which products don't require addresses on the link? How do they do this? Which products support DHCP?  -----------[000149][next][prev][last][first]---------------------------------------------------- Date: Thu, 7 Jul 1994 20:42:26 GMT From: li@virtual12.harvard.edu (W. David Li) To: comp.os.ms-windows.networking.tcp-ip,comp.os.ms-windows.programmer.networks,comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc Subject: INFOR NEEDED: NOS PROGRAMMING  Hi, I am doing some networking programming(TCP/IP) using NOS -- Network Operating System by Phil Karn. The trouble is that I could not find any programming guide or manual to help me through this. Do I really have to go through all those source code? Can anyone tell me a bit on where to find the information? I am familiar with the Unix networking programming but not sure how large the difference is between NOS and UNIX. Please reply to my account. Thanks David  -----------[000150][next][prev][last][first]---------------------------------------------------- Date: 7 Jul 1994 21:12:33 GMT From: zhou@isis.epm.ornl.gov To: comp.protocols.tcp-ip,comp.client-server,comp.unix.internals Subject: Data formats needed for non-XDR conversion  I would like to know if you could give me some pointers on where can I find all (or some of) the data formats for all machine types. Instead of using XDR converting routines to convert the data formats used by different processors, I am trying to code my own routines to do such conversions due to performance reasons. I heard that OSF' DCE doesn't use XDR routines too. Any comments on this? Thanks a lot in advance. Honbo Honbo Zhou (Ph. D.), (615) 481-8354 (H), 576-6129 (O) Engineerin, Physics, and Mathematics Division ---- PVM Oak Ridge National Laboratory, Oak Ridge, TN 37831-6367 http://www.epm.ornl.gov/~zhou  -----------[000151][next][prev][last][first]---------------------------------------------------- Date: Thu, 7 Jul 1994 21:14:51 GMT From: mike_gore@ccm.hf.intel.com To: misc.jobs.offered,comp.protocols.tcp-ip,comp.dcom.lans Subject: SR NETWORK INFASTRUCTURE ENGINEER @ INTEL IN OREGON  Intels Information Technology Group in Oregon is looking for an individual to implement and support new networking technology for HW/SW Engineering, Manufacturing, Administration and Product Research. You initial focus will be support of site domain name system (DNS) servers and conversion of hosts to the different sites in oregon domain.. Will maintain Perl scripts to automate the generation of DNS records and correlation of other network databases. Qualified candidates will posses experience in Unix systems administration with a focus on networking. Sun OS & ATT SYSV.4 needed along with PERL. In addition you should have experience in support of PC DOS/Windows TCP/IP. This position is located outside of Portland Oregon and offers an excellent salary, bonus, stock options and relocation package. If you are interested EMAIL an ASCII resume OR Call Mike @ 602-554-4485  -----------[000152][next][prev][last][first]---------------------------------------------------- Date: 8 Jul 1994 13:05:21 -0700 From: nsi@teleport.com (Northwest Software) To: comp.protocols.tcp-ip Subject: Help, we need a TCP/IP SWQA Contractor  We're looking for a TCP/IP SWQA Contractor for a Client Project in Portland, OR. Job desc. contact info below. Thanks ********************************************************************** Mike Nelson Consulting and Recruiting Sales Engineer Software & Hardware Engineers Northwest Software, Inc. Technical Writers P.O. Box 91396 Portland, Oregon & other locations Portland, OR 97291-0396 nsi@teleport.com My favorite quote from a job seeker: FAX: (503) 645-5892 "I'm still looking for a job that pays me to drink beer and chase women." ********************************************************************** *********************************** * SWQA Engineer, TCP/IP * *********************************** DESCRIPTION: 5-7 months, Portland, Oregon (on-site); Develop SW tests for network software used to interface PC/MAC perhipheral equipment. SW Technicians will assist conducting the tests. Further project details will be disclosed to qualified applicants. REQUIRED: Min 5 years industry experience, 1 year of formal SWQA experience, 2 years with TCP/IP network protocols, BSCS or equivalent. DESIRED: DOS, MSW, Macintosh, other LAN/WAN protocols, "sniffer" debug tool INTERESTED ? RESPOND IN STRICT CONFIDENCE TO: Northwest Software, Inc. P.O. Box 91396 Portland, OR 97291-0396 FAX: 503-645-5892 Email: nsi@teleport.com BELOW YOU WILL FIND: A. General Notes about NSI's openings B. A message for recent college grads C. Information about NSI D. Information about the Pacific Northwest GENERAL NOTES ABOUT OUR OPENINGS: 1. If convenient, NSI prefers emailed resumes -ASCII only. Your resume will be added to our on-line resumes, which gives you greater exposure within NSI. It is desirable to follow up with a postal mailed d resume so we have a "pretty" copy on file. 2. We will not forward your resume to any Client without your specific permission. After we review your resume we will call or send email back disclosing who our Client is and asking your specific permission to represent you. 3. Double representation is a situation we avoid. Once you have given NSI permission to represent you with a specific Client DO NOT have other Companies represent you to this same Client without first obtaining permission from NSI. In general representation expires after about 3 months, you do not need NSI's permission to be represented by someone else if it has been > 3 months. 4. Some of our Clients can be slow giving us feedback. Once you have given NSI permission to represent you **feel free** to check back with us in 2 weeks if you haven't heard anything. 5. Unless otherwise stated in the posting, ALL JOBS must be done at our Client site. 6. Openings for "regular" employment with our Clients require that you are a USA Citizen or Permanant Resident. 7. For temporary positions NSI will sponsor visas if necessary. 8. If you are not a good match for the position you have applied for we will keep your resume on file to consider for future openings. However, feel free to apply again as you see new jobs posted. MESSAGE TO NEW COLLEGE GRADUATES: If you are a new college graduate, you should be aware that our clients pay our fees and usually expect us to recruit experienced professionals and/or consultants. Therefore, we'd like to suggest that you either contact your college placement center, or college recruiters at the employers' directly. Most large companies have a program to recruit new college graduates like yourself. ABOUT NORTHWEST SOFTWARE, INC.: Northwest Software, Inc. (NSI) provides Consulting Services to top-rated high technology companies across the United States. NSI has offices in Portland Oregon and India. NSI's services include temporary positions and regular employment. We fill jobs for Software Engineers, Hardware Engineers, Technical Writers, Programmer/Analysts, Management, and Marketing positions. Most of our temporary positions pay by the hour. Occasionally NSI bids on fixed price projects. ABOUT THE PACIFIC NORTHWEST: The majority of our openings are in the Portland/Vancouver area. The Oregon Coast and mountain Skiiing areas are about 60 miles away. Many outdoor people take advantage of the convenient camping, hunting, and fishing spots. The Portland area has a population of about 1,000,000 and includes a variety of suburbs with a high quality of living. The cost of living is about 20% less than California. Oregon does not have a sales tax, but does have a 9% State income tax. Washington has a sales tax, but no State income tax. -- nsi@teleport.COM Public Access User --- Not affiliated with TECHbooks Public Access UNIX and Internet at (503) 220-1016 (2400-14400, N81)  -----------[000153][next][prev][last][first]---------------------------------------------------- Date: 8 Jul 1994 09:46:16 -0400 From: jmb@kryten.atinc.com (Jonathan M. Bresler x346) To: comp.protocols.tcp-ip Subject: subnetting  having just read rfc950 again, i understand the following to apply to subnetting. 1. the "all subnet bits 0" subnet should not be used as a physical network. 2. the "all subnet bits 1" subnet should not be used as a physical network. 3. no host should be "all host bits 0" 4. and no host at "all host bits 1" so.... #subnet bits #of subnets #of hosts #lost addresses due to subnetting 1 0 0 * 126 all = 254 2 2 2 * 62 2 * 62 + 2 * 2 = 128 3 6 6 * 30 2 * 30 + 6 * 2 = 72 4 14 14 * 14 2 * 14 + 14 * 2 = 56 etc is this correct? jmb -- Jonathan M. Bresler jmb@kryten.atinc.com | Analysis & Technology, Inc. | 2341 Jeff Davis Hwy play go. | Arlington, VA 22202 ride bike. hack FreeBSD.--ah the good life | 703-418-2800 x346  -----------[000154][next][prev][last][first]---------------------------------------------------- Date: Fri, 8 Jul 1994 09:15:21 From: karl@cavebear.com (Karl Auerbach) To: comp.protocols.tcp-ip Subject: Re: Small and Compact TCP/IP/PPP  In article <48575@mindlink.bc.ca> Robert_Bradford@mindlink.bc.ca (Robert Bradford) writes: >From: Robert_Bradford@mindlink.bc.ca (Robert Bradford) >How small and compact, in terms of memory requirements, can you >make a TCP/IP and PPP implementation? Geoff Cooper wrote a TinyTCP package to bootload the Imagen laser printers. And it was pretty small. There's a lot you can do to shrink the code to tiny proportions if you start removing the generalizations. For example, I just came across a TCP/IP implementation that knew nothing about being an arp client, subnet masks or routes, it simply sent everything to the ethernet address of a device which it had been configured to use as a "router". The original PC/IP code ignorred offered windows on the basis that it was carrying telnet traffic, and no human could type fast enough to fill a window. Of course, such a diminished piece of code should be used only in constrained circumstances. Any attempt to use it in general practice is pretty much doomed. I've lost track of both Geoff and the software. --karl--  -----------[000155][next][prev][last][first]---------------------------------------------------- Date: 8 Jul 1994 11:29:04 -0400 From: mossburg@aol.com (MOSSBURG) To: comp.protocols.tcp-ip Subject: Re: Connecting to Internet  In article <9407062222.AA27444@futon.sfsu.edu>, sulistio@futon.sfsu.edu (Sulistio Muljadi) writes: >I am trying to set up Internet conection (full IP) for my company. >It will be on 56kbps leased line. I am trying to figure out what kind >of hardware needed to set the connection. I would like the same info but for novell 3.12 server. Matthew Mossburg mossburg@aol.com  -----------[000156][next][prev][last][first]---------------------------------------------------- Date: 8 Jul 1994 15:00:55 -0600 From: wllarso@sandia.gov (William L. Larson) To: comp.protocols.tcp-ip,comp.sys.sun.admin Subject: Obtaining Ethernet/MAC Network Addresses From Sun System  I am interested in identifying the Ethernet/MAC address for the network interfaces on a Sun computer running 4.1.3. My situation is that I have three Ethernet interfaces plus one FDDI interface, but Sun only reports a single MAC address for the system which is for the first Ethernet interface. All other network interfaces report the same MAC address. Is anyone aware of any mechanism for obtaining the Ethernet addresses for the second and third Ethernet interfaces along with the MAC address for the FDDI interface? Responses via Email are most appreciated. Thanks Bill Larson (wllarso@sandia.gov) Phone: (505)844-2103 Sandia National Laboratories FAX: (505)844-2067 Org. 13918 M/S 0806 PO Box 5800 Albuquerque NM 87185  -----------[000157][next][prev][last][first]---------------------------------------------------- Date: Fri, 8 Jul 1994 05:04:52 GMT From: jamesd@netcom.com (James A. Donald) To: comp.protocols.tcp-ip,alt.winsock Subject: Windows screws up as server?  I have heard that windows does not work well as an internet server, and in consequence you are likely to lose mail. Allegedly if another computer contacts your computer to deliver mail while your computer is busy, your computer will screw up and and may lose the mail. Is this a problem, is it only a problem with particular implementations, or is it an inherent problem because windows is non pre-emptive? -- --------------------------------------------------------------------- We have the right to defend ourselves and our property, because of the kind of animals that we James A. Donald are. True law derives from this right, not from the arbitrary power of the omnipotent state. jamesd@netcom.com  -----------[000158][next][prev][last][first]---------------------------------------------------- Date: Fri, 8 Jul 1994 05:26:41 GMT From: micky@ejv.com (Micky Liu) To: comp.protocols.tcp-ip Subject: ttcp_fwd-like program available?  For those of you who don't know ttcp_fwd is a general purpose program for reading in data over one port and forwarding it to another port. Both tcp and udp are supported and connections are duplex. Anyway, enough of an advertisement for ttcp_fwd... I am looking for a program that can take a socket connection as input and fan it out to several other ports. Does such an animal exist yet? If you know of any, I would appreciate any pointers that you may be able to provide. I know that this sounds like multicast and I have been looking into using the MBONE software to achieve the same results, but I am worrysome about having to make system level changes as well as having to create special MBONE routers to go across LANs. Basically, I would be really happy with a 'user-level' multicast ability... In any case, any guidance would be greatly appreciated. Please try to reply by email as I have a difficult time keeping up with netnews ;-) Micky Liu micky@ejv.com  -----------[000159][next][prev][last][first]---------------------------------------------------- Date: Fri, 8 Jul 1994 05:29:51 GMT From: micky@ejv.com (Micky Liu) To: comp.protocols.tcp-ip Subject: Current Status of CMP and TMux?  I've just retrieved the minutes for the last IETF BOF meeting on tcp connection multiplexing and it is from last year (early 1993). I am wondering if there was any further work done on either the CMP (Connection Multiplexing Protocol) or on TMux. Any pointers would be greatly appreciated. Micky Liu micky@ejv.com  -----------[000160][next][prev][last][first]---------------------------------------------------- Date: 8 Jul 1994 12:45:56 -0400 From: jonbeal@saturn.caps.maine.edu (Jon Beal) To: comp.protocols.tcp-ip,comp.unix.aix Subject: Does a DHCP daemon exist?  I am looking for a daemon for the Dynamic Host Configuration Protocol, as detailed in RFC1541. Does anyone know if a Unix implementation exists yet? (If so, where can I find it?) Thanks in advance, Jon Beal  -----------[000161][next][prev][last][first]---------------------------------------------------- Date: Fri, 8 Jul 1994 14:43:23 -0500 From: amanda@intercon.com (Amanda Walker) To: comp.protocols.ppp,comp.protocols.tcp-ip,comp.sys.mac.comm Subject: Re: where can I get the interSLIP for MAC?  messina@mcs.com (David Messina) writes: > It's free, and available on many archives (info-mac, e.g.) The canonical source is ftp.intercon.com, in the directory /InterCon/sales. It's also available on ftp.tidbits.com, but it's *not* generally available on random archive sites. If it's on info-mac, it should be taken off of it. Putting InterSLIP up for FTP on any server requires explicit permission of InterCon Systems Corporation. InterSLIP may be free of charge, but it still copyrighted commercial software. Amanda Walker InterCon Systems Corporation  -----------[000162][next][prev][last][first]---------------------------------------------------- Date: Fri, 8 Jul 1994 06:23:32 GMT From: boyd@ssmd.mrl.dsto.gov.au (Steve Boyd) To: comp.sys.mac.comm,comp.sys.mac.misc,comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc,comp.protocols.ppp Subject: Re: where can I get the interSLIP for MAC?  In article <ZHAO.94Jul6121917@crl.crl.nmsu.edu> zhao@crl.nmsu.edu (Z. Zhao) writes: >From: zhao@crl.nmsu.edu (Z. Zhao) >Subject: where can I get the interSLIP for MAC? >Date: 6 Jul 94 12:19:17 >Can anybody here tell me where the interSLIP for MAC is hidden ? >Is it a freeware or shareware or commercial package? It's freeware. You can download it from InterConn Systems at ftp.intercon.com. Sorry but I don't know the directory(s). ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Steve Boyd email:boyd@ssmd.mrl.dsto.gov.au voice: +61 3 626 8305 Fax: +61 3 626 8999 __ |\ / |_| \ D E P A R T M E N T O F D E F E N C E .' \ --------------------*-------------------- / \ DEFENCE SCIENCE & TECHNOLOGY ORGANISATION \ __ / Aeronautical & Maritime Research Laboratory \_.-' \_*/ Ship Structures & Materials Division v ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ All opinions expressed here are mine.  -----------[000163][next][prev][last][first]---------------------------------------------------- Date: Fri, 8 Jul 94 06:24:56 GMT From: jonesjg@dg-rtp.dg.com (Greg Jones) To: comp.protocols.tcp-ip Cc: bji+@cs.cmu.edu Subject: Re: Getting Remote Host Address Before Accept()  In article <773532931.5620.0@unix9.andrew.cmu.edu> "Bryan J. Ischo" <bi04+@andrew.cmu.edu> writes: > > This is more of a UNIX question than tcp-ip, but ... does anyone know how to > get the address of the next remote host on the listener queue BEFORE calling > accept()? Basically, I want to know who is trying to connect so I know > whether or not to accept the connection. I could accept the connection, > the check the remote address in the struct sockaddr filled in by accept(), > then disconnect the remote host is not on my access list ... but as far as I > know, the connect() call on the other end would succeed, and I don't want that. > Actually the client connect will complete reguardless of when you accept the connection. Since the server is listening on the socket the connection request is queued on the servers socket. The accept creates a new socket for connection, but the TCP handshake has already completed, before the server calls accept(). Common practice is as you suggest - accept(), getpeername(), and disconnect if you so desire. > Bryan > bji+@cs.cmu.edu (preferred), bi04+@andrew.cmu.edu -- Greg Jones  -----------[000164][next][prev][last][first]---------------------------------------------------- Date: 8 Jul 1994 09:08:07 GMT From: antonis@intranet.gr (Antonis Kyriazis) To: comp.protocols.tcp-ip Subject: HYPERCOM  Hi Did one have any good/bad experiences using Hypercom routers? thank you +-------------------------------------------------------------------+ | Antonis Kyriazis | | Networks & Communications e-mail: antonis@intranet.gr | | INTRACOM sa | | 19.5 km Marcopoulo Ave. fax: +30-1- 68 60 106 | | Peania 190 02 | | GREECE phone: +30-1- 68 60 122 | | The expressed opinions are of my own + - MACEDONIA IS GREEK - + +-------------------------------------------------------------------+  -----------[000165][next][prev][last][first]---------------------------------------------------- Date: 8 Jul 94 14:12:40 EDT From: un027714@wvnvms.wvnet.edu (J. Parcone) To: comp.protocols.tcp-ip Subject: Can't reconnect....HELP!  Hello, Net!! Slight problem: I have two processes connected via sockets across Ethernet. When the client process quits it closes the connection, but then the server closes the connection but it doesn't really close. There is a huge delay before the connection can be opened again, (might be because I'm trying to read from a broken pipe now?). What can I do to prevent this? Is there any good example socket C source I can ftp? All help appreciated, James Parker  -----------[000166][next][prev][last][first]---------------------------------------------------- Date: Fri, 8 Jul 1994 11:34:19 GMT From: swel@bluecross.on.ca (Steve Welsh) To: comp.protocols.tcp-ip Subject: TN3270  Does anyone know of a TN3270 s/w that runs on DOS and provides a "mod 4" emulation. I have DOS s/w that provides "mod 2" emulation and windows s/w that provides "mod 4". Any help would be aprreciated. Thanks Steve -- Steve Welsh \\\/// swel@bluecross.on.ca / @ @ \ __ __ ___ __ Telecommunications Specialist | j | [_ / |_| \ / | /\ / / _ Ontario Blue Cross | (---)| __] \__ | | \/\/ _|_ / \/ \_|  -----------[000167][next][prev][last][first]---------------------------------------------------- Date: Fri, 8 Jul 1994 11:51:19 GMT From: brobbins@newbridge.com (Bert Robbins) To: comp.protocols.tcp-ip Subject: Re: IP address selection  Tom Techoueyres (wali@gate.net) wrote: : Hi, : My company is getting a 56K dedicated connection to Internet, I got already : the IP address that my service provider gave me. It is a class C. this : means that the last octet of the IP address is for our company, which gives : us 254 addresses. the primary server is a MicroVax running VMS, is there : a logical way to assign an address to the primary server? The first three : octet are control by the service provider, the last octet by the company, : but should it be 1, 37 or 250? I don't know what value I should assign : to the primary server? : I would appreciate any help, thank you! It dosen't matter unless you are going to subnet your class C address. If you do subnet then take a look at RFC 1219 for an idea on how to do this with flexibility.  -----------[000168][next][prev][last][first]---------------------------------------------------- Date: Fri, 8 Jul 1994 17:17:19 From: karl@cavebear.com (Karl Auerbach) To: comp.protocols.tcp-ip Subject: Re: Fake network addresses  >Chris Rohrer (crohrer@advtech.uswest.com) wrote: >: I was of the understanding that there is a Class A or maybe a Class B >: address that is reserved and not allocated to anyone on the Internet, >: The purpose is to alllow private networks that do not/can not/will not >: connect directly to the Internet the opportunity to have an address space >: that will not conflict with or confuse anyone's routing tables. The RFC you cited is quite separate from the "test" reserved addresses. Class C 192.0.2.x is reserved and should not exists. I use it as a preconfigured address in products I write and I coerce the IP stack into never sending from that Class C net number. This forces the user to configure the product. I doubt, however, that routers and such would keep such addresses out of their routing tables should they accidently appear. --karl--  -----------[000169][next][prev][last][first]---------------------------------------------------- Date: Fri, 8 Jul 1994 14:20:18 GMT From: erick@sunee.uwaterloo.ca (Erick Engelke) To: comp.protocols.tcp-ip Subject: Re: Different speeds using WFTPD!!!???  Lost the original message, but it was about someone who only got 2 or 3 kilobytes per second on a PC with an SMC 8013 or WD 8013 or 8003 card. I seem to post this every few weeks to some group or another. Trash 8003PKDR and get the free Crynwr packet driver named WD8003 or something similar. It can be found at many sites including Simtel, wuarchive, ftp.ftp.com The problem is this, Western Digital wrote that packet driver before SMC bought them out. That packet driver has a bug in that it does not check to see that the previous packet has been fully outputted before attempting to write the next packet. So any TCP which writes back-to-back packets, ie. any TCP you would want to use, will end up trashing most of the packets. The stuff on the actual wire is crap, so you would be annoying others with this bad driver. I have given up on SMC, I have explained it to them many times but they still distribute that broken driver. Erick  -----------[000170][next][prev][last][first]---------------------------------------------------- Date: Fri, 8 Jul 1994 14:26:17 GMT From: erick@sunee.uwaterloo.ca (Erick Engelke) To: comp.protocols.tcp-ip Subject: Re: Small and Compact TCP/IP/PPP  Robert Bradford <Robert_Bradford@mindlink.bc.ca> wrote: > >How small and compact, in terms of memory requirements, can you >make a TCP/IP and PPP implementation? My WATTCP package can be stuffed into about 30 kilobytes, more if you converted it from C. It is designed for MS-DOS but is easily ported to most other architectures. You can find it at dorm.rutgers.edu in pub/msdos/wattcp/wattcp.zip >So, the question is how small can you make such an >implementation? It can be "shrink wrapped" with the application >and just support one application (i.e., one TCP connection) on >one port using only the serial port. It must be able to do >dial-up and accept IP address assignment from the remote >system. The remote end will fully support TCP and IP and PPP, >but the local end need only implement enough to support its >application and still establish a working link to the remote >end. That's how it is set up. It is also the TCP used in MS-Kermit, TSoft's shareware NFS for MS-DOS, and countless net utilities. Erick  -----------[000171][next][prev][last][first]---------------------------------------------------- Date: Fri, 8 Jul 1994 15:57:26 GMT From: vjs@calcite.rhyolite.com (Vernon Schryver) To: comp.protocols.tcp-ip,comp.client-server,comp.unix.internals Subject: Re: Data formats needed for non-XDR conversion  In article <2vhr41$8u7@stc06.CTD.ORNL.GOV> zhou@isis.epm.ornl.gov writes:
>I would like to know if you could give me some pointers on where can I
>find all (or some of) the data formats for all machine types. Instead of
>using XDR converting routines to convert the data formats used by
>different processors, I am trying to code my own routines to do such
>conversions due to performance reasons.
>
>I heard that OSF' DCE doesn't use XDR routines too. Any comments on this?

DCE is based on the Apollo NCS scheme.  NCS has some advantages, but
data formating was not one of them.

but was jokingly known to others as "receiver makes it wrong."  In fact,
NCS has a complicated version of XDR.  For example, instead of one
integer format as in XDR that just happens to match the byte order of
the CPU's used by the vendor that pushed XDR (and common network practice),
you have at least two, and the receiver must be prepared to convert from
any of them to its native format.  "Reciever makes it right" makes sense
provided you grew up in a closed and controlled environment and think
that you can enumerate all possible data formats now.  (Remember Apollo.)
In real life, there are always more formats than you can know about,
and people are always inventing new ones.  In real life, XDR made it
easy for 32-bit big-endian machines using one kind of floating point
and one character set, while NCS made it fairly easy for 32-bit big- or
little-endian machines using a few kinds of floating point and two
character sets.  All other machines must convert their data.  NCS did
not make the conversion faster or easier.  It just bloated the necessary
code.

Vernon Schryver    vjs@rhyolite.com


-----------[000172][next][prev][last][first]----------------------------------------------------
Date:      Fri, 8 Jul 1994 16:02:56 GMT
From:      vjs@calcite.rhyolite.com (Vernon Schryver)
To:        comp.protocols.tcp-ip
Subject:   Re: Routers, packet size, and RFC 1122 (a query)

In article <2vhpou$9vg@pipe1.pipeline.com> alberg@pipeline.com (Al Berg) writes: > ... >When FTPs happen between the UNIX boxes and a PC on the same >segment, the maximum packet size is about 1500 bytes and >performance is good. > >When FTPs happen between a host on segment A and a client on >segment B, maximum packet size drops to 576 bytes and speed >drops by a factor of 5 or more. A factor of 5 is high. I would expect a factor a little smaller than 1500/576 or about 2.5. >When we put up a Chameleon FTP server on a PC on segment A and >do an FTP from a PC on segment B, maximum packet size stays at >1500 bytes and performance is good. > ... >The IBM rep sent us info saying that RFC 1122 basically says >that when IP packets cross a router, ... >Has anyone "solved" this problem on their net? Many BSD derived systems have an "all subnets are local" switch to violate the "Host Requirements" RFC rule. I think AIX uses BSD-derived network code, and so it might have that switch. If so, and if subnets are being used, that would solve the problem. Some systems also have an "all nets are local" switch, which would fix the problem. The official, recommended solution is to use "MTU path discovery." Vernon Schryver vjs@rhyolite.com  -----------[000173][next][prev][last][first]---------------------------------------------------- Date: 8 Jul 1994 16:55:10 GMT From: murf@perftech.com (John Murphy) To: comp.protocols.tcp-ip Subject: Re: Different speeds using WFTPD!!!???  In article <CsML5v.K9n@watserv1.uwaterloo.ca>, erick@sunee.uwaterloo.ca (Erick Engelke) says: >I have given up on SMC, I have explained it to them >many times but they still distribute that broken driver. > That's not the only bug in that driver. I even sent them the code to Murf  -----------[000174][next][prev][last][first]---------------------------------------------------- Date: Fri, 8 Jul 1994 17:30:01 +0000 From: Roger@natron.demon.co.uk (Roger Barnett) To: comp.object,comp.protocols.tcp-ip,comp.lang.c++ Subject: Re: Wanted: Object Oriented distributed communication toolkit  In article <CsKsJC.9BI@da_vinci.ecte.uswc.uswest.com> scollins@da_vinci.mtt.it.uswc.uswest.com "Steven Collins" writes: > Looking for an Object Oriented distributed communication toolkit > with a C++ interface. CORBA implementations are too heavyweight. > I'm interested in something that is much much easier to use than > BSD sockets and XDR. > Would "like" the product to run on different UNIX flavors plus MAC/PC. << apologies for posting instead of mailing >> Steve, I tried to mail you the following but it was bounced at your end: Although you say you don't want CORBA stuff, have you looked at the DOME product from Object Oriented Technologies Ltd in the UK (not to be confused with a US piece of software of the same name) ? This is written entirely in C++ and offers a full C++ binding, supports various comms protocols, and is available on a wide range of systems. Contact info: Chris Nugent on chris@rtc.co.uk Regards, -- Roger Barnett "There are helicopters on the walls of Troy" Clive James  -----------[000175][next][prev][last][first]---------------------------------------------------- Date: Fri, 8 Jul 1994 17:40:59 GMT From: w-rolph@ds.mc.ti.com (Don Rolph) To: comp.protocols.tcp-ip Subject: Re: IP address selection  In article <2vhdpb$ef7@tequesta.gate.net> wali@gate.net (Tom Techoueyres) writes:
>From: wali@gate.net (Tom Techoueyres)
>Date: 7 Jul 1994 17:24:59 GMT

>Hi,

>My company is getting a 56K dedicated connection to Internet, I got already
> the IP address that my service provider gave me. It is a class C. this
>means that the last octet of the IP address is for our company, which gives
>us 254 addresses. the primary server is a MicroVax running VMS, is there
>a logical way to assign an address to the primary server? The first three
>octet are control by the service provider, the last octet by the company,
>but should it be 1, 37 or 250? I don't know what value I should assign
>to the primary server?
>I would appreciate any help, thank you!

>tom
>wali@gate.net

We made the primary server xxx.xxx.xxx.001 for what its worth!

Regards.

Don Rolph w-rolph@ds.mc.ti.com WD3 MS10-13 (508)-699-1263


-----------[000176][next][prev][last][first]----------------------------------------------------
Date:      Fri, 8 Jul 1994 17:42:52 GMT
From:      droehr@borland.com (Daev Roehr)
To:        comp.protocols.tcp-ip,alt.winsock
Subject:   Re: Windows screws up as server?

James,

>Is this a problem, is it only a problem with particular
>implementations, or is it an inherent problem because
>windows is non pre-emptive?

Windows make a lousy server, mostly because of the coopertive multi-tasking,
partly because the 16-bit address space is all shared, and partly because
it's not very robust. It does however, make a pretty good WWW reader.<g> The
Daytona release (ie NT 3.5) is a better bet.

_daev

My opinions are my own. My corporate master wishes it so.
"Resistance is futile." - The Borg    "Oh Yeah?" - Tommy Smothers


-----------[000177][next][prev][last][first]----------------------------------------------------
Date:      08 Jul 1994 18:25:06 GMT
To:        comp.protocols.tcp-ip
Subject:   Does anyone know of a scriptable telnet for Sun (or anything else?)

I'd like to be able to run a script, a bit like a uucp script, but to
a telnet server.

Any ideas?

Thanks

Tim


-----------[000178][next][prev][last][first]----------------------------------------------------
Date:      Fri, 8 Jul 1994 20:50:50 GMT
To:        comp.protocols.tcp-ip
Subject:   Message for Anonymous FTP server

Is there a way with the Wollongong Implementation of TCP/IP to
add a message to a guest login to an anonymous FTP server?

Thank you.

Dorothy.Edmondson@daytonOH.NCR.COM
AT&T Global Information Solutions

dorothy.edmondson@daytonOH.NCR.COM


-----------[000179][next][prev][last][first]----------------------------------------------------
Date:      8 Jul 1994 20:54:20 GMT
From:      bpc@taichitaichi.cc.bellcore.com (chapman,benjamin p)
To:        comp.sys.mac.comm,comp.sys.mac.misc,comp.sys.mac.programmer,comp.protocols.tcp-ip
Subject:   Help with MacTCP and Telnet

I am forwarding this message from a friend.  Please respond directly to him
but if that doesn't work, I'll forward a response to him.  I can be reached
at bpc@taichi.cc.bellcore.com

Hi,

I am trying to finish a program that I have taken over from another programmer
that needs to be able to communicate to a Unix machine via telnet.  What I am
looking for is some high-level libraries or functions that will enable me
to open and close a telnet session, and send and receive characters through
that session.  The code that I am working on has been ported from a PC
version that the previous programmer wrote, and that program used a package
called Distinct which provided those calls that were needed.  What I need to
know is if there is some similar package available for the mac, or if there
is something similar via FTP.

Any help on this matter would be greatly appreciated as I am a novice when it
comes to Mac programming.  Please send email to alan@hudtech.com

<Hit CR to continue, "q" to leave message >

Alan Davey
w)(212)779-2225


-----------[000180][next][prev][last][first]----------------------------------------------------
Date:      Fri, 8 Jul 1994 21:16:21 GMT
From:      johnk@gordian.com (John Kalucki)
To:        comp.protocols.tcp-ip
Subject:   Re: Fake network addresses


: Hi all,

: I was of the understanding that there is a Class A or maybe a Class B
: address that is reserved and not allocated to anyone on the Internet,
: The purpose is to alllow private networks that do not/can not/will not
: connect directly to the Internet the opportunity to have an address space
: that will not conflict with or confuse anyone's routing tables.

1597  I    Y. Rekhter, R. Moskowitz, D. Karrenberg, G. de Groot, "Address
Allocation for Private Internets", 03/17/1994. (Pages=8)
(Format=.txt)


-----------[000181][next][prev][last][first]----------------------------------------------------
Date:      Fri, 8 Jul 1994 21:53:36 GMT
From:      rvw@laplace.math.purdue.edu (Rich Williams)
To:        comp.protocols.tcp-ip
Subject:   Phone # for Grand Junction needed.

I need the number for Grand Junction Networks Inc. I was
hoping to talk to some one about their new ether switch.

Best regards,

rvw@math.purdue.edu          |  Purdue University
(317) 494-4246               |  Math Department
#include <std/disclaimer.h>  |  West Lafayette, IN 47907


-----------[000182][next][prev][last][first]----------------------------------------------------
Date:      Fri, 8 Jul 1994 22:29:18 GMT
From:      deleon@cat.hpl.hp.com (Laura de Leon)
Subject:   BayLISA: Next Generation Internet Protocol


July 21st:	Dino Farinacci (Cisco)

Title: Next Generation Internet Protocol (IPng)

Description:

The global Internet is going through growing pains.
Address space exhaustion is approaching and routing
table sizes are becoming too large for modern day routers
to handle. IPng will be a new internet network layer

This talk will present a bit of history leading up to
the proposals put forth today. Describe the IETF
structure that supports the proposals. Introduce the
various proposals and the mergers that have occured over
the course of refinement. And in conclusion, hint at
leading candidates and indicate when the IETF will decide.

August 18th:	Peter Salus: The History of UNIX

The Bay-LISA group meets monthly to discuss topics of interest for
administration of sites with more than 100 users and/or computers.
The meetings are free and open to the public.

BayLISA holds monthly meetings on the third Thursday of each month at
7:30 PM (please do not arrive before 7:00).  We meet at Synopsys
Building C in Mountain View off Highway 237 at Middlefield.

To get further information on the meeting location, you can request it
from the majordomo server on baylisa.org, you can ftp it from

ftp.baylisa.org:/BayLISA/location

or you can query the BayLISA mail server by cutting and pasting
the following line to your shell:

echo "index baylisa" | mail majordomo@baylisa.org

Starting this May and going through the rest of the summer, we plan
send email to:

mbone@baylisa.org

BayLISA makes video tapes of the meetings available to members.  For more
information on available videos, please send email to:

video@baylisa.org

For any other information, please send email to:

info@baylisa.org

above.


-----------[000183][next][prev][last][first]----------------------------------------------------
Date:      Sat, 9 Jul 1994 00:39:22 GMT
From:      steve@ecf.toronto.edu (Steve Kotsopoulos)
To:        comp.protocols.tcp-ip,comp.os.misc
Subject:   Call for beta testers - Adaptive File Distribution Protocol (AFDP)

efficient and reliable group communication.

The protocol is built on top of UDP, and uses a rate-based flow control
mechanism to provide efficient and reliable file distribution.  AFDP
uses the publishing metaphor: any machine receiving files is called a
subscriber and any machine sending files is called a publisher.  One
special subscriber is designated as the secretary; this machine is
responsible for managing the group membership and authorizing publishers.
AFDP dynamically selects between 3 different transfer modes: unicast,
multicast (on hosts that support it), and broadcast.

You can call AFDP from any of your applications, or just use the existing
file transfer mechanisms of AFDP.

AFDP has been tested on IRIX, SunOS, Solaris, RISC/os, Ultrix, and SVR4.2.
Our sources also include a library of convenience functions for writing
network applications, which can be re-used in other programs.

AFDP is not yet ready for public release, but we are looking for a group
of beta-testers who are familiar with network programming.  If you do not
fit in this category, please wait for the public release of AFDP.

If you would like to beta-test AFDP,
please send the following to afdp@ecf.toronto.edu:

- the operating systems you are running
- which systems support IP multicast
- tell us what you would like to use AFDP for

We will contact the beta-team next week, with information on
how to obtain our code.

Steve Kotsopoulos <steve@ecf.toronto.edu>
Jeremy Cooperstock <jer@dgp.toronto.edu>
--
Steve Kotsopoulos  P.Eng.                         steve@ecf.toronto.edu
Systems Analyst,  Engineering Computing Facility, University of Toronto


-----------[000184][next][prev][last][first]----------------------------------------------------
Date:      Sat, 09 Jul 1994 10:59:49 -0500
From:      messina@mcs.com (David Messina)
To:        comp.protocols.ppp,comp.protocols.tcp-ip,comp.sys.mac.comm
Subject:   Re: where can I get the interSLIP for MAC?

In article <9407081443.AA23279@fusion.intercon.com>, amanda@intercon.com
(Amanda Walker) wrote:

> messina@mcs.com (David Messina) writes:
> > It's free, and available on many archives (info-mac, e.g.)
>
> The canonical source is ftp.intercon.com, in the directory /InterCon/sales.
> It's also available on ftp.tidbits.com, but it's *not* generally available
> on random archive sites.  If it's on info-mac, it should be taken off of it.
> Putting InterSLIP up for FTP on any server requires explicit permission of
> InterCon Systems Corporation.  InterSLIP may be free of charge, but it still

Sorry to step on your toes, Amanda. :)

I incorrectly assumed InterSLIP was widely distributed, but I did not
actually check.  So as Amanda said, get InterSLIP from InterCon or
TidBits.  Don't expect to find it anywhere else.

--
David Messina
messina@mcs.com


-----------[000185][next][prev][last][first]----------------------------------------------------
Date:      Sat,  9 Jul 94 23:32:00 -0700
From:      philip.burton@spacebbs.com (Philip Burton)
To:        comp.protocols.tcp-ip
Subject:   NDIS supported for Mac?

I hope this isn't a dumb question.  This came up in a "bull session."

Is there NDIS support for the Mac under System 7?  If not, is this
support unnecessary?  Is there an equivalent mac-level interface?

-- Phil Burton --    philip.burton@spacebbs.com
- Palo Alto, CA -
---
þ CMPQwk #1.4þ UNREGISTERED EVALUATION COPY


-----------[000186][next][prev][last][first]----------------------------------------------------
Date:      9 Jul 1994 13:21:17 GMT
From:      marcin@pk-siec (Marcin Klimowski)
To:        comp.protocols.tcp-ip,comp.mail.smail,comp.mail.sendmail,comp.mail.misc,comp.mail.mime
Subject:   Re: POP protocol on SCO

martin bowman (mbowman@sita.int) wrote:

: Does anyone have any information about implementing the POP protocol on SCO
: UNIX?
try ftp.sco.com:/TLS/BLAH bLAH bLAH
or  soils.agron.iastate.edu:
--
------------------------------------------------------------------------------
Marcin Klimowski | e-mail - marcin@oeto.pk.edu.pl | IRCNICK - Cinek
| 	    marcin@twins.pk.edu.pl|
------------------------------------------------------------------------------
YOUR bus ALWAYS ARRIVES LATER :(
------------------------------------------------------------------------------


-----------[000187][next][prev][last][first]----------------------------------------------------
Date:      Sat, 9 Jul 1994 17:36:31 GMT
From:      tung@eespcb.ncku.edu.tw (Assistant)
To:        comp.protocols.tcp-ip
Subject:   A interesting routing quesiton.....

Hi,

Here is a old network configuration of our lab:

140.116.32.0                     internet
140.116.32.01...252 -------------------------140.116.32.253----------->

Now we decide devide 4 subnet from 140.116.32.0, and route the IP packet
from the novell server, below is the new configurtion:

140.116.32.64
|          140.116.32.192                       gate 140.116.32.78)
| |        140.116.32.208                       gate 140.116.32.206)
| | |      140.116.32.224                       gate 140.116.32.222)
| | | /----------------------140.116.225...237 (netmask ff.ff.ff.f0
| | | |                                         gate 140.116.32.238)
| | | |      novell server
| | | |   +-----------------+
| | | \---|140.116.32.238(A)| netmask=?, gate=? (Q2,3)
| | \-----|140.116.32.222(B)|
| \-------|140.116.32.206(C)|
\---------|140.116.32.078(D)|
|                 |
|         +-----------------+
|
|                   140.116.32.0                                   internet
\----------------------------------------------------140.116.32.253--------->
(140.116.32.XXX not include in A,B,C,D subnet)       (router)

We have set the netmask and default gateway of PCs connecting to port A,B,C,D
but at novell,we have some question here...

1. We load tcpip.nlm with tcpip=yes, rip=yes, anything else needed?
Does tcpip.nlm ver 1.00 work fine?
2. What netmask sould we set for port ABCD, FF.FF.FF.F0?
3. What gateway sould we set for port ABCD, 140.116.32.241?
ps: When we load tcpip.nlm with this setting, it shows:
"140.116.32.238 is not on the same subnet as 140.116.32.241....."
4. What netmask sould we set for port Z, FF.FF.FF.F0 or FF.FF.FF.00
if ff.ff.ff.f0, how can hosts at port a, b, c, d connect to 140.113.32.xxx
not on ABCD? (ex:140.116.32.60)
Should we add static route to port Z?
5. What gateway sould we set for port Z, 140.116.32.253?
6. It is said that all the port of novell should has the same netmask,
is it true?
7. The manual said that we'd better set RIP to off, why?

This is serious to us, any suggestion will be much appreciated.....

thanks again.

tung@eespcb.ncku.edu.tw


-----------[000188][next][prev][last][first]----------------------------------------------------
Date:      Sat, 9 Jul 1994 17:39:20 GMT
From:      aboba@netcom.com (Bernard Aboba)
Subject:   comp.protocols.tcp-ip.ibmpc Frequently Asked Questions (FAQ), part 1 of 3

Archive-name: ibmpc-tcp-ip-faq/part1

comp.protocols.tcp-ip.ibmpc:
FAQ Posting, part 1, 7/1/94

****************  Legalese ************

This document is Copyright (C) 1993,1994 by Bernard Aboba, except where
the copyright is retained by the original author(s). This document
may be distributed non-commercially, provided that it is not
modified in any way. However, no part of this publication may be
sold or packaged with a product for sale in any form without the
prior written permission of Bernard Aboba.

This FAQ is presented with no warranties or guarantees of ANY KIND
including correctness or fitness for any particular purpose. The
author(s) of this document have attempted to verify correctness of the
data contained herein; however, slip-ups can and do happen.  If you use
this data, you do so at your own risk. While we make every effort to
keep this FAQ up to date, we cannot guarantee that it is, and we will
not be responsible for any damages resulting from the use of the information
or software referred to herein.

Unless otherwise stated, the views expressed herein are my own.  Last
time I looked, I had not been appointed official spokesperson of any
of the following:

The Planet Earth
The U.S.Government
The State of California (not so good)
The University of California, Berkeley
The City of Berkeley (bringing you Riot of the Week(SM) )
Publisher's Group West
Any major or minor breakfast cereal (not even oatmeal!)

This FAQ will be posted monthly. In between it will be
available as:
file://ftp.netcom.com/pub/mailcom/IBMTCP/ibmtcp.zip

*********** Citation entry  ***********

This FAQ may be cited as:

Aboba, Bernard D.(1994) "comp.protocols.tcp-ip.ibmpc Frequently
file://ftp.netcom.com/pub/mailcom/IBMTCP/ibmtcp.zip,
57 pages.

*********** Test HTML FAQ  ***********

As a test, I've been playing with putting this FAQ into
HTML form. To try it out, point your browser to:
http://www.zilker.net/users/internaut/current.html

*********** Change History  ***********

Changes from 6/1/93 posting:
FAQ split into three parts. Updated several entries;
Over half a dozen new entries. Have added coverage
on 32-bit support. Changed entries sport a "*".

*********** KA9Q Request  ***********

In order to beef up the section of the FAQ on KA9Q,
I am asking for sample config files for use with the
CWRU or DIS KA9Q versions, to demonstrate use of the
following features:

1. Dial on demand.
2. Use of KA9Q with built-in PPP. (has *anyone*
gotten this work?)
3. DNS server.
4. Use of KA9Q as a SLIP server with security.
5. Use of the SMTP/POP3 server with rewriting of
addresses or rejection of junk mail.
6. Use of the Gopher/HTTP/CSO server.

*********** Related FAQs ***************************

There is a FAQ available on features of TCP/IP
Packages for DOS and Windows. This is available at:
file://ftp.cac.psu.edu/pub/dos/info/tcpip.packages.

The Windows Sockets Faq is posted to alt.winsock, and
is available at:
file://SunSite.UNC.EDU/pub/micro/pc-stuff/ms-windows/winsock/FAQ

The PC-NFS FAQ is available at:
file://seagull.rtd.com/pub/tcpip/pcnfs.FAQ.v1.4.Z or pcnfsfaq.zip
file://ftp.york.ac.uk/pub/FAQ/pcnfs.FAQ

The SNMP FAQ is regularly posted to comp.protocols.snmp

The TCP/IP FAQ is posted to comp.protocols.tcp-ip, and is
maintained by gnn@netcom.com.

The "How To Get It" FAQ on the Crynwr packet driver
collection is irregularly posted to comp.protocols.tcp-ip.ibmpc
by Russ Nelson, nelson@crynwr.com.

***************** Book info  ******************

A bunch of you have requested information on the
book I am working on.  Here is the basic info:

Title: The PC-Internet Connection, TCP/IP
Networking for DOS and Windows
Authors: Bernard Aboba and Britt Bassett
Pages: 800 (estimated), 7" by 9"
Distributor: Publisher's Group West
ISBN: 1-883979-00-5
Price: $32.95 (est), includes Chameleon Sampler software, WS-Gopher, PC-Eudora. Estimated release: October, 1994 To look at sample chapters from the book, check out the following WWW page: http://www.zilker.net/users/internaut/forth.html For those of in North America who *must* have a look at the book before it comes out, and are willing to comment on it, send me$25 to cover
copying and postage, and I'll send you a copy.
If you send back comments, I'll return the $25. Since this is a big book, be prepared to spend some time looking at it. For those outside North America, sorry but we're on a tight deadline, and so we will not be able to include you. *********** EXAMPLE CONFIGURATION FILES *********** Many thanks to Dave Fetrow (fetrow@biostat.washington.edu) for creating an archive of setup files. The archive is particularly oriented toward sets of applications that are somewhat tricky, such as combinations involving different driver sets, mixtures of NetWare, TCP/IP, and W4WG, etc. Please include not only the setup and configuration files but some directions. Comments included with the setup files are highly desirable. The files can include your name if you desire. Please mail submissions to ftp@ftp.biostat.washington.edu. The archive itself is located at: file://ftp.biostat.washington.edu/ftp/pub/msdos/network.setups Late breaking development: the archive has crashed, and files have been lost. TABLE OF CONTENTS A. Components of a TCP/IP solution A-1. What do I need to run TCP/IP on the PC? A-2. What are packet drivers? Where do I get them? A-3. What is Winsock? Where can I get it? A-4. What is Trumpet Winsock? How do I get it to dial? A-5. What publicly distributable TCP/IP applications are there for DOS? Windows? A-6. What software is available for doing SLIP? Compressed SLIP? PPP? For DOS? For Windows? A-7. What about the software included with various books? A-8. What diagnostic utilities are available to find problems with my connection? Where can I get them? A-9. Is there a CD-ROM with the software included in this FAQ? A-10. Does Windows NT support SLIP? PPP? A-11. Where can I take a peak at the WFW v3.11 VxD beta? A-12. How do I get my BBS to run over TCP/IP? A-13. Are there graphical TCP/IP servers out there? A-14. What methods of dynamic address assignment are available? A-15. How can I set up PPP server on a UNIX host? A-16. What is WinSNMP? B. Questions about drivers B-1. What do I need to know before setting up SLIP or PPP? B-2. How do I configure SLIPDISK? B-3. How do I install packet drivers for Windows applications? B-4. When do I need to install WINPKT? B-5. How to do I run both WinQVT and ODI? B-6. Is it possible to use BOOTP over SLIP? B-7. How do SLIP drivers work? B-8. When do I need to install PKTMUX? B-9. Can NDIS be used underneath multiple protocol stacks of the same type? B-10. Is there an NDIS over packet driver shim? B-11. How do I run NetBIOS over TCP/IP? B-12. How do I run NFS and another TCP/IP application? B-13. How do I run Trumpet Winsock along with KA9Q or NFS? B-14. Sample Stick Diagrams B-15. Strange and wonderful configuration files submitted by readers C. KA9Q Questions C-1. What version of KA9Q should I use and where do I get it? C-2. What do I need to run KA9Q? Why won't it do VT-100 emulation? C-3. How do I configure KA9Q as a SLIP dialup connection? C-4. How do I configure KA9Q as a router? C-5. How do I get KA9Q to support BOOTP? C-6. How do I get KA9Q to support PPP? C-7. How do I get KA9Q to support SLIP dialin? C-8. Can I use KA9Q as a packet filter? D. Hints for particular packages D-1. How do I get DesQView X to run over the network? D-2. Why is NFS so slow compared with FTP? D-3. Where can I get information on running NetWare and TCP/IP concurrently? D-4. What NetWare TCP/IP NLMs are out there and how do I get them to work? D-5. How do I get a telecom package supporting Int 14h redirection to work? D-6. How do I run SLIP/PPP with Windows For Workgroups TCP/IP? D-7. How do I get Windows For Workgroups to work alongside NetWare? D-9. How come package X doesn't support the AppleTalk packet driver? D-10. NCSA Telnet doesn't reassemble fragments. What should I do? E. Information for developers E-1. What publicly distributable TCP/IP stacks are there that I can use to develop my own applications? E-2. Where can I get a copy of the Windows Sockets FAQ? --------------------- FAQ Begins Here --------------------------- A. Components of a TCP/IP solution A-1. What do I need to run TCP/IP on the PC? To run TCP/IP on the PC you will need: * Appropriate hardware, such as: Ethernet card Token Ring card AppleTalk card Serial Port Any other network card with a packet driver or NDIS or ODI driver, (such as Arcnet), will also work. If your card supports NetBIOS, this is also acceptable, since you can run a packet-driver-over- NetBIOS shim. * Drivers for your hardware. Your card probably came with one or more of the following drivers: Network Device Interface Specification (NDIS) drivers [spec. by 3Com & Microsoft, used by LAN Manager, Windows for Workgroups, and Windows NT. LAN Manager uses NDIS 2.0, Windows NT uses 3.0, and WFW supports 2.0 and will support 3.0] ODI Drivers [spec. by Novell, abbreviation for Open DataLink Interface] Packet Drivers [spec. by FTP Software] TCP/IP stacks have been written for each of these driver interfaces, so the important thing is whether your chosen stack is compatible with the interface available for your card. A shim is software that runs on top of one set of drivers to provide an interface equivalent to another set. This is useful, for example,if you are looking to run software requiring an NDIS driver(such as Chameleon NFS) alongside software requiring a packet driver interface (such as KA9Q, Gopher, Popmail, NCSA Telnet, etc.), or run software intended for, say, a packet driver over an NDIS driver instead. Shims are available to run packet drivers over NetBIOS, ODI, or NDIS, in order to run software expecting a packet driver over NDIS, ODI, or NetBIOS instead. There are also shims to run NDIS over ODI (ODINSUP), and ODI over Packet Drivers (PDETHER). * A TCP/IP protocol stack. The TCP/IP protocol stack runs on top of the driver software, and uses it to access your hardware. If you are running a TCP/IP protocol stack that requires drivers that aren't available for your hardware, you're in trouble. Check into this before purchasing! * If running Windows applications that require it, WINSOCK.DLL. Windows Sockets is a sockets interface which was created as a Windows DLL. Each TCP/IP implementation requires its own version of Windows Sockets. Trumpet Winsock and VxDTCP are the only two publicly distributable Windows Sockets implementations. WINSOCK.DLL provides 16-bit support; WSOCK32.DLL provides 32-bit support. * Applications software. Although most of us in this newsgroup seem to spend our time looking for working combinations of applications,WINSOCK.DLLs, Windows Sockets compliant TCP/IP implementations, shims, drivers, and hardware, ultimately your goal is eventually to run an application successfully. If and when that happens, please send me a note, so I can add it to this FAQ. A-2. What are packet drivers? Where do I get them? Packet drivers provide a software interface that is independent of the interface card you are using, but NOT independent of the particular network technology. As Frances K. Selkirk (fks@vaxeline.ftp.com) notes: "That's one reason they're easier to write than ODI drivers! If you write a class three (802.5 Token Ring) driver, you will need to use software that expects a class three driver, not software that expects a class 1 (DIX ethernet) driver. There are a few drivers that fake class 1. I believe only class 1 and class 6 (SLIP) drivers are supported by freeware packages." The chances are fair that your Ethernet card came with a packet driver, and if so, you should try that first. If not, then you can try one of the drivers from the Crynwr collection (formerly called the Clarkson Drivers). See the Resource listing for info. For 3COM drivers, try ftp ftp.3com.com. For technical information, try info@3com.com. For marketing and product info, try leads@hq.3mail.3com.com.The packet driver specification is available from vax.ftp.com in packet-d.ascii The following vendors have packet drivers with source available for their pocket lan adaptors: D-Link - +1-714-455-1688 Solectek - +1-619-450-1220 Accton - +1-415-266-9800 Compulan - +1-408-922-6888 (soon Kodiak's Noteport - +1-408-441-6900) You can obtain a complete library of packet drivers from many of the Simtel20 mirror sites, including: file://oak.oakland.edu/pub/msdos/pktdrvr/pktd11.zip, pktd11c.zip. A-3. What is Windows Sockets? Where can I get it? The idea for Windows Sockets was born at Fall Interop '91, during a Birds of a Feather session. From the Windows Sockets specification: [courtesy of Mark Towfiq, towfiq@Microdyne.COM]: The Windows Sockets Specification is intended to provide a single API to which application developers can program and multiple network software vendors can conform. Furthermore, in the context of a particular version of Microsoft Windows, it defines a binary interface (ABI) such that an application written to the Windows Sockets API can work with a conformant protocol implementation from any network software vendor. Windows Sockets will be supported by Windows, Windows for Workgroups, Win32s, and Windows NT. It will also support protocols other than TCP/IP. Under Windows NT, Microsoft will provides Windows Sockets support over TCP/IP and IPX/SPX. DEC will be implementing DECNet. Windows NT will include mechanisms for multiple protocol support in Windows Sockets, both 32-bit and 16-bit. Mark Towfiq writes: "Files and information related to the Windows Sockets API are available via file://sunsite.unc.edu/pub/micro/pc-stuff/ms-windows/winsock, which is a mirror of /pub/winsock on Microdyne.COM (SunSite has a much faster connection to the Internet, so you are advised to use that). If you do not have FTP access to the Internet, send a message with the word "help" in the body to either ftpmail@SunSite.UNC.Edu, or ftpmail@DECWRL.DEC.Com, to obtain information about the FTP to Mail service there." Alternative sources for the Windows Sockets specification include rhino.microsoft.com (an FTP server running NT), as well as the Microsoft forum on CompuServe (go msl). Currently NetManage (NEWT), Distinct, Spry, FTP and Frontier are shipping Winsock TCP/IP stacks, as is Microsoft (Windows NT and TCP/IP for WFW), Beame & Whiteside Software (v1.1 compliant), and Sun PC-NFS. If you are looking for a Winsock.dll, you should first contact your TCP/IP stack vendor. Novell has one in beta for their Lan Workplace for DOS. A-4 What is Trumpet Winsock? How can I get it to dial? Peter Tattam has released a shareware Windows Sockets compliant TCP/IP stack. You can obtain it via file://ftp.utas.edu.au/pc/trumpet/winsock/winsock.zip, winapps.zip, or file://biochemistry.bioc.cwru.edu/pub/trumpwsk/winsock.zip. The first thing to do after you download WINSOCK.ZIP is to create a directory for Trumpet Winsock, such as C:/TRUMPWSK, and put it in your DOS PATH statement. Trumpet Winsock operates over packet drivers, or over a serial port using its own built-in SLIP/CSLIP. If you are using a network adapter, this means that you will have to locate a packet driver for your adapter, and load it. Trumpet Winsock also comes with WINPKT, and this is loaded next, via the command WINPKT.COM 0x60 [or whatever the software interrupt for your packet driver] You will then enter Windows, and create a group in the Program Manager for all the files that come with Trumpet Winsock. The stack itself is loaded by executing TCPMAN. Applications that come with it include WinCHAT, a chatting program; PINGW, a ping utility; FTPW for FTP, WINARCH for Archie. When you first execute TCPMAN, you will be asked to fill out the setup information for the stack. Select whether you will be using a network adapter or SLIP; you cannot use both. Since Trumpet Winsock does not yet support PPP, you will need to load the EtherPPP driver and WINPKT prior to running Windows. EtherPPP is available via file://merit.edu/pub/ppp/etherppp.zip. This is an Ethernet simulation driver, so you will configure Trumpet Winsock as though it were running over an Ethernet Packet driver, i.e. by loading WINPKT 0x60, and setting the packet driver vector in TCPMAN to 60. EtherPPP comes with its own dialer, so you will need to create a dialing script. If your TCP/IP address will be changing, you will also need to write a little batch script to capture the assigned IP address, and insert it into Trumpet's initialization file. EtherPPP takes up too much RAM (121K), but otherwise works fine. If for some reason you don't like Trumpet Winsock's scripting language, you can use any other comm program that doesn't drop carrier on exit, or the DIALER program, available via: file://ftp.cica.indiana.edu/pub/pc/win3/util/dialexe.zip. As for Trumpet Winsock's built-in scripting language, the default dialout script is LOGIN.CMD. A sample LOGIN.CMD file from Geoff Cox (geoff@satro.demon.co.uk): # # initialize modem # output atzm0\13 input 10 OK # # set modem to indicate DCD # output at&d2&c1\13 input 10 OK\n # # send phone number # output atdt0813434848\r # # my other number # #output atdt241644\13 # # now we are connected. # #input 30 CONNECT # # wait till it's safe to send because some modem's hang up # if you transmit during the connection phase # #wait 30 dcd # # now prod the terminal server # #output \13 # # wait for the username prompt # input 30 ogin: username Enter your username output \satro\r # # and the password # input 30 assword: password Enter your password output \my password\r # # we are now logged in # input 30 otocol: # # see who on for informational reasons. # output SLIP\r input 30 HELLO A-5. What publicly distributable TCP/IP applications are there for DOS? Windows? Right now there are a wealth of publicly distributable TCP/IP applications running under DOS. Windows also has a wealth of programs available, including implementations of Gopher, Mail (POP3/SMTP), FSP, Mosaic, Telnet, FTP, IRC, and WAIS. See the Resource listings for information. A-6. What software is available for doing SLIP? Compressed SLIP? PPP? For DOS? For Windows? For OS/2? For SLIP or CSLIP use with DOS, I recommend using SLIPPER or CSLIPPER. These are packet drivers that can be used along with a dialer. For PPP, I recommend the EtherPPP packet driver described above. There is a special version of NCSA Telnet for PPP, available from merit.edu, /pub/ppp directory. KA9Q supports SLIP/CSLIP, but unfortunately can not be used as a TCP/IP protocol stack to run other apps. I have heard good things about IBM's TCP/IP for OS/2, but haven't used it msyelf. Please see the FAQ from comp.os.os2.networking for details. IBM, FTP Software, Beame & Whiteside, Frontier, SPRY and Netmanage also offer SLIP support in their products. See the resource listings for details. A-7. What about the software included with various books? The software included with various books (including mine) is usually Chameleon Sampler from NetManage. Sampler supports SLIP/CSLIP/PPP, but not connection over a network, and includes software for FTP, Telnet, TN3270, and Mail. The stack included with Sampler (NEWT) is Winsock compatible, so you can run any Windows Sockets-compatible application over it. Installation is quite a bit simpler compared with going the Trumpet Winsock route, so this is probably the best way to go assuming that you are a dialup IP user. A-8. What diagnostic utilities are available to find problems with my connection? Where can I get them? Frequently used diagnostic utilities include ifconfig (checks the configuration of the network interfaces), ping (tests IP layer connectivity), traceroute (traces the route that a packet takes between two sites), netstat (checks the routing table), tcpdump (protocol analyzer), arp (looks at the IP to Ethernet address mappings). KA9Q includes ifconfig, ping and traceroute functions. In KA9Q hop check is the equivalent of traceroute. The Trumpet TCP/IP stack also has a hopchk2 command that is a traceroute equivalent. Etherload is very useful for network profiling, while Etherdump can be used for packet catching, although I wish it would give more information, along the lines of TCPDUMP. Trumpet Winsock comes with Windows implementations of Ping and Traceroute. A-9. Is there a CD-ROM with the software included in this FAQ? The Packet Driver, WinSock & TCP/IP CD-ROM is available from CDPublishing for$29.95. This includes the packet drivers of course,
but also lots of other DOS and Windows TCP/IP stuff, including
Windows Sockets applications. It also includes the text of all
the RFCs. This is now somewhat out of date (it was cut in
December), but is otherwise highly recommended.

CDPublishing, (604)874-1430, (800)333-7565, fax: (604)874-1431,
email: info@CDPublishing.com, FTP archive: ftp.CDPublishing.com,
Gopher site: gopher.CDPublishing.com, WWW: http://www.CDPublishing.com

A-10. Does Windows NT support SLIP? PPP?

The "Daytona" release of Windows NT will include support for
PPP (client and server) and SLIP (client), both including
support for Van Jacobson header compression.

A-11. Where can I take a peak at the WFW v3.11 VxD beta?

This is a beta release of the forthcoming 32 bit-TCP/IP stack for
Windows for Workgroups v3.11. This is looking *very* good; it's
fast, and has worked fine for me. It also supports a host of very
nice new features, including DHCP automatic configuration, WINS
name resolution, and Windows Sockets v1.1. However, plesae not that
it does not offer SLIP or PPP support.
The final beta release is now available via:
file://ftp.microsoft.com/PerOpSys/WFW/tcpip/

A-12. How do I get my BBS to run over TCP/IP?

First off, let's clarify what we mean by "over TCP/IP." Usually
this means "accessible via Telnet." Be aware that doing this will
not necessarily work well, since few BBSes have been tested running
over TCP/IP. As a result you may experience frequent crashes, or
abominable transfer rates. For example, I have seen transfer rates
as low as 100 characters/second over a 14.4 Kbps PPP connection
which routinely supports 1600 cps transfers with FTP.

This situation might be improved by running an FTP server instead.
This could be accomplished for example by running KA9Q in another
window under DesQView, or by putting the files on an NFS-mounted
drive, then using another machine as the FTP server.

One way to hook up a multi-line BBS is to use a terminal server,
and hook up the BBS's serial ports to that. The disadvantage of this is that
if your BBS is really big you will need multiple terminal servers
which will each have their own domain names and TCP/IP addresses.
Confusing.

Brian Clements of Murkworks has a better solution, called BBSnet.
It provides a Telnet interface that looks like a FOSSIL driver.  The first
version runs partly as an NLM; some of the code resides on the server.
For info, contact

BBSnet,MurkWorks, Inc., P.O. Box 631,Potsdam, NY 13676,
+1 315 265 4717, info@MurkWorks.com

eSoft has also recently announced that they are working on a TCP/IP
compatible version of TBBS. Look for this to be shown at OneBBS
Con '94 in Atlanta.

A-13. Are there graphical servers out there?

Yes! For Windows there is a graphical SMTP daemon which is not very
functional (it can't do as much as KA9Q); several Web servers, including
a Windows version of NCSA's HTTP, and SerWeb.

For Windows NT, The European Microsoft Windows Academic Consortium (EMWAC) has
released Windows NT servers for Gopher, WAIS, and WWW. These servers
are easy to install, and fast, and offer the full complement of capabilities,
installation as a Windows NT service, etc.

See the resource section for details.

A-14. What methods of address assignment are available?

Methods of address assignment include client/server protocols
(RARP, BOOTP, DHCP), as well as script-based methods
supports assignment of addresses from the server.

As part 2 of this FAQ discusses, there are RARP and BOOTP clients
and servers available for DOS. Typically the clients work by stashing
the IP address in a DOS environmental variable. It is then your responsibility
to modify the appropriate config files to reflect this
address. This can be done using a DOS batch script and a utility such as
DOS awk. This same approach can be used to modify config files when using
EtherPPP; this does not place the IP address into a variable, but the output
of EtherPPP can be piped to a file and the IP address picked off and inserted
in the appropriate locations. If this sounds complicated, it is; be warned.

Trumpet Winsock supports script-based assignment of addresses. Microsoft
supports a DHCP client in WFW TCP/IP, and both client and server in Windows NT.
There is also a forthcoming DHCP server for Sun.

A-15. How can I set up PPP server on a UNIX host?

This is not the appropriate place to address that question, but lots
of info on this is available in the comp.protocols.ppp FAQ.

A-16. What is WinSNMP?

WinSNMP is an API which provides a standard interface to to the
Simple Network Management Protocol (SNMP) for network
management applications running under Windows. Applications written to
WinSNMP can run on any WinSNMP-compatible implementation.

Vendors supporting WinSNMP include FTP Software, which supports it
in both OnNet 1.1, and PC/TCP 3.0.

B-1. What do I need to know before setting up SLIP or PPP?

Before setting up your SLIP or PPP connection, you should
have available the following information:

dynamically, or from the server.
* If from the server, whether you will be using RARP, BOOTP or DHCP.
* The domain name and TCP/IP address of your machine (if you are not
configuring the address dynamically or via BOOTP)
* The domain name and TCP/IP address of the primary and secondary
Domain Name Server.
* The domain name and TCP/IP address of an NNTP server.
* Whether your host supports POP, and if so, what version.
* Whether the host supports compressed or uncompressed SLIP, or PPP.
* The size of the Maximum Receivable Unit (MRU).

Do not attempt to connect to your host before you have this
information, since it will just waste your time and money, and may
cause problems for the network.  In particular, do not attempt to
initiate a connection using a made up TCP/IP address! It is possible

This is probably the quickest way to get people very angry at you.

be the same. This makes it easy to configure your setup files.
Dynamic addressing means that the host will send you a message
and inserting it into the setup files. If not, then you may have
to edit your setup files every time you log on. Yuck!

Chameleon NFS includes a version of SLIP which can handle dynamic
DOS does as well.

You can also retrieve your address using RARP, BOOTP or DHCP. RARP
is only available to those on the same LAN as the RARP server, since
it uses broadcasting. BOOTP clients can access BOOTP servers on other
LANs via BOOTP relay. DHCP is a BOOTP extension, which allows
complete configuration of a client from info stored on a DHCP server, and in
DHCP frames are very similar to BOOTP frames, devices supporting BOOTP relay
will also support DHCP relay.

Of course, for DHCP or BOOTP to work, you will need to set up a DHCP
or BOOTP server. DHCP servers are available for UNIX, and Windows NT.

PPP also supports server assignment of TCP/IP addresses.

B-2. How do I configure SLIPDIAL?

From Ashok Aiyar, ashok@biochemistry.bioc.cwru.edu:

PHONE Script Files:

PHONE comes with several scripts (for various modems) and for the
University of Minnesota Terminal server built into it.  The command
PHONE WRITE writes these scripts to an ASCII file called PHONE.CMD,
which can be edited to your needs (modem and slip server)

The documentation that accompanies PHONE, provides good instructions on
writing script files to get PHONE to dial SLIP servers other than
the University of Minnesota server.  For example here is a script
that I use to dial a CISCO server at the University that I attend.

Background:  To start a SLIP connection, I dial our terminal server,
session with the following command "slip username-slip.dialin.cwru.edu",
followed by my password -- again.

Here then is the relevant portion of the PHONE.CMD script file -
#
# CWRU-TS2 SLIP login script by Ashok Aiyar 3/26/93
# Last revised 3/28/93
TimeOut 60      'CWRU-TS2 terminal server is not responding'
Message         "CWRU-TS2 SLIP login script -- Version 1.1"
Message         'Waiting for SLIP server to respond'
Quiet ON
Expect 'Verification'
Message         'Request for User Verification Received from CWRU-TS2'
Quiet OFF
Send '%u<'
Private
Send '%p<'
TimeOut 30    'SLIP server did not respond to your validation request'
Expect 'CWRU-TS2>'
Send 'SLIP<'
TimeOut 10    'SLIP server did not respond to SLIP command'
Send '%u-slip.dialin.cwru.edu<'
TimeOut 10 'SLIP server did not respond to hostname'
Send '%p<'
TimeOut 10
Message 'Login to CWRU SLIP server successful'
Wait 1.0
#
#
Procedure      Host.CWRU.LogOut
# Nothing special needs to be done to logout
EndProcedure   Host.CWRU.LogOut
#
#   End of Script file
#
----------------------------------------------------------------------
How to use packet drivers other than UMSLIP with PHONE?

The quick answer -- there is no "clean" way.  Below is a batch file
hack that I wrote to use PHONE with other packet drivers.  In this
example, the packet driver is Peter Tattam's CSLIPPER.  To use a
batch file like this, you must know the parameters with which you
plan to use the packet driver -- i.e interrupt vector, baud rate,
port address, and IRQ.  This batch file requires UMSLIP.COM,
CSLIPPER.EXE, and TERMIN.COM to be in the same directory

All that the BATCH file does is to let you dial the SLIP connection
using PHONE, load the appropriate packet driver, hangup the
connection, and unload the driver when you are done ...

-- being CWRUSLIP.BAT --
@echo off
rem   this batch file is an ugly hack of U. of Minn. "SLIP.BAT"
rem   awaiting a version of C/SLIPPER that can directly interact
rem   with PHONE
rem   CWRUSLIP.BAT file is used with PHONE.EXE to start a SLIP
rem   connection on CWRU-TS2

@echo off
cls
goto start

:start
if %1. == ?.         goto help
if %1. == help.      goto help
if %1. == setup.     goto setup
if %1. == dial.      goto forceD
if %1. == hangup.    goto forceH
if %1. == quit.      goto forceH
if %1. == HELP.      goto help
if %1. == SETUP.     goto setup
if %1. == DIAL.      goto forceD
if %1. == QUIT.      goto forceH
goto bogus

:forceH
termin 0x60
umslip >nul
phone force hangup

:slipper
termin 0x60
REM  the following line must be changed to reflect the COM port,
REM  IRQ, baud rate, and software interrupt
lh c:\packet\cslipper com1 vec=60 baud=57600 ether
goto end

:forceD
termin 0x60
umslip >nul
phone force dial
goto slipper

:setup
termin 0x60
umslip >nul
phone setup
goto help

termin 0x60
goto end

:bogus
echo %1 is not a valid command.
echo Try "cwruslip help" for a list of valid commands
echo.

:help
echo --------------------------------------------------------------
echo           Case Western Reserve University SLIP Setup
echo                  using Univ. of Minnesota PHONE
echo --------------------------------------------------------------
echo cwruslip setup     modem settings, phone number, username etc.
echo.
echo cwruslip dial      DIAL and establish the SLIP connection
echo cwruslip quit      HANGUP the phone and unload the driver
echo cwruslip help      this screen
echo.

:end
-- end CWRUSLIP.BAT --

B-3. How do I install packet drivers for Windows applications?

How do I install packet drivers for Windows applications?

The secret is to load the packet driver, then run Windows. If you
are running Trumpet Winsock, you will also have to load WINPKT
before running Windows, as follows:

winpkt 0x60

If you are running DOS applications within a virtual DOS session
follows:

PKTMUX 4 [or however many sessions you want]

Then within each DOS session, load PKTDRV, the virtual packet driver.

If you are running Trumpet Winsock along with other DOS apps in a
virtual DOS session, then you will need to load PKTDRV prior to

PKTMUX 4
PKTDRV 0x62
WINPKT 0x62
PKTDRV 0x60
WIN

TCPMAN will then find the virtual packet driver at 0x62.

B-4. When do I need to install  WINPKT?

PKTMUX and WINPKT both accomplish the same thing: allowing you to
connect to a DOS packet driver running in real mode from a virtual
DOS session under Windows. PKTMUX is useful when you are running
more than one TCP/IP stack, and since it takes up more RAM and is
slower than WINPKT, you should only use it when you want to run more
than one stack at a time. If you are running only one DOS app,
or are using Trumpet Winsock, stick with WINPKT.

James Harvey (harvey@iupui.edu) notes:
Winpkt is only useful running DOS applications with built-in TCP/IP
stacks under Windows, and for some Windows-based stacks (like the
Trumpet winsock.dll).  When an application registers with a packet
driver TSR to receive packets of a specified protocol type, one of the
things it hasto pass as a parameter to the packet driver in the call
is the address of a routine in the application that the packet driver
is to call when it has a packet to pass back to the application.  In
the case of an application running in 386 enhanced mode in a DOS shell
under Windows that is using a packet driver loaded in real mode before
Windows was loaded, the packet driver must ensure that Windows has the
application in memory when it does the callback, otherwise the callback
jumps off into space and your system locks up.  Winpkt does a Windows
system call to force the app into memory before the callback is done.

Erick Engelke (erick@development.uwaterloo.ca) notes:
Windows in enhanced mode uses the protected mode of the
386 CPU to create multiple virtual machines.  Winpkt tells
Windows to switch to the correct virtual machine before
trying to pass up the packet.  This reduces the chances of
Windows crashing.

B-5. How to do I run both WinQVT and ODI?

My advice is to use the Windows Sockets version of WinQVT/Net, Trumpet
Winsock, and ODIPKT. ODIPKT will allow you to run packet driver software
over ODI. You will also need to load WINPKT for Trumpet Winsock.

NE2000.COM [or other ODI driver]
IPXODI [IPX version supporting ODI]
NETX
ODIPKT 1 96
WINPKT 0x60
WIN [run windows]

Then run Trumpet Winsock, and load WinQVT/Net.

B-6. Is it possible to use BOOTP over SLIP?

Yes, but it is easier to use dynamic address assignment to get
before switching to SLIP.

If you need BOOTP, then you should run a BOOTP server on the SLIP
server so that it can tell which SLIP connection originated the
request. Of course, the BOOTP server will ignore the hardware address
of the request originator, but instead will keep track of the SLIP
interface the request came in on. See the question on adding BOOTP to
KA9Q for info on how to handle this on the PC. Under UNIX, you may
have to add BOOTP capability to your slip driver, and rebuild the
kernel. (Not recommended for the squimish).

B-7. How do SLIP drivers work?

Some TCP/IP applications are written to only support Class 1 (Ethernet)
packet drivers, but do not support Class 6 (SLIP). For these applications, you
need software to make the application think it is dealing with a class 1
SLIP or PPP packets and stripping the headers off outgoing packets.

B-8. When do I need to install PKTMUX?

PKTMUX is needed to allow you to use more than one TCP/IP stack at the same
time. This is useful if you have applications that require different stacks.
Note that you do not need PKTMUX to run different protocols, since packet
drivers only look at packets in the protocol they're designed to handle,
and therefore you can use more than one of these at a time without conflict.
You also don't need PKTMUX if all your applications use the same TCP/IP stack.

PKTMUX works by looking at outgoing datagrams, and caching information on
source and destination ports and addresses. Using this information, PKTMUX
tries to sort incoming datagrams by TCP/IP stack. If it can't figure out
which stack to send a datagram to (as might be the case if you were running
a server application on a well-known port, and had not sent any outgoing
packets yet), PKTMUX will send the datagram to all stacks. If all stacks
do not complain about the datagram, PKTMUX will throw away the ensuing outgoing
ICMP error message, assuming that one of the stacks correctly received
the datagram. If all stacks complain, it will send a single ICMP message
and throw the rest away.

While PKTMUX does its job very well, there are some situations that it cannot
handle, such as port conflicts. If two applications open the same TCP port,
chaos is inevitable, and there is little that PKTMUX can do to help.

B-9. Can NDIS be used underneath multiple protocol stacks of the same type?
No. There is no equivalent to PKTMUX for NDIS.

B-10. Is there an NDIS over packet driver shim?
Joe Doupnik writes:

"No. Packet Drivers work by having an application register
for a particular packet TYPE, such as 0800 for IP. NDIS works much
differently, by offering a peekahead of every packet to applications in turn,
a polling operation. The only way NDIS could gracefully sit on a PD would
be to run the Packet Driver in all-types mode and let NDIS see all pkts
not used by other clients. Needless to say, that's an undesirable situation.
The quick solution, costing about US$100 (at least at my place, more at yours) is a second Ethernet board in the client together with a second IP address (most important, please)." B-11. How do I run NetBIOS over TCP/IP? NetBIOS over TCP/IP is discussed in RFCs 1001 and 1002, which defines three types of NetBIOS nodes: * B nodes, which use UDP broadcast packets to distribute datagrams and resolve names. * P nodes, which use point-to-point communications and which require NetBIOS Datagram Distribution (NBDD) and NetBIOS Name Servers (NBNS). P nodes do not listen to or use broadcast services, so they cannot be used alongside B nodes. Unfortunately NBNS, and NBDD servers were not widely implemented, and those that do exist (such as an implementation from Network Telesystems) are not inexpensive. * M nodes, which use both point-to-point and broadcast. B node technology cannot be used on an IP internet without extensions, since UDP broadcast packets are not forwarded through routers. This is not a problem with use of NetBIOS over IPX/SPX, since in IPX/SPX broadcast packets are forwarded. However, until very recently, M and P node technology was not supported by popular TCP/IP implementations. For example, PC/TCP supports B node technology with extensions such as a broadcast file, host file, or DNS resolution of NetBIOS names. Windows NT and WFW TCP/IP uses an LMHOSTS file for resolving names. According to Chip Sparling of FTP Software: "From what I remember from our discussions of a few years ago, P nodes were only implemented by Ungermann Bass and 3COM (and they required you to use a NetBIOS name resolver which was non-rfc 1001, 1002 compliant), nobody did M nodes (as far as I remember) and PC-LAN, Lantastic and LanManager used B node. Also, if you did a P or M node it wouldn't be compatible with a B node NetBIOS. We decided that we could give the compatibility and functionality (routability) with a B node plus extensions implementation. So, that's what we did." Without implementation of M and P node technology, the only way to run over an IP internet is to to implement B node technology with extensions, as FTP Software does in PC/TCP. According to Chip, "one way to handle large numbers of hosts on multiple networks is to use the broadcast file extenstion. Instead of putting specific ip addresses in the broadcast file, use a subnet broadcast address like nnn.nnn.nnn.255. which will cover an entire subnet." Assuming you don't need any of the extensions to RFC NetBIOS Microsoft created to make NetBIOS work smoothly in a routed environment (available only in their IP stack), you can choose from a wide variety of commercial vendors. For example, FTP Software's PC/TCP includes RFC NetBIOS support; Performance Technologies has a NetBIOS that runs over packet drivers, as does Accton (LANSoft). If any other vendors are reading this, I'd love to have information on how *you* implement NetBIOS over TCP/IP, and whether you'll be supporting WINS, the new P-node technology name resolution service from Microsoft. WINS will be included in the next WFW TCP/IP release, which is currently in beta test and available for download from ftp.microsoft.com. Consult the beta release documentation for more information on this. B-12. How do I run NFS along with another TCP/IP application? The DOS NFS implementation by M. Durkin now supports a built-in packet multiplexer that can handle NFS plus another stack loaded simultaneously. If you need to load more stacks, then you will need to run PKTMUX as well. See the resource section for details. B-13. How do I run Trumpet Winsock along with KA9Q or NFS? The secret is to load WINPKT on top of the PKTDRV virtual packet driver, if you are running PKTMUX. B-14. Sample Stick Diagrams It has been proposed that we begin to collect some diagrams of working combinations of hardware, drivers, shims, stacks, and applications. I'm game, and have made a start below. If you've got some other exotic configuration that works (or if you've tried one of the configurations below and discovered it doesn't work, drop me a line). Running an individual DOS application under Windows NCSA telnet / DOS Trumpet / POPmail/ PC Gopher III | DOS Session | Windows 3.1 | WinPKT | Packet driver or Shim | DOS | Network Adapter DOS Trumpet, NCSA Telnet, and WinQVT/Net over Ethernet under Windows QVT/NET | TRUMPET NCSA telbin | | | | PKTDRV1 PKTDRVn | | | | DOS Session DOS Session Windows Session +-----------+-----------------+ | | | + | WINDOWS 3.1 ............. WINDOWS 3.1 | | | PKTINT(QVT/NET own) | | | PKTDRVx +-------------------------------+ PKTMUX n | Packet Driver or SHIM | DOS | Network Adapter PC Gopher III, NCSA Telnet over CSLIP under Windows PC Gopher III NCSA telbin | | PKTDRV1 PKTDRVn | | DOS Session DOS Session +-----------+-----------------+ | + WINDOWS 3.1 | | | | + PKTMUX n | CSLIPPER | DOS | Serial Port PC Gopher II and NetWare on a LAN - Alternative I [Didn't work for me, but it's supposed to be OK] NetWare PC Gopher | III | | | DOS Session NETX | | Windows 3.1 | | PDIPX WINPKT / \ / \ / \ / \ / Packet Driver | DOS | Network Adapter PC Gopher III and NetWare on a LAN - Alternative II PC-Gopher III | DOS Session | Windows 3.1 | | NetWare | \ / NETX WINPKT \ / IPXODI ODIPKT \ / \ / | Link Support Layer | ODI driver | DOS | Network Adapter WinQVT/Net and PC Gopher II and NetWare over a LAN - Alternative I PC Gopher III | Win QVT/Net PKTDRV1 | | | DOS session Windows 3.1 | | Windows 3.1 PKTINT (QVT/NET own) | | | PKTDRVn WinPKT | | | NetWare +----------------+ | | | | | PKTMUX n NETX | | \ PDIPX \ | \ | \ | \ | Packet Driver --------------+ | DOS | Network Adapter WinQVT/Net, PC Gopher III and NetWare over a LAN - Alternative II QVT/Net PC Gopher III NCSA telbin | | | | PKTDRV1 ..... PKTDRVn | | | | | DOS Session DOS Session Windows Session +-----------+-----------------+ | | | | | WINDOWS 3.1 .......................WINDOWS 3.1 | | | PKTINT(QVT/NET own) | | | PKTDRVx | | | | | | | | +------------------+------------+ | NetWare | \ / NETX PKTMUX n (use if >1 TCP/IP app) \ / IPXODI ODIPKT \ / \ / | Link Support Layer | ODI driver | Network Adapter PC Eudora and Windows Trumpet over CSLIP under Windows using Trumpet Winsock PC Eudora Windows Trumpet \ / \ / \ / \ / TCPMAN | Windows 3.1 | WINPKT 0x60 | DOS | Serial Port PC Eudora and Windows Trumpet supporting Ethernet and CSLIP under Windows using NDIS supporting stack [Chameleon] [Please note: this is not possible under Trumpet Winsock, since it can only handle a single interface; it requires a stack that routes] PC Eudora Windows Trumpet \ / \ / \ / \ / Chameleon NEWT | Windows v3.1 | +------------------+ | | Protocol Manager | | | NDIS Mac Driver Serial Port | DOS | Ethernet card PC Eudora, Windows Trumpet, and KA9Q under Windows WinTrump PC Eudora \ / \ / KA9Q \ / | | PKTDRV TCPMAN \ | \ / \ / \ / \ / Windows | PKTDRV 0x62 | PKTMUX 2 | Packet Driver | DOS | Ethernet Card HGopher, PC Eudora, and WinTrumpet Under Windows (Whether the TCP/IP stack is loaded before or after Windows depends on the stack) HGopher | | PC | Eudora | WinTrumpet \ | / \ | / \ | / \|/ TCPMAN | Windows 3.1 | WINPKT | Packet Driver | DOS | Ethernet Card B-15. Strange and wonderful configuration files submitted by readers Robert Clift (clifta@sfu.ca) writes: "I have WinQVT/Net 3.4, PC Gopher III (including NCSA DOS Telnet), KA9Q (gopher and FTP server), and POPMail all running together under Windows over PKTMUX on a 3C503 packet driver (and Ethernet card)." Here is the stick diagram (yikes!): Win/QVTNet 3.7 KA9Q Gopher PC POPMail 3.2 PC Gopher III 1.01 on interrupt 65 & FTP Server \ / \ | \ / \ | \ / \ | \ / \ PKTDRV PKTDRV \ | / \ DOS Session DOS Session \ | / \ | ------------------- \ | / Windows 3.1 | PKINT | PKTDRV on Int 65 no listeners set | PKTMUX 1.2 with 3 channels | Clarkson 3C503 Packet Driver | DOS | 3Com Etherlink II/16 TP | Ethernet NOTES: Win/QVTNet must be loaded as the very first Windows application and must be kept operating as long as your are in Windows. It appears that its TCP/IP stack does some strange things when it disconnects and kills access to the actual packet driver. I run PC gopher and POPMail alternatively, so they share one channel which is allocated via PKTDRV before running the application and deallocated after the application is finished (I usually throw in a reset command to PMTMUX as well just to be safe). To explain what is happening (as best I can since a lot of this came from experimentation): 1. The packet driver is loaded 2. PKTMUX is run over the packet driver in order to multiplex it (in this case three channels). 3. A virtual packet driver is loaded for Win/QVTNet on interrupt 65 and the packet driver is told that it is not to listen for any server requests. 4. PKINT is loaded over top of the virtual packet driver 5. Start Windows and run Win/QVTNet as the first application, it must be kept running throughout the Windows session. 6. Load a virtual packet driver from a DOS session and start KA9Q. I use the following batch file to do this: c:\network\pktdrv 63 /l h: cd \ net091b c:\network\pktdrv 63 /uu c:\network\pktmux /r 7. Load a virtual packet driver and run PC Gopher or POPMail as needed. I use the following batch files for PC Gopher and POPMail respectively: c:\network\pktdrv 63 h:\goph-cli\gopher /T=h:\goph-cli\text /X=h:\goph-cli\binary c:\network\pktdrv 63 /uu c:\network\pktdrv 66 /c h:\popmail\popmail /noems c:\network\pktdrv 66 /uu 8. The only problem seems to be that the NNTP module in Win/QVTNet will not operate correctly if POPMail is operating. Otheriwse it seems to work okay without too many problems. C. KA9Q Questions C-1. What version of KA9Q should I use and where do I get it? There are so many releases of KA9Q that it is a significant amount of work just to keep track of them all. This has occurred partly because KA9Q does not support extended or expanded memory, and therefore many people have needed to customize it with the features relevant to them in order to allow it to do what they want as well as fit into memory. The primary difference among the various releases is whether they include code for a BBS, packet radio support (AX.25), synchronous cards (for use with leased lines), NNTP, CSO or Gopher servers, packet filtering, DNS, RIP or PPP support. The three primary KA9Q releases at this time are those managed by Ashok Aiyar (ashok@biochemistry.bioc.cwru.edu), those put out by Demon Internet Services (DIS), and the JNOS distribution. JNOS is the primary packet radio- oriented release; the other two major releases do not include AX.25 support. Since JNOS does not include several features important to non-packet radio users (DNS/Gopher/CSO server, hop check), try one of the other two releases if you're not interested in packet radio. Ashok's release is based on the N1BEE 0.85-beta which in turn is based on PA9GRI 2.0m NOS. Version 11c includes support for NTP, CSO, gopher, FTP, FINGER, HTTP and SMTP/POP2/POP3 servers, plus VT102 and packet filtering support. Please not that this release does *not* include radio or synchronous card support, unlike the standard KA9Q release, and only support SLIP/CSLIP. Also, there is no DNS server support, and the tip command has been removed, so that you need to use an external dialer to make the connection. Available as: file://biochemistry.bioc.cwru.edu/pub/nos/nos11c.exe, nos11c.txt, nos11c.map, nos192.txt, nos_1229.man, vt102.zip, filter.txt, autoexec.nos The TextWin version from Demon Internet Services includes support for DNS server, packet filtering, FTP, SMTP/POP2/POP3 servers, NNTP server, VT102 support, NTP, BBS, SLIP/CSLIP,PPP (I don't know anyone who has gotten this to work), demand dial, ping, hop check (traceroute equivalent). From mike@childsoc.demon.co.uk (Michael Bernardi): "Demon Internet Services have a dialin Internet service in the UK. They also support a customised version of KA9Q optimised for dialup, they also support the PCElm mailer, SNEWS news reader and a customised front end. There is also a combined NEWS and MAIL program called CPPNEWS and an alternative MAIL program called VIEW, these last are unsupported by Internet@demon.co.uk but other DIS users do support them. All these programs can be found on ftp.demon.co.uk in the pub/ibmpc/ directory, and are written to work with KA9Q (specifically the DIS version)." Anthony McCarthy has added a multi-windowing system to KA9Q that supports the mouse, which has been recommended. See Resource listings for info. The DIS release includes three versions, small, medium and large. The large version includes everything but the kitchen sink, including an NNTP server. I also believe it includes the KA9Q BBS code, and radio support. Editorial: To my mind, the time has come for the major releases to combine their code bases and produce a version with the best features of all of them. To my mind, the ideal KA9Q release would be a release combining the improved server support of the CWRU release with a working PPP implementation, demand dial, and DNS server support. C-2. What do I need to run KA9Q? Why won't it do VT-100 emulation? KA9Q is usually run from a startup script, such as my script startnos.bat: \nos\drivers\8003pkdr \nos\net -d \nos Here I first load the packet drivers for my 8003 Ethernet card, then run KA9Q (known as net.exe). The KA9Q package then reads commands from a configuration file, called AUTOEXEC.NOS in some implementations, AUTOEXEC.NET in others. For VT100 emulation with KA9Q, try using Giles Todd's VT102.COM, available via ftp from ftp.demon.co.uk, cd /pub/ibmpc/DIS. C-3. How do I configure KA9Q as a SLIP dialup connection? Here is a sample CSLIP only configuration file: # Set the host name # hostname aboba.slip.netcom.com ip address [192.187.134.3] # # # # Configure COM3 on Interrupt 5, at 38400 bps with # RTS/CTS (c) and Van Jacobson Compression (v) and MTU = 1008 # attach asy 0x3e8 5 VJSLIP sl0 8092 1008 38400 cvj ifconfig sl0 netmask 255.255.255.252 # # # route add default sl0 # route all packets over sl0 by default (sl0 is the route to # the Internet) # # Time To Live is the maximum number of hops a packet can take # before it is thrown away. This command prevents an inadvertent # infinite loop from occuring with packets in the network. # ip ttl 255 # #------------------------------------------------- # # The Maximum Segment Size is the largest single transmission that # you care to receive. An mss of 216 will force folks to send you # packets of 256 characters or less (counting the overhead). # tcp mss 1048 # #------------------------------------------------- # # The Window parameter establishes the maximum number of bytes that # may be outstanding before your system expects an ack. If window is # twice as big as mss, for example, there will be two active packets # on the channel at any given time. Large values of window provide # improved throughput on full-duplex links, but are a problem on the # air. Keep mss <= window <= 2*mss if you're on the air. # # tcp window 6888 # #------------------------------------------------- # # This entry will open net.log in the \spool directory and will # record the server activity of your system. If you don't want a log, # comment out this line; if you do, make sure you have a \spool # directory! # log \spool\net.log # #------------------------------------------------- # # Each of the servers (services you will provide) must be turned # on before they will be active. The following entries turn all # of them on. To turn any function off use the command 'stop' after # NET gets fired up, or just comment out the line here. # start ftp start echo start discard #start telnet start smtp # isat on # domain addserver 192.100.81.101 domain addserver 192.100.81.105 smtp gateway 140.174.7.1 # # # Display Name and IP Address # hostname ip address # # Just for yucks, lets try calling the other end. comm sl0 atdt14082411528 # THE END After executing this setup file, if your version of KA9Q supports the comm command you should hear the modem dial out to your SLIP host. Enter TIP sl0 at the prompt to be connected to the SLIP interface. You will then see your hosts's login prompt. Give the login name and password, and when you go into SLIP mode, hit F10 to get back to the prompt. Note that newer versions of KA9Q may not be compatible with the comm command, since they support more sophisticated dialing scripts. Type RESET 1 at the prompt. This moves session 1 from tip mode into SLIP mode. Type another RESET to kill any residual processes that may be operating. At this point you should have a functioning connection. You might try to ping your host via the command: PING <host adddress> If this works, you will then see the round trip time to your host, in milliseconds. Other possible diagnostic commands: ASYSTAT <interface> Gives statistics on packets received, sent, etc. TRACE <interface> 1011 Shows incoming characters RIP TRACE 1 Traces RIP packets HOP CHECK <address> Traces the route to the designated system. Useful for figuring out routing problems. C-4. How do I configure KA9Q as a router? The KA9Q configuration that follows uses two interfaces, one a CSLIP interface to an annex terminal server (sl0), the other an Ethernet interface (lan) with another machine (a NeXT) attached. Note the use of Van Jacobson compression (v) on the slip line, as well as the strange interrupt settings (Interrupt 5, port is COM3). One of the nice things about KA9Q is that it is flexible enough to deal with such situations. Here is a sample router configuration file: # Set the host name # hostname gate.slip.holonet.net # # # Configure COM3 on Interrupt 5, at 38400 bps with # RTS/CTS (c) and Van Jacobson Compression (v) # attach asy 0x3e8 5 VJSLIP sl0 8092 576 38400 cv ifconfig sl0 ipaddress [157.151.0.253] netmask 255.255.255.0 # # FTP, Inc., compatible packet driver installed at software interrupt number # 0x60; probably an Ethernet card of some kind. # attach packet 0x60 lan 2 1500 ifconfig lan ipaddress [157.151.64.1] netmask 255.255.255.0 # route add default sl0 # The local Ethernet has a Class C network address so # route all IP addresses beginning with 157.151.64 to it. route add 157.151.64/24 lan # # # Time To Live is the maximum number of hops a packet can take # before it is thrown away. This command prevents an inadvertent # infinite loop from occuring with packets in the network. # ip ttl 400 # #------------------------------------------------- # # The Maximum Segment Size is the largest single transmission that # you care to receive. An mss of 216 will force folks to send you # packets of 256 characters or less (counting the overhead). # tcp mss 576 # #------------------------------------------------- # # The Window parameter establishes the maximum number of bytes # that may be outstanding before your system expects an ack. # If window is twice as big as mss, for example, there will be two # active packets on the channel at any given time. Large values of # window provide improved throughput on full-duplex links, but are a # problem on the air. Keep mss <= window <= 2*mss if you're on the air. # # tcp window 6888 # #------------------------------------------------- # # This entry will open net.log in the \spool directory and will # record the server activity of your system. If you don't want a log, # comment out this line; if you do, make sure you have a \spool # directory! # log \spool\net.log # #------------------------------------------------- # # Each of the servers (services you will provide) must be turned # on before they will be active. The following entries turn all # of them on. To turn any function off use the command 'stop' after # NET gets fired up, or just comment out the line here. # start ftp start echo start discard #start telnet start smtp # isat on # domain addserver 157.151.0.2 domain addserver 157.151.0.1 smtp gateway 157.151.0.2 # # # Use Router Information Protocol (RIP) to inform the router at # 157.151.0.253 about the existence of the local network. Send # RIP packets every 240 seconds. rip add 157.151.0.253 240 # # # Just for yucks, lets try calling the other end... # comm sl0 atdt7041063 # # THE END Here is another routing configuration file, using proxy arp: # Set the host name # hostname gate.slip.holonet.net # # # Configure COM3 on Interrupt 5, at 38400 bps with # RTS/CTS (c) and Van Jacobson Compression (v) # attach asy 0x3e8 5 VJSLIP sl0 8092 576 38400 cv ifconfig sl0 ipaddress [157.151.0.253] netmask 255.255.255.0 # # FTP, Inc., compatible packet driver installed at software interrupt number # 0x60; probably an Ethernet card of some kind. # attach packet 0x60 lan 2 1500 ifconfig lan ipaddress [157.151.64.1] netmask 255.255.255.0 # # Set Routing Tables # # route add default sl0 # The local Ethernet has a Class C network address so # route all IP addresses beginning with 157.151.64 to it. route add 157.151.64/24 lan # # Use Proxy ARP # arp publish 157.151.64.1 ether 00:00:c0:33:f3:13 arp publish 157.151.64.254 ether 00:00:c0:33:f3:13 # # For PC AT # isat on # # Add Domain Name Servers # domain addserver 157.151.0.2 domain addserver 157.151.0.1 smtp gateway 157.151.0.2 # # # Time To Live is the maximum number of hops a packet can take # before it is thrown away. This command prevents an inadvertent # infinite loop from occuring with packets in the network. # ip ttl 400 # #------------------------------------------------- # # The Maximum Segment Size is the largest single transmission that # you care to receive. An mss of 216 will force folks to send you # packets of 256 characters or less (counting the overhead). # tcp mss 576 # #------------------------------------------------- # # The Window parameter establishes the maximum number of bytes # that may be outstanding before your system expects an ack. # If window is twice as big as mss, for example, there will be two # active packets on the channel at any given time. Large values of # window provide improved throughput on full-duplex links, but are a # problem on the air. Keep mss <= window <= 2*mss if you're on the air. # # tcp window 6888 # #------------------------------------------------- # # This entry will open net.log in the \spool directory and will # record the server activity of your system. If you don't want a log, # comment out this line; if you do, make sure you have a \spool # directory! # log \spool\net.log # #------------------------------------------------- # # Each of the servers (services you will provide) must be turned # on before they will be active. The following entries turn all # of them on. To turn any function off use the command 'stop' after # NET gets fired up, or just comment out the line here. # start ftp start echo start discard #start telnet start smtp # # Display Name and IP Address # hostname ip address # # Just for yucks, lets try calling the other end. comm sl0 atdt7041063 # THE END C-5 How do I get KA9Q to support BOOTP? The CWRU NOS version has a working BOOTP client and server built-in, and is the best version if you are looking for BOOTP support. If you are using another version of KA9Q that does not support BOOTP, try the following: Steven L. Johnson (johnson@TIGGER.JVNC.NET) notes: KA9Q does have a bootp client but it is not compiled in by default. It has a bug that truncates the returned ip address to 16 bits which must be corrected before it will work. It also complains about bootp servers that only support RFC 951 bootp without RFC 1084 (or 1048) vendor extensions. Other than that it seems to work for me. To enable the bootp client, add the following line to config.h: #define BOOTP 1 To correct the ip address truncation problem, in bootp.c change: Ip_addr = (int) reply.yiaddr.s_addr; /* yiaddr */ ^^^^^problem at line 188 to: Ip_addr = (int32) reply.yiaddr.s_addr; /* yiaddr */ ^^^^^^^solution And of course, recompile. This worked on the src1229 (1991) version and may work on the most recent version. I did check to make sure that the bug still exists, but I haven't rechecked whether there are additional problems in the new version. C-6. How do I get KA9Q to support PPP? Although I haven't gotten this to work yet, there is hope. The only major version of KA9Q supporting PPP is the TextWin version. Here is a sample ppp configuration file for it: # Set the host name # hostname aboba.slip.netcom.com ip address [192.187.134.3] # # # # Configure COM3 on Interrupt 5, at 38400 bps with # MTU = 1008 # attach asy 0x3e8 5 ppp pp0 8092 1008 38400 dialer pp0 dialer.ppp ifconfig pp0 netmask 255.255.255.252 ppp pp0 trace 2 ppp pp0 quick ppp pp0 lcp open ppp pp0 ipcp open # # # route add default pp0 # route all packets over pp0 by default (pp0 is the route to # the Internet) # # Time To Live is the maximum number of hops a packet can take # before it is thrown away. This command prevents an inadvertent # infinite loop from occuring with packets in the network. # ip ttl 400 # #------------------------------------------------- # # The Maximum Segment Size is the largest single transmission that # you care to receive. An mss of 216 will force folks to send you # packets of 256 characters or less (counting the overhead). # tcp mss 1048 # #------------------------------------------------- # # The Window parameter establishes the maximum number of bytes that # may be outstanding before your system expects an ack. If window is # twice as big as mss, for example, there will be two active packets # on the channel at any given time. Large values of window provide # improved throughput on full-duplex links, but are a problem on the # air. Keep mss <= window <= 2*mss if you're on the air. # # tcp window 6888 # #------------------------------------------------- # # This entry will open net.log in the \spool directory and will # record the server activity of your system. If you don't want a log, # comment out this line; if you do, make sure you have a \spool # directory! # log \spool\net.log # #------------------------------------------------- # # Each of the servers (services you will provide) must be turned # on before they will be active. The following entries turn all # of them on. To turn any function off use the command "stop" after # NET gets fired up, or just comment out the line here. # start ftp start echo start discard #start telnet start smtp # isat on # domain addserver 192.100.81.101 domain addserver 192.100.81.105 smtp gateway 140.174.7.1 # # # Display Name and IP Address # hostname ip address # # THE END In file dialer.ppp: control down wait 1000 control up wait 1000 wait 2000 send "at\r" wait 3000 "OK" send "atdt8659004\r" wait 60000 "login: " send "<userID>\r" wait 5000 "word:" wait 1000 send "<password>\r" C-7. How do I get KA9Q to support SLIP dialin? If you are willing to settle for little or no security, there is not much you have to change to allow a KA9Q system to receive calls, as opposed to originating them. These should include: 1. Setting the system to autoanswer, via use of the ATS0=1 command to the modem. 2. Setting up a trace on the router end, to figure out if it's working, via the command: TRACE <interface> 1011, where <interface> = sl0 for SLIP, or another value such as LAN or ether0 for the Ethernet interface. It's probably a good idea to put a trace on all interfaces until the system is shaken down. Note that without addition of a special dialing script, this setup is completely insecure! C-8. Can I use KA9Q as a packet filter? Yes! Both the TextWin Large and CWRU NOS versions support this. You can filter by incoming or outgoing, TCP or UDP port number, IP address, SYN bit on, etc. D. Hints for particular packages D-1. How do I get DesQView X to run over the network? V1.0 of DesQView X did not include a TCP/IP protocol stack. Surprise! It required a TCP/IP implementation such as Beame & Whiteside, PC-NFS, FTP's PC/TCP, or Novell LWP. They've corrected the situation in subsequent revisions. Contact QuarterDeck for assistance. [pricing and availability, anyone?] D-2. Why is NFS so slow compared with FTP? NFS usually runs over RPC via UDP, rather than utilizing TCP. NFS only acknowledges a write request when the disk completes; there are no sliding windows as in TCP. This makes NFS fairly inefficient. Frances K. Selkirk (fks@vaxeline.ftp.com ) notes: "There are NFS implementations that use TCP. They are only faster over WANs. UDP is faster over most normally functioning LANs. The lockstep paradigm is inherent to NFS, but some implementations provide the ability to violate it - a speed win when the net is reliable, a loss when it is not. Whatever the transport, NFS will have more overhead than TCP, because it is trying to transparently imitate an OS, and has to do a lot of shuffling and translating." D-3. Where can I get information on running NetWare and TCP/IP concurrently? The bit.listserv.novell group regularly posts a FAQ which includes information on concurrent use of TCP/IP and Novell IPX. D-4. What NetWare TCP/IP NLMs are out there and how do I get them to work? A public and known to work reliable TFTP and BOOTP daemon for NetWare OS 3.1x/4.0x and NetWare/IP are available from ftp.novell.de at ~/pub/netwire/unsupported/server/bootpd.exe. Contact: dirk@rhein-main.de D-5. How do I get a telecom package supporting Int 14h redirection to work? INT 14 is the BIOS serial port interrupt. "Int 14h redirection" means that Interrupt 14 is redirected to a Telnet connection to a particular host. This is useful because it allows a communications application to readily support telnet. Int 14h support is becoming increasing common, with vendors such as Mustang (QMODEM Pro) and Procomm Plus for networks having included this feature. Aside from commercial stacks (such as FTP's PC/TCP), try the TCPPORT program in WATTCP, available via ftp dorm.rutgers.edu, get /pub/msdos/wattcp/apps.zip. However, I have tried to get this to run with QMODEM Pro and found that I didn't have enough RAM. FTP's PC/TCP includes a program called tnglass that supports Int 14h redirection. D-6. How do I run SLIP/PPP with Windows For Workgroups TCP/IP? Rumour has it that there is a serial NDIS driver available called NBR11. This is available via ftp complab.gtri.gatech.edu, cd /pub/lanman/ndis. D-7. How do I get Windows For Workgroups to work alongside NetWare? ODINSUP from Novell is an NDIS over ODI shim. This allows you to run software requiring ODI drivers, as well as software requiring NDIS drivers. Since IPX and TCP/IP are different protocols, you will not need to run PKTMUX. Available via ftp.novell.com, cd /netwire/novfiles/client.kit/doswin/files/WSDOS1.EXE. D-9. How come package X doesn't support the AppleTalk packet driver? An AppleTalk driver is available as appletlk.com as part of the Crynwr driver set. NCSA Telnet 2.3.03 and NuPOP support it, but very few other applications do, including Trumpet Winsock. This is because AppleTalk corresponds to packet driver class 5, while most applications only support Class 1 (Ethernet). Vendors with Windows Sockets implementations that support AppleTalk include FTP Software's PC/TCP. WinQVT/Net's built-in TCP/IP stack version is also rumored to be due to support AppleTalk in a future release. D-10. NCSA Telnet doesn't reassemble fragments. What should I do? Yell at the folks at NCSA to fix the problem, and to notify all the people who are using the same TCP/IP code to insert the fix in their software as well. This problem is really common, and very annoying, and affects NCSA Telnet as well as PC Gopher III, and POPmail. One possible workaround is to set the MTU to 576, but this will not always work. The following solution has been provided by Matthew T Kaufman (matthew@echo.com): How to get rid of the message: "IP: fragmented packet received, frags not supported" (assuming you have a C compiler and source code) by Matthew T Kaufman (matthew@echo.com) Many people on the net have complained that NCSA Telnet (among other useful PC TCP/IP programs) doesn't properly handle fragmented IP packets. this problem becomes especially evident if any of your packets are arriving over SLIP connections. I figured that the fastest way to get it to work would be to go ahead and do it myself rather than wait for it to get to the top of the list of desired features. MANY other programs have used the NCSA TCP/IP implementation, so if you maintain a program which does, PLEASE add this fix. I (and MANY OTHERS) are unable to use your software until you do. I posted the basic form of this fix around the beginning of the year, but it didn't seem to make it into several subsequent versions of related software, so I am posting and mailing this once again, in a revised form, with helpful hints at the end. I request only the following in return: This software revision is in the public domain. It may be used anywhere without further permission from the author. Please credit the origin of the fix in your release notes or bug fix document. (I am "Matthew Kaufman, matthew@echo.com") If you are the official maintainer of a software package which you have added this fix to, please send me an email note letting me know that the fix made it in. (So I don't need to worry that, for instance, the next version of NCSA Telnet or WinQVT/Net isn't going to include this) And, please add this fix as soon as possible. So here's my fix: The following are the changes to the NCSA Telnet TCP/IP engine to add support for IP fragment reassembly. I also know how to make telnet compile properly under Borland C without running out of space in DGROUP (see the end of this) if you have any questions, you can reach me at: matthew@echo.com. I am willing to help, within the limits of my schedule. changes follow: file: engine\ip.c (the only file that needs to change) delete the following: >/* >* We cannot handle fragmented IP packets yet, return an error >*/ > > if(p->i.frags &0x20) { /* check for a fragmented packet */ > netposterr(304); > return(1); > } ---------- after the line: > iplen-=hlen; but before the lines: > /* > * check to make sure that the packet is for me. add this: /* check for fragment and handle. note that the &0x20 above is WRONG */ if(p->i.frags) /* NOW check for a fragmented packet - mtk add*/ { ipfraghandle(p,iplen); /* pass in computed iplen to save time */ return(1); } ---------- and then, at the end of that file (ip.c) add this: /* * IP Fragment Reassembly Hack * by Matthew T Kaufman (matthew@echo.com) * 1/1993, 8/1993 */ typedef struct ipb { DLAYER d; IPLAYER i; uint8 data[4104]; /* "Big Enough" */ }FIPKT; #define IPF_CHUNKS 513 /* 4104 / 8 */ #define IPF_BITWORDS 18 /* 513 / 32 round up + 1*/ #define IPF_BUFFERS 7 /* Max # of different fragmented pkts in transit */ typedef struct { FIPKT pkt; unsigned long bits[IPF_BITWORDS]; int lastchunk; unsigned long lasttime; unsigned int iplen; }FPBUF; static FPBUF far Frag[IPF_BUFFERS]; ipfraghandle(IPKT *p, int iplen) { uint16 fraginfo; uint16 foffset; uint16 iden; FPBUF far *buf; int i; fraginfo = intswap(p->i.frags); foffset = fraginfo & (0x1fff); #define morefrags (fraginfo & (0x2000)) iden = intswap(p->i.ident); /* we already KNOW that this IS fragmented */ /* see if we can find any friends who've already arrived... */ buf = (FPBUF *) 0L; for(i=0; i<IPF_BUFFERS; i++) { if(p->i.ident == Frag[i].pkt.i.ident) { buf = &(Frag[i]); goto foundfriend; } } /* otherwise, we must be the first one here */ { long oldtime = 0x7fffffff; int oldest = 0; for(i=0; i<IPF_BUFFERS; i++) { if(Frag[i].lasttime == 0) /* unused buffer? */ { buf = &(Frag[i]); goto foundempty; } if(Frag[i].lasttime < oldtime) /* track LRU */ { oldtime = Frag[i].lasttime; oldest = i; } } /* if we're here, we need to reuse LRU */ buf = &(Frag[oldest]); foundempty: ; /* initialize new buffer */ /* time will be filled in later */ for(i=0; i<IPF_BITWORDS; i++) buf->bits[i] = 0L; /* reset */ buf->lastchunk = 0; /* reset */ /* fill in the header with the current header */ movmem(p,&(buf->pkt), sizeof(DLAYER) + sizeof(IPLAYER) ); } foundfriend: ; /* now, deal with this specific fragment... */ /* copy data */ movmem(&(p->x.data),&(buf->pkt.data[8 * foffset]),iplen); /* update rx chunks information */ for(i=foffset; i<= (foffset+(iplen / 8)); i++) { buf->bits[i/32] |= (unsigned long) (1L<<(i % 32)); } if(!morefrags) { /* now we can tell how long the total thing is */ buf->iplen = (8*foffset)+iplen; buf->lastchunk = foffset; /* actually, lastchunk is more than this, but it */ /* IS true that we only need to check through */ /* this foffset value to make sure everything has */ /* arrived -mtk */ } /* now touch the time field, for buffer LRU */ buf->lasttime = clock(); /* check to see if there are fragments missing */ if(buf->lastchunk == 0) { /* we haven't even gotten a fragment with a cleared MORE */ /* FRAGMENTS flag, so we're missing THAT piece, at least */ return 1; } for(i=0; i<= buf->lastchunk; i++) { /* scanning to see if we have everything */ if(0 == ((buf->bits[i/32]) & (unsigned long)(1L<<(i % 32))) ) { return 1; /* still waiting for more */ } } /* otherwise, done waiting... use the packet we've gathered */ /* first clear stuff from fragment buffer: */ buf->lasttime = 0L; /* mark as free to take */ buf->lastchunk = 0; /* need to do this, because we use it as flag */ buf->pkt.i.ident = 0; /* so we don't find this later */ buf->pkt.i.frags = 0; /* in case anybody above us checks */ /* then send it on its way... */ if(!comparen(nnipnum,p->i.ipdest,4)) { /* potential non-match */ if(comparen(nnipnum,junk,4) && p->i.protocol==PROTUDP) return(udpinterpret((UDPKT *)p,iplen)); return(1); /* drop packet */ } /* end if */ switch (buf->pkt.i.protocol) { /* which protocol */ case PROTUDP: return(udpinterpret((UDPKT *)&(buf->pkt),buf->iplen)); case PROTTCP: return(tcpinterpret((TCPKT *)&(buf->pkt),buf->iplen)); case PROTICMP: return(icmpinterpret((ICMPKT *)&(buf->pkt),buf->iplen)); default: netposterr(303); return(1); } } *** helpful hint: if you run out of space in DGROUP, its because your compiler doesn't place each 'far' data object in its own segment. To make things work, you need to make the raw packet buffer be in its own segment. Here's how: in include/pcdefs.h search for: --> unsigned char far raw[17000]; (the 17000 might be some other number... smaller, if someone tried to fix this before) and change to --> unsigned char far raw[17000]={0,0}; /* force into own segment */ E. Information for developers E-1. What publicly distributable TCP/IP stacks are there that I can use to develop my own applications? In writing an application, you can use device drivers provided by particular vendors, or you can opt for an Application Binary Interface (ABI) that supports multiple TCP/IP protocol stacks, such as Winsock. For a given version of Windows, Winsock is an ABI for both Windows 3.x and Windows NT (via the NT Win16 subsystem). Device drivers are included with PC-NFS and Beame & Whiteside's BW-TCP. Free examples of ABIs are the WATTCP API, the NCSA API (public domain), the Trumpet ABI from Peter Tattum, and the NuPOP ABI. All major TCP/IP vendors have by now implemented Windows Sockets. E-2. Where can I get a copy of the Windows Sockets FAQ? A separate developer-oriented FAQ file about Windows Sockets created by Mark Towfiq is available on SunSite.UNC.EDU:/pub/micro/pc-stuff/ms-windows/winsock/FAQ and Microdyne.COM:/pub/winsock/FAQ An alternative source for the FAQ is ftp.microsoft.com. ------------------------------ END OF PART 1 ------------------------ Please send comments to: Bernard Aboba Author of: The Online User's Encyclopedia, Addison-Wesley, 1993 The PC-Internet Connection, Publisher's Group West, 1994 email: aboba@netcom.com WWW page: http://www.zilker.net/users/internaut/index.html  -----------[000189][next][prev][last][first]---------------------------------------------------- Date: Sat, 9 Jul 1994 17:40:01 GMT From: aboba@netcom.com (Bernard Aboba) To: comp.protocols.tcp-ip.ibmpc,comp.protocols.tcp-ip,comp.answers,news.answers Subject: comp.protocols.tcp-ip.ibmpc Frequently Asked Questions (FAQ), part 2 of 3  Archive-name: ibmpc-tcp-ip-faq/part2 comp.protocols.tcp-ip.ibmpc: FAQ Posting, part 2, 7/1/94 *********** QUICKIE Guide to Useful Stuff ************ Drivers Packet drivers: file://oak.oakland.edu/pub/msdos/pktdrvr/pktd11.zip file://oak.oakland.edu/pub/msdos/pktdrvr/pktd11c.zip Packet specs: file://vax.ftp.com/pub/packet-d.ascii NDIS specs: file://vax.ftp.com/pub/ndis-mac.v101.txt file://vax.ftp.com/pub/ndis-mac.v201.txt ODI driver info: file://sjf-lwp.novell.com/anonymous/dev_docs/lan_drv/*, ODI Protocol stack info: file://sjf-lwp.novell.com/anonymous/dev_docs/pstacks/* Slipper: file://ftp.utas.edu.au/pc/trumpet/slipper/slipper.zip PKTMUX: file://dorm.rutgers.edu/pub/msdos/wattcp/pktmux12.exe EtherPPP: file://merit.edu/pub/ppp/etherppp.zip GoSLIP: file://ftp.cdrom.com/.5/cica/winsock/goslip11.zip ODIPKT: file://hsdndev.harvard.edu/pub/odipkt/odipkt.com Config file: file://hsdndev.harvard.edu/pub/odipkt/net.cfg Readme file: file://hsdndev.harvard.edu/pub/odipkt/readme Winsock Applications Trumpet Winsock: file://biochemistry.bioc.cwru.edu/pub/trumpwsk/winsock.zip file://ftp.utas.edu.au/pc/trumpet/winsock/winsock.zip file://biochemistry.bioc.cwru.edu/pub/trumpwsk/winapps.zip file://ftp.utas.edu.au/pc/trumpet/winsock/winapps.zip Trumpet Newsreader: file://biochemistry.bioc.cwru.edu/pub/wintrumpet/wtwsk10z.zip HGopher: file://lister.cc.ic.ac.uk/pub/wingopher/hgopher2.4.zip Voice Chat: file://ftp.cica.indiana.edu/pub/pc/win3/winsock/IVC10.ZIP PCEudora: file://ftp.cdrom.com/.5/cica/winsock/eudora14.exe WinFTP: file://ftp.cdrom.com/.5/cica/winsock/winftp.zip WinTalk: file://ftp.cdrom.com/.5/cica/winsock/wtalk11.zip GoSLIP: file://ftp.cdrom.com/.5/cica/winsock/goslip11.zip 3270: file://ftp.ccs.queensu.ca/pub/msdos/tcpip/qws-3270.zip PhWIN: file://ftp.cdrom.com/.5/cica/winsock/phwin22.zip FTP client: file://ftp.usma.edu/pub/msdos/winsock.files/ws_ftp.zip EINet WAIS: file://ftp.einet.net/einet/pc/EWAIS200.ZIP Finger: file://ftp.cica.indiana.edu/pub/pc/win3/winsock/finger31.zip Dialer: file://ftp.cica.indiana.edu/pub/pc/win3/util/dialexe.zip WinQVTNet: file://biochemistry.cwru.edu/pub/qvtnet/ Mosaic: file://ftp.ncsa.uiuc.edu/PC/Mosaic/wmos20a5.zip, win32s.zip, readme.now WinTelnet: file://ftp.ncsa.uiuc.edu/Telnet/windows/executables/wtel1b1.zip MPEG Viewer: file://ftp.ncsa.uiuc.edu/PC/Mosaic/viewers/mpegw32c.zip Windows Quicktime: file://lister.cc.ic.ac.uk/pub/wingopher/viewers/movies/qtwplay.zip Windows sound player: file://lister.cc.ic.ac.uk/pub/wingopher/viewers/audio/wnplny09b.zip Cello: file://ftp.law.cornell.edu/pub/LII/Cello/cello.zip, cellofaq.zip Viewers: file://ftp.law.cornell.edu/pub/LII/Cello/viewers.zip Windows W3 server: file://sunsite.unc.edu/pub/micro/pc-stuff/ms-windows/winsock/apps/serweb03.zip JPEG Viewer: file://ftp.law.cornell.edu/pub/LII/Cello/lview31.zip GIF Viewer: file://ftp.law.cornell.edu/pub/LII/Cello/wingif14.zip Wham viewer: file://ftp.law.cornell.edu/pub/LII/Cello/wham131.zip Ghostscript: file://ftp.law.cornell.edu/pub/LII/Cello/gswin.zip X Windows Demo: file://ftp.cica.indiana.edu/pub/pc/win3/uploads/xwindemo.zip Windows NT servers W3 server: file://emwac.ed.ac.uk/pub/https/HSI386.ZIP WAIS server: file://emwac.ed.ac.uk/pub/waistool Gopher server: file://emwac.ed.ac.uk/pub/gophers/GSI386.ZIP FTP server: file://sunsite.unc.edu/pub/micro/pc-stuff/ms-windows/winsock/apps/nt-ftpd.zip DOS Applications Minuet: file://boombox.micro.umn.edu/pub/pc/minuet/latest/minuarc.exe, install.txt PC-Pine: file://ftp.cac.washington.edu/mail/PC-PINE/pcpine_p.zip NCSA Telnet: file://merit.edu/pub/ppp/pc/ncsappp.zip KA9Q: file://biochemistry.bioc.cwru.edu/pub/nos/nos11c.exe, nos11c.txt, nos192.txt NOS View: file://ucsd.edu/hamradio/packet/tcpip/nosview/nosvw304.zip NUPOP: file://ftp.acns.nwu.edu/pub/nupop/nupop201 Minuet: file://boombox.micro.umn.edu/pub/pc/minuet/minuarc.exe PC Pine: file://ftp.cac.washington.edu/mail/pcpine_p.zip NCSA Telnet: file://mer.edu/pub/ppp/ncsappp.zip ****************************************************** RESOURCE LISTING Key Downright speculation = I have not used this product personally, nor has anyone I know. However, the specifications sounded interesting, so it's included. Suggestion = I have not used this enough to pass judgement, but it has come to me recommended by someone I respect. Recommendation = I use this package regularly, and like it. BOOKS Downright speculation NOSIntro - An Introduction to the KA9Q Network Operating System Price: 11.50 Pounds sterling, plus postage and handling. U.S. price, including shipping: 17.34 pounds sterling This book by Ian Wade (author of NOSView) thoroughly covers KA9Q. Publisher is Dowermain, 356 pages, 35 chapters, 6 appendices, illustrated. ISBN 1-897649-00-2. Dowermain, Ltd., 7 Daubeney Close, Harlington, DUNSTABLE, Bedfordshire, LU5 6NF, United Kingdom, email ian@g3nrw.demon.co.uk. Written orders only, no U.S. distributor yet. Recommendation InfoPOP - Guide to Internet Resources Free InfoPOP/Windows is a smallish guide to the Internet in the form of a Windows Help application. InfoPOP/DOS is a TSR with the same content. Available via ftp gmuvax2.gmu.edu, or the fenwick.gmu.edu gopher Computers/Info-Technology/Software |___under Software available on this Gopher MAILING LISTS Windows Sockets winsock-request@microdyne.com winsnmp-request@microdyne.com W3 for Windows mail LISTSERV@fatty.law.cornell.edu, with sub cello-l your full name in the body of the message. Firewalls mail majordomo@greatcircle.com, with sub firewalls-digest in the body of the message. Back issues are available at ftp.greatcircle.com:/pub/firewalls.digest/vNN.nMMM.Z where NN is the volume number and MMM is the issue number. SNMPv1 list mail snmp-request@psi.com, subject: subscribe, body: youraddress@yourhost.domain SNMPv2 list mail snmpv2-request@tis.com, subject: subscribe, body: youraddress@yourhost.domain Novell mailing list mail listserv@suvm.acs.syr.edu body: subscribe NOVELL <Your Full Name> CUTCP mailing list mail listserv@nstn.ns.ca body: sub cutcp-l <Your Full Name> PUBLICLY DISTRIBUTABLE SOFTWARE Key Recommendation = I use, or have used this software or equipment, and I like it. Suggestion = I have not used this software, but it has been recommended to me by people that I trust. Downright Speculation = Neither myself nor anyone I know has used this, but it claims to offer interesting capabilities, so it's included. If you don't have access to FTP, you can retrieve the files via e-mail, using the following mail servers: FTPmail ftpmail@decwrl.dec.com ftpmail@ftp.uni-stuttgart.de ftpmail@grasp.insa-lyon.fr ftpmail@doc.ic.ak.uk BITFTP (available to BITNET users only) bitftp@vm.gmd.de bitftp@plesarn.edu.pl bitftp@pucc.princeton.edu DRIVERS AND SHIMS Recommendation Crynwr drivers free Support Contact Crynwr for info The Crynwr drivers, formerly known as the Clarkson University CUTCP drivers, are created by Russ Nelson of Crynwr Software, which sells packet and other driver support. The Crynwr drivers support many Ethernet adapter boards, including those from 3COM, Telesystems, AT&T, Digital, Mitel, HP, BICC, NCR, Novell, Interlan, MICOM, Racal/Interlan, NTI, Tiara, Ungermann-Bass, and Western Digital. The Packet Driver Specification v1.09 is available via: file://vax.ftp.com/pub/packet-d.ascii, packet-d.mss Drivers available at: file://ftp sun.soe.clarkson.edu/pub/packet-drivers/drivers.zip, drivers1.zip, drivers2.zip PC-NFS drivers available in file://ftp.sun.soe.clarkson.edu/pub/packet-drivers/compat.zip (requires Sun's PC-NFS). The drivers, currently in release 11 are available at: file://oak.oakland.edu/pub/msdos/pktdrvr/pktd11.zip (executables) file://oak.oakland.edu/pub/msdos/pktdrvr/pktd11a.zip (sources) file://oak.oakland.edu/pub/msdos/pktdrvr/pktdt11b.zip (sources) file://oak.oakland.edu/pub/msdos/pktdrvr/pktd11c.zip (executables) file://oak.oakland.edu/pub/msdos/pktdrvr/pktd11.zip (additional executables and sources) Crynwr Software, 11 Grant St., Potsdam, NY 13676, (315)268-1925, fax: (315)268-9201, email: nelson@Crynwr.com *Downright speculation Drivers for Western Digital Ethernet Boards free Available as: file://ftp.cdrom.com/.2/SimTel/msdos/lan/wdpost.zip Recommendation NDIS Drivers free Libraries of free NDIS drivers for DOS and OS/2 are available at FTP Software, Inc. at file://vax.ftp.com/ndis/ndis.txt. Another source of NDIS drivers is the Windows for Workgroups package. New drivers are available for download from Microsoft Product Support Services, available at (206)936-MSDL, or on CompuServe or GEnie. The Windows Driver LIbrary (WDL), which includes printer, display and network drivers is also available on disk from Microsoft by calling (800)426-9400. The NDIS spec is available as: file://vax.ftp.com/pub/ndis-mac.v101.txt, ndis-mac.v201.txt Suggestion SLIPPER v1.3 Free CSLIPPER Free SLIPPER and CSLIPPER get rave reviews for being less obtrusive than some other SLIP/CSLIP drivers so that the machine loses fewer clock ticks. The result is that the clock stays more accurate. SLIP/CSLIP operation is supported at up to 57.6 Kbps on a 486. CSLIPPER is a version which supports Van Jacobson header compression. Supports PKTMUX. SLIPPER is available from: file://ftp.utas.edu.au/pc/trumpet/slipper/slipper.zip file://biochemistry.cwru.edu/pub/slipper/slippr13.zip CSLIPPER is available from: file://biochemistry.cwru.edu/pub/slipper/cslipper.exe P. Tattam, Programmer; Psychology Department, University of Tasmania, Hobart, Tasmania, Australia, 61-02-202346; email: peter@psychnet.psychol.utas.edu.au Recommendation ETHERPPP Free Glenn McGregor, formerly of Merit Network, has released ETHERPPP, a PPP packet driver that simulates a class 1 (Ethernet) packet driver. It works well enough, is simple to configure, but takes up too much RAM (121K). Available as: file://merit.edu/pub/ppp/etherppp.zip Recommendation PKTMUX v1.2 Free This program allows multiple TCP/IP protocol stacks to use a single packet driver. It can also run over shims such as DIS_PKT; I have used it with four or more simultaneous DOS-based applications. Works great. However, if you are only using a single DOS TCP/IP application under Windows, use WINPKT instead, since it takes less memory and is faster. Available via file://ftp-ns.rutgers.edu/pub/msdos/wattcp/pktmux12.exe, or file://biochemistry.bioc.cwru.edu/pub/dos/pktmux12.exe, pktmux12.txt Downright speculation ODITRPKT v2.0 Supports packet drivers over ODI and token ring. Available as file://datacomm.ucc.okstate.edu/pub/oditrpkt/BETA12.ZIP Recommendation WINPKT free WINPKT is needed for running DOS applications with built-in TCP/IP stacks under Windows, as well as for some Windows-based TCP/IP stacks (suck as Trumpet Winsock). Compatible with ODIPKT. Available at file://biochemistry.bioc.cwru.edu/pub/slip/dos/winpkt.com Downright speculation PKTINT PKTINT is included with the non-Winsock-compatible version of WinQVT/Net to communicate with the real mode packet driver. Available at file://biochemistry.micro.umn.edu/pub/qvtnet/qvtne397.zip *Recommendation DIS_PKT free Provides a packet driver over an NDIS driver. This is useful when you need to run both packet driver software (such as KA9Q or NCSA Telnet) and NDIS-based software (such as Chameleon NFS). The latest version works with WFW v3.11, and includes a help file WFW.TXT with sample PROTOCOL.INI files, etc. Available via: file://biochemistry.bioc.cwru.edu/pub/qvtnet/dis_pkt9.zip file://netlab.usu.edu/novell.dir/dis_pkt9.zip Suggestion PDEther v1.03 Supports ODI over packet drivers. Although I haven't had much success with it, others have used it on thousands of machines and found it better than ODIPKT, especially under Windows. Available as: file://sjf-lwp.novell.com/odi/pdether/getpde103.zip *Recommendation Odipkt v3.0 Supports packet drivers over ODI. This is the recommended method of getting Novell NetWare to coexist with a packet-driver based TCP/IP stack. Compatible with WINPKT. Available as file://hsdndev.harvard.edu/pub/odipkt/odipkt.com, net.cfg, odipkt.8, odipkt.asm. Recommendation CIRA RARP server Free This is a RARP server that runs under DOS, and can give out an IP address from a pool. Available as file://pine.circa.ufl.edu/pc/rarp/rarp.zip. Recommendation RARP client Free This is a RARP client that can store the retrieved IP address in a DOS environmental variable, for later substitution into a file. Available as file://pine.circa.ufl.edu/pc/rarpset.zip. Recommendation BOOTPQ v1.2 Free BOOTPQ is a BOOTP client that can take an IP address extracted via BOOTP and put it into a DOS environmental variable. Available as file://biochemistry.cwru.edu/pub/dos/bootpq12.zip Recommendation BOOTP Free A bootp server available via file://biochemistry.cwru.edu/pub/dos/bootp.zip or file://ftp-ns.rutgers.edu/pub/msdos/wattcp/bootp.zip WINDOWS SOCKETS IMPLEMENTATIONS Recommendation Trumpet WinSock A shareware version of Windows Sockets that runs over packet drivers and requires WINPKT. Available as: file://ftp.utas.edu.au/pc/trumpet/winsock/twsk10a.zip, winapps.zip, or file://biochemistry.bioc.cwru.edu/pub/trumpwsk/twsk10a.zip, winapps.zip P. Tattam, Programmer; Psychology Department, University of Tasmania, Hobart, Tasmania, Australia, 61-02-202346; email: peter@psychnet.psychol.utas.edu.au Recommendation Dialer DIALER is a Windows program that will dial up a host and then run a series of WIndows applications. It isn't needed with Trumpet Winsock anymore, since this now has its own built-in scripting language. Available at: file://ftp.cica.indiana.edu/pub/pc/win3/util/dialexe.zip Recommendation Chameleon Demo Free This is a a demonstration version of the NetManage Chameleon TCP/IP stack. Quoting from the install instructions: To install the software, copy each .zip file onto a separate floppy. Insert diskette #1 into drive A: type win a:setup (assuming you have the installation floppy in the A drive). You will be prompted for all the other relevant information (i.e. adapter type, IP address, subnetmask, etc.). You can use Custom to configure some optional information (i.e. default gateway, DNS server, etc.). During the installation you will be prompted for a serial number. The valid serial number is DEMO_520045343970001, and the Key is F39B. The included software is only valid for 30 days from March 3, 1994. So, some time in April you'll get a license violation message, at which time you are supposed to run out and purchase a legal copy (we will not object to purchases prior to the expiration day). The winsock.dll provided in this release is compatible with the Windows Sockets version 1.1 specification. If you find any problems, please send your e-mail to winsock@netmanage.com. Actually, we want to hear from you even if you don't have any problems. Ò Available at: file://ftp.netmanage.com/pub/winsock/chameln1.zip, chameln2.zip, chameln3.zip,chameln4.zip, readme.txt Downright Speculation VxDTCP A shareware version of Windows Sockets, running over NDIS, and implemented as a VxD driver. Available at: file://biochemistry.bioc.cwru.edu/pub/wintcp/vxdtcpa2.zip Downright Speculation Microsoft TCP/IP for WFW 3.11 Adds TCP/IP to WFW 3.11. Available as: file://ftp.microsoft.com/Advsys/MSclient/WFW/WFWTCP.EXE, README.TXT WINDOWS SOCKETS COMPATIBLE APPLICATIONS *Recommendation Windows Mosaic v2.0a5 free The Internet's Swiss army knife: supports hypertext links, font styles, embedded pictures, sounds, and movies. An amazing application. Compatible with Windows Sockets. Version 2.0 supports forms, clickable regions within pictures. Please note: Since Mosaic is now a 32-bit app, unless you are running Windows NT, you must install Win32s (available from ftp.microsoft.com) in order to run Mosaic. Also, make sure you get the viewers for sounds, JPEG, and MPEG. Available at: file://ftp.ncsa.uiuc.edu/PC/Mosaic/wmos20a5.zip, win32s.zip, readme.now (Windows Mosaic) GIF viewer: file://lister.cc.ic.ac.uk/pub/wingopher/viewers/image/wingif14.zip file://lister.cc.ic.ac.uk/pub/wingopher/viewers/image/gv.zip JPEG viewer: file://ftp.ncsa.uiuc.edu/PC/Mosaic/viewers/lview31.zip file://lister.cc.ic.ac.uk/pub/wingopher/viewers/image/lview31.zip file://lister.cc.ic.ac.uk/pub/wingopher/viewers/image/jview090.zip MPEG viewer: file://biochemistry.cwru.edu/pub/dos/mpeg2.zip file://lister.cc.ic.ac.uk/pub/wingopher/viewers/movies/mpeg2.zip Windows Quicktime: file://lister.cc.ic.ac.uk/pub/wingopher/viewers/movies/qtwplay.zip Sound player: file://lister.cc.ic.ac.uk/pub/wingopher/viewers/audio/wnplny09b.zip Downright Speculation WinIRX free A Windows Sockets program that makes it easier to search or retrieve from the National Center for Biotechnology Information (NCBI) Retrieve Email server. Available via: file://biochemistry.cwru.edu/pub/dos/win-irx.zip, win-irx.txt. *Recommendation PCEudora v1.42 Free The Windows version of Eudora, compatible with Windows Sockets. Handles SMTP, POP3. This is the nicest TCP/IP mail client available anywhere. To be able to send and receive file enclosures, make sure to obtain BINHEX.EXE. The lastest version now runs under Windows NT. Available at: file://ftp.qualcomm.com/quest/eudora/windows/1.4/beta file://ftp.cdrom.com/.5/cica/winsock/eudora14.exe (PC Eudora) file://boombox.micro.umn.edu/pub/pc/binhex/binhex.exe (BINHEX) Qualcomm, sales: eudora-sales@qualcomm.com, bug reports: pc-eudora-bugs@qualcomm.com, (800)238-3672 Suggestion Trumpet Telnet v0.5 A Windows Sockets compatible Telnet implementation. Available at: file:/petros.psychol.utas.edu.au/pub/trumpet/trmptel/trmptel.exe Downright speculation WinTimeSync A Windows Sockets-compatible implementation of NTP. Available at: file://ftphost.cac.washington.edu/pub/winsock/tsync1_4.zip *Downright speculation WinTalk v1.1 A Windows Sockets-compatible implementation of Ntalk and Talk. Available at: file://elf.com/pub/wintalk/wtalk11.zip file://ftp.cdrom.com/.5/cica/winsock/wtalk11.zip Downright speculation Windows Telnet beta 3 free An unsupported Telnet implemenation for Windows. Windows Sockets compatible. Available at: file://ftp.ncsa.uiuc.edu/PC/Telnet/windows/wintelb3.zip *Recommendation WinFTP A Windows Sockets-compatible FTP client, with a 32 bit version available, written by slahiri@magnus.acs.ohio-statie.edu. Available via: file://ftp.cdrom.com/.5/cica/winsock/winftp.zip file://cnuce-arch.cnr.it/pub/msdos/win3/winsock/winftp.zip A non-blocking version is available via: file://lahiri.chrr.ohio-state.edu/?/wsaftp.zip *Downright speculation PhWin Windows implementation of Ph. Available at: file://ftp.cdrom.com/.5/cica/winsock/phwin22.zip Suggestion WS-FTP client free This is a graphical FTP implementation by John A. Junod. Available at: file://ftp.usma.edu/pub/msdos/winsock.files/ws_ftp.zip (executable) file://ftp.usma.edu/pub/msdos/winsock.files/ws_ftp_s.zip (source code) file://microdyne.com/pub/incoming/ws_ftp.zip file://sunsite.unc.edu/pub/micro/pc-stuff/ms-windows/winsock/apps/ws_ftp.zip John Junod; zj8549@trotter.usma.edu; junodj@gordon-emh2.army.mil NCOIC, Technology Integration Branch, Computer Science School, FT Gordon, GA 30905; (706)791-3245 AV:780-3245 Downright Speculation USGS WAIS Client A Windows WAIS client, available at: file://ridgisd.er.usgs.gov/software/wais/wwais23.zip. Downright Speculation WAIS Manager A Windows WAIS client, now compatible with Windows Sockets, available at: file://ftp.cnidr.org/pub/NIDR.tools/wais/pc/windows/waisman3.zip Jim Fullton, UNC Office of Information Technology, Computing Systems Development Group, (919)962-9107; email: fullton@samba.oit.unc.edu. *Recommendation EINet winWAIS v2.00 shareware,$35

The most mature Windows WAIS client,  Windows Sockets-compatible. Available at:
file://ftp.einet.net/einet/pc/EWAIS155.ZIP or
file://ftp.cica.indiana.edu/pub/pc/win3/winsock/ewais200.zip
Note: this program does not run under Windows NT.

EINet Windows Shareware, MCC, 3500 West Balcones Center Drive,
Austin, TX 78759-6509

*Downright Speculation
Internet Voice Chat v1.0

This is a program that allow voice conversations over the Internet. It
even supports an answering machine and call screening!
Requires WinSock 1.1, a sound card with microphone, and 386 or better.
Available at:
file://ftp.cica.indiana.edu/pub/pc/win3/winsock/IVC10.ZIP
file://www.unb.ca/pub/winsock/IVC10.ZIP
file://ftp.demon.co.uk/pub/ibmpc/winsock/IVC10.ZIP

Recommendation
Windows IRC

This is a Windows IRC client, available as:
file://ftp-ns.rutgers.edu/pub/msdos/trumpet/irc/winirc.exe, winirc.doc

*Downright Speculation
WS-IRC
Shareware

A really nice shareware Windows IRC client, available as:
file://ftp.cdrom.com/.5/cica/winsock/wsirc13a.zip
Also available on cs.bu.edu, winftp.cica.indiana.edu,
ftp.undernet.org, ftp.demon.co.uk

Recommendation
Windows Trumpet v1.0a

WinTrumpet is a Windows-Sockets compatible NNTP client
from P. Tattam that supports the Trumpet ABI, packet
drivers, Novell Lan Workplace for DOS and WinSock v1.1.
It is the nicest shareware NNTP newsreader for Windows
Sockets. Available at:
file://ftp.utas.edu.au/pc/trumpet/wintrump/*
file://biochemistry.cwru.edu/pub/wintrump/wtwsk10a.zip
(Windows Sockets version), wtpkt10a.zip, wtabi10a.zip,
winpkt.com, wtlwp10a.zip (Lan Workplace for DOS)

Recommendation
HGopher v2.4	Free

This is a Windows-sockets compatible version of Gopher. Looks good.
Be sure to get the viewers, too.
Available at:
file://lister.cc.ic.ac.uk/pub/wingopher/hgopher2.4.zip

Downright Speculation
WLPRSPL v4.0	Shareware

This is a windows sockets-compatible lpr implementation that
offers support for multiple queues. Be aware that LPQ doesn't
run with LAN Workplace for DOS, since it doesn't fully
implement Windows Sockets. It also runs with wslpd's new
"raw spooler," provided that you get lpd up and running
prior to printing, since it will timeout quickly. Also,
remember to name the spool files correctly and once you set
the default spool directory, don't specify a full path in
defining a spool file.

Contact: th.heil@kfa-juelich.de Available as:
file://sunsite.unc.edu/pub/micro/pc-stuff/ms-windows/winsock/apps/wlprsp40.zip.

Recommendation
WinLPR v1.0	Shareware

This is an implementation of lpr, lpq, and lprm that allows
you to print to a machine running lpd. It works fine for me.
Contact: th.heil@kfa-juelich.de. Available at:
file://sunsite.unc.edu/pub/micro/pc-stuff/ms-windows/winsock/apps/winlpr10.zip

Recommendation
Winfsp v1.2	Free

A Windows Sockets-compatible implementation of the
File Slurping Protocol.  I got it working with no
problem. Be aware that the Òprotocol searchÓ option
can take quite a while; you may have be asking the
client to individually test hundreds of ports, at
a second per port. Available at:
file://ftp.cica.indiana.edu/pub/pc/win3/winsock/winfsp12.zip

*Recommendation
WinQVT/Net v3.97
Shareware	$40 Students$20

QVTNet is a Windows v3.1 application that supports FTP
client and server (not fully graphical; commands are
entered at the bottom of the window), telnet (up to
15 simultaneous sessions), mail (SMTP and POP3),
NNTP (up to 30 newsgroups) and lpr.  It is written
as a DLL, and comes in several versions: a Windows
Sockets-compatible version (recommended); a 32-bit
version;  and a version with it's own built-in
TCP/IP stack. The version with the built-in stack
requires that you load PKTINT in DOS before running
it, and also requires you to supply your own packet
drivers, and is compatible with AppleTalk as well as
class 6 SLIP drivers.

Note: the 16-bit Winsock version of WinQVT/Net has
problems under Windows NT; use the 32-bit version instead.

Available at:
file://biochemistry.bioc.cwru.edu/gopher/pub/qvtnet/qvtne397.zip
(packet driver version with built-in TCP/IP stack),
file://biochemistry.bioc.cwru.edu/gopher/pub/qvtnet/qvtnt397.zip
(Windows NT version),
file://biochemistry.bioc.cwru.edu/gopher/pub/qvtnet/qvtws397.zip
(Windows Sockets version).

Contact: djpk@troi.cc.rochester.edu

*Downright Speculation
WinVN v0.82

A semi-graphical Windows application for reading news
which supports NNTP over TCP/IP or serial line connections.
Compatible with Winsock v1.1; a version is also available
for Windows NT. Does not support LocalTalk. Current
version has been tested with:

NetManage's WINSOCK
FTP Inc.'s WINSOCK
Wollongong's WINSOCK
NT's WSOCK32
DEC's Pathworks
MS's Lan Man

Available at:
file://ftp.cica.indiana.edu/pub/pc/win3/winsock/wnvn082s.zip
file://ftp.cdrom.com/.5/cica/winsock/wnvn082s.zip

Sam Rushing, email: rushing@titan.ksc.nasa.gov,
hoggle!hoggle2!rushing@peora.sdc.ccur.com

You'll find a bunch of zip files. Be sure to use binary mode.

Recommendation
WS-Finger	Free

A Windows Sockets compatible finger implementation. Available at:
file://sparky.umd.edu/pub/winsock/wsfngr11.zip

Recommendation
Finger v3.1	Free

The Windows version of Finger, which requires a Winsock DLL.
It works; try it out.
Available at:
file://ftp.cica.indiana.edu/pub/pc/win3/winsock/finger31.zip

*Recommendation
Cello WWW client v1.0	Free

Unlike Mosaic, Cello WWW does not support inline pictures,
although it does support viewing of sounds, pictures,
postscript and movies through external viewers. The
current version supports Windows Sockets, and can be run
under Windows NT.

Available at:
file://ftp fatty.law.cornell.edu/pub/LII/Cello/cello.zip,
viewers.zip, the graphics viewer and sound player;
gswin.zip, a Ghostscript Postscript viewer for Windows.

Suggestion
SMTP client v1.1	Free

A Windows Sockets-compatible SMTP client that is limited to
send only. Not as functional as PCEudora (which also handles
POP3). Available at:
file://sunsite.unc.edu/pub/micro/pc-stuff/ms-windows/winsock/apps/smtp11.zip

Contact: Todd.Young@StPaul.NCR.COM

Suggestion
Windows TN3270 client	Free

A Windows Sockets-compatible TN3270 client. Available at:
file://ftp.ccs.queensu.ca/pub/msdos/tcpip/qws3270.zip

Suggestion
Hlook

This is a reverse lookup tool that gives you the DNS name
from an IP address. Available as:

*Recommendation
WS-Archie

A windows sockets compatible Archie implementation by David Woakes.
Looks very good; runs fine under Windows NT.
file://ftp.demon.co.uk/pub/ibmpc/winsock/apps/wsarchie/wsarch05.zip

Suggestion
X.500 implementation

A windows sockets compatible X.500 implementation:
file://naic.nasa.gov/software/windows-dua/pixie22b.zip, wdua12.zip

Suggestion
SWIX X.500 implementation

A windows sockets compatible X.500 implementation:
file://ftp.demon.co.uk/pub/ibmpc/winsock/apps/swix/swixb1.exe

Downright speculation
HTML Assistant	Free

This an MS Windows-compatible text editor for use in
creation of HTML documents. It supports multiple documents.
Available at:

Downright speculation
HTMTools	Free

This program is a DLL that allows you to go directly from
MS Word for Windows v2.0 to HTML. Written by Jorma
Hartikka, Jorma.Hartikka@csc.fi. Available as:
file://ftp.funet.fi/pub/msdos/windows/winword/htmtl050.zip

*Downright speculation
Word Macros for HTML	free

This adds a toolbar to MS Word for Windows that supports adding
links, inline images, etc. Available via:
file://ftp.cuhk.hk///pub/www/windows/util/cu_html.zip

*Downright speculation
HTMLWriter	Free

HTML Writer is another tool for producing HTML documents.
It is available via file://ftp.byu.edu/tmp/htmlwrit.zip.

Downright speculation
Mr. Squiggle	Free

This a Windows-Sockets compatible whiteboard application
that allows two people to share the same drawing window
over the Internet.  It was implemented in Visual Basic V3,
and uses Brian Syme's VBWSK Visual Basic Winsock control.
Available at:
file://commsun.its.csiro.au/csiro/win3/squiggle/squiggle.zip, squiggle.doc

APPLICATIONS DEMOS

Suggestion
Starnet X-Window Server Demo       Free

This is a a demonstration version of the Starnet X-server.
The pricing is reasonable and the product is fast.
They have versions that work with Windows Sockets,
packet drivers under DOS, and some other brands under
DOS. It is available at:

Suggestion
ECSmail	Commercial

ECSmail is a commercial product supporting IMAP with DOS,
Windows and Mac clients. this is a demo version. Available at:
file://info.asu.edu/pub/mail/ecs/ecsmail/MUASet/windows/mua2-3.exe

DOS TCP/IP STACKS

Suggestion
WATTCP	free

Development package for TCP/IP.  Available via:

Erick Engelke, WATTCP Architect; email erick@ftp-ns.rutgers.edu

Suggestion
Trumpet TCP/IP stack

This TCP/IP stack comes in three versions: a TSR version; a
Windows Sockets version (discussed below); and a built-in
version. It includes a traceroute program called hopchk2.

Available as file://ftp.utas.edu.au/pc/trumpet/abi-version/
Available at file://biochemistry.bioc.cwru.edu/pub/trumpet/tcp201.zip

P. Tattam, Programmer; Psychology Department, University of
Tasmania, Hobart, Tasmania, Australia, 61-02-202346; email:
peter@psychnet.psychol.utas.edu.au

Downright Speculation
PC-IP	Free

This was the software that started it all. It has been worked
on at MIT, Carnegie Mellon, and Harvard and other places, but
by now is out of date. Its authors recommend looking at newer
alternatives such as NCSA, WATTCP, etc.

Harvard version: Source code:
file://ftp hsdndev.harvard.edu,/pub/pcip/pcip.tar.Z,
Binaries: file://hsdndev.harvard.edu/pub/pcip/bin/packet/*.exe
file://hsdndev.harvard.edu/pub/pcip/bin/general/*.exe

Another version:
file://netlab.usu.edu/netwatch/pcip96.zip

DOS APPLICATIONS

Suggestion
IRC client	free

A client for Internet Relay Chat.

Available at file://ftp.utas.edu.au/pc/trumpet/irc/irc100.zip
Available at
file://biochemistry.bioc.cwru.edu/pub/trumpet/irc100.zip,
ircabi.zip, irclwp.zip

P. Tattam, Programmer; Psychology Department, University of
Tasmania, Hobart, Tasmania, Australia, 61-02-202346; email:
peter@psychnet.psychol.utas.edu.au

Recommendation
WAIS for DOS	free

A DOS WAIS client which uses the Clarkson drivers is
available at
file://sunsite.unc.edu/pub/packages/infosystems/wais/DOS/pcdist.zip.

A DOS WAIS client that requires the PC/TCP software from
FTP Software is available at
file://oac.hsc.uth.tmc.edu/public/dos/misc/oacwais.exe.

For information, contact: Steven E. Newton, Office of Academic
Computing, University of Texas Health Science Center, Houston,
email: snewton@oac.hsc.uth.tmc.edu.

There is also a Novell LAN Workplace WAIS client available at
file://ftp.oit.unc.edu/pub/WAIS/UNC/nov-cli-visual.zip.

Suggestion
PDCLKSET	Free

Requiring a packet driver, this software sets your PC clock
via an Internet time server.It also offers several useful
network testing functions. Supports ping, and can build an arp
table of nodes on the subnet. Available at
file://oak.oakland.edu/pub/msdos/pkdrvr/pdclk207.zip

Suggestion
NCSA Telnet	Free

Available at file://zaphod.ncsa.uiuc.edu/PC/Telnet/msdos/tel2307b.zip,
tel2307s.zip.  Also available at
file://wsmr-simtel20.army.mil/PD1:<MSDOS.PKTDRVR>/tel2307b.zip

Compatible with LocalTalk.  A special version which supports
PPP is available at file://merit.edu/pub/ppp/ncsappp.zip,
ncsappp.txt. A PPP FAQ is available at file://merit.edu/pub/ppp/ppp.faq

Be aware that the current version does not reassemble fragments, even
though a fix is available for this (argghhh....)

Recommendation
MS-Kermit 	Free

This version of Kermit supports telnet, VT320 and Tektronix
emulation, as well as SIXEL. It incorporates the WATTCP
stack, and also runns over Novell's LWP/DOS+Telapi, FTP
Inc's PC/TCP+Tnglass, Beame & Whiteside's TCP/IP stack;
DEC Pathworks, as well as over NetBIOS. It supports Int
14h as well as Int 6Bh, and can run over packet drivers.

Available at file://kermit.cc.columbia.edu/kermit/bin/msvibm.zip,
msvibm.pif (Windows PIF file for MS-DOS Kermit)

Downright speculation
PCUCP    Free

This is a Windows v3.1 application that allows multiple open
text windows at the UNIX end. It is available at
file://ftp.cica.indiana.edu/pub/pc/win3/modem/pcucp11a.zip.

Recommendation
CUTCP Telnet	Free

CUTCP is the premiere DOS telnet application. Aside from
VT100, and Tektronxi emulation, CUTCP also handles 3270
emulation. The latest release has added ping and ODI
support. Now supported by Rutgers University, having
been tranferred from Clarkson University and Brad
Clements. This directory contains the source and
binary distributions, both in zip archives. For
information contact cutcp-support@ftp-ns.rutgers.edu.

Available at
file://ftp-ns.rutgers.edu/pub/msdos/cutcp/current/cutcp-b.zip
(Documentation and binaries), cutcp-s.zip
(Source, documentation, and binaries).

Downright speculation
Clarkson Archie	Free

Available at file://omnigate.clarkson.edu/pub/cutcp/archie.zip

Suggestion
Princeton Telnet Free

The Princeton version of Telnet supports localtalk cards
and also does tn3270 access. Works on all localtalk cards
(Sitka, Daystar, Farallon, ... )

Available at file://pusun3.princeton.edu/pub/PU2-2TN/pu2-2tn.zip

Recommendation
Clarkson Charon IPX/TCP email and printer gateway v4.0

Charon is a gateway widely used with Pegasus mail.
Available at file://omnigate.clarkson.edu/pub/cutcp/charon40.zip,
file://sun.soe.clarkson.edu/pub/cutcp/charon.zip

*Suggestion
Pegasus mail

Ron Sires <rons@netcom.com> writes:

transfer through the WinSock interface.  I haven't used it for tcp/ip mail
yet, but its great as a Novell network email system.  My company uses it
extensively.  The program is free, but the author charges for printed
check out the bit.listserv.pmail newsgroup"

Pegasus mail is available via:
file://risc.ua.edu/pub/pegasus/winpm111.zip (Windows version),
pmail311.zip (DOS version)

Recommendation
Phone package	Free

A phone dialer package for DOS that was written to run with
the UMSLIP driver. Be aware that UMSLIP does not work with PKTMUX.

Available at file://ftp.ncsa.uiuc.edu/pub/pc/slip/sliparc.exe, phone.doc

*Downright speculation
NFS Client
Business users	$20 (Shareware) Home or Ed. use$15 (Shareware)

This a shareware NFS client. The shareware fee includes the right to a year's worth of free upgrades. All TCP/IP stack versions of it are available under one license. Site license discounts start at 20 machines. I have tried this,
multiplexer. Available at:
file://polyslo.calpoly.edu/pub/mdurkin/nfs/bugs.lst
(Known and recently fixed bugs list)
file://polyslo.calpoly.edu/pub/mdurkin/nfs/nfs025-m.zip
(MS-DOS NFS client for Microsoft Lan Manager)
file://polyslo.calpoly.edu/pub/mdurkin/nfs/nfs025-n.zip
(MS-DOS NFS client for Novell LAN WorkPlace)
file://polyslo.calpoly.edu/pub/mdurkin/nfs/nfs025-t.zip
(MS-DOS NFS client for Trumpet TCPDRV)
file://polyslo.calpoly.edu/pub/mdurkin/nfs/nfs025-w.zip
(WATTCP MS-DOS NFS client)

*Downright speculation
XFS  Shareware
Educational license   $15 Commercial$25

This is another NFS client implementation for MS-DOS, by Robert Juhasz (robertj@lwfws1.uni-paderborn.de). It runs over packet drivers and
includes a built-in PKTDRVR multiplexer so you can run other software
concurrently. There are site license discounts. Requires a 286. Available as:
file://ftp.cdrom.com/.2/SimTel/msdos/nfs/xfs171.zip

Recommendation
Talk v1.2	Free

A DOS Talk client running over packet drivers. Available as:
file://oak.oakland.edu/pub/msdos/pktdrvr/talk-12.zip

Recommendation
PC Gopher III	Free

An MS-DOS client for the Gopher information server. Be aware
that you must load WINPKT.COM (or PKTMUX if you are running
multiple TCP/IP applications) to get this program to work
under Windows. The code for PC Gopher III has also been
incorporated into Minuet.

Available at file://boombox.micro.umn.edu/pub/gopher/PC_client/docs/pcgopher.txt
file://biochemistry.cwru.edu/pub/dos/pcg3.zip, pcg3doc.zip

WINPKT is available at file://biochemistry.micro.umn.edu/pub/slip/dos/winpkt.com

Downright Speculation
Uwho	Free

Uwho is Stan Barber's interface to whois and ph e-mail
address servers that runs under MS-DOS. An alpha test
version is available at
file://punisher.caltech.edu/pub/dank/uwho/uwho218b.tar.Z,
uwho218b.zip, or unarchived in subdir uwho218b.
The archived text files are inUnix format.

Recommendation
DOS Trumpet v1.06b 	Shareware, $10. Trumpet is an NNTP newsreader for DOS that can be placed on a NetWare server, while storing news groups and configuration files in each user's directory. It supports packet drivers, LAN WorkPlace for DOS, and Trumpet ABI. Available at file://ftp.utas.edu.au/pc/trumpet/dostrump/trmp106b.zip Available at file://biochemistry.bioc.cwru.edu/pub/trumpet/trmp106b.zip, newsabi.zip, newslwp.zip Contact: peter@psychnet.psychol.utas.edu.au Multi-user site licenses Trumpet will be charged by the total number of users who have access to Trumpet on a network. A site is designated as being one organization located within a radius of10 km. The pricing structure is: 1-99 users$10 US per user
100-999 users	$1000 US +$2 US per additional user above 100
1000-4999 users	$2800 US +$0.20 US per additional user over 1000
5000+	$3600 US P. Tattam, Programmer; Psychology Department, University of Tasmania, Hobart, Tasmania, Australia, 61-02-202346; email: peter@psychnet.psychol.utas.edu.au Downright Speculation Broadcast Free This is a PC client for the Macintosh Broadcast program, by Kai Getrost. Available at file://caisr2.caisr.cwru.edu/pub/net/bdcst11.zip *Suggestion DOSLynx free This is a textual browser for WWW that requires a class 1 packet driver, and includes its own built-in TCP/IP stack. It can call external viewers but does not allow viewing of inline images. It is compatible with EtherSLIP or EtherPPP, but takes up quite a bit of memory, leaving little left over for documents on a 640K machine. Available via: ftp://ftp2.cc.ukans.edu/pub/WWW/DosLynx/ Suggestion NuPOP/PC free In addition to a POP/SMTP mail client that supports MIME, NuPOP contains an FTP client, a Ph (phonebook) client, a Gopher client, a news reader, a Telnet client, and an LPR (print) client. Version of NuPOP are also available that support Wollongong TCP kernel, WATTCP kernel, and Trumpet ABI TCP kernel. Can be gotten to support LocalTalk via the provided LocalTalk driver. Do not use the Clarkson drivers for this. By the way, NuPOP also supports serial access, as well as running over TCP/IP. Available at file://ftp.acns.nwu.edu/pub/nupop/nupoprea.zip (real mode executable) file://ftp.acns.nwu.edu/pub/nupop/nupoppro.zip (protected mode executable) file://ftp.acns.nwu.edu/pub/nupop/nupopsup.zip (additional files required) If you want the news reading and MIME support, you must first install the protected mode version described above, and then install the following over it. file://ftp.acns.nwu.edu/pub/nupop/nupop210_test_release/nupop210.zip or if you get the real mode executable: file://ftp.acns.nwu.edu/pub/nupop/nupop210_test_release/real210.zip Suggestion POPmail-PC v3.2.2 This is the package included with SLIPDISK. Supports Ethernet, AppleTalk, and SLIP. Use the AppleTalk driver that works with NuPOP. Available at file://boombox.micro.umn.edu/pub/pc/popmail/popmail-3.2.2/program/popmail.exe, popmail.hlp file://boombox.micro.umn.edu/pub/pc/popmail/popmail-3.2.2/manuals/manual.asc, popmail.doc, popmail.sty A POP3 server for VMS and MS-DOS client software is available at file://logos.ucs.indiana.edu/INDEX. Recommendation Minuet A smorgasbord of DOS TCP/IP applications, including gopher, mail, ftp, news, and telnet, Minuet includes code from PC Gopher III, and POPmail. It supports multiple windows, as well as Ethernet, AppleTalk and SLIP packet drivers. Use the AppleTalk driver that works with NuPOP. Since Minuet does so much, and does it well, you may not want to use anything else, unless you don't have enough RAM for it. Available at file://boombox.micro.umn.edu/pub/pc/minuet/minuarc.exe Suggestion PC-Pine v3.88 Free This is a PC-compatible version of Pine, running under DOS. There are versions written for FTP Software's PC/TCP, Novell's Lan WorkPlace for DOS, and WATTCP. Available at file://ftp.cac.washington.edu/mail/pcpine_p.zip (WATTCP version), pcpine_n.zip (Novell LWP), pcpine_f.zip (FTP PC/TCP) Note that PC Pine relys on the Interactive Mail Access Protocol (IMAP2) rather than POP. You must have an IMAP server installed in order to use it. IMAPd is available at file://ftp.cac.washington.edu/mail/imap.tar.Z For a listing of other IMAP-compatible clients, get file://ftp.cac.washington.edu/mail/imap.software. Downright speculation Ph client University of Illinois CCSO name server client. Available at file://uxc.cso.uiuc.edu/net/ph/dos/pcph.com, pcph.README Downright Speculation FTPNuz$10/shareware

Gene Mangum's shareware newsreader for DOS, which requires FTP
Software's PC/TCP kernel. Runs under MS-DOS, as well as in a
DOS window under MS Windows and OS/2. Features include support
by mail via SMTP.

Available at file://calvin.sfasu.edu/pub/dos/network/ftp-pctcp/ftpnuz10.zip

Gene Mangum; email: h198@hosp.med.umich.edu

DOS SERVERS

Recommendation
KA9Q
Educational Use	Free
Commercial Use	$50 There are several versions of KA9Q, each with different capabilities. The current most capable versions are the ones put together by the folks at Demon Internet Services (DIS) in the UK, and the version put out by Ashok Aiyar at CWRU. CWRU Version 1.0b is based on the N1BEE 0.85-beta which in turn is based on PA0GRI 2.0m NOS, and includes support for NTP, CSO, Gopher, FTP, and SMTP/POP2/POP3 servers, plus VT102 and packet filtering support. Base code is by Ashok Aiyar, ashok@biochemistry.cwru.edu. The Textwin version from DIS does not include Gopher support, but does support Domain Name Service and can act as an NNTP server. KA9Q can route TCP/IP packets over X.25, Ethernet, LocalTalk (with a special version), and serial lines (via SLIP/CSLIP/PPP). It supports connection to 56 Kbps leased lines via a CSU/DSU and an SCC card, and supports up to 4 serial ports per machine. This means you can purchase a 56 Kbps Internet link, then divide it among 4 users, bringing the cost way down. KA9Q is a useful tool for sysops looking to hook their systems to the Internet, regardless of what kind of computer the BBS runs on. Available as: file://biochemistry.cwru.edu/pub/nos/nos10b.exe, nos10b.txt, nos10b.map, nos192.txt, nos_1229.man, vt102.zip, filter.txt, autoexec.nos Alternative sites: file://ucsd.edu/hamradio/packet/tcpip/ka9q file://boombox.micro.umn.edu/pub/gopher/PC_server/ka9q A Macintosh port (NetMac) is available at file://sumex-aim.stanford.edu/info-mac/comm/ Textwin (multiwindowing version with mouse support) package is available in three versions: large, small and tiny. The tiny package includes support for NNTP, SMTP and POP servers; the small version adds support for FTP servers; and the large version adds packet filtering, RIP and DNS support. Available as: file://ftp.demon.co.uk/pub/ibmpc/textwin. Contact: amc@beryl.demon.co.uk, amccarthy@cix.compulink.co.uk, 100012.3712@compuserve.com An access control program for SLIP gates, known as SLIPLOG, is available via: file://mvmpc9.ciw.uni-karlsruhe.de/public/nos/sliplog.zip If you have trouble accessing this with the ws-ftp client, set your servertype to ka9q. Phil Karn, KA9Q; 7431 Teasdale Ave, San Diego, CA 92122; (619)587-8281, fax: (619)587-1825 Downright Speculation NOSView v3.04 Written by Ian Wade, G3NRW, NOSView is online documentation for KA9Q, which describes all the NOS commands. It also contains a complete set of templates for use of KA9Q. Available at file://ucsd.edu/hamradio/packet/tcpip/nosview/nosvw304.zip Contact: Ian Wade, ian@g3nrw.demon.co.uk Downright Speculation Hamburg Gopher Server Available at: file://boombox.micro.umn.edu/pub/gopher/PC_server/hamburg/gophserv.zip (server package), file://boombox.micro.umn.edu/pub/gopher/PC_server/hamburg/gophdoc.zip (documentation), file://boombox.micro.umn.edu/pub/gopher/PC_server/hamburg/engine.zip (database engine) file://ftp.informatik.uni-hamburg.de/pub/infosystems/gopher/pc/go4ham/go4ham.zip Downright Speculation Stan's Own Server Free SOS is based on the now-outdated PC-IP, and as a result is not used much anymore. However, there is no other publicly distributable NFS server package out there, so if you need one, you might as well try this. Available at file://sun.soe.clarkson.edu/pub/packet-drivers/soss.zoo, sossread.me. Also available at file://spdcc.com/pub/sos/soss.zoo, sossexe.zoo A version with a couple of bugs fixed is available at file://hilbert.wharton.upenn.edu/pub/tcpip/soss.zip For info, contact: Richard Bruan, rbraun@spdcc.com, or Seemong Tan, stan@cs.uiuc.edu. Downright Speculation BOOTP and FTPD NLMs Available via file://novell.felk.cvut.cs/pub/nw311/ftpd, /pub/nw311/bootpd, /pub/nw311/resolv. Downright Speculation LPD Free FTP and BOOTP server included This software is a freeware line printer daemon as well as an FTP and BOOTP server. Available via file://tacky.cs.olemiss.edu/pub/lpd/lpd.zip, lpdsrc.zip Recommendation TELNETD Free TELNETD is a simple, free and unsupported TELNET server for PCs, by Erick Engelke. It works on top of packet drivers and lets you run most DOS software. However, it doesn't do everything; if you want a commercial-quality implementation, get Everywhere Access. Available at file://ftp-ns.rutgers.edu/pub/msdos/wattcp/telnetd.zip Recommendation COMD Free COMD by Erick Engelke allows you to share serial port devices, including printers and modems with another TCP/IP connected computer. Available at file://ftp-ns.rutgers.edu/pub/msdos/wattcp/comd.zip Downright Speculation SMTP server free An SMTP server for DOS. Available at: file://ftp-ns.rutgers.edu/pub/msdos/wattcp/smtpserv.zip WINDOWS SERVERS Recommendation WS-Gmail Free An SMTP and POP3 server implementation with a matching mail client that supports multiple userIDs as well as aliases. Written by y John A. Junod. Available as: file://ftp.usma.edu/pub/msdos/winsock.files/ws_gmail.zip (Mail implementation) John A. Junod; 267 Hillwood Street, Martinez, GA 30907; email: jundj@css583.gordon.army.mil; (706)791-3245 AV:780-3245 Recommendation Fingerd Free A Windows Sockets compatible finger server: file://sparky.umd.edu/pub/winsock/wfngrd10.zip Downright Speculation Web4Ham v0.14 Free A Windows Sockets compatible HTTP server, by Gunter Hille, hille@informatik.uni-hamburg.de. Available as: file://cica.indiana.edu/pub/pc/win3/uploads/web4ham.zip ftp://ftp.informatik.uni-hamburg.de/pub/net/winsock/web4ham.zip Recommendation SerWeb v0.3 Free A fully functional HTTPd implementation for Windows. For info, contact: estrella@cass.ma02.bull.com. Available as: file://sunsite.unc.edu/pub/micro/pc-stuff/ms-windows/winsock/apps/serweb03.zip *Suggestion NCSA HTTPd for Windows Free This is a fully compliant HTTTP server from NCSA that supports scripts. Available as: ftp://ftp.ncsa.uiuc.edu/Web/ncsa_httpd/contrib/whtp11a6.zip Downright speculation Cookie server Free This is a Windows-Sockets compatible fortune cookie server (RFC 865) that runs on port 17. Available at: file://ftp.cica.indiana.edu/pub/pc/win3/winsock/cooksock.zip. Contact: alun@huey.wst.com Suggestion Windows Sockets for PC/NFS free An implementation of Windows Sockets for PC/NFS. Available at: file://ftp.cica.indiana.edu/pub/pc/win3/winsock/wsck-nfs.zip *Suggestion WinFTPd$15 (shareware)

An FTP daemon for Windows by Alun Jones (alun@huey.wst.com).

Available at:
file://ftp.cica.indiana.edu/pub/pc/win3/winsock/wftpd19.zip
file://ftp.cdrom.com/.5/cica/winsock/wftpd19.zip

Downright Speculation
WinLPD	Free

An lpd implementation for Windows.  Contact: dog@inel.gov

Available at:
file://sunsite.unc.edu/pub/micro/pc-stuff/ms-windows/winsock/apps/wslpd-11.exe

Downright speculation
Text server

This is an extended finger client, which can also serve text
files. Available at
file://ftp.cica.indiana.edu/pub/pc/win3/winsock/txtsrv.zip

Recommendation
SMTP daemon v1.6	free

A Windows-Sockets SMTP daemon, complete with source code.
Works fine. Available at:
file://ftp.cica.indiana.edu/pub/pc/win3/winsock/wsmtpd16.zip.

contact: iblenke@cip60.corp.harris.com

WINDOWS NT SERVERS

Recommendation
Windows NT FTP daemon	Free

This is a Windows NT version of ftpd. Quite fast.
Available at:
file://sunsite.unc.edu/pub/micro/pc-stuff/ms-windows/winsock/apps/nt-ftpd.zip

*Recommendation
HTTPS v0.6	Free

This is a very powerful and easy to install HTTP server,
probably the best I've seen running under any OS.
HTTPS is a Windows NT HTTP v1.0 server for Windows NT
produced as part of the European Microsoft Windows NT
Academic Centre (EMWAC).  Binaries are available for
Intel and DEC Alpha architectures. HTTPS is
supports Forms and CGI-BIN scripts, and runs as a Windows
NT service.

HTTPS (For HTTP Service) can be configured via the control
panel, is integrated with the WAISS server, and logs HTTP
transactions in the event logger. Available at:
file://emwac.ed.ac.uk/pub/https/HSI386.ZIP (Intel version),
HSALPHA.ZIP (DEC Alpha version), HHTPS.TXT
(description of the server)

*Recommendation
GOPHERS v0.6	Free

This is a Windows NT Gopher server for Windows NT
produced as part of the European Microsoft Windows
NT Academic Centre (EMWAC).  Binaries are available
for Intel and DEC Alpha architectures. This gopher
server is multi-threaded, and runs as a Windows NT
service. It can be configured via the control panel.
Available at:
file://emwac.ed.ac.uk/pub/gophers/GSI386.ZIP (Intel version),
GSALPHA.ZIP (DEC Alpha version), MESSAGE.TXT
(description of the server)

*Recommendation
WAISS v0.6	Free

This is a Windows NT WAIS server for Windows NT produced as
part of the European Microsoft Windows NT Academic Centre
(EMWAC). It inclues an indexing tool, WAISINDX that lets you
index documents in a number of formats. This is the easiest
to set up WAIS server I've seen, and it is well integrated
with the Gopher and HTTP servers.

Binaries are available for Intel and DEC Alpha
architectures. This WAIS server is multi-threaded, and
runs as a Windows NT service. It can be configured via
the control panel. Available at:
file://emwac.ed.ac.uk/pub/waistool

Downright speculation
NT-Perl	Free

This is a Windows NT implementation of Perl v4.036, ported by Intergraph.

Available at:
file://emwac.ed.ac.uk/pub/ntperl.zip.

UNIX SERVERS

Recommendation
SMBServer v1.6	Free

SMBServer includes a UNIX-based SMB file and print server,
as well as a UNIX SMB client and a NetBIOS nameserver (NBNS).
It can be used with clients such as Windows for Workgroups,
Windows NT, OS/2, Pathworks, and LanManager for DOS. This
means that it can attach to Windows NT and WFW servers or
mount portions of the UNIX file system on these machines.
You can also print from UNIX to an SMB printer by adding
security, umask support, guest connections and system
attribute mapping. SMBServer is being run under Linux,
SunOS, Solaris, SVR4, Ultrix, OSF1, AIX, BSDI, NetBSD,
Sequent, HP-UX, SGI, FreeBSD, and NeXT.

Available at:
file://nimbus.anu.edu.au/pub/tridge/server/tarred/smbserver-1.6.03.tar.gz

WAN CONNECTIVITY

Suggestion
Niwot synchronous board	 $695 This Niwot synchronous adapter comes with a packet driver that works with PCROUTE or KA9Q, and can handle speeds up to T1. Niwot Networks, (303)444-7765 Suggestion RISCom N1 single port card$495
N2 dual port card

This board is supported by BSD/386, and supports HDLC at
56 Kbps for connection to Cisco routers running PPP.

SDL Communications, Inc.; (508)238-4490

Suggestion
Livingston Portmaster IRX-114 terminal servers

Livingston Enterprises; (800)458-9966, fax: (510)426-8951,
email: doug@livingston.com

Suggestion
Morning Star Routers

Morning Star Technologies, Inc; (614)451-1883, (800)558-7827,
fax: (614)459-5054, email: marketing@morningstar.com,
support@morningstar.com, ftp archive: ftp.morningstar.com,
WWW server: http://www.morningstar.com

Suggestion

This is a reasonably priced T1 CSU/DSU.

Capella Networking; (415)591-3400, (408)225-2655, email: dstolz@capella.com

ROUTERS AND BRIDGES

Recommendation
KA9Q
Educational Use	Free
Commercial Use	$50 KA9Q includes routing and packet filtering capabilities, along with a variety of other client and server capabilities. See the listing under Servers. Suggestion PCRoute v2.24 Free This package can convert a PC into a TCP/IP router. It doesn't require more than 1 Mb of memory, and works fine on an 8088, although faster machines are recommended. This is a fast and reliable router and highly recommended for routing between Ethernets. Available at file://ftp.acns.nwu.edu/pub/pcroute/readme.1st (Readme file) file://ftp.acns.nwu.edu/pub/pcroute/readme.pcroute.doc (PCRoute documentation) file://ftp.acns.nwu.edu/pub/pcroute/pcroute2.24.tar.Z (executables) file://ftp.acns.nwu.edu/pub/pcroute/pcroute2.24.src.tar.Z (source code) 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 Northwestern, PCBridge has been taken over by Alessandro Fanelli and Luigi Rizzo. The latest version of PCBridge is now ROMable. The software is available at file://pical3.iet.unipi.it/pub/bridge/bdg277.tar.Z Alessandro Fanelli, Luigi Rizzo (luigi@iet.unipi.it), Universita di Pisa - via Diotisalvi 2, 56126 Pisa, Italy ; +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 at file://net.tamu.edu/pub/security/TAMU/drawbridge-1.1.tar.gz, drawbridge.README, drawbridge-1.1-des.tar.gz Downright Speculation KarlBridge v1.41 This software, which uses WATTCP, 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. It now supports SNMP queries for remote management. Novell SAP and NCR WaveLAN filtering are coming in a future release. Available at file://128.146.1.7/pub/kbridge/kbridge141.zip TROUBLESHOOTING Downright Speculation Windows Ping free Available at: file://microdyne.com/pub/incoming/ws_ping.zip, file://ftp.usma.edu/pub/msdos/winsock.files/ws_ping.zip John Junod; zj8549@trotter.usma.edu; junodj@gordon-emh2.army.mil NCOIC, Technology Integration Branch, Computer Science School, FT Gordon, GA 30905; (706)791-3245 AV:780-3245 Downright Speculation DOS Ping free Available at: file://ftp.usma.edu/pub/msdos/misc/ping.exe Downright Speculation Traceroute free A version of traceroute for DOS, available at: file://biochemistry.bioc.cwru.edu/pub/trumpet/tcp201.zip There are also versions of ping and traceroute included with Trumpet Winsock. Downright Speculation SNMP monitor Free An SNMP monitor for Sun, available at: file://sun.soe.clarkson.edu/pub/packet-drivers/snmpsrc.zip. Also available at file://enh.nist.gov/misc/snmpsrc.zip, snmpsup.zip, snmpsun.tar_Z Suggestion Fergie Free Fergie is a packet monitoring and grabbing tool that supports SNMP and supersedes The Beholder and Gobbler. Spectre is a network host profiler. Tricklet is a set of SNMP utilities. Fergie is available at file://dnpap.et.tudelft.nl/pub/Fergie/frgbin2.zip. The source code is available at file://dnpap.et.tudelft.nl/pub/Fergie/frgsrc2.zip. To get on the Fergie mailing list, send mail to: request@dnpap.et.tudelft.nl Suggestion Beholder - The Next Generation (BTNG) Free BTNG is an RMON compatible Ethernet monitor for OS/2, SunOS and Ultrix. Tricklet is a set of SNMP utilities for OS/2 and UNIX. To run these tools under OS/2, you will need an Ethernet card with an NDIS driver for OS/2. Available at: file://dnpap.et.tudelft.nl/pub/btng/README (Readme file) file://dnpap.et.tudelft.nl/pub/btng/btng41exe.zip (OS/2 binaries) file://dnpap.et.tudelft.nl/pub/btng/btng41src.zip (OS/2 source) file://dnpap.et.tudelft.nl/pub/btng/BTNG.FAQ (Frequently Asked Questions) Suggestion NetProbe Free An unsupported utility from 3Com that can decode XNS, TCP/IP, ICMP, AppleTalk, IPX/SPX, SMB, and other protocols, but only supports the Etherlink, Etherlink II, EtherLink Plus and Token Plus adapters. Available on CompuServe in the 3Com forum as EPROBE.ZIP in lib 5, unsupported utilities. Downright Speculation Netwatch Free Essential network debugging tools for the PC. Available at file://netlab.usu.edu/netwatch.dir/netwatch.exe. Recommendation Ethload v1.04 Free This is an Ethernet load monitor that gives all kinds of useful statistics on your network, including breakdowns by protocol (supports IP, NetWare, OSI, DECNet, NetBEUI), source or destination, ports, etc. Very useful. Available at file://oak.oakland.edu/pub/msdos/lan/ethld104.zip. Also available at file://wsmr-simtel20.army.mil/<msdos.lan>/ethld104.zip. *Recommendation EtherDump v1.04 Free This is a tracing program, similar to TCPDump. However, the output isn't quite as sophisticated or easy to read, although it certainly is voluminous. Available at: file://oak.oakland.edu/pub/msdos/lan/ethdp104.zip file://wsmr-simtel20.army.mil/<msdos.lan>/ethdp104.zip file://ftp.cdrom.com/.2/SimTel/msdos/lan/ethdp104.zip *Downright speculation SNMPMAN SNMPMAN is an SNMP-based network monitoring package written by Abner Correia, Jorge Pires, and Tiago Silva (snmpman@di.fc.ul.pt). Information on SNMPMAN is available via http://www.fc.ul.pt/software/snmpman.html. Available at: file://ftp.fc.ul.pt/pub/networking/snmp/snmpman.zip SNMPMAN, Faculdade de Ciencias da Universidade de Lisboa (Departamento de Informatica), Campo Grande-Bloco C5, 1700 LISBOA, Portugal; voice: +351 1 7510003, fax: +351 1 7577831. *Downright speculation NetGuardian v1.1 NetGuardian is an SNMP-based network monitoring package written by Paulo Sergio Mena, Ricardo Machado de Oliveira and Rui Santos Antonio, (netguard@di.fc.ul.pt). It requires Ling Thio and Dirk Wisse's WINSNMP.DLL. Information on NetGuardian is available via http://www.fc.ul.pt/software/netguard.html. Available at: file://ftp.fc.ul.pt/pub/networking/snmp/netguard.zip NetGuardian, Faculdade de Ciencias da Universidade de Lisboa (Departamento de Informatica), Campo Grande-Bloco C5, 1700 LISBOA, Portugal; voice: +351 1 7510003, fax: +351 1 7577831. *Downright speculation NetAddress v1.1 Free This program collects Ethernet addresses and various statistics, including protocols used, IP and IPX address, AppleTalk name, etc. Available at: file://oak.oakland.edu/pub/msdos/lan/net-ad11.zip file://ftp.cdrom.com/.2/SimTel/msdos/lan/net-ad11.zip TCP/IP AND NETWARE Downright speculation BYU Netware shell drivers free Allows you to build an IPX.COM that runs over packet drivers. Works by providing .obj and .lan files for the Neware shell generation program, shgen.exe. Running shgen.exe produces netX.com as well as an ipx.com for your interface card. Again, I've had better results with ODIPKT than with this. Available at: file://vax.ftp.com/pub/packet.driver/pubdom/byu Downright speculation Intel PDIPX free Another way of building an IPX.COM that runs over packet drivers. Available at: file://ftp sun.soe.clarkson.edu/pub/packet-drivers/intel.pdipx.zip Suggestion PDEther v1.03 An ODI over packet driver shim. See entry under Drivers and Shims. Recommendation Odipkt v3.0 A packet driver over ODI shim. See entry under Drivers and Shims. UNCLASSIFIABLE (BUT INTERESTING) STUFF Downright speculation GIGO Free This has nothing to do with TCP/IP, but rather is a UUCP packet to FidoNet *.PKT translator. For info, contact: gigo-r@wmeonlin.sacbbx.com. Available at file://ftp.netcom.com/pub/jfesler/gigo.zip ------------------------------ END OF PART 2 ------------------------ Please send comments to: Bernard Aboba Author of: The Online User's Encyclopedia, Addison-Wesley, 1993 The PC-Internet Connection, Publisher's Group West, 1994 email: aboba@netcom.com WWW page: http://www.zilker.net/users/internaut/index.html  -----------[000190][next][prev][last][first]---------------------------------------------------- Date: 9 Jul 1994 17:42:13 GMT From: emv@garnet.msen.com (Edward Vielmetti) To: comp.protocols.tcp-ip Subject: Re: Fake network addresses  John Kalucki (johnk@gordian.com) wrote: : Chris Rohrer (crohrer@advtech.uswest.com) wrote: : : I was of the understanding that there is a Class A or maybe a Class B : : address that is reserved and not allocated to anyone on the Internet, : : The purpose is to alllow private networks that do not/can not/will not : : connect directly to the Internet the opportunity to have an address space : : that will not conflict with or confuse anyone's routing tables. : 1597 I Y. Rekhter, R. Moskowitz, D. Karrenberg, G. de Groot, "Address : Allocation for Private Internets", 03/17/1994. (Pages=8) : (Format=.txt) There's a response to this RFC by E.Fair (Apple), E.Lear (SGI) et seq. that notes that it is not unusual for networks originally designed as "will not connect" to be either connected to other corporate private nets or eventually to the whole world. Frankly I think you're making a decision to re-number at some point in the future if you're using "reserved" addresses, and if you can't quantify and budget for the cost of renumbering you shouldn't use "reserved" addresses for real computers. Edward Vielmetti, vice president for research, Msen Inc. emv@Msen.com Msen Inc., 320 Miller, Ann Arbor MI 48103 +1 313 998 4562 (fax: 998 4563) msen info addresses: info@msen.com -$20/mo public access Internet
occ-info@msen.com - Online Career Center jobs database


-----------[000191][next][prev][last][first]----------------------------------------------------
Date:      Sat, 9 Jul 1994 17:42:46 GMT
From:      aboba@netcom.com (Bernard Aboba)
Subject:   comp.protocols.tcp-ip.ibmpc Frequently Asked Questions (FAQ), part 3 of 3

Archive-name: ibmpc-tcp-ip-faq/part3

comp.protocols.tcp-ip.ibmpc:
FAQ Posting, part 3, 7/1/94

COMMERCIAL PRODUCTS

*Downright speculation
TCP/IP BOOT-PROM

The TCP/IP BOOT-PROM is a TCP/IP based Boot ROM available for about
34 Ethernet and Token Ring PC network controllers. It uses the protocols
BOOTP and TFTP to download the DOS operating system and network software
from a TCP/IP based servers like UNIX, NetWare, OS/2 or Windows NT.
Several network software like PC-NFS, PC/TCP, PC-Interface, B&W NFS,
LAN WorkPlace, NetWare, NetWare/IP, LanManager, TUN and other are supported
on the diskless client site.

The builtin application interface allows to access the ROMs TCP/IP stack
e.g. UnixWare.

Dirk Koeppen EDV-Beratungs-GmbH, Germany
Phone: +49 69 89 3000, Fax: +49 69 89 3004, email: dirk@incom.de

Downright Speculation
3Com TCP w/ DPA v2.0

3Com; (800)638-3266

Downright Speculation
Internet in a Box

This is a much ballyhooed product, which will include a special version
of Ed Krol's book, alongside a complete suite of applications. Rumour
has it that the installation procedure is quite streamlined in that it
sets up all the stack as well as all the applications in one fell swoop.

Spry Inc.; 1319 Dexter Ave North, Seattle WA 98109; (206)286-1412, email:
sales@spry.com

Downright Speculation
AIR for Windows

Spry Inc.; 1319 Dexter Ave North, Seattle WA 98109; (206)286-1412, email:
sales@spry.com

Downright Speculation
Teemtalk for DOS
Teemtalk for Windows

Teemtalk supports connections over ARPA Services 2.0+ (HP), Beame & Whiteside,
CTerm (DEC), Int-6B (Novell NASI), Int-14, MS LanManager, Lan Workplace, LAT,
NetBIOS, Netmanage Chameleon, OSLAN (ICL), Pathway, PC-NFS, PCTCP,
TELAPI (Novell), and also support Windows Sockets, and regular or BIOS level
serial connections.

Emulations include  VT 52/100/220/240/320/340/640, Viewdata
40/80/Split, DG200, HP2392A, Tek4014, Regis and W2119. Protocol support
Kermit and Xmodem. It also supports DDE.

Pericom,  1-609-895-0404 (US) and 0908-265533 in the UK.

Suggestion
BW-NFS v3.0c

NFS is implemented as a TSR; the TCP stack is a device driver.
The package supports SLIP, NFS client, Telnet (VT220 and
3270 emulation), finger, talk, ftp, and SMTP mail.  It also can act as a
server for telnet, FTP, finger, and lp.  The 3270 emulation is reportedly
OK.

Beame & Whiteside Software Inc.; 706 Hillsborough St., Raleigh, NC 27603-1655
(919)831-8989, tech: (919)831-8975, fax: (919)831-8990, email: sales@bws.com

Suggestion
Chameleon v3.15	$125 (upgrade price) ChameleonNFS v3.15$400

Chameleon is a Windows 3.x TCP/IP implementation that can handle FTP,
Telnet (3270, ANSI, VT-52, VT100 and VT220 emulation), ping, SMTP, POP2,
and NFS (client and server) all in multiple windows, simultaneously.  The
package also supports DNS via an implementation of BIND, as well as SNMP.
ChameleonNFS is compatible with the IPX/Link product for Netware from
NetManage. Most of the code resides in a DLL. Chameleon supports multiple
interfaces, and can route betweenthem. The newest release supports CSLIP,
PPP and NNTP.

NetManage, Inc.; 20823 Stevens Creek Blvd.,Cupertino, CA 95101;
(408)973-7171, fax: (408)257-6405, email: support@netmanage.com

Downright speculation
Distinct Network Applications v3.02	$395 Distinct Software Development Kit$495
Network & Developer Combination	        $695 Distinct TCP/IP for Windows - Network Applications v3 integrates several Windows based TCP/IP utilities under a single interface. These include: Distinct Telnet which allows multiple concurrent Telnet sessions on different remote hosts, allowing you to cut and paste information between these systems as well as between the systems and your local host. Distinct FTP is a drag and drop FTP which allows you to drag a local or remote file to a local printer. Distinct FTP has both a client and a server; this means that files can be also transferred by selected users from PC to PC (password protection is included). TFTP provides file transfer services to communications servers and routers that do not have FTP. Network Monitor monitors host-to-host communication and data transmission traffic and is able to capture network traffic to a file. Distinct TCP/IP for Windows - Software Development Kit This product is engineered as 100% DLL, and requires only 4 Kb DOS memory for a driver. The product supports up to 64 concurrent sockets, and buffers are allocated and deallocated as they open and close. Includes three development kits: Distinct TCP/IP for Windows - Berkeley-style Sockets (TCP, UDP, ICMP, Telnet, FTP) Distinct TCP/IP for Windows - Windows Sockets ver. 1.1 Distinct RPC - a complete ONC RPC/XDR toolkit for Windows (Client and Server RPC over both TCP and UDP; includes RPCGEN) Distinct Corporation;14395 Saratoga Avenue, Suite 120, Saratoga, CA 95070; (408)741-0781, fax: (408)741-0795, email: chris@distinct.com Distinct Corporation; P.O. Box 3410, Saratoga, CA 95070-1410; (408)741-0781, email: mktg@distinct.com Suggestion Everywhere Access This is a remote access package for TCP/IP, including support for telnet server, FTP and Kermit transfers, VT100, VT220, VT300 emulation, password security. Includes versions working with WATTCP as well as other implementations. Supro Network Software Inc.; P.O. Box 18, Warsaw, Ontario, Canada K0L-3A0; (705) 652-1572, email: info@snsi.com Downright Speculation Fusion Pacific Software; (800)541-9508 Downright Speculation ICE/TCP James River Group; 125 North First St., Minneapolis, MN 55401; (612)339-2521, email: jriver@jriver.com Downright Speculation Lanera TCPOpen/Standard v2.2 Lanera Corporation; 516 Valley Way, Milpitas CA 95035; (408)956-8344, email: lanera@netcom.com Downright Speculation Lantastic for TCP/IP Artisoft, Inc.; 691 East River Road, Tucson, AZ 85704; (602)293-6363 Suggestion LAN Workplace for DOS v4.1r8 Novell, Inc.; 122 East 1700 South, Provo, UT 84606; (800)772-UNIX Downright Speculation NS & ARPA Services v2.5 Hewlett-Packard; 19420 Homestead Rd., Cupertino, CA 94014; (408)725-8111 Downright Speculation The Wollongong Group's PathWay Access A family of complete IP Services for DOS/Windows, Macintosh, OS/2, and VMS systems, as well as SNMP and X-400/X-500 products. Wollongong has been providing IP solutions for over 14 years. PathWay Access for DOS/Windows 3.0 - This product has been significantly enhanced with the majority of changes being to the Windows applications, emulations and remote access. Integrated into Windows, the applications are Windows Sockets compatible. Support for all NOS, extensive DBMS and third party support. VT100-220, VT320-330, VT240-340, 3270 mods 2-5, 3179g, tek4010-4105, drag & drop FTP client/server, LPR/LPD/IPR, NetBIOS, NDIS/ODI/PDS/ASI, SLIP/CSLIP/PPP/X.25, MIB2 SNMP agent, Scripting, Graphical Remapping, NFS, SMTP/IMAP/POP(MIME), NetNews reader. Pricing: Many different pricing schemes exist for these products based on customer requirements, from shrink-wrap bundles to expandable licenses that can be added to in any number, with discounts based on accrued amount levels. Aggressive educational discounts and trade-up pricing are offered. PathWay Access (Single User-DOS/Windows or Mac) -$350
Client NFS module - $95 API -$200

Technically supported evaluations are provided free of charge to qualified
individuals.  Also offered is a demonstration disk tour of PathWay Access 3.0
free and yours to keep.

The Wollongong Group; 1129 San Antonio Rd, Palo Alto, CA 94303;
800-872-8649 (Outside Cal), 800-962-8649 (In Cal), (519)747-9900
(415)962-7247, email: sales@twg.com

Downright Speculation

X LINK Technology; 741 Ames Avenue, Milpitas CA 95035; (408)263-8201, fax:

Suggestion
PC-NFS v5.0	$395 PC-NFS from SunSelect (a Sun Microsystems business) includes a TCP/IP stack, TCP/IP utilities under DOS and Windows, an NFS client, remote printing support, SNMP, and Windows Sockets. Add-on packages support email and advanced telnet. A Programmer's Toolkit is available which provides DOS and Windows support for TCP/IP over sockets and XTI, as well as TIRPC, NIS and supporting APIs. SunSelect; 2 Elizabeth Drive, Chelmsford, MA 01824-4195;(800)24-SELECT or (508)442-0000; fax: (508)250-5068 Recommendation PC/TCP v2.2$400
Kernel Only	$200 PC/TCP v2.2 offers a solid implementation of TCP/IP for DOS, with some Windows applications. It includes NFS for UDP or TCP, remote login (telnet, rlogin, supdup) with a variety of terminal emulators, file transfer (FTP, TFTP, rcp), electronic mail and news (pop2, pop3, pcmail, mail, SMTP, NNTP), printing (LPR and print redirection) and informational utilities (whois, ping, finger, host). Some kerberos support is available to domestic customers. If used alongside ConcordCommunications Mapware controllers, this product is capable of handling both OSI and TCP/IP concurrently. 3270 support is OK. It is available for Ethernet (DIX or 802.3), Token Ring, SLIP, PPP, LocalTalk and X.25 interfaces, over packet drivers, ODI drivers, NDIS drivers, banyan drivers, and ASI drivers. This package does not route; you are therefore restricted to installing it with PPP, SLIP or Ethernet, but not some combination of the above. PC/TCP is incompatible with Stacker. As of version 2.2, the Windows applications have been improved. New to Windows support is the ability to mount and unmount NFS drives from within Windows, and to use PCNFSD printer services from Windows. The 2.2 manual includes a 6-page install guidelette, and now offers a menu-driven installation and configuration program. FTP Software, Inc.; 2 High St., North Andover, MA 01845; (800)282-4387, Support: 1-800-382-4ftp, fax: (508)794-4477, email: sales@ftp.com Downright Speculation Piper/IP$375
Developer's Kit	$375 Piper/IP runs under DOS protected mode, using less than 6K of lower DOS memory. The company claims that FTP transfers take place at100K/second over a LAN. They also claim the ability to run concurrrently with NetWare, VINES, LAN Manager, LAN Server, and WFW. The package includes a FTP, Telnet (client and server), and SMTP. Ipswitch, Inc.; 580 Main St, Reading, MA 01867; (617)942-0621, email: ub@ipswitch.com Downright Speculation Super-TCP v3.00r$495
Super-NFS client v3.00r

SuperTCP supports telnet (3270, VT100, VT102, and VT220 emulation), talk,
SMTP, ftp, ping, and with Super-NFS, NFS client.  SuperTCP supports both
TCP/IP and Novell IPX protocols, as well as SNMP.

It is written as a DLL, although a TSR version of the protocol stack is
also available for those who want to use DOS as well. Network statistics
(arp, ICMP messages, etc.) are available.

Frontier Technologies;10201 North Port Washington Road, Mequon, WI 53092,
(414)241-4555, fax:(414)241-7084, email: tcp@frontiertech.com

Downright Speculation
TCP/IP for DOS v2.10

IBM; Dept. E15, P.O. Box 12195, Research Triangle Park, NC 27709;
(800)IBM-CALL

Downright Speculation
TCP/IP Utilities for LanManager v1.0
Windows for Workgroups TCP/IP
Windows NT

Microsoft; One Microsoft Way, Redmond WA 95052-6399; (206)882-8080

Downright Speculation
TCP/2 for DOS

Essex Systems; (508)532-5511

Downright Speculation
TTCP v1.2r2

Turbosoft Pty Ltd; 248 Johnston St., Annandale, NSW Aus. 2038; +61 2 552
1266, email: info@abccomp.oz.au

XWARE

Suggestion
PC-Xview

PC-Xview is available for DOS or Windows, supporting use of X over the
network.  It also supports NCD's Xremote protocol that allows X to run over
a modem much faster than could be achieved running a standard X package
over SLIP or PPP.

Network Computing Devices, Inc.; (800)793-7638

Downright Speculation
MicroX for Windows

A demo of this product is available as:

StarNet Communications, Corp.

Downright speculation
XVISION	$449 XVision allows X applications to run under Windows. You have a choice of running each X app in its own Window, or all X applications within one big Window. VisionWare, Ltd.; 57 Cardigan Lane, Leeds, England; 44-0-532-788858, (800)222-0550, fax:44-0-532-304676 Downright Speculation DesQView X DesQView X integrates networks of DOS and UNIX machines using the X-Windows protocol, allowing DOS machines to act as X-Windows clients and servers. Quarterdeck Office Systems; 150 Pico Boulevard, Santa Monica, CA90405; (213)392-9851, fax:(213)399-3802 Development Software Epilogue Technology: Includes source code. info@epilogue.com, fax: (505)271-9788 Spider Systems Available for many architectures. ian@spider.co.uk, fax: 44-31-555-0664 Marben Produit TCP/IP Source available, fax: 33-1-47.72.55.00 Network Research FUSION Source available, fax: 1(805)485-8204 ------------------------------ END OF PART 3 ------------------------ Please send comments to: Bernard Aboba Author of: The Online User's Encyclopedia, Addison-Wesley, 1993 The PC-Internet Connection, Publisher's Group West, 1994 email: aboba@netcom.com WWW page: http://www.zilker.net/users/internaut/index.html  -----------[000192][next][prev][last][first]---------------------------------------------------- Date: Sat, 9 Jul 1994 18:19:30 +0000 From: mickm@mickm.demon.co.uk (Mick Morgan) To: comp.protocols.tcp-ip Subject: Re: THE winsock??  In article <6.14403.716.0NAEA18E@spacebbs.com> philip.burton@spacebbs.com "Philip Burton" writes: > [stuff deleted] > > Damn shame, though. There are some good parts of OSI. Too bad the > purists didn't design the OSI applications to run on top of the TCP > layer. > > -- Phil Burton -- philip.burton@spacebbs.com > - Palo Alto, CA - -- Mick Morgan Home 'phone 0508-470938 CCTA ("Can't Change The Acronym") Work 'phone 0603-694927 Email mickm@mickm.demon.co.uk  -----------[000193][next][prev][last][first]---------------------------------------------------- Date: Sat, 9 Jul 1994 19:20:42 +0000 From: proyse@peeras.demon.co.uk (Phil Royse) To: comp.protocols.tcp-ip Subject: Re: Best way to change IP addresses for a group of systems  In article <1994Jul5.153915@siacbbn.com> adiwan@siacbbn.com "Arif Diwan (BBN" writes: >In article <2v1902$8km@ccnet.ccnet.com>,
>        jantypas@ccnet.com (John Antypas) writes:
>...
>  a) is there a way I can give my hosts TWO IP addresses on their interfaces?
>  (Old IP and New IP) for say, a month.
>
>You can assign multiple IP addresses to an interface. I know of three ways:
>
>                                                617-873-6274

That sounds OK, but (sorry if it's a dumb question) how does the
process know which IP address to use.  I'm thinking of a user on this
machine (say) telnetting to another host... which IP source address
is used if there are two (or more) assigned to the interface...?

--

Phil Royse     Comms Consultant  |  PRA Consulting Ltd.
TUDOR HOUSE                      |
Surrey  CR8 4LN (UK)  Tel: (+44) 81 645-9868   proyse@peeras.demon.co.uk


-----------[000194][next][prev][last][first]----------------------------------------------------
Date:      Sat, 9 Jul 1994 19:53:09 +0000
From:      proyse@peeras.demon.co.uk (Phil Royse)
To:        comp.protocols.tcp-ip
Subject:   Re: Implementing IP address extensions

In article <1994Jul6.185228.3682@bay.cc.kcl.ac.uk>
udaa055@bay.cc.kcl.ac.uk "Andy Harper, KCL Systems Manager" writes:

>An oft discussed question is how the IP addresses used on Internet can be
>extended now that the explosion in personal computers and connectivity has left
>the 32-bit address space looking a bit sick! Rumour has it that, if growth
>increases at the same rate as currently, we'll run out of addresses in the near
>future.

[stuff deleted]

>So, what options are there that don't require all and sundry who use Internet
>to spend wads of cash and/or find upgraded network applications that understand
>
>Andy Harper
>Kings College London

Yes, wads of cash, it's bound to be.  I've follwed all the stuff on IPng,
TUBA, SIPP CATNIP and now Big Ten (?).  None of them will be a low-cost
migration.

I just think that people will become more careful over address allocation.
I have already floated at least two heretical ideas and one neutral one...

The neutral one is that DHCP will make life a lot easier and allow
N temporary users (e.g. PCs) to share M addresses on a " lease " basis.

The heretical ideas:

1.	there are many more TCP/IP users who don't want to connect
to the Internet and fewer organisations *need* to.  Most of academe
(as your good selves) is connected.  Corporations who have "a few"
technical people who can justify Internet connectivity will
probably settle for clever use of firewalls and proxy telnet, ftp etc.

2.	there may come a time when IP address space is so scarce
that some people will offer it for sale and some will buy it.... well,
it happens with some very unusual commodities....  Wimbledon tickets,
cherished number plates, antique toys, trade marks... why not:

"For sale: 123.1.29 to 32  only one owner, $5,000 o.n.o." "PLUS - an X.21 PPP link into our Internet router, only$4,000 pa."

Any thoughts?

Phil

--

Phil Royse     Comms Consultant  |  PRA Consulting Ltd.
TUDOR HOUSE                      |
Surrey  CR8 4LN (UK)  Tel: (+44) 81 645-9868   proyse@peeras.demon.co.uk


-----------[000195][next][prev][last][first]----------------------------------------------------
Date:      Sat, 9 Jul 1994 20:41:10 GMT
From:      wdawson@willard.atl.ga.us (Willard Dawson)
Subject:   Re: Obtaining Ethernet/MAC Network Addresses From Sun System

wllarso@sandia.gov (William L. Larson) writes:

>I am interested in identifying the Ethernet/MAC address for the network
>interfaces on a Sun computer running 4.1.3.  My situation is that I
>have three Ethernet interfaces plus one FDDI interface, but Sun only
>reports a single MAC address for the system which is for the first
>Ethernet interface.  All other network interfaces report the same MAC

>Is anyone aware of any mechanism for obtaining the Ethernet addresses
>for the second and third Ethernet interfaces along with the MAC address
>for the FDDI interface?

>Responses via Email are most appreciated.  Thanks

Oh, and just to complicate your data collection by adding this data
point by news instead of by email:  There is a bit of code that is
referenced in one of the SunSolve documents that purports to show

1)  Due to a problem on SunSolve, or in the original document, the
source code is obviously not clean, with the beginning of the
program re-appearing in the middle of the listing.
2)  Even after being fixed up, the program does not compile under
SunOS nor under Solaris 2.3.  That is, there are undefined
DEFINE symbols that do not exist under /usr/include/*.h nor in
/usr/include/sys/*.h... the code is probably BSD stuff, instead of
SunOS stuff.

So, I've not really helped you, yet... which is why I'm interested in


-----------[000196][next][prev][last][first]----------------------------------------------------
Date:      Sun, 10 Jul 1994 03:30:23 GMT
From:      samg@netcom.com (Sam Ghandchi)
To:        comp.protocols.tcp-ip
Subject:   Need to Find TTCP???

Hi

I am looking for TTCP.  Could you tell me where
I can find it?

TIA,
- Sam Ghandchi
samg@netcom.com


-----------[000197][next][prev][last][first]----------------------------------------------------
Date:      Sun, 10 Jul 1994 03:32:13 GMT
From:      samg@netcom.com (Sam Ghandchi)
To:        comp.protocols.tcp-ip
Subject:   Any Info on TK/TCL would be appreciated


Is there any newsgroup where TK/TCL expert programmers
discuss topics?

Any info is appreciated.

Regards,
- Sam Ghandchi
samg@netcom.com


-----------[000198][next][prev][last][first]----------------------------------------------------
Date:      10 Jul 1994 16:45:52 -0700
From:      tbrink@crl.com (Tom Brink)
To:        comp.protocols.tcp-ip
Subject:   Re: Variable Subnetting

mike@ozonline.com.au (Michael Bethune) writes:

>used with say, OSPF based routing.

>Specifically, All host based TCP/IP implementations that I'm aware of only
>recognise non-variable sub-netting, ie through RIP or other implementation.

>My understanding is that such hosts will make sub-optimal routing decisions
>without full knowlege of the network significant part of the IP address.

OSPF is more practical in a Wide Area Network sense, not a LAN.  We use
OSPF for our WAN, then flood RIP (or default route) into the LAN.  Default
Route works better, as the local subnet mask will probably not do for RIP.
--
/|                          Tom Brink
\o.0'                         tbrink@crl.com
U ACK!THPTPTPT!


-----------[000199][next][prev][last][first]----------------------------------------------------
Date:      Sun, 10 Jul 1994 09:58:27 +0000
From:      tfl@psp.co.uk (Thomas F Lee)
To:        comp.os.ms-windows.networking.tcp-ip,comp.os.ms-windows.programmer.networks,comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject:   Re: DNS

In article <9407070706.AA01007@ariake.nwk.cl.nec.co.jp>
mweiss@nwk.cl.nec.co.jp "Michael J. Weiss" writes:

> Can someone explain what DNS is?

DNS = Domain Name Server

A DNS server is a _server_ which resolves _Host Names_ into _IP Addresses_.
A host name is a textual name for a particular host on a TCP/IP internetwork
whilst the IP address is a 32-bit address which the lower levels of the
protocol require.

DNS is covered by two rfc's: RFC1034 which describes the concepts and
faciliteis and RFC1035 which details the implementation and specification.
The most common implementation of DNS is called BIND - Berkely Internet
Name Domain server.

> Also, what does it have to do with DHCP?

Not a lot really.  DHCP, Dynamic Host Configuration Procotol, is a protocol
which a host uses a server to give the host an IP address.	If a host
does not know or have it's IP address, DHCP could be used to deliver it.
This has a lot to do with both diskless workstations (which use bootp to
determine ip address and then tftp to load the hosts's boot image).  DHCP
is based on bootp.

Where I think there may be a connection relates to the inclusing of DHCP and
WINS in Daytona.  In Daytona NTAS, the NTAS box can be a DHCP server. NT
and WfWG boxes can then use the server to give the client's their IP address.
The connection is that DHCP will then pass WINS (Windows Internet Name Service)
the IP address so that WINS can then be used as an alternative to DNS
for resolving IP addresses.  WINS is a part of Daytona (server bits being
in Daytona NTAS and client facilities in Daytona Desktop, and in the
Wolverine client for W4WG).

We played with this a bit during last week and the DHCP stuff works
great.  Didn't really have much time to explore WINS though.  Documentation
on DHCP can be found on gowinnt.microsoft.com (there is a DHCP.DOC Word
and RFC 1533.

Hope this helps.

Thomas
--
+-----------------+---------------------------+
! Thomas F Lee    !  Voice: 0628 850 077      !
! tfl@psp.co.uk   !  Fax  : 0628 850 143      !
+-----------------+---------------------------+


-----------[000200][next][prev][last][first]----------------------------------------------------
Date:      10 Jul 1994 14:17:04 GMT
From:      gerryw@hpbrak42.uksr.hp.com (Gerry WINSOR)
To:        comp.protocols.tcp-ip
Subject:   IP Usage Billing package ?

Hi,

Anyone aware of a commercially available "TCP/IP Billing" package which'll
use actual IP usage rates as the billing calculation ?

GerryW

--
____________________________________________________________________________
**************
**** /_ _ ****   "Mr. Osborne, sir, may I be excused ?
*** / //_/ ***    My brain is full."
****  /   ****                 		- Larson
**************

Gerry Winsor            HPDESK:      Gerry WINSOR/HP8005/OA
Hewlett-Packard Ltd     UnixMail:    gerryw@hpbrak42.uksr.hp.com
Mailstop Q3             X.400 :      WINSOR,Gerry/HP8005,OA/HP/GB/GOLD 400/HP
Cain Road, Bracknell    Telephone:   (+44) 344 362384
Berks.  RG12 1HN.       Fax:         (+44) 344 362199
United Kingdom          Telnet:      316-2384
VoiceMail:   316-2384
____________________________________________________________________________


-----------[000201][next][prev][last][first]----------------------------------------------------
Date:      Sun, 10 Jul 1994 15:26:15 GMT
From:      bear@world.std.com (William J Sanderson)
To:        comp.protocols.tcp-ip
Subject:   ARCHIE  request and its port and protocols

When performing ARCHIE lookups on the net, does ARCHIE user TCP or UDP or
both packets.  Also is there a "known" port for ARCHIE???

Thanks

Bill Sanderson
wsanders@ccmg.lotus.com


-----------[000202][next][prev][last][first]----------------------------------------------------
Date:      Sun, 10 Jul 1994 17:20:40 GMT
From:      samg@netcom.com (Sam Ghandchi)
To:        comp.protocols.tcp-ip
Subject:   I am looking for an EXPERT TK/TCL PROGRAMMER $55.00/hr  I am looking for a TK/TCL Expert Programmer. I can pay$55.00/hr.  Knowledge of X.25/Frame Relay/SMDS/ATM and
Fiber is a plus.

The contract will be a six month contract
with possibility to extend.  The location is the
Milpitas area. Please send resume and salary
history to:

samg@netcom.com (Sam Ghandchi)


-----------[000203][next][prev][last][first]----------------------------------------------------
Date:      10 Jul 1994 17:39:18 GMT
From:      mike@ozonline.com.au (Michael Bethune)
To:        comp.protocols.tcp-ip
Subject:   Variable Subnetting

used with say, OSPF based routing.

Specifically, All host based TCP/IP implementations that I'm aware of only
recognise non-variable sub-netting, ie through RIP or other implementation.

My understanding is that such hosts will make sub-optimal routing decisions
without full knowlege of the network significant part of the IP address.


-----------[000204][next][prev][last][first]----------------------------------------------------
Date:      Sun, 10 Jul 1994 23:00:42
From:      tnemeth@immuno.imvs.sa.gov.au
To:        comp.protocols.tcp-ip
Subject:   Re: Does anyone know of a scriptable telnet for Sun (or anything else?)


>I'd like to be able to run a script, a bit like a uucp script, but to
>a telnet server.

Why don't you try the latest C-Kermit?


-----------[000205][next][prev][last][first]----------------------------------------------------
Date:      10 Jul 1994 18:35:51 GMT
From:      gloria@cais.cais.com (Gloria Fu)
To:        comp.protocols.tcp-ip
Subject:   Help Configuring MacPPP????  and TCP

Hello!  I have been trying to configure my MacPPP on my computer.  I have
actuallly tried MacSlip, InterSLIP and now have been steered toward
MacPPP.  After reading the directions, I still get the message "MacPPP down".

I have a PB 180 with a Global Village Powerport Gold Internal Modem.  I
have been told that because the modem is not Hayes compatible, it has led
to problems with my provider.  The provider uses the basic Unix shell,
but still I have had enormous difficulties trying to get the SLIP
connection.  I don't even get a dial tone.

Any suggestions?

Gloria Fu
gloria@cais.com


-----------[000206][next][prev][last][first]----------------------------------------------------
Date:      10 Jul 1994 18:52:55 GMT
From:      skendric@fred.fhcrc.org (Stuart Kendrick)
To:        comp.protocols.tcp-ip
Subject:   Re: Connecting Appletalk+ethernet+SLIP internet

You need an IP router.  I've never heard of a software-based one which
will support dial-up via SLIP on one interface.  I think you are stuck,
without spending the bucks for a hardware-based solution.

--sk

In article <CsH34F.Dsn@discus.technion.ac.il>
s2929773@techst02.technion.ac.il (Yosefi Ori ) writes:

> Hi,
>
> I wanted to know if there is any way I can connect an existing
> Appletalk network (consisting of an EtherTalk Zone and A localtalk zone)
> to the Internet Over a SLIP connection (Dial Up).
>
>
> I installed MacTCP on the computer with the modem and I can use the internet
> OK, but I can't manage to use the internet from another Mac (Not having a modem)
>
> Is there any way to cause Macs to sends their Packets throuhgh another one?
>
> Thank a lot for any help,
>
> Ori Yosefi.

Stuart Kendrick
FHCRC


-----------[000207][next][prev][last][first]----------------------------------------------------
Date:      11 Jul 1994 08:15:14 -0700
From:      jantypas@ccnet.com (John Antypas)
To:        comp.protocols.tcp-ip
Subject:   Is this a crazy idea?


I have a client that would like to connect his office machine and
a few dialin employees to the Internet.  While the traditional solutions
would work, would the following also work?

- Client buys a 56Kb CSU
- Client gets a Portmaster terminal server or equiv.
- Provider provides an async framed PPP via the CSU to the portmaster.
- Everyone else just runs off the portmaster using it as a router.

Does this buy anything?  The portmaster can be had for about $900, a CSU for about$300.
--
John Antypas@21st Century Softwware (jantypas@soft21.s21.com)

"God is too busy to create chaos and disorder in this world, he can't be
everywhere at once all of the time,  That's why he made two year olds"
"


-----------[000208][next][prev][last][first]----------------------------------------------------
Date:      Sun, 10 Jul 1994 21:44:04 GMT
From:      geertj@ripe.net (Geert Jan de Groot)
To:        comp.protocols.tcp-ip
Subject:   Re: Fake network addresses

In <2vmnhl$fma$1@heifetz.msen.com> emv@garnet.msen.com (Edward Vielmetti) writes:

>: : I was of the understanding that there is a Class A or maybe a Class B
>: : address that is reserved and not allocated to anyone on the Internet,
>: : The purpose is to alllow private networks that do not/can not/will not
>: : connect directly to the Internet the opportunity to have an address space
>: : that will not conflict with or confuse anyone's routing tables.

>: 1597  I    Y. Rekhter, R. Moskowitz, D. Karrenberg, G. de Groot, "Address
>: 	   Allocation for Private Internets", 03/17/1994. (Pages=8)
>: 	   (Format=.txt)

>There's a response to this RFC by E.Fair (Apple), E.Lear (SGI) et
>seq. that notes that it is not unusual for networks originally
>designed as "will not connect" to be either connected to other
>corporate private nets or eventually to the whole world.

That really depends. First, I highly doubt that applications like
electronic door relays (for access control) will ever need public
access. You can think of this as a niche but we have cases where
people have more than 100000 of these devices. If you think they
need public address space; fine, but do realize that we will all
suffer because we will run out of address space much more quickly.
(I can tell; the RIPE NCC is the regional registry for Europe and
I make my living working on applications like these).

The second kind of applications are the enterprizes that want to
have a class B so they can assign a class C network number to
each of their 30-host subsidiaries, 15 in total, because this
makes administration very convienent. According to
current guidelines, their class B application would be denied and
they would get something like 8C's or some more if they can justify it.
Some organisations *really* want a B and RFC1597 gives them an
alternative.

We frequently get applications for organisations applying for a
class A so they can assign a B to each of their subsidiaries.
For Europe alone, we get something like 8 of these per year.
I hope you agree that it is a good thing that some of these
can be addressed using RFC1597. What to think of an electricity
company that wants an A to address each eletricity meter?

Please recognize that the vast majority of TCP/IP applications
is *not* Internet-connected. Why would they be forced to comply
to assignment efficiency guidelines when they could care less
about Internet connectivity? Again, RFC1597 provides an alternative.

The address space defined in RFC1597 makes certain that if such
an organisation wants external connectivity after all, there will
be no routing ambiguity. In contrast, if you would pick a random
number as suggested in RFC1627, say, network 15.0.0.0, you will
*never* be able to talk to HP (to which 15.0.0.0 has been
assigned to).
You think that is unrealistic? Talk to the network people at
space (194.0.0.0 is the class C block from which class C number
assignments are done in Europe).
In contrast, RFC1597 specifies that if you are using network 10.0.0.0,
that network will *never* show up on the Internet itself and your
firewall will *always* be able to speak to other organisations
(even if they use network 10 too, their firewall would not,
so you can talk to your firewall, the firewall can talk to
their firewall, and their firewall can talk to their internal net 10).
I fail to see how picking a number as per RFC1627 can guarantee this.
(and there is no such thing as address space that will never be
using up *all* address space, including chopping up class A's
to smaller chunks for assignment).

Concerns that firewalls will not be needed in future network developments
will not hold either. While I agree that future authentication
improvements will make life easier, it will take a long while for these
to get implemented. There is no guarantee that there will not be
programming errors which cause security flaws. There is no guarantee
that all machines in your network will be upgraded to the lastest,
safest, version. Someone might want to bring in his own machine
and connect it to your network.
If your bank would connect to the Internet in full, and a cracker
would use a flaw and get all data on your financial situation
(including mortgages, loads and debts), you can do whatever you want
but your data will still be out there. A bank will very likely not
open up itself to this kind of liability.
If someone breaks into your engeneering machine, stealing
confidential design data, you can close the security hole after the
fact but the competition will still have information on your future
designs.
Therefore, people will continue to deploy firewalls.

We have to recognize that IPv4 will be here for a long time to
come. Whatever IPng will be decided in Toronto, it will take at
least 3 years for mature implementations to become available
and older equipment to die off.
After that, it will take a considerable  amount of time for
people to migrate, at least 5 years. In non-technical environments,
people usually plan to depreciate their equipment over a long
period so this time scale is not unrealistic.
We don't want to run out of address space in that time, do we?

One can think of forcibly getting address space back to the
Internet Registries, as suggested in RFC1627. I think this will
not work. How would you react if someone would say: 'based on
the current size of your network, we will reassign the top half of
your class B network to someone else by jan 1st, 1995'?
You might even sue me.

If you want address space, you have 3 choices:

1. Obtain official address space. Plan to come up with extensive
documentation on how you will set up your network, and what
the future plans will be. Your initial plan should be at least
10% efficient.

2. Use private address space as defined in RFC1597. You can be
The behaviour with respect to external connectivity,
is closely defined.

3. Use private address space, but pick a number as per RFC1627.
You can still be liberal assigning address space. However,
external connectivity behaviour is completely undefined
and there will be cases where communication will be impossible.

I don't like to say 'no' to many of the applications I see but
unfortunately, this is the current situation. RFC1597 provides
relief to those applications that do not want to plan for
efficient network utilisation but still want defined behaviour
for their external connectivity.

We (Yakov, Bob, Daniel and me) have been asked to write a rebuttal
document by various people. We are currently evaluating the
situation but feel that such a discussion should not be done
via RFC documents series and we will have some discussion first.
It will likely be discussed at the next IETF.

We have been informed that the allocation of address space,
as defined in RFC1597, stands. If you choose for option 2 above,
there will be no routing ambiguity for your firewall hosts.

Geert Jan


-----------[000209][next][prev][last][first]----------------------------------------------------
Date:      Mon, 11 Jul 1994 02:12:59 GMT
From:      hsm@unislc.slc.unisys.com (Helge Moulding)
To:        comp.protocols.tcp-ip
Subject:   Re: Max IP packet length and MTU

Rick Jones wrote,
: Lest anyone think that I am trying to ferment revolution
As long as it is good to drink...

: and start
: flooding the Internet with IP fragments, as much as what I've been
: saying has been to challenge assumptions to ascertain their validity.
: Particularly the one that says that IP Fragmentation is "expensive"
: (an unfortunately vague term) [...]
The implementation of TCP-IP that I am familiar with incurs fragmentation
costs principally during reassembly, due to the fact that received
fragments must be staged until all fragments are there. Since higher
layers (particularly TCP) may (or must) do the same, CPU cost isn't
nearly as significant as buffer cost.

As far as routers are concerned, however, the best performance is
reached when the software needs only to decrement the hopcount,
adjust the checksum and call the packet driver for the outgoing
interface. I suspect that when adding the need to fragment, no matter
how sophisticated the pointer-handling capabilities, the performance
may suffer by much more than just a factor of two or so.

I find that remembering that I am not the only one pulling shenanigans
on the network helps put things like this into perspective... Also
keep in mind that (usually!) the only time that *router* fragmenting
occurs is when the routers are connecting two disparate media: 802.3
to FDDI, ferinstance. Chances are that the differing data transfer
rates of the two media may already be creating all kinds of gremlins...

I suppose "expensive" is still vague, but, hey, so is "enchilada"...
--
Helge "How many Megs must a man install before his PC
is a host...?" Moulding
(Just another guy who is only human)
------------------------------------------------------------------------------
It is a curious fact that when a man is acting most like an animal,
he excuses his behavior on the grounds that he is "only human."
-- paraphrased from _The_Fringe_of_the_Unknown_ by L.Sprague de Camp
------------------------------------------------------------------------------


-----------[000210][next][prev][last][first]----------------------------------------------------
Date:      Mon, 11 Jul 1994 13:10:38 -0500
From:      amanda@intercon.com (Amanda Walker)
To:        comp.protocols.ppp,comp.protocols.tcp-ip,comp.sys.mac.comm
Subject:   Re: where can I get the interSLIP for MAC?

messina@mcs.com (David Messina) writes:
> Sorry to step on your toes, Amanda. :)

No problem.  We actually haven't had problems with people copying it around
indiscriminately, but our legal beagles don't want anyone to think it's in the
public domain :)...

Amanda Walker
InterCon Systems Corporation


-----------[000211][next][prev][last][first]----------------------------------------------------
Date:      Mon, 11 Jul 1994 06:26:12 GMT
From:      mintz@cup.hp.com (Ken Mintz)
To:        comp.protocols.tcp-ip
Subject:   Re: Book Review - TCP/IP Illustrated, Volume 1

Tom Limoncelli (tal@Warren.MENTORG.COM) wrote:
> >We certainly don't need a review on
> >6 month old movies OR 6 month old books.
>
> ----------------------------- by Tom Limoncelli
> I thought the movie Philadelphia was excellent and brought a very
> hidden (but pervasive) issue to an audience that would usually not deal
> with, nor appreciate, such issues until they were facing them head-on.

Thanks for the timely review.  I had not seen the movie, wasn't even aware
of it.  Your review has heightened my interest.

-- Ken Mintz (allegorically speaking; touche'!)


-----------[000212][next][prev][last][first]----------------------------------------------------
Date:      Mon, 11 Jul 1994 07:45:43 +0000
From:      proyse@peeras.demon.co.uk (Phil Royse)
To:        comp.os.ms-windows.networking.tcp-ip,comp.os.ms-windows.programmer.networks,comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject:   Re: DNS

In article <773834307snz@psp.co.uk> tfl@psp.co.uk "Thomas F Lee" writes:

>A DNS server is a _server_ which resolves _Host Names_ into _IP Addresses_.
>
>We played with this a bit during last week and the DHCP stuff works
>great.  Didn't really have much time to explore WINS though.  Documentation
>on DHCP can be found on gowinnt.microsoft.com (there is a DHCP.DOC Word
>document by J Allard - worth reading).

Thomas,  what were using for the DHCP server?  an NTAS system? Beta?

I have got the TCP-32 Beta stack working between my two WfWG 3.11
PCs here, and I would like to play with DHCP, ahead of advising some
clients on this.

Phil

--

Phil Royse     Comms Consultant  |  PRA Consulting Ltd.
TUDOR HOUSE                      |
Surrey  CR8 4LN (UK)  Tel: (+44) 81 645-9868   proyse@peeras.demon.co.uk


-----------[000213][next][prev][last][first]----------------------------------------------------
Date:      Mon, 11 Jul 1994 16:45:34 -0500
From:      netguide@panix.com
To:        comp.protocols.ppp,comp.protocols.tcp-ip,comp.sys.mac.comm,comp.sys.mac.misc,comp.sys.mac.wanted
Subject:   SLIP and PPP Clients/Dynamic Addressing


I am interested in finding out what SLIP and PPP clients there are
available for the Macintosh besides InterSLIP, InterPPP and MacPPP.
Additionally, I am looking for the ability to utilize dynamic IP
addressing; I would be very interested in any packages that make this
(easily) possible.

Does anyone have any suggestions?
(email copies of posts appreciated)

David Wood
obsidian@panix.com


-----------[000214][next][prev][last][first]----------------------------------------------------
Date:      11 Jul 1994 15:06:32 -0400
From:      jmb@kryten.atinc.com (Jonathan M. Bresler)
To:        comp.protocols.tcp-ip
Subject:   subnetting


having just read rfc950 again, i understand the following to apply
to subnetting.

1.	the "all subnet bits 0" subnet should not be used as a physical
network.
2.	the "all subnet bits 1" subnet should not be used as a physical
network.
3.	no host should be "all host bits 0"
4.	and no host at "all host bits 1"

so....

#subnet bits	#of subnets	#of hosts	#lost addresses
due to subnetting

1		0		 0 * 126	all = 254
2		2		 2 *  62	2 * 62 +  2 * 2 = 128
3		6		 6 *  30	2 * 30 +  6 * 2 = 72
4		14		14 * 14		2 * 14 + 14 * 2 = 56
etc

is this correct?

jmb
--
Jonathan M. Bresler  jmb@kryten.atinc.com	| Analysis & Technology, Inc.
| 2341 Jeff Davis Hwy
play go.					| Arlington, VA 22202
ride bike. hack FreeBSD.--ah the good life	| 703-418-2800 x346


-----------[000215][next][prev][last][first]----------------------------------------------------
Date:      11 Jul 1994 15:10:29 -0400
From:      brain@msen.com (Jim Brain)
To:        comp.protocols.tcp-ip,comp.protocols.ibm
Subject:   Re: Problems with IBM OS/2 TCP/IP implementation

Well, I want to thank everyone who helped me with my problem.  To expound:

I was trying to code up some sockets stuff, and I got the code from a co-
worker who has recently left the company.  The code worked on his machine, but
not on mine when I tried it.  On the server I got:

Sent 108 bytes
Sent 108 bytes
.
.
.
Sent 108 bytes   (10th send)

...

I thought TCP had record delimiters, but it does not.  Aha, as many people
told me, I have to create them myself.

I stole the solution from "Client/Server Programming for OS/2 2.0" to fix
the problem.

Pseudo code:

Send{

send length in network order
send data

}

Recv{

read data until you get 4 bytes.
change to host from network format.
read in data until you get length number of bytes.
}

Took a few compiles to get h->n n->h number conventions tucked away, but...

It now works!

Now, if someone could just tell me how to get my TCP/os/2 machine to
quit asking the nameserver for the address to go to, as it installed in my
local hosts file.  But at least the dang stuff works.

What's funny, is that I have read the books on sockets in an effort to learn
all about it, but nowhere did I see this caveat.  I guess it is implied.

Thanks to all who helped.

Jim


-----------[000216][next][prev][last][first]----------------------------------------------------
Date:      11 Jul 1994 09:47:18 GMT
From:      phrrngtn@dcs.st-andrews.ac.uk (Paul J. J. Harrington)
To:        comp.protocols.tcp-ip
Subject:   Re: Does anyone know of a scriptable telnet for Sun (or anything else?)

tnemeth@immuno.imvs.sa.gov.au writes:

>>I'd like to be able to run a script, a bit like a uucp script, but to
>>a telnet server.

>Why don't you try the latest C-Kermit?

Or Libes' "expect"

pjjH

--
Paul Harrington, phrrngtn@dcs.st-andrews.ac.uk  	 +44 334 463261
Division of Computer Science, St Andrews University, Scotland KY16 9SS


-----------[000217][next][prev][last][first]----------------------------------------------------
Date:      Mon, 11 Jul 1994 10:22:07 GMT
From:      jmi@csd.cri.dk (John Mills)
To:        comp.protocols.tcp-ip
Subject:   Re: Any Info on TK/TCL would be appreciated

In article 34x@netcom.com, samg@netcom.com (Sam Ghandchi) writes:
>
>Is there any newsgroup where TK/TCL expert programmers
>discuss topics?
>

comp.lang.tcl

>Any info is appreciated.
>
>Regards,
>- Sam Ghandchi
>samg@netcom.com
>


-----------[000218][next][prev][last][first]----------------------------------------------------
Date:      Mon, 11 Jul 1994 13:11:13 GMT
From:      igb@fulcrum.co.uk (Ian G Batten)
Subject:   Re: Obtaining Ethernet/MAC Network Addresses From Sun System

In article <2vkeq7$bsd@somnet.sandia.gov>, William L. Larson <wllarso@sandia.gov> wrote: > Ethernet interface. All other network interfaces report the same MAC > address. That's because Suns as standard use the same MAC address for each interface. This is quite legal, and is I believe actively encouraged by the specs. ian  -----------[000219][next][prev][last][first]---------------------------------------------------- Date: Mon, 11 Jul 1994 13:30:26 GMT From: larryp@sco.COM (Larry Philps) To: comp.protocols.tcp-ip Subject: Re: How to use UDP in interrupt manner with SCO sV r3.2 v4.0?  In <2vh3ab$e3l@cumulus.CAM.ORG> imatex@CAM.ORG (Imatex Communications Inc.) writes:

> I want to acheive communications between many servers (that don't
> communicate to each other) and many clients (that don't communicate to
> each other neither) using UDP protocol.
>
> I would prefer to work in asynchronous communication, since each clients must
> wait for their stdin to receive data to be transmitted on the lan.
>
> I tought to use SIGIO as described by Richard Stevens in Unix Network
> Programming. Since I am developping on SCO Unix System V release 3.4
> version 4.0, SIGIO is not available. I also took a look to streams, but I
>
> So far, as I've seen, the only way to use streams in TCP/IP
> communication is via TLI. Tell me I am wrong!

SCO has a BSD socket layer that sits on top of the STREAMS implemenation
of TCP/IP, and allows you to program to the sockets interface just like
on BSD based systems.  There is no SIGIO, but asynchronous I/O is indeed
possible, it uses SIGPOLL.

> Any sugestion, with C code examples, will be VERY helpfull.

#define SIGIO SIGPOLL

sigset(SIGIO, input_handler);

int pid;
int s;
int on;

/* Create socket */
if ((s = socket(AF_INET, SOCK_DGRAM, 0)) < 0) {
perror("socket");
exit(1);
}

/* Mark this process as the one to receive async I/O signals */
pid = getpid();
if (ioctl(s, SIOCSPGRP, &pid) == -1) {
perror("ioctl: SIOCSPGRP");
exit(1);
}

/* Turn on non-blocking I/O */
on = 1;
if (ioctl(s, FIONBIO, &on)) {
perror("ioctl: FIONBIO");
exit(1);
}

/* Turn on async I/O */
on = 1;
if (ioctl(s, FIOASYNC, &on)) {
perror("ioctl: FIOASYNC);
exit(1);
}

---
Larry Philps              Senior Software Engineer            larryp@sco.com
SCO Canada, Inc., 130 Bloor St. West, 10th floor, Toronto, Ontario.  M5S 1N5
Phone: (416) 960-4012                                    Fax: (416) 922-2704


-----------[000220][next][prev][last][first]----------------------------------------------------
Date:      Mon, 11 Jul 1994 13:33:30 GMT
From:      marka@syd.dms.CSIRO.AU (Mark Andrews)
To:        comp.protocols.tcp-ip
Subject:   Re: Variable Subnetting

In article <2vpbo6$bbv@budapest.ozonline.com.au> mike@ozonline.com.au (Michael Bethune) writes: >Anyone got any comments about the behaviour of variable subnetting >used with say, OSPF based routing. > >Specifically, All host based TCP/IP implementations that I'm aware of only >recognise non-variable sub-netting, ie through RIP or other implementation. > >My understanding is that such hosts will make sub-optimal routing decisions >without full knowlege of the network significant part of the IP address. > >Comments? Host which are not multi-homed need know nothing of the network other than how to find their default router. ICMP redirects should get them to the best router regardless of routing protocol being used or whether variable subnets are being used. Host should be using IRDP if available to find the default router. Multi-homed hosts are the only hosts that should potentially be listening routing protocols. This is regardless of whether they are acting as a router or not. Be carful with multi-homed machines as most of the current crop of OS's don't cope with having different netmasks on the same network. (BSD 4.4 derived system do cope with this senario.) I wouldn't want a machine to be listening to routing protocols in a variable subnet envirionment unless you know for sure that it can cope with variable subnets as it is actually more likly to misdirect packets. Mark  -----------[000221][next][prev][last][first]---------------------------------------------------- Date: 11 Jul 1994 13:47:53 GMT From: tpoind@advtech.uswest.com (Tom Poindexter) To: comp.protocols.tcp-ip Subject: Re: Any Info on TK/TCL would be appreciated  In article <samgCspGHp.34x@netcom.com> samg@netcom.com (Sam Ghandchi) writes: > >Is there any newsgroup where TK/TCL expert programmers >discuss topics? comp.lang.tcl - very active newsgroup, FAQ posted frequently, ftp archive site is harbor.ecn.purdue.edu -- Tom Poindexter tpoind@advtech.uswest.com or tpoindex@nyx.cs.du.edu U S WEST Advanced Technologies, Boulder, Colorado "I hate it when that happens"  -----------[000222][next][prev][last][first]---------------------------------------------------- Date: 11 Jul 1994 14:34:09 GMT From: rsalz@osf.org (Rich Salz) To: comp.protocols.tcp-ip,comp.client-server,comp.unix.internals Subject: Re: Data formats needed for non-XDR conversion  In <CsMpnq.8F9@calcite.rhyolite.com> vjs@calcite.rhyolite.com (Vernon Schryver) writes: >Instead of XDR, NCS had what its authors called "receiver makes it right" >but was jokingly known to others as "receiver makes it wrong." In fact, >NCS has a complicated version of XDR. Well, yeah, kinda. XDR is "use a canonical format." That is, everyone converts to a specified format and some machines pay a penalty. NCS is "pick a canonical format." That is, everyone can convert to one of a couple of different formats and everyone must know all of them. In theory this is ugly and leads to bloated code. In practice, there are two integer formats and three or four floating point formats. Contrary to what Vernon says, the NCS scheme was believed to be better in a heterogenous world, not a closed world. Nobody really knows which method is better because nobody has done any comparisons, at any level: cost of marshalling on both sides, and cost of marshalling in comparison to a typical RPC (and what is a typical RPC, anyway). /r$


-----------[000223][next][prev][last][first]----------------------------------------------------
Date:      11 Jul 1994 17:18:00 GMT
From:      carlson@Xylogics.COM (James Carlson)
To:        comp.protocols.tcp-ip
Subject:   Re: Is this a crazy idea?

In article <2vrnm2$ksb@ccnet.ccnet.com>, jantypas@ccnet.com (John Antypas) writes: |> Am I insane for thinking about this? |> |> I have a client that would like to connect his office machine and |> a few dialin employees to the Internet. While the traditional solutions |> would work, would the following also work? |> |> - Client buys a 56Kb CSU |> - Client gets a Portmaster terminal server or equiv. |> - Provider provides an async framed PPP via the CSU to the portmaster. |> - Everyone else just runs off the portmaster using it as a router. |> |> Does this buy anything? The portmaster can be had for about$900, a CSU
|> for about $300. We do this here for connecting our East and West Coast offices through a sw56 link. (Although, of course, we use Annexen instead of Portmasters...) Some things to be aware of: - Asynch-to-synch converting CSU/DSUs don't do hardware flow control, so you'll have to run XON/XOFF over the link and properly configure PPP to mask these characters. - Lost XONs are a particular problem over such a link. You'll need to make sure that the vendor has made special provisions to handle this problem. (Namely, periodically outputting XON until new data are received.) - Asynch PPP is not compatible with synch PPP. You'll need to make sure that the other end of this link has the same type of encapsulation. (This may be a problem when connecting to Internet access providers.) -- James Carlson <carlson@xylogics.com> Tel: +1 617 272 8140 Annex Software Support / Xylogics, Inc. +1 800 225 3317 53 Third Avenue / Burlington MA 01803-4491 Fax: +1 617 272 2618  -----------[000224][next][prev][last][first]---------------------------------------------------- Date: Mon, 11 Jul 1994 17:59:45 GMT From: coghlan@bcarh5f8.bnr.ca (Patrick Coghlan) To: comp.protocols.tcp-ip Subject: How can I build an X sniffer (xscope?)  I want to intercept all packets between an X terminal and a host. I believe X runs over TCP so can someone please point me at: - relevant RFCs I should look at - what "tricks" I need to employ to intercept and forward all packets between the X terminal and the host Thanks in advance.  -----------[000225][next][prev][last][first]---------------------------------------------------- Date: Mon, 11 Jul 1994 18:31:10 GMT From: samg@netcom.com (Sam Ghandchi) To: comp.protocols.tcp-ip Subject: Re: Any Info on TK/TCL would be appreciated  THANKS A LOT FOR ALL THE REFERENCES. Regards, - Sam Ghandchi  -----------[000226][next][prev][last][first]---------------------------------------------------- Date: Mon, 11 Jul 1994 18:59:25 GMT From: donp@novell.com (don provan) To: comp.protocols.tcp-ip Subject: Re: A interesting routing quesiton.....  In article <1994Jul9.173631.559@dec8.ncku.edu.tw> tung@eespcb.ncku.edu.tw (Assistant) writes: >Here is a old network configuration of our lab: Very good picture. It told me everything I needed to know. I'll leave it out of the response for brevity and summarize as follows: you are trying to have four sub-subnets hanging off one of your subnets. The sub-subnets have a mask of ff.ff.ff.f0, while the subnet mask is ff.ff.ff.0. >We have set the netmask and default gateway of PCs connecting to port A,B,C,D >but at novell,we have some question here... OK, I'll answer the questions, but let me jump ahead and answer question 6 first, as it is the crux. >6. It is said that all the port of novell should has the same netmask, > is it true? The v1.00 version of the TCPIP.NLM, all subnets of a given network must have the same network mask. The routing protocol RIP does not support variable subnet masks, so that release of TCP/IP support for NetWare doesn't support them, either. V2.x releases of the TCPIP.NLM support something called proxy-ARP, which allows you to do exactly what you want. You can find that NLM in the v4.x releases of NetWare as well as the v2.x releases of Novell's MultiProtocol Router product. (It wouldn't surprise me to discover that this NLM is available on NetWire, but I can't recall whether it's been released that way or not.) Perhaps this is a good excuse to upgrade your NetWare to the v4.02 release? :-) I'll answer the other questions in the context of the v2.x TCPIP.NLM using proxy-ARP. >1. We load tcpip.nlm with tcpip=yes, rip=yes, anything else needed? No, that is sufficient. > Does tcpip.nlm ver 1.00 work fine? Yes, but it doesn't support this feature. There was, however, one deficiency (well, privately I'd admit it was a bug) in that it does not detect and prevent attempts to use variable subnet masks. In other words, you're problems have been somewhat magnified because TCPIP.NLM let you get a lot farther down a dead end then it really should have. >2. What netmask sould we set for port ABCD, FF.FF.FF.F0? Yes. >3. What gateway sould we set for port ABCD, 140.116.32.241? No. You should not specify any gateway. The GATEWAY parameter informs IP about a router on that network which leads out to the wider world. It should be used only when there is such a gateway that doesn't speak RIP. In this case, there are no gateways on your sub-subnets of any sort, so no GATEWAY parameter is appropriate >4. What netmask sould we set for port Z, FF.FF.FF.F0 or FF.FF.FF.00 > if ff.ff.ff.f0, how can hosts at port a, b, c, d connect to 140.113.32.xxx > not on ABCD? (ex:140.116.32.60) > Should we add static route to port Z? With proxy-ARP, the correct mask is the one you've been trying to use unsuccessfully with v1.0: ff.ff.ff.0. No static route is necessary; the routing will all be handled automatically by the v2.x NLM. >5. What gateway sould we set for port Z, 140.116.32.253? You can if you want. If 140.116.32.253 speaks RIP, it will be discovered automatically, so in that case the GATEWAY parameter would be redundant >7. The manual said that we'd better set RIP to off, why? I'm not sure what manual you're talking about, and I don't know why it would tell you to set RIP off. Perhaps it was only talking about a server not being used as a router? In your case, if you're already using RIP on your network, there's no reason not to let the NetWare router participate in the RIP conversation. >This is serious to us, any suggestion will be much appreciated..... I hope this helps. don provan donp@Novell.com  -----------[000227][next][prev][last][first]---------------------------------------------------- Date: Mon, 11 Jul 1994 20:14:10 GMT From: dowd@eng.buffalo.edu (Patrick Dowd) To: comp.protocols.tcp-ip Subject: SIGCOMM'94 Advance Program - Early registration deadline Aug 1  --------------------------------------------------------------- Please Note: the deadline for early registration is August 1st. --------------------------------------------------------------- Advance Programme ACM SIGCOMM'94 CONFERENCE Communications Architectures, Protocols and Applications University College London London, UK August 31 to September 2, 1994 (Tutorials and Workshop, August 29-30) Sponsored by The ACM Special Interest Group of Data Communication This conference provides an international forum for the presentation and discussion of communication network applications and technologies, architectures, protocols, algorithms, and performance models. The conference and tutorials will be conducted on the University College London, London England. ---------------------------------- T E C H N I C A L P R O G R A M ---------------------------------- Monday 29 August 1994 * 7:30AM - 5:00PM Tutorial and Conference Registration UCL CS Department, Pearson Building * 9:00AM - 5:00PM, Tutorial T1 "Personal Communication Services and Networks" Zygmunt Haas (AT&T Bell Labs) UCL CS Department, Pearson Building * 9:00AM - 5:00PM, Tutorial T2 "Protocol Performance" David D. Clark (MIT) UCL CS Department, Pearson Building Tuesday 30 August 1994 * 7:30AM to 5:00PM Tutorial and Conference Registration Edward Lewis Lecture Theatre, Windeyer Building * 9:00AM - 5:00PM, Workshop W1 "Topics in High Performance Networking Support of Distributed Systems" Derek McAuley (University of Cambridge) UCL CS Department, Pearson Building * 9:00AM - 5:00PM, Tutorial T3 "Fiber Optic Networks" Paul E. Green, Jr. (IBM Corporation) UCL CS Department, Pearson Building * 9:00AM - 5:00PM, Tutorial T4 "Multimedia Conferencing on the Internet" Van Jacobson (Lawrence Berkeley Laboratories) Edward Lewis Lecture Theatre, Windeyer Building * 9:00AM - 5:00PM, Tutorial T5 "Asynchronous Transfer Mode" Rainer Handel (Siemens Munich) UCL CS Department, Pearson Building * 5:30PM - 8:30PM Welcoming Reception The Quad at University College London Wednesday 31 August 1994 * 7:30AM to 5:00PM Conference Registration Edward Lewis Lecture Theatre, Windeyer Building * 9:00AM - 10:00AM Session 1: Keynote Address (1994 ACM SIGCOMM Award Winner) Edward Lewis Lecture Theatre, Windeyer Building * 10:30AM-12:30PM Session 2: Protocol Performance Experiences with a High-Speed Network Adaptor: A Software Perspective (Best Student Paper) P. Druschel (University of Arizona), L.L. Peterson (University of Arizona), & B.S. Davie (Bellcore) User-space Protocols Deliver High Performance to Applications on a Low-Cost Gb/s LAN A. Edwards, G. Watson, J. Lumley, D. Banks, C. Calamvokis, & C. Dalton (Hewlett-Packard Labs, Bristol) TCP Vegas: New Techniques for Congestion Detection and Avoidance L.S. Brakmo, L.L. Peterson, & S.W. O'Malley (University of Arizona) A Structured TCP in Standard ML E. Biagioni (Carnegie Mellon University) * 12:30PM - 2:00PM Lunch * 2:00PM-3:30PM Session 3: Congestion Management Making Greed Work in Networks: A Game-Theoretic Analysis of Switch Service Disciplines S. Shenker (Xerox PARC) Scalable Feedback Control for Multicast Video Distribution in the Internet J. Bolot (INRIA), T. Turletti (INRIA) & I. Wakeman (University College, London) Statistical Analysis of Generalized Processor Sharing Scheduling Discipline Z.-L. Zhang, D. Towsley, & J. Kurose (University of Massachusetts) * 4:00PM-5:30PM Session 4: ATM Flow Control The Dynamics of TCP Traffic over ATM Networks A. Romanow (Sun Microsystems) & S. Floyd (Lawrence Berkeley Labs) Reliable and Efficient Hop-by-Hop Flow Control C. Ozveren (DEC, Littleton), R. Simcoe (DEC, Littleton) & G. Varghese (Washington University, St. Louis) Credit Update Protocol for Flow-Controlled ATM Networks: Statistical Multiplexing and Adaptive Credit Allocation H.T. Kung (Harvard University), T. Blackwell (Harvard University), & A. Chapman (BNR) * 7:30PM - 10:00PM SIGCOMM Social: Reception and Dinner The Dinosaur Room, Natural History Museum (Tickets Required) Thursday 1 September 1994 * 7:30AM to 5:00PM Conference Registration Edward Lewis Lecture Theatre, Windeyer Building * 8:30AM - 10:00 AM Session 5: Internet Routing Flexible Routing and Addressing for a Next Generation IP P. Francis (NTT Software Labs) & R. Govindan (Bellcore) An Architecture for Wide-Area Multicast Routing S. Deering(Xerox PARC), D. Estrin (University of Southern California), D. Farinacci (Cisco Systems), V. Jacobson (Lawrence Berkeley Labs), C.-G. Liu (University of Southern California) & L. Wei (University of Southern California) Distributed Routing Based on Link-State Vectors J. Behrens & J.J. Garcia-Luna-Aceves (University of California at Santa Cruz) * 10:30AM-12:00PM Session 6: ATM Switching and Signalling Signaling and Operating System Support for Native-Mode ATM Applications R. Sharma & S. Keshav (AT&T Bell Labs) Experiences of Building ATM Switches for the Local Area D.R. McAuley, R.J. Black & I.M. Leslie (University of Cambridge) Controlling Alternate Routing in General-Mesh Packet Flow Networks S. Sibal (RPI) & A. DeSimone (AT&T Bell Labs) * 12:00PM - 1:30PM Lunch * 1:30PM-3:00PM Session 7: Nueral and Optical Networks On Optimization of Polling Policy Represented by Neural Network Y. Matumoto (I.T.S., Inc., Japan) An Optical Deflection Network J. Feehrer (University of Colorado, Boulder), L. Ramfelt (University of Colorado, Boulder/Royal Institute of Technology, Stockholm), & J. Sauer (University of Colorado, Boulder) Conflict-Free Channel Assignment for an Optical Cluster-Based Shuffle Network Configuration K.A. Aly (University of Central Florida) * 3:30PM-5:30PM Session 8: Selected Topics MACAW: A Media Access Protocol for Wireless LANs V. Bharghavan (UC Berkeley), A. Demers (Xerox PARC), S. Shenker (Xerox PARC) & L. Zhang (Xerox PARC) Asymptotic Resource Consumption in Multicast Reservation Styles D.J. Mitzel (University of Southern California) & S. Shenker (Xerox PARC) Highly Dynamic Destination-Sequenced Distance- Vector Routing (DSDV) for Mobile Computers C.E. Perkins & P. Bhagwat (IBM, Watson Research Center) A Methodology for Designing Communication Protocols G. Singh (Kansas State University) * 5:30PM - 6:30PM SIGCOMM Business Meeting Friday 2 September 1994 * 8:30AM - 10:00AM Session 9: Traffic Models Wide-Area Traffic: The Failure of Poisson Modeling V. Paxson & S. Floyd (Lawrence Berkeley Labs) Analysis, Modeling and Generation of Self-Similar VBR Video Traffic M.W. Garrett & W. Willinger (Bellcore) An Algorithm for Lossless Smoothing of MPEG Video S.S. Lam, S. Chow, & D. Yau (University of Texas, Austin) * 10:30AM-12:00PM Session 10: Host Software USC: A Universal Stub Compiler S.W. O'Malley, T. Proebsting, & A. Montz (University of Arizona) An Object-based Approach to Protocol Software Implementation C.-S. Liu (Chung Yuan Christian University, Taiwan) Improved Algorithms for Synchronizing Computer Network Clocks D.L. Mills (University of Delaware) * 12:00PM - 12:15PM Closing Session Note: Program subject to change. ----------------- T U T O R I A L S ----------------- Tutorial T1 ----------- Zygmunt Haas, AT&T Bell Labs "Personal Communication Services and Networks" The recent explosion of interest in wireless and mobile networks, stimulated by the effort of Personal Communication Services and Networks (PCS & PCN) to be deployed at the beginning of the next century, suggests the enormous technological, scientific, and commercial potential in this field. The subject of wireless and mobile communication integrates the large body of knowledge accumulated through the traditional radio research, the large networking experience accumulated through the proliferation of LANs and WANs, and the vision of ubiquitous connectivity anywhere, at anytime, with anyone, and in any format. The tutorial exposes both the theoretical and the practical aspects of mobile networking, from a networking and application perspective. We will present the concept, architecture, and functionality of Personal Communications Services and Networks (PCS & PCN) and Universal Personal Telecommunications (UPT) and we will describe the most common platform for mobile communications: the wireless systems. In particular, systems such as cellular, cordless, and satellite will be discussed. Existing and in-progress standards are also outlined. Finally, an abundance of examples of the wireless and mobile networks will be described, giving realism to the presented material. TOPICS: * Elements of Wireless Mobile Communications * Wireless Services and Applications * The Cellular Concept * The Cordless Concept * Digital Communication Networks * Local-Area Wireless Data Access * Wide-area Wireless Data Access * Mobile Satellite Communications * Standardization of Wireless Networks * PCS/PCN and UPT * Summary: Where we have started and where are going . Zygmunt Haas received his B.Sc. in EE in 1979 and M.Sc. in EE in 1985, both with Summa Cum Laude. From 1979 till 1985 he worked for the Government of Israel. In 1988, he earned his Ph.D. from Stanford University researching fast packet-switched networks, and subsequently joined AT&T Bell Laboratories in Holmdel NJ, where he is now a Member of Technical Staff in the Wireless Networks Department. Dr. Haas is an author of numerous technical papers and holds several patents in the field of high-speed networking, wireless networks, and optical switching. He has organized several workshops and served as a guest editor for JSAC issues. Dr. Haas is a Senior Member of IEEE and his interests include: mobile and wireless communication networks, personal communication services, high-speed communication protocols, and optical switching. Tutorial T2 ----------- David D. Clark, MIT "Protocol Performance" Getting proper performance from a network or protocol is often a difficult task. This tutorial uses examples from the Internet (TCP/IP) protocol suite to illustrate critical performance issues. The focus is on providing real-world advice on how to design and implement protocols in ways that avoid performance problems. The presentation will include examples of various performance problems and how to detect and recognize them. Topics * Performance issues (reliability, throughput and delay) * Implementation bottlenecks * Specifications and their limitations * Heterogeneity and its impact on implementation * Network dynamics * Visualizing protocol performance * Limits of protocol performance Dr. David Clark is a senior research scientist at MIT Laboratory for Computer Science and a recipient of the ACM SIGCOMM Award. He has worked on TCP/IP since the mid-1970s and from 1981 to 1989 was chairman of the Internet Activities Board. He is widely known for his insight into protocol design and performance and for his skill in identifying and eliminating myths about protocol implementation and performance. His current areas of research include high-performance networks, the evolution of the Internet, ATM and information networking. He received his doctorate from MIT in 1973. Tutorial T3 ----------- Paul E. Green, Jr., IBM "Fiber Optic Networks" Fiber optic technology has completely transformed the internal operation of the world's telephone networks and is beginning to impact local computer networks. Compared to the voice grade phone line technology, which defined most of the network architectures that we are still living with today, fiber offers ten orders of magnitude better bandwidth and an equal improvement in achievable bit error rate. By use of WDM and circuit switching, the additional benefits of protocol transparency can be achieved. There is a widespread feeling that the generation of network that will follow today's ATM and upgraded Internet structures might very well be based on techniques that directly unlock this revolutionary improvement at the physical level. The course is devoted to the new class of "all-optical" networks that attempt to do this. The lecturer will cover the optoelectronic components involved and will also treat some of the network architectural consequences, the regulatory and economic picture, and review some systems already implemented. TOPICS * Motivating fiber optic networks * Fibers, couplers and taps * Optical resonant structures * Laser diodes and amplifiers * Optical receivers * System considerations * Network topologies and link budgets * Protocols, layers and network control * Some implemented systems * Status and prospects Paul E. Green, Jr, is Manager of Advanced Optical Networking Member at IBM Research in Hawthorne, NY. He received the ScD degree from M.I.T. in 1953, and after some years at M.I.T. Lincoln Laboratory, where he made pioneering contributions to spread spectrum, adaptive receivers, radar astronomy and seismic data processing, he joined IBM Research in 1969. At IBM he has held a variety of management and Corporate Technical Staff positions. His technical interests have centered on computer network architecture, and he has received several IBM Outstanding Innovation Awards for his role in the initial formulation and promotion of Advanced Peer to Peer Networking, now the basis for further evolution of IBM's System Network Architecture. He is a member of the National Academy of Engineering, in 1983 was named Distinguished Engineering Alumnus by North Carolina State University, and received the IEEE's Simon Ramo Medal in 1991. He is the author of many technical papers, has edited several books on computer communications, and is the author of the textbook Fiber Optic Networks, published by Prentice Hall in June,1992. He has been President of both the IEEE Communication Information Theory Society and the Communication Society. Tutorial T4 ----------- Van Jacobson, LBL "Multimedia Conferencing on the Internet" An architectural overview and detailed walk-through of the protocols and applications that provide real-time, multiparty, audio, video and shared workspace conferencing on today's Internet. Experiments and demonstrations over the Internet MBONE and the DARTNET testbed have shown that multimedia and conferencing applications can indeed work over IP internets. Playback algorithms that adapt to variations in network delay (such as VAT) and information distribution algorithms designed to facilitate shared workspaces (such as those used in the shared whiteboard) have made these sorts of applications possible. This tutorial describes these algorithms and the applications that use them. Topics * IP as a real-time infrastructure: multicasting and queueing * Adaptive Playback: VAT * Managing Sessions: SD * Managing Shared Workspaces: Shared Whiteboard * Implications for the future of IP Van Jacobson is a senior researcher at Lawrence Berkeley Laboratories, where he works on real-time system performance, protocol and operating system performance. He is widely known for his groundbreaking work on TCP/IP performance, TCP/IP congestion control, and support for multimedia applications on the Internet. He is the recipient of a number of awards and teaches periodically at U.C. Berkeley and Stanford University. Tutorial T5 ----------- Rainer Handel, Siemens Munich "Asynchronous Transfer Mode" The tutorial will provide a comprehensive introduction to the Asynchronous Transfer Mode (ATM). Both technical and marketing aspects of ATM will be addressed. ATM specification is not yet complete but in a state that allows implementations which are basically compliant with a worldwide agreed, unique standard supporting data, voice, image and multimedia applications. The presentation of the concept of ATM networking will include the ATM protocol reference model, the architecture of ATM networks, interfaces and procotols, traffic control and resource management, signalling, operational aspects, ATM evolution and internetworking aspects, and of course a detailed description of the ATM layer and ATM adaptation layer functions. An overview of how ATM cells are switched and transmitted will also be given. The possible use of ATM in a business and residential environment and its market acceptance depending on product availability, cost and feature offerings will be clarified. TOPICS: * High speed networks * ATM concept * ATM protocols * ATM interfaces * interworking and evolvability * market aspects * switching and transmission products * network implementations and service offerings Rainer Handel has been with Siemens (Public Communications Networks Group) since 1978 doing system design and software development for switching systems, ATM conceptual and standardization work, ATM network and product planning, and currently long-term telecom market and technology trend evaluation. For several years he was active in the standards bodies CCITT, ETSI and T1, and is the author of several papers and a book on ATM. Workshop W1 ---------- Derek McAuley, University of Cambridge "Topics in High Performance Networking Support of Distributed Systems" This one day workshop will present the experiences of the speakers in building various components of distributed systems which aim to effectively utilise modern high performance networks. This workshop consists of 4 talks. Each talk will be 60 minutes with 15 minutes for discussion. 1. The CHORUS Communication Architecture, Marc Rozier The communication service is a key component of the CHORUS micro-kernel architecture. First, it provides the basic framework allowing efficient modular operating system implementations. By dramatically reducing the overhead of local communications, it is key to the success of such serverized implementations, which are now able to compete with monolithic implementations. Second, it provides efficient, network-transparent, communication services, well adapted to the distribution of the operating system servers. In particular, it makes possible the implementation of UNIX systems on massively parallel architectures, offering a single system image to their users. This tutorial will address the various aspects of this communication architecture, from the definition of the communication services, to some aspects of its implementation. Emphasis will be placed on insights from previous versions of this service. 2. The Organization of Networks in Plan 9, Rob Pike In a distributed system networks are of paramount importance. This tutorial describes the implementation, design philosophy and organization of network support in Plan 9. Topics include network requirements for distributed systems, our kernel implementation, network naming, user interfaces and performance. We also observe that much of this organization is relevant to current systems. 3. Mixed media applications, David Tennenhouse WWW is a rapidly growing phenomena which highlights the interesting applications possible with mixed media types. From experience with the WWW this tutorial will address the issues raised in supporting these mixed media types and the problems in building systems which support media with time constraints. 4. What can you do with ATM today?, Derek McAuley ATM must now be officially a bandwagon. Some will tell you it solves all the world's problems because it was designed to, while others will say it's good for nothing. The reality and hype are hard to distinguish. This talk will address what ATM can be used for today and highlight those features for which it is rightly criticised not least of which is end-system integration. The talk could be subtitled, "Difficult questions to ask your ATM salesman''. Marc Rozier is the head of the Micro-Kernel Department within Chorus systemes. He graduated from Ecole Nationale Superieure Informatique et de Mathematiques Applique'es de Grenoble (ENSIMAG) before earning a doctor's degree in Computer Science from Institut National Polytechnique de Grenoble (INPG). In 1981-82, he was involved in the CESAR project at IMAG (Grenoble), working on the Validation of Distributed Systems. He gained experience in programming languages for distributed applications and distributed systems. He joined INRIA in 1982 as a researcher in the CHORUS distributed operating system project. In 1987, he became one of the founders of Chorus systemes. He is one of the main designers of the CHORUS-v3 Micro-Kernel technology. He is the author of several publications in international journals and conferences. Rob Pike is well known for his appearances on "Late Night with David Letterman", is also a Member of Technical Staff at AT&T Bell Laboratories in Murray Hill, New Jersey, where he has been since 1980, the same year he won the Olympic silver medal in Archery. In 1981 he wrote the first bitmap window system for Unix systems, and has since written ten more. With Bart Locanthi he designed the Blit terminal; with Brian Kernighan he wrote The Unix Program- ming Environment. A shuttle mission nearly launched a gamma-ray telescope he designed. He is a Canadian citizen and has never written a program that uses cursor addressing. David Tennenhouse is an Assistant Professor of Computer Science and Electrical Engineering at MIT's Laboratory for Computer Science. He is leader of the Telemedia, Networks and Systems Group, which is addressing systems issues arising at the confluence of three intertwined technologies: broadband networks, high definition video and distributed computing. David studied electrical engineering at the University of Toronto, where he received his B.A.Sc. and M.A.Sc. degrees. In 1989 he completed his Ph.D. at the Computer Laboratory of the University of Cambridge. His Ph.D. research focused on ATM-based site interconnection issues. This work, which was conducted within the Unison Project, led to the early implementation of an ATM-based wide area testbed. Derek McAuley is a Lecturer in the Computer Laboratory at the University of Cambridge. His research interests include networking, distributed systems and operating systems. Recent work has concentrated on the support of time dependent mixed media types in both networks and operating systems. He has failed to leave Cambridge since arriving in 1979 to read Mathematics. In 1989 he completed his Ph.D. on ATM internetworking. He has had a hand in de-commissioning 4 ATM networks, including Tennenhouse's carefully constructed Unison platform. --------------- L o c a t i o n --------------- The conference will be held in the Edward Lewis Lecture Theatre which is located in the Windeyer Building on the UCL campus. This building is located on the corner of Cleveland Street and Howland Street, with the entrance on Cleveland Street. Tutorials are all in UCL Computer Science Department in the Pearson Building, except T4 (Van Jacobson) on the Tuesday which is held in the Edward Lewis Lecture Theatre. The main entrance of UCL is located at the north end of Gower Street, close to Euston Square, Warren Street, or Euston tube stations. The UCL Computer Science Department is located in the basement of the Pearson Building. Location --------------------------- T r a n s p o r t a t i o n --------------------------- * Getting to London There are four airports in and around London. Here is some information that might help you to plan your journey. Please consult your travel agency or the airports directly for further information. LONDON Heathrow Airport: 24 km west of London Telephone: +44-81-745-6156 LONDON Gatwick Airport: 46 km south of London Telephone: +44-293-535-353 STANsted Airport: 55 km north east of London Telephone: +44-279-680-500 * Getting to UCL and Hotels UCL is located in central London, and is served by Warren St, Euston and Euston Square Underground (tube) stations, as well as several main bus routes. The department of computer science is right by the entrance to the main quadrangles, on Gower Street. From Heathrow: Best by tube with Victoria Line to Euston Station (about #3, 50 minutes). Alternatives are via Bus with London Transport A1 Airbus to Victoria Station (45 minutes). For local hotels it is probably best to go to Euston Station and get a taxi from there unless you have a street map already and know the nearest tube station. A free tube map may be obtained at any ticket office. From Gatwick: Best by train, BR Gatwick Express to London Victoria Station every 15 minutes (about #8.60, 30 minutes). Unless you plan to sightsee outside London a car is probably a waste of time. Tube fares are based on a zone system. After 9:30AM you can get One Day Travel cards which allow you unlimited travel within given zones for the rest of the day - that includes train and bus services within that zone too. Zones 1,2 & 3 #2.30 pounds. Zones 1-5 #2.60 pounds. ------------------------- A c c o m o d a t i o n s ------------------------- The following hotels are walking distance from the conference meeting room on the UCL campus. Contact the hotel directly to place reservations.It is highly recommended that reservations are made as early as possible. Refer to SIGCOMM'94 when making the reservation. * Hotel Ibis Euston 3 Cardington Street, NW1 Telephone: +44-71-388-7777, Fax: +44-71-388-0001 Total Rooms: 300 Single Room #49.50, Double Room #49.50 Near UCL, about 10 minute walk from main Conference Hall. * St. George's Hotel Langham Place, W1N Telephone: +44-71-580-0111, Fax: +44-71-436-7997 Total Rooms: 86 Single Room: #80.00, Double Room: #100.00 (Includes Continental Breakfast) Situated near Oxford Circus, about 10 minute walk from main venue. * RAMSAY HALL 20 Maple Street, W1P Total Rooms: 400 Telephone: +44-71-387-4537, Fax: +44-71-383-0843 Single Room: #19.50, Double Room: not available. (Includes Continental Breakfast) Student residence used as hotel during summer break, 5 minute walk from main conference venue. * Hotel Russell Russell Square, WC1 Telephone: +44-71-837-6470, Fax: +44-71-837-2857 Total Rooms: 328 Single Room: #70.00, Double Room: #90.00 (Includes Continental Breakfast) Old Victorian Style Hotel. About 15 minute walk from Conference venues. Russel Square Station is on the Picadilly line which reaches to Heathrow Airport. Airport Bus stop nearby as well. * Forte Crest Bloomsbury Coram Street, WC1 Telephone: +44-71-837-1200 Fax: +44-71-837-5374 Total Rooms: 230 Single Room: #69.00, Double Room: #79.00 (Includes Continental Breakfast) Modern hotel near Hotel Russell. There are a large number of hotels near the conference. Almost any hotel in the WC1 area of London is within 15 minutes walking distance. A list of more hotels may be found via www (http://www.cs.ucl.ac.uk/sigcomm94) or anonymous ftp (norman.eng.buffalo.edu:/pub/SIGCOMM94). The list also includes nearby lower cost housing and youth hostels. ------------------------------------------------ R E G I S T R A T I O N I N F O R M A T I O N ------------------------------------------------ Full conference registration includes breaks, lunch, Tuesday evening reception, one ticket to dinner in the Dinosaur Room of the Natural History Museum on Wednesday, and a copy of the conference proceedings. Student registration includes breaks, lunch and proceedings but does not include the dinner/museum event. On site registration will begin Monday August 29, 1994 from 7:30AM - 5:00PM, and every day of the con- ference starting at 7:30 am. ACM and SIGcomm Membership -------------------------- If you are not an ACM or a SIGCOMM member at this time, you may join now to take full advantage of ACM/SIGcomm Member or Student rates for SIGCOMM94: - ACM Associate Member Dues$82/#52
- Add SIGCOMM to ACM Membership      	$22/#15 - ACM Student Dues$25/#17
- Add SIGCOMM to ACM Student Membership	$15/#10 - SIGCOMM Membership only (non-ACM)$50/#32

Total Membership Fees              $/# _________ (Note:$ indicates U.S. dollars, and # British Pounds Sterling)

To advance the sciences and arts of information processing; to promote
the free interchange of  information about  the sciences  and  arts of
information processing both among  specialists and  among the  public;
and  to  develop  and  maintain  the  integrity  and   competence   of
individuals engaged  in  the  practice  of  information processing.  I
hereby affirm that I subscribe  to the purpose of  ACM and  understand
that my membership is not transferable.

Signature _________________________________________ Date ____________

Tutorials
---------

Check each tutorial attending.  The tutorial registration fee includes
one copy  of the tutorial notes and  lunch.  Tutorials  are on a first
come first serve basis.

- T1 	Personal Communication Services & Networks (Monday)
- T2 	Protocol Performance (Monday)
- T3 	Fiber Optic Networks (Tuesday)
- T4 	Multimedia Conferencing on the Internet (Tuesday)
- T5 	Asynchronous Transfer Mode (Tuesday)
- W1 	Workshop on Distributed Systems (Tuesday)

Tutorial Rates
Postmarked by         	Postmarked
aug/1/1994           	after aug/1/1994

ACM/SIG Member          _____@ $275/#172 _____@$325/#205
Non-Member              _____@ $350/#220 _____@$400/#250
Student                 _____@ $138/#87 _____@$175/#110

Total Tutorial Fees     _____$/# _____$/#

Special Needs
-------------

Vegetarian Meals:    	- Yes  	- No

Conference Registration
-----------------------

Please complete and  send  registration form, with check,  credit card
information or money orders (no purchase orders) to the address below.
Registrations accepted  via postal  mail,  fax or  email (with  credit
card) only.

Postmarked by         	Postmarked
Aug/1/1994           	after Aug/1/1994

ACM/SIG Member			_____@ $315/#200 _____@$365/#230
Non-Member     			_____@ $397/#252 _____@$440/#275
Student       	 		_____@ $100/#63 _____@$130/#82

Total Registration  Fees    $/# _____$/# _____

Extra Dinner/Museum Ticket      _____@ $55/#35 TOTAL ENCLOSED$/#  _____ (ACM/SIGCOMM Membership, tutorials,
conference registration)

NAME _________________________________________________________________

AFFILIATION __________________________________________________________

______________________________________________________________________

PHONE _____________________________ FAX ______________________________

SIGCOMM Member? 	- YES    	 - NO
ACM/SIGCOMM Member Number ____________________________________________

CREDIT CARD PAYMENT 	- VISA   - MASTERCARD   - euroCARD

CARD HOLDER NAME _____________________________________________________

CARD NUMBER ______________________________________ EXP. DATE _________

SIGNATURE ____________________________________________________________

Please send this  form and a check,  credit card information  or money
orders (no purchase orders) to SIGCOMM'94.  Registrations accepted via
postal mail, fax or email only.

Send U.S. or   				Send Pound Sterling
Credit Card Payments to:

Patrick McCarren                        Soren-Aksel Sorensen
ACM - 17th Floor                        Dept. of Computer Science
New York, NY 10036                      London WC1E 6BT
USA                                     United Kingdom
phone: +1 212/626/0611                  phone: +44 71 380 7269
fax: +1 212/302-5826                    fax +44 71 387 1397
mccarren@acm.org

Email registrations  can  only  be  made  by a credit card  during the
pre-registration period ending 1 August 1994 and must use credit  card
payment.   A registration confirmation  letter  will  be sent to  each
participant  upon  receipt of  the  completed  registration  form  and
accompanying  payment.   Registration fee  will  be  refunded,  less a
$30/#19 administration fee, if cancelation notification is received prior to 15 August 1994. Substitution for a paid attendee is acceptable. ---------------------------------------------- C o n f e r e n c e O r g a n i z a t i o n ---------------------------------------------- General Chair: Jon Crowcroft, University College London Program Chairs: Stephen Pink, Swedish Institute of Computer Science Craig Partridge, BBN (Program Co-Chair for North America) Ian F. Akyildiz, Georgia Institute of Technology, USA Lillian N. Cassel, Villanova Univ., USA Vinton Cerf, MCI, USA Lyman Chapin, BBN, USA Jon Crowcroft, Univ. College London, UK Andre Danthine, Univ. of Liege, Belgium Gary Delp, IBM, USA Patrick W. Dowd, SUNY/Buffalo, USA Deborah Estrin, Univ. Southern California, USA David Feldmeier, Bellcore, USA Sally Floyd, Lawrence Berkeley Laboratory, USA David Greaves, ORL Cambridge, UK Per Gunningberg, Swedish Institute of Computer Science, Sweden Christian Huitema, INRIA, France David Hutchison, Lancaster Univ., UK Raj Jain, Ohio State University, USA Jim Kurose, Univ. of Massachusetts, USA Ian Leslie, Univ. of Cambridge, UK David Oran, Digital Equipment Corp, USA Gerard Parr, University of Ulster, Northern Ireland Guru Parulkar, Washington Univ. St Louis, USA Krzysztof Pawlikowski, Univ. of Canterbury, New Zealand Bernhard Plattner, ETH Zurich, Switzerland Scott Shenker, XEROX PARC, USA Deepinder Sidhu, Univ. of Maryland-BC, USA Jonathan M. Smith, Univ. Pennsylvania, USA Khosrow Sohraby, Univ. of Missouri - Kansas City, USA James Sterbenz, IBM Research, USA Greg Watson, Hewlett Packard Labs, UK Greg Wetzel, AT&T Bell Laboratories, USA Lixia Zhang, XEROX PARC, USA --------------------------------------------------- F O R A D D I T I O N A L I N F O R M A T I O N --------------------------------------------------- Additional information may be found/requested from: www: http://www.cs.ucl.ac.uk/sigcomm94 anonymous ftp: norman.eng.buffalo.edu:/pub/sigcomm94 email: sigcomm94@eng.buffalo.edu fax: +1 716.645.3656 phone: +1 716.645.2406  -----------[000228][next][prev][last][first]---------------------------------------------------- Date: Mon, 11 Jul 1994 23:44:23 +0000 From: mmcmullen@gsfcmail.nasa.gov (steve johnson) To: comp.protocols.tcp-ip Subject: simple X protocol questions  someone around here wrote a document specifying certain network requirements and referred to the X protocol as X-11. i always thought it was X.11. is either one of us right? i know how to hook people up using X (rexec, rlogin, telnet, etc.), but have very little knowledge of the details. i seem to remember seeing things like X.11R3 and X.11R4. are these revisions? am i crazy? if our users are running mostly over TCP/IP ethernet lans with an occasional Novell or AppleShare does it make a difference to our specification?  -----------[000229][next][prev][last][first]---------------------------------------------------- Date: 12 Jul 1994 08:26:06 -0500 From: trisoft@bga.com (TriSoft) To: comp.protocols.ppp,comp.protocols.tcp-ip,comp.sys.mac.comm,comp.sys.mac.misc,comp.sys.mac.wanted Subject: Re: SLIP and PPP Clients/Dynamic Addressing  David, I will make a quick (and highly prejudice) recommendation for MacSLIP. It has a very powerful scripting language for automating the connection, extremely high throughput, and will give good performance on everything up through a PowerMac. If you want to get more information on MacSLIP, you can contact TriSoft via this email, or 1-800-531-5170 (512-472-0744). James M. Knox  -----------[000230][next][prev][last][first]---------------------------------------------------- Date: 12 Jul 94 09:24:49 -0500 From: imhw400@indyvax.iupui.edu (Mark H. Wood) To: comp.protocols.tcp-ip Subject: Re: Implementing IP address extensions  In article <773783589snz@peeras.demon.co.uk>, proyse@peeras.demon.co.uk (Phil Royse) writes: > In article <1994Jul6.185228.3682@bay.cc.kcl.ac.uk> > udaa055@bay.cc.kcl.ac.uk "Andy Harper, KCL Systems Manager" writes: > >>An oft discussed question is how the IP addresses used on Internet can be >>extended now that the explosion in personal computers and connectivity has left >>the 32-bit address space looking a bit sick! Rumour has it that, if growth >>increases at the same rate as currently, we'll run out of addresses in the near >>future. > > [stuff deleted] > >>So, what options are there that don't require all and sundry who use Internet >>to spend wads of cash and/or find upgraded network applications that understand >>new addressing formats? >> >>Andy Harper >>Kings College London > > Yes, wads of cash, it's bound to be. I've follwed all the stuff on IPng, > TUBA, SIPP CATNIP and now Big Ten (?). None of them will be a low-cost > migration. > > I just think that people will become more careful over address allocation. > I have already floated at least two heretical ideas and one neutral one... > > The neutral one is that DHCP will make life a lot easier and allow > N temporary users (e.g. PCs) to share M addresses on a " lease " basis. > > The heretical ideas: > > 1. there are many more TCP/IP users who don't want to connect > to the Internet and fewer organisations *need* to. Most of academe > (as your good selves) is connected. Corporations who have "a few" > technical people who can justify Internet connectivity will > probably settle for clever use of firewalls and proxy telnet, ftp etc. > > 2. there may come a time when IP address space is so scarce > that some people will offer it for sale and some will buy it.... well, > it happens with some very unusual commodities.... Wimbledon tickets, > cherished number plates, antique toys, trade marks... why not: > > "For sale: 123.1.29 to 32 only one owner,$5,000 o.n.o."
> 	"PLUS - an X.21 PPP link into our Internet router,
> 	only $4,000 pa." > > There must be many academic bodies with spare address space? > > Any thoughts? Yeah, but you won't like them. Bite the bullet and do it right, right now. IP was quite good enough for the academic/military/industrial complex, but the game has changed. 5.5 billion people can't be served with 4 billion addresses, even if we take all the Coke machines off the net. It doesn't have to be all-or-nothing. Gateways exist for VTP/Telnet and FTAM/FTP, for example, and that should take care of 95% of "traditional" use if we choose to go that direction. The infosystem stuff that's growing furiously right now can ride alternatives just as easily as it can IP, and in fact should never notice the change. The backbone network and big players can change as soon as they all agree on it, and the smaller players can adapt over time as their vendors give them more attractive options. After all, that's why we have a layered architecture instead of monolithic applications. As long as the interfaces and the semantics are unchanged (so far as the client knows), the internals of any layer (and layers on the other side of it) are irrelevant. -- Mark H. Wood, Lead Systems Programmer +1 317 274 0749 [@disclaimer@] Internet: MWOOD@INDYVAX.IUPUI.EDU BITNET: MWOOD@INDYVAX "I live the greatest adventure one could ever wish." - a tosc  -----------[000231][next][prev][last][first]---------------------------------------------------- Date: Tue, 12 Jul 1994 10:16:05 -0500 From: dmacfarlane@zip.sbi.com (David R.D. Macfarlane) To: comp.protocols.ppp,comp.protocols.tcp-ip Subject: How do I set up routing on SunOS for rempte SLIP users?  I'm having trouble setting up cslip-2.7 on SunOS 4.1.3. I can get the line to answer and go into SLIP mode, and my remote station (running Trumpet Winsock) can use TCP/IP to the host directly, but they can't see any hosts outside the local domain. FTP, Mosaic, etc., just time out when they try to connect to a distant host. I think its something to do with routing, but I'm not sure. How should routing be set up on the host to which SLIP users dial in? If I have a default route (created by the existance /etc/defaultroute) then the in.routed daemon doesn't run, but I don't think I need dynamic routing so perhaps that's okay. When the SLIP user is connected, sliplogin adds a route so that netstat -r looks like: Routing tables Destination Gateway Flags Refcnt Use Interface localhost localhost UH 4 17440 lo0 199.123.192.10 parts UH 1 33 sl0 default 199.123.192.1 UG 3 6342 le0 199.123.192.0 parts U 2 308 le0 So, .10 can talk to parts and TCP/IP services on parts, and parts can talk to things like ftp.uu.net and www.ncsa.uiuc.edu, etc., but .10 can't talk to ftp.uu.net, etc. Any suggestions or solutions will be very much appreciated. Thanks. David. David R.D. Macfarlane | "I'm stubborn as those dmacfarlane@zip.sbi.com | garbage bags that time | cannot decay." - L. Cohen  -----------[000232][next][prev][last][first]---------------------------------------------------- Date: Tue, 12 Jul 94 11:21:32 -0500 From: jefrob@delphi.com To: comp.protocols.tcp-ip Subject: Re: THE winsock??  A word on OSI (from a biased vendor of an OSI-based real-time object database): CLNP/CLNS, the OSI connectionless network layer, is arguabbly superior to IP in both routing algorithms and address space. Even if you don't like OSI (probably because it was over-hyped and under-hacked and in general presented as a top-down big-brained thing nowhere near as cool as the Internet), you have to admit that the IP layer is undergoing some potentially serious retooling! Oh, by the way, we have a HIGH-PERFORMANCE OSI stack for windows implemented as straight 32-bit code in the kernel (VxDs) which supports multiple netcards full-tilt AND is enabled by X.500. Our customers use it underneath our LiveData product, which uses OSI application layer protocols as the back-bone of a real-time client-server object database. Could our stuff run over TCP-IP? Of course. But we decided to get real with architecture first (which OSI IMHO achieves) and then worry about low-level issues like whose sliding window is best. Jeff Robbins Cycle Software, Inc.  -----------[000233][next][prev][last][first]---------------------------------------------------- Date: Tue, 12 Jul 94 11:25:36 -0500 From: jefrob@delphi.com To: comp.protocols.tcp-ip Subject: Re: OSI vs TCP/IP Question  Walt, I can't answer your TCP question, but our OSI-based products (LiveNet and LiveData) support multiple simultaneous sub-nets. You get your choice of using all sub-nets at once, or designating fall-back sub-nets. LiveNet is a seven-layer OSI stack implemented as 32-bit code in the Windows kernel. LiveData is a real-time client-server object database which uses OSI application protocols like MMS (manufacturing message spec.) as its backbone. Jeff Robbins Cycle Software, Inc. (617) 770-9594  -----------[000234][next][prev][last][first]---------------------------------------------------- Date: Tue, 12 Jul 1994 03:37:55 GMT From: <dennyfox@maroon.tc.umn.edu> To: comp.protocols.tcp-ip,comp.os.linux.misc Subject: BOOTP Test Program  Can anyone point me to a BOOTP test program which will display the results from any/all BOOTP servers who respond to a BOOTP request issued from the command line? Tried the comp.protocols.tcp-ip and comp.os.linux... FAQs with no luck. Source code would be nice, I'd like to compile versions for SunOS 4.1.3, Linux, and MSDOS. Thanks in advance... Denny Fox E-Mail: dennyfox@maroon.tc.umn.edu  -----------[000235][next][prev][last][first]---------------------------------------------------- Date: 12 Jul 1994 06:46:05 GMT From: pblack@amos.trl.OZ.AU (Peter Black) To: comp.protocols.tcp-ip Subject: Query on cwnd algorithm in BSD code  I have been looking at the BSD code for TCP (1990 code and 4.4BSD-Lite), and have a query. In the tcp_input.c code, the cwnd update algorithm is:- cwnd += pk_size * pk_size / cwnd + pk_size / 8 for (cwnd > ssthresh). The first part of this is standard (in the rfc), however, the second part (pk_size / 8) is stated as being used to allow large windows to open quicker. I was wondering where this addition is suggested/defined (eg rfc's, ietf, papers) and what precise reasoning is given for this term. Thanks in advance for any pointers. Peter Black Telecom Research Laboratories, Clayton, Vic, Australia p.black@trl.oz.au -------------------------------------------------------------------- Peter Black | Phone: +61 3 253 6384 Telecom Research Laboratories | Fax: +61 3 253 6144 P.O. Box 249 | Email: p.black@trl.oz.au Clayton Vic 3168 | Australia | --------------------------------------------------------------------  -----------[000236][next][prev][last][first]---------------------------------------------------- Date: Tue, 12 Jul 1994 09:48:31 GMT From: jmi@csd.cri.dk (John Mills) To: comp.protocols.tcp-ip Subject: Re: How can I build an X sniffer (xscope?)  In article 24950@bcarh54a.bnr.ca, coghlan@bcarh5f8.bnr.ca (Patrick Coghlan) writes: >I want to intercept all packets between an X terminal and a host. > >I believe X runs over TCP so can someone please point me at: > > - relevant RFCs I should look at > - what "tricks" I need to employ to intercept and forward all > packets between the X terminal and the host > >Thanks in advance. I used a freeware product called xscope a few years ago... it came with source... (You should be able to fiund it with archie?) It is placed at the display end of the x chain... with a different address, i.e. 10001 (I think), it's task is to connect to the REAL X-server, and also to present a server socket to callers... when a caller connectes, it copies the input socket data to the display socket (and visa versa) printing out any useful data it finds to it's STDOUT... You then start your XClient program with <name>:<10001>.0 (or the other way around?) and your program routes through this... reasopnably easy... We where thinking of modifying it to record keystrokes and mouse movements for later replay, but never had the budget to get it to function 100%... hope this helps! P.S. You PROBABLY don't need to refer to RFC's but you will need to refer to the lower level X manuals (some of 0 - 5) in the O'reiley sets...  -----------[000237][next][prev][last][first]---------------------------------------------------- Date: 12 Jul 1994 16:36:48 -0400 From: chrisl@ncms.org (Chris Lang) To: comp.os.ms-windows.networking.tcp-ip,comp.os.ms-windows.programmer.networks,comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc Subject: Re: DNS  tfl@psp.co.uk (Thomas F Lee) writes: >In article <9407070706.AA01007@ariake.nwk.cl.nec.co.jp> > mweiss@nwk.cl.nec.co.jp "Michael J. Weiss" writes: >> Can someone explain what DNS is? >DNS = Domain Name Server Just to pick a nit, DNS stands for "Domain Name System". I don't know of an acronym for the actual servers, they're just called "DNS servers" or "nameservers". -Chris -- Chris Lang | Technology Integration, Inc. chrisl@ncms.org | 3025 Boardwalk +1 313 995 4042 | Ann Arbor, MI 48108  -----------[000238][next][prev][last][first]---------------------------------------------------- Date: 12 Jul 1994 17:07:04 -0400 From: gallaugher@aol.com (Gallaugher) To: comp.protocols.tcp-ip Subject: MacSLIP w/Zoom v.32bis probs?  I'm trying to use MacSLIP 2.0.4 with my Zoom v.32bis modem. I can connect to my host but I get a MacSLIP BOOTP Failed error shortly after connection. Does anyone know what could be causing this? I'm pretty sure it's in the MacSLIP software because I've used a Supra 144 (before it got struck by lightning) and a USR 2400 with the same cables, etc. & the both work fine. The Zoom works with other services, too. Also, if anyone knows how I can contact Hydepark for tech support (I sent a message to info@hydepark.com), I'd appreciate a phone number or at least a city they're located in. Please E-Mail me at: jmgallau@mailbox.syr.edu (not my aol account) Regards, John Gallaugher  -----------[000239][next][prev][last][first]---------------------------------------------------- Date: Tue, 12 Jul 1994 16:54:24 From: timc@sni.com.au (Tim Cullen) To: comp.protocols.tcp-ip Subject: open UDP socket returns ENOSPC - Why ?  On our Unix SVR4 system, the following call int s = socket(AF_UNIX,SOCK_DGRAM,0) returns s < 0 and errno = ENOSPC, perror() gives "No space left on device Investigation using "truss" shows open("/dev/udp", O_RDWR, 0) Err#28 ENOSPC The only way to remove this problem is to re-boot until it happens again. Does anyone know the cause ? ENOSPC is not a documented error form a socket call. Thanking you in advance Regards, Tim Cullen (timc@sni.com.au) Siemens Nixdorf Information Systems Pty Ltd 655 Pacific Highway, St Leonards, NSW, 2065, AUSTRALIA Voice: +61-2-430-2154, Fax: +61-2-439-5734  -----------[000240][next][prev][last][first]---------------------------------------------------- Date: Tue, 12 Jul 1994 11:55:30 +0000 From: ronald@demon.co.uk (Ronald Khoo) To: comp.protocols.tcp-ip Subject: TOS bits vs routers  What do notice do IP routers take of TOS bits ? If you have good info for any particular router, I would be grateful if you could reply to me personally, and I will summarise in a week to the list. If such a summary of this info already exists, I'd be grateful for a pointer. I've been nearly off-net for almost two years and am a bit lost. Thanks. -- Ronald Khoo, <ronald@demon.net> Tel: +60 3 7560 439 (Home) +60 3 241 5232 (Work) Fax: +60 3 241 8832  -----------[000241][next][prev][last][first]---------------------------------------------------- Date: Tue, 12 Jul 1994 14:06:56 GMT From: hughes@logos.ucs.indiana.edu (Larry J. Hughes Jr.) To: comp.os.ms-windows.networking.tcp-ip,comp.os.ms-windows.programmer.networks,comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc Subject: Re: DNS  In article <773834307snz@psp.co.uk>, tfl@psp.co.uk (Thomas F Lee) writes: #In article <9407070706.AA01007@ariake.nwk.cl.nec.co.jp> # mweiss@nwk.cl.nec.co.jp "Michael J. Weiss" writes: # #> Can someone explain what DNS is? # #DNS = Domain Name Server # #A DNS server is a _server_ which resolves _Host Names_ into _IP Addresses_. Not to pick nits, but DNS stands for "Domain Name System." It can potentially consist of hundreds or thousands of servers, as it does on the Internet. It would be slightly more accurate to say that it maps a hierarchical namespace of host names and network addresses. This includes host names to network addresses, and vice-versa (network addresses to host names). It also supports a separate mapping for mail exchange purposes. A pretty good conceptual intro to DNS can be found in Douglas Comer's "Internetworking with TCP/IP." =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Larry J. Hughes, Jr. hughes@indiana.edu Indiana University, UCS Software Engineer Service Development Group "Subvert the dominant paradigm" =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=  -----------[000242][next][prev][last][first]---------------------------------------------------- Date: 12 Jul 1994 14:37:06 GMT From: adiwan@siacbbn.com (Arif Diwan (BBN)) To: comp.protocols.tcp-ip Subject: Re: Installing SLIP  In article <2vcc7p$lbv@acsc.com>, rao@acsc.com (Rao Srinivasa) writes:
R.Srinivasa|> In article <1994Jul1.205328.13600@wisipc.weizmann.ac.il>,
R.Srinivasa|> yuvalt@silver.weizmann.ac.il (Tal Yuval) writes:
...
T.Yuval|> My question is: If I want to connect a SLIP machine to the network
T.Yuval|> (lets say that the host is 132.76.80.121), do I have to create a new
T.Yuval|> network (i.e. 132.76.81) and make 132.76.80.121 its gateway or can I
T.Yuval|> put my SLIP machine on the same IP network?

R.Srinivasa|> You can connect a host by SLIP without wasting a subnet
R.Srinivasa|> number for it ...
...
<<<

You do not have to put the SLIP host on a different subnet. I am on a dialup
SLIP connection and I am on the same parent network. A point-to-point
connection can be thought of as a tuple where the local IP can be the same
as on of your other interfaces. In my case,

lo0: flags=49<UP,LOOPBACK,RUNNING>
du0: flags=51<UP,POINTOPOINT,RUNNING>
inet 128.89.4.202 --> 128.89.8.11 netmask ffff0000
du1: flags=10<POINTOPOINT>
inet 128.89.4.202 --> 128.89.8.14 netmask ffff0000

In another scenario I have used variable length subnets to create a virtual
interface which has sort of p2p "connections" to two real interfaces. Here
I used one bit subnets, with the broadcast address of the one-bit subnet
being the virtual interface address. A good many people have objections to
this scheme but we needed it and it works.

--

617-873-6274


-----------[000243][next][prev][last][first]----------------------------------------------------
Date:      12 Jul 1994 15:15:10 GMT
From:      longm@firnvx.firn.edu (Michael Long)
To:        comp.protocols.tcp-ip
Subject:   DNS for Windows?

I am looking for a DNS Windows Package.  If anyone knows where I can ftp
one I would appreciate it.

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


-----------[000244][next][prev][last][first]----------------------------------------------------
Date:      12 Jul 1994 17:52:00 GMT
From:      bumble@hudson.cse.psu.edu (Marc David Bumble)
To:        comp.protocols.tcp-ip
Subject:   ATM Performance Monitoring?


I have access to an ATM network in the Bay Area.  The project involves
running audio, video, and shared X applications across the network to other
connected sites.  We can get the applications to run, but we dont

We would like to monitor the performance of the network, and produce
meaningful results.  Is there any shareware software available which
would help us to monitor the network performance across the atm
network?  What parameters are good to monitor, ie which parameters
will be meaningful to others?

The host machine which connects to the atm network, connects directly
to atm via fiber, so ethernet monitors will not help.

thanks for any assistance,

marc

bumble@riacs.edu
NASA Ames Research Center
Research Institute for Advanced Computer Science
Moffett Field, CA


-----------[000245][next][prev][last][first]----------------------------------------------------
Date:      12 Jul 1994 18:18:00 GMT
From:      mbrodsky@lmumail.lmu.edu (Deal)
To:        comp.protocols.tcp-ip
Subject:   What is:   FILE SERVICE PROTOCOL  ?


The L.A. Times Article published and article today on Page 1,
(A1 Tuesday , July 12, 1994) .

I thought that the article was particularly sensational, accusing
the Internet as haven for hackers and pirates, and at one point in the
article he writes:

"Pirate sites...can generally be found only by highly sophisticated
computer users who are well-schooled in the intricacies of the Internet.
The pirates use a new and relaitvely obscure method for transfering
information, known as the "file service protocol," and they often change
the location of their sites every few weeks to avoid detection"

Does he mean "FTP" or is this "FSP" something else, all together?

I am thinking of writing a letter to the editor, so also respond to
me directly asap, so that I can confirm what also appears to be sloppy
reporting.

- Michael Brodsky
mbrodsky@lmumail.lmu.edu


-----------[000246][next][prev][last][first]----------------------------------------------------
Date:      12 Jul 1994 19:23:14 GMT
From:      twallace@mason1.gmu.edu (Todd A Wallace)
To:        comp.protocols.tcp-ip
Subject:   Problem: our net vs Internet

We are supposed to join the wonderful world of Internet connectivity. To
that end, we have a NetHopper router and a new upgraded account with
Netcom.

However, we have a problem.

The IP addresses are totally different from the IP address we have been
assigned from Netcom.

QUESTION: Is there a way to resolve this problem without having to
change the IP addresses on every single one of our PCs and UNIX boxes?

Thanks for any help/hints.
Todd Wallace


-----------[000247][next][prev][last][first]----------------------------------------------------
Date:      12 Jul 1994 19:32:55 GMT
To:        comp.protocols.ppp,comp.protocols.tcp-ip,comp.sys.mac.comm,comp.sys.mac.misc,comp.sys.mac.wanted
Subject:   Re: SLIP and PPP Clients/Dynamic Addressing

In article <netguide-1107941645340001@netguide.dialup.access.net>, netguide@panix.com writes:
|>
|> I am interested in finding out what SLIP and PPP clients there are
|> available for the Macintosh besides InterSLIP, InterPPP and MacPPP.
|> Additionally, I am looking for the ability to utilize dynamic IP
|> addressing; I would be very interested in any packages that make this
|> (easily) possible.
|>
|> Does anyone have any suggestions?
|> (email copies of posts appreciated)
|>
|> David Wood
|> obsidian@panix.com

We are using MacPPP here in conjuctino with Telebit NetBlazers.
They support dynamic IP addressing.  On the Mac side, you need
to set MacTCP to server addressing.  On the NetBlazer side you
need to use the pool command to enable address serving.

Jeff
gottloeb@gumby.sp.trw.com


-----------[000248][next][prev][last][first]----------------------------------------------------
Date:      13 Jul 1994 04:13:25 -0500
From:      ucacjon@ucl.ac.uk (Jon Crowcroft)
To:        comp.protocols.tcp-ip
Subject:   Re: IP Usage Billing package ?

In article <2vovt0$bjn@hpwin055.uksr.hp.com>, gerryw@hpbrak42.uksr.hp.com (Gerry WINSOR) writes: |> Hi, |> |> Anyone aware of a commercially available "TCP/IP Billing" package which'll |> use actual IP usage rates as the billing calculation ? and how will it deal with retransmits ? are they the fault of a) a poor RTT estimator in the client b) a badly engineered network c) a provider downstream being overbusy or what have you and will they bill for the duration of an FTP (the longer my FTP takes, the _cheaper_ i want t to be, but i rely on loss to triger the TCP backoff to find the bandiwdth, so how are they gonna reconcile that with the above>? and who do you charge for sending me mail, or for me sending NFS traffic back to? sorry, such a package would necessiate looking in and above the transport layer, and i am not gonna permit you to run it, and anyhow, it will make your routers go appalingly slowly charging by usage only makes sense for traffic that must be restrained - e.g. real time traffic - bulk data transfer (ftp, email bboards, archie, gopher, wais, www, etc) is best not useage charged.....it is not optimal... for these latter, charge for the per annum link into the internet, and rely on fair share tcp algorithms and sensible packet drop strategies in the routers to do the rest do you really want to revisit the nightmare most telcos have of spending 30%+ of your revenuse simply recovering bills? there is a "market force" myth going around (some people at INET in prague were trying to perpertrate it) that you get more money by doing useage based charging this is false, and there are people who even have maths to show it... -- jon crowcroft (hmmm...)  -----------[000249][next][prev][last][first]---------------------------------------------------- Date: 12 Jul 1994 20:06:39 GMT From: dmore@gisws3.rtpnc.epa.gov (Duane More) To: comp.protocols.tcp-ip Subject: TTL Versus Expire time  In setting up cache-only server, the Expire time is set to, say, 1000 hours. I notice that the TTL entry for records coming from the 12 Hours. What I am wondering is in the event of some failure, how long will the resource records kept by the cahce-only server be used. I guess the real questions is what the TTL is used for as opposed to the Expire entry in the SOA record of the cache server. -- ---- Duane N. More | In Support of: dmore@unixmail.rtpnc.epa.gov | US EPA  -----------[000250][next][prev][last][first]---------------------------------------------------- Date: 12 Jul 94 20:33:26 GMT From: EMMA@pge.com (Edmond Melkomian) To: comp.protocols.tcp-ip Subject: IBM TCP/IP  Has anyone done work with SMF on MVS and IBM TCP/IP product. Any info is appreciated. Please email me at EMMA@PGE.COM thanks, Edmond  -----------[000251][next][prev][last][first]---------------------------------------------------- Date: 12 Jul 1994 21:00:50 GMT From: vern@daffy.ee.lbl.gov (Vern Paxson) To: comp.protocols.tcp-ip Subject: Re: What is: FILE SERVICE PROTOCOL ?  In article <mbrodsky-120794122315@157.242.64.49>, Deal <mbrodsky@lmumail.lmu.edu> wrote: > Does he mean "FTP" or is this "FSP" something else, all together? FSP is something else. From the INFO file that comes with the sources: FSP is a set of programs that implements a public-access archive similar to an anonymous-FTP archive. It is not meant to be a replacement for ftp; it is only meant to do what anonymous-ftp does, but in a manner more acceptible to the provider of the service and more friendly to the clients. FSP is UDP-based, trading off slow transfer rates for the additional robustness that comes from a stateless service. The INFO files directs interested parties to contact jtraub@cs.cmu.edu. Vern Vern Paxson vern@ee.lbl.gov Information and Computing Sciences ucbvax!ee.lbl.gov!vern Lawrence Berkeley Laboratory (510) 486-7504  -----------[000252][next][prev][last][first]---------------------------------------------------- Date: 13 Jul 1994 09:18:45 -0700 From: jbarnes@crl.com (John Barnes) To: comp.protocols.tcp-ip Subject: How to register UDP ports  Hi, I need to register two UDP ports. I can not remember how to go about doing it. We have a client/server application we will be selling and want to reserve two UDP ports for are application. Please email replies to jbarnes@crl.com. Thanks, Jym Barnes  -----------[000253][next][prev][last][first]---------------------------------------------------- Date: 13 Jul 1994 08:17:16 -0500 From: trisoft@bga.com (TriSoft) To: comp.protocols.ppp,comp.protocols.tcp-ip,comp.sys.mac.comm,comp.sys.mac.misc,comp.sys.mac.wanted Subject: Re: SLIP and PPP Clients/Dynamic Addressing  >You know what? I wish that you would configure my copy of MacSLIP. I got >MacSLIP with my Microphone Pro software and found it VERY difficult to set >up. I'm sorry that I paid extra to get the product, as the free package, >MacPPP, is much easier to set up and, according to our unix guys, more >reliable. I'm not a moron either, but MacSLIP certainly is a pain to set >up. Curt, Have you talked to Software Ventures (the Microphone folks)? They have a tech support department to help with problems like this. And if they can't solve the problems, then they are supposed to contact the MacSLIP developer for help. [Same thing we do for copies *we* sell.] In spite of the fact that you purchased MacSLIP from Software Ventures instead of us, I would still be happy to help you get it set up. Usually it only takes a couple of minutes. Since there is very little setup for MacSLIP itself (most of the messy stuff is actually config. for MacTCP -- a problem you would have with *either* MacSLIP or MacPPP), I presume you had a problem with the setting up a script. The first thing needed to make any mods to the script is, of course, to know what you want it to do. I.e., what does your service provider expect from you and what does it send to you. After that it is just a matter of going down the sample script (at least, that is how most folks do it), and making a couple of changes as needed. [For instance, the sample script we send out looks for a prompt "Username:", but your server may send the prompt "login:" -- so you just change the word.] If you would like to e:mail me your script and a printout of the sequence your service provider expects, I will be happy to "mark it up" for you. It probably needs about three lines changed, maybe four. And (before you ask): No, I am certain you are "not a moron". The configuration really is usually pretty simple, but can be intimidating to someone looking at it "cold." That makes it easy to get "turned around", frustrated, and to give up on it. [BTW, suggestions as to why MacPPP is "so much easier" would be appreciated.] Disclaimer: Most of the above comments about the sample script refer to copies of MacSLIP sold by TriSoft. I do not guarantee they exactly match whatever Software Ventures may be distributing. jmk  -----------[000254][next][prev][last][first]---------------------------------------------------- Date: 13 Jul 1994 09:22:45 -0400 From: jonbeal@saturn.caps.maine.edu (Jon Beal) To: comp.protocols.tcp-ip Subject: DHCP daemon (or lack thereof)  Sorry to be posting this here, but... I received a request from someone at mayo.edu this morning about the responses I had received for my earlier request of DHCP information. I inadvertently deleted that note before responding, and I can't seem to get the right email address. (I know it's close, but not quite...) So anyway, my results... It seems that no DHCP daemon currently exists. Several companies have announced commercial products, but it sounds like they are still in the development stages. It looks like we're stuck waiting or finding other solutions...  -----------[000255][next][prev][last][first]---------------------------------------------------- Date: 13 Jul 1994 04:33:12 GMT From: balenson@tis.com (David M. Balenson) To: sci.crypt,alt.privacy,alt.security,alt.security.pgp,alt.security.ripem,comp.protocols.kerberos,comp.protocols.tcp-ip,comp.security.misc,comp.security.unix,ieee.announce Subject: 2nd CFP: ISOC Symposium on Network and Distributed System Security  CALL FOR PAPERS The Internet Society Symposium on Network and Distributed System Security 16-17 February 1995, Catamaran Hotel, San Diego, California GOAL: The symposium will bring together people who are building software and/or hardware to provide network and distributed system security services. The symposium is intended for those interested in the more practical aspects of network and distributed system security, focusing on actual system design and implementation, rather than in theory. We hope to foster the exchange of technical information that will encourage and enable the Internet community to apply, deploy and advance the state of the available security technology. Symposium proceedings will be published by the Internet Society. Topics for the symposium include, but are not limited to, the following: * Design and implementation of security services -- access control, authentication, availability, confidentiality, integrity, and non-repudiation. * Design and implementation of security mechanisms and support services -- encipherment, authentication, and key management systems, including fair cryptography -- access control, authorization and audit systems -- and intrusion detection systems. * Requirements and designs for securing distributed applications and network functions -- message handling, file transport, remote file access, directories, time synchronization, interactive sessions, remote data base management and access, routing, voice and video multicast and conferencing, news groups, network management, boot services, mobile computing, and remote I/O. * Requirements and designs for securing networked information resources and tools -- Archie servers, the Wide Area Information Servers (WAIS), the Internet Gopher, and the WorldWide Web (WWW). * Design and implementation of measures for controlling internetwork communication and services in a coherent manner -- firewalls, packet filters, application gateways, and user/host authentication schemes. * Requirements and designs for telecommunications security especially for emerging technologies -- very large systems like the international Internet, high-speed systems like the gigabit testbeds, wireless systems, and personal communication systems. * Special issues and problems in security architecture, such as interplay between security goals and other goals -- efficiency, reliability, interoperability, resource sharing, and cost. GENERAL CHAIR: Jim Ellis, CERT Coordination Center PROGRAM CHAIRS: David Balenson, Trusted Information Systems Rob Shirey, The MITRE Corporation PROGRAM COMMITTEE: Tom Berson, Anagram Laboratories Matt Bishop, University of California at Davis Ravi Ganesan, Bell Atlantic Burt Kaliski, RSA Laboratories Steve Kent, BBN Communications Paul Lambert, Motorola John Linn, OpenVision Technologies Clifford Neuman, Information Sciences Institute Hilarie Orman, University of Arizona Michael Roe, Cambridge University (UK) Rob Rosenthal, U.S. National Institute of Standards and Technology Jeff Schiller, Massachusetts Institute of Technology Mike St. Johns, Advanced Research Projects Agency Peter Yee, U.S. National Aeronautics and Space Administration Roberto Zamparo, Telia Research (Sweden) SUBMISSIONS: The committee invites both technical papers and proposals for panel discussions on technical and other topics of general interest. Technical papers should be 10-20 pages in length. Panel proposals should be two pages in length, and should describe the panel topic, name the panel chair, explain the format of the panel, and list three to four potential panelists. The technical papers will appear in the proceedings. Panel chairs and panelists will have the option of having written statements appear in the proceedings. All submissions should contain a separate title page which includes the type of submission (paper or panel), the title or topic, the names of the author(s), organizational affiliation(s), telephone and FAX numbers, postal addresses, Internet electronic mail addresses, and the point of contact, if more than one author. Since the review process will be anonymous, the author's names, affiliations and other information should appear only on the separate title page. Deadline for paper submission: August 15, 1994 Notification sent to authors by: October 17, 1994 Deadline for camera-ready copy: November 15, 1994 Submissions must be made by 15 August 1994. Submissions should be made via electronic mail. Submissions may be in either of two formats: PostScript or ASCII. If the committee is unable to print a PostScript submission, it will be returned and ASCII requested. Therefore, PostScript submissions should arrive well before 15 August. If electronic submission is absolutely impossible, submissions should be sent via postal mail. All submissions and other correspondence should be directed to the Program Co-Chair: David M. Balenson Trusted Information Systems, Inc. 3060 Washington Road (Rt. 97) Glenwood, Maryland 21738 USA Phone: 301-854-6889 FAX: 301-854-5363 Email: balenson@tis.com Each submission will be acknowledged through the medium by which it is received. If acknowledgment is not received within seven days, please contact the Program Co-Chair as indicated above. Authors and panelists will be notified of acceptance by 17 October 1994. Instructions for preparing camera-ready copy for the proceedings will be postal mailed at that time. The camera-ready copy must be received by 15 November 1994. ----- -- David M Balenson  -----------[000256][next][prev][last][first]---------------------------------------------------- Date: 13 Jul 1994 05:11:29 GMT From: tpa@well.sf.ca.us (Thomas Paul Anderson) To: comp.protocols.tcp-ip,comp.unix.solaris Subject: Re: TCP anomalous (?) behaviour in application  MARCO PACE (MPACE@ESOC.BITNET) wrote: : Hi, : can anybody provide some useful advice on the following problem? : I have two applications (running on a SUN workstation with Solaris 2.3) : communicating using TCP. One is a server, accepting connections; the : other is a client, connecting to the server. The client writes some : data to the server after connecting to it, the server reads the data : after accepting the connection. : The behaviour I can't explain is that, if the server dies (is killed) : after accepting the connection from the client, the client can still : perform successfully its write without realizing the death of the : server. In other words, the write primitive returns successfully. : A second write to the server, on the contrary, fails as expected. : Why this behaviour ? I think it might be related to the connection : status (to be checked with the UNIX utility 'netstat') which appears : to be still existing after the server's death. : How can I detect the server's death immediately ?? : Any help will be appreciated. : Thanks, : Marco : ------------------------------------------------------------------------- : Marco Pace, Software Engineer Tel : +49 6151 903065 : Vitrociset S.p.A. Fax : +49 6151 904065 : ESOC, Robert-Bosch-Strasse 5 e-Mail: mpace@esoc.bitnet : D-64293 Darmstadt, Germany x400: C=DE;A=DBP;P=ESA;O=ESOC;S=PACE;G=MARCO I guess it depends which side is which: assuming you are using sockets, then the "living" side should get a SIGPIPE. In BSD the default action for SIGPIPE is "ignore", in SVR4 the default action is termination (talk about a subtle change :-}). In any event, I would think it advisable to install a SIGPIPE handler to allow your applictions to shutdown in an orderly manner.  -----------[000257][next][prev][last][first]---------------------------------------------------- Date: 13 Jul 1994 05:45:08 GMT From: davep@comtch.iea.com (Dave Paulsen) To: comp.protocols.tcp-ip,alt.winsock Subject: Re: Windows screws up as server?  In article <droehr.16.0009B73A@borland.com>, droehr@borland.com (Daev Roehr) says: >>Is this a problem, is it only a problem with particular >>implementations, or is it an inherent problem because >>windows is non pre-emptive? > >Windows make a lousy server, mostly because of the coopertive multi-tasking, >partly because the 16-bit address space is all shared, and partly because >it's not very robust. It does however, make a pretty good WWW reader.<g> The I dunno, it seems to work fine. My system is a 386-40 w/8Mb and a couple of older Conner 340Mb IDEs. Using W4Wg 3.11, Trumpet 1.0b, WinQVT 3.97 FTPServer, and httpd 1.2 on a 28.8 SLIP connection, I've done ftp's with QVT's client and ws_ftp and get from 26-35 Kbps transfer rates. The system is still very experimental, but in limited testing transfering files and html documents, it hasn't crashed without my deliberately screwing with it. _dave_(seemingly obligatory and definately bandwidth wasting .sig)  -----------[000258][next][prev][last][first]---------------------------------------------------- Date: Wed, 13 Jul 1994 06:20:21 GMT From: curt@uhunix3.uhcc.Hawaii.Edu (Curt Fiedler) To: comp.protocols.ppp,comp.protocols.tcp-ip,comp.sys.mac.comm,comp.sys.mac.misc,comp.sys.mac.wanted Subject: Re: SLIP and PPP Clients/Dynamic Addressing  TriSoft (trisoft@bga.com) wrote: : David, : I will make a quick (and highly prejudice) recommendation for MacSLIP. : It has a very powerful scripting language for automating the connection, : extremely high throughput, and will give good performance on everything up : through a PowerMac. : If you want to get more information on MacSLIP, you can contact TriSoft : via this email, or 1-800-531-5170 (512-472-0744). : James M. Knox You know what? I wish that you would configure my copy of MacSLIP. I got MacSLIP with my Microphone Pro software and found it VERY difficult to set up. I'm sorry that I paid extra to get the product, as the free package, MacPPP, is much easier to set up and, according to our unix guys, more reliable. I'm not a moron either, but MacSLIP certainly is a pain to set up. Use MacPPP, if you want fewer set up headaches, IMHO. Or get the guys/gals at TriSoft to configure it for you. :) Good Luck, Curt up.  -----------[000259][next][prev][last][first]---------------------------------------------------- Date: 13 Jul 1994 07:01:19 GMT From: ice@actlab.rtf.utexas.edu (Jeffrey J. Radice) To: comp.protocols.tcp-ip Subject: Gateway through dynamic SLIP??  I have a local network of tcp/ip connected Linux and WFW3.11. The Linux box also serves as a SLIP connection to the internet. It is a dynamic SLIP connection so my host ip varies, while the remote host ip is constant. I don't have access to the remote host at all...all i get is an address from them. I have played with the /sbin/route to no end, using different default gw #s, and nothing changes...it is the same effect as when i assign no gateway. I can telnet through SLIP just fine...I can telnet/ftp from WFW to Linux fine and from there out. I can't telnet from WFW to the internet directly. I would assume that this is because i need to set up my Linux as the gateway. What am i missing here? All help is appreciated. Please respond via email as i'll be out of town for a few days. Thanks. -jjr ice@actlab.rtf.utexas.edu  -----------[000260][next][prev][last][first]---------------------------------------------------- Date: 13 Jul 1994 16:25:49 -0400 From: Ajay.Simha@launchpad.unc.edu (Ajay Simha) To: comp.protocols.tcp-ip Subject: KA9Q  Hi! Does anyone know about the copyright info on ka9q? Any other opinions about this software? -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- Launchpad is an experimental internet BBS. The views of its users do not necessarily represent those of UNC-Chapel Hill, OIT, or the SysOps. -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --  -----------[000261][next][prev][last][first]---------------------------------------------------- Date: 13 Jul 1994 12:23:21 GMT From: mharrop@interlog.com (Matt Harrop) To: comp.protocols.ppp,comp.protocols.tcp-ip,comp.sys.mac.comm,comp.sys.mac.misc,comp.sys.mac.wanted Subject: Re: SLIP and PPP Clients/Dynamic Addressing  In article <netguide-1107941645340001@netguide.dialup.access.net>, obsidian@panix.com wrote: > I am interested in finding out what SLIP and PPP clients there are > available for the Macintosh besides InterSLIP, InterPPP and MacPPP. > Additionally, I am looking for the ability to utilize dynamic IP > addressing; I would be very interested in any packages that make this > (easily) possible. > MacPPP does dynamic with no problem at all. InterSLIP may or may not, I'm not sure. Regards, -- Matt Harrop mharrop@interlog.com InterLog Internet Services voice (416) 537-7453 fax (416) 532-5015 Online Publishing, Marketing, and Support on the Internet Lowest Cost Dial-Up Internet Connectivity in Toronto --$0.25/hour


-----------[000262][next][prev][last][first]----------------------------------------------------
Date:      Wed, 13 Jul 1994 17:29:11
From:      jlamia@skypoint.net
To:        comp.protocols.tcp-ip
Subject:   Trumpet Winsock SLIP at 115200

I would like to run Trumpet's Winosck at 115200 but am unable to set the
entery field for seepd that high. Is this possible with Trumpet?


-----------[000263][next][prev][last][first]----------------------------------------------------
Date:      13 Jul 1994 10:49:04 +0200
From:      casper@fwi.uva.nl (Casper H.S. Dik)
To:        comp.protocols.tcp-ip,comp.unix.solaris
Subject:   Re: TCP anomalous (?) behaviour in application

tpa@well.sf.ca.us (Thomas Paul Anderson) writes:

>I guess it depends which side is which:  assuming you are using sockets, then
>the "living" side should get a SIGPIPE.  In BSD the default action for SIGPIPE
>is "ignore", in SVR4 the default action is termination (talk about a subtle
>change :-}).

That isn't true: SIGPIPE was designed to *kill* naive processes that
continued to write to a pipe w/o a reader. E.g., lastcomm | head
will show the first 10 lines.  You don't want lastcomm to  keep
using up CPU time until it's done reading the pacct file, since none
gets its output.  It gets killed with SIGPIPE.

This is the same for BSD and for SVR4.  (SunOS 4.x and SunOS 5.x both
terminate, as does 4.x BSD)

>In any event, I would think it advisable to install a SIGPIPE handler to
>allow your applictions to shutdown in an orderly manner.

signal(SIGPIPE, SIG_IGN) will help too (write will return an error).

Casper


-----------[000264][next][prev][last][first]----------------------------------------------------
Date:      13 Jul 1994 15:15:45 GMT
From:      mike@ozonline.com.au (Michael Bethune)
To:        comp.protocols.tcp-ip
Subject:   Re: Variable Subnetting

In article <Css2zx.Ezz@syd.dms.CSIRO.AU>, marka@syd.dms.CSIRO.AU (Mark Andrews) says:
>
>In article <2vpbo6$bbv@budapest.ozonline.com.au> mike@ozonline.com.au (Michael Bethune) writes: >>Anyone got any comments about the behaviour of variable subnetting >>used with say, OSPF based routing. >Host which are not multi-homed need know nothing of the network >other than how to find their default router. ICMP redirects should get >them to the best router regardless of routing protocol being used or >whether variable subnets are being used. Hmm, how about subnets with multiple routers. Don't hosts on these networks need to know more about routing than can be supplied by simply a default router entry? > >Host should be using IRDP if available to find the default router. Umm, whats IRDP? > >Multi-homed hosts are the only hosts that should potentially be >listening routing protocols. This is regardless of whether they are >acting as a router or not. Be carful with multi-homed machines as most of >the current crop of OS's don't cope with having different netmasks on >the same network. (BSD 4.4 derived system do cope with this senario.) By the same network, what are we referring to here, does that mean the same C class or B class network with multiple subnet masks? >Mark Thank you for your reply to my Post.  -----------[000265][next][prev][last][first]---------------------------------------------------- Date: 13 Jul 1994 15:19:21 GMT From: fmanchon@zenon.inria.fr (Francois Manchon) To: comp.protocols.dicom,comp.protocols.ibm,comp.protocols.iso,comp.protocols.iso.x400,comp.protocols.misc,comp.protocols.nfs,comp.protocols.pcnet,comp.protocols.ppp,comp.protocols.snmp,comp.protocols.tcp-ip,comp.protocols.appletalk,comp.dcom.cell Subject: Summary: Want papers on network performance evaluation  Here is the summary of answers to my question. Thanks to all those who replied. Not many answers I am afraid. But many queries to send the summary... Here goes my original question, and then a couple of pointers. Cheers, Francois MANCHON <Francois.Manchon@sophia.inria.fr> ====================================================================== SIMULOG - Agence Sophia-Antipolis - Les Taissounieres HB2 Route des Dolines - 06560 VALBONNE - FRANCE Tel: +33 93 65 25 46 - Fax: +33 93 65 25 57 ...................................................................... Puisque toutes ces choses nous depassent, feignons d'en etre l'organisateur...'' -- Jean Cocteau ...................................................................... Date: Wed, 29 Jun 1994 11:37:20 +0200 Subject: Want papers on network performance evaluation - comp.protocols.misc #2164 From: Francois.Manchon@sophia.inria.fr (Francois Manchon) Hello Netters ! First of all, sorry for posting to so many groups at once. I really could not find any well-suited group for this question. PLEASE do not post a follow-up. Reply to me by e-mail and I will post a summary to comp.protocols.misc if people ask for it. I am currently doing a survey of performance evaluation for corporate telecom networks. I am looking for articles or technical reports describing experiments or (preferably), algorithms to evaluate the performances of a network under various load conditions. Mathematical algorithms are preferred, though simulators might be of interest. On-line measurements can be interesting too. The protocols we are interested in are the following: - Physical layer: voice/data multiplexers - Link layer: HDLC/SDLC/LAPB/LAPD, PPP, 802.x (mostly Ethernet, Token-Ring and FDDI), Frame-Relay, ATM, ICMP, SMDS - Network layer: X.25, SNA, IP, CBDS, RIPE, OSPF - Transport layer: TCP, UDP, APPN, DECnet, ISO transport, IPX Questions we try to answer are (among others): - Impact of error recovery on performance (e.g., on packet transmission delay) - Protocol overheads - Traffic paterns occurring in real networks Thanks in advance to all, and please remember to reply by e-mail. ...................................................................... Date: Mon, 18 Apr 1994 14:21:03 +0200 Subject: Re: TCP-IP performance references. - comp.protocols.tcp-ip #13301 From: tkr@puffball.demon.co.uk (Tim Rylance) The "Internet System Handbook" edited by Daniel C. Lynch and Marshall T. Rose, Addison Wesley 1993, ISBN 0-201-56741-5 has an excellent 100-page chapter by Jeffrey Mogul on "IP Network Performance". -- Tim Rylance <tkr@puffball.demon.co.uk> ...................................................................... Date: Mon, 27 Jun 94 08:36:26 EDT From: kevin_dubray@wellfleet.com (Kevin Dubray) Francois, You might check out "OSI Internet Performance," by Rick Wilder & Allison Mankin. (Mitre Technical Report, 1991, MTR-90W001173). This report focuses on congestion avoidance and flow control mechanisms in a TP4 environment. Perhaps better for you, it also has a good bibliography which may provide more datapoints for your work. Allison Mankin (mankin@cmf.nrl.navy.mil) may be able to give you further pointed insight to your topic. If possible, would you forward me a copy of your summary? Unfortunately, I don't often get a chance to read comp.* and would not like to miss seeing your summary. Thank you. Regards, Kevin Kevin Dubray Wellfleet Communications, Inc. kdubray@wellfleet.com [Note: I have not been able to get the Mitre report yet. Any hint? -- FM] ...................................................................... Date: Mon, 27 Jun 1994 13:19:04 -0500 From: Geoff.Sobering@nih.gov (Geoff Sobering) You probably already know of the review of ethernet swithes in the March, 1994 issue of "Data Communications". While the spcifics of the article may be of little interest to you, the testing methdology may. The test was specifically constructed to test the perfomance of the various devices under full-load, worst-case conditions. I look forward for your synopsis. Good luck, Geoff Sobering Geoff.Sobering@nih.gov In Vivo NMR Research Center (301) 402-3209 (voice) National Institutes of Health (301) 402-0119 (FAX) Bldg. 10, Rm. B1D-125 Bethesda, MD 20892 ...................................................................... Date: Mon, 27 Jun 1994 17:55:45 PDT From: "Jose Carrasco" <jcarras@telemtrx.com> Organization: Network Telemetrics, Inc. Hello Francois...in reply to your posted request for information. Network Telemetrics in Los Angeles, California USA manufactures a unique system for measuring end-to-end response time from PCs to SNA mainframes and from PCs to file servers. The name of the product is ProView-SNA. ProView-SNA lets you monitor Service Level 24 hours a day, is independent of network topology and generates its' own traffic at the application layer. The Proview-SNA consists of three components: 1.The Master Station, which executes on a dedicated OS/2 workstation, serves as the main user interface and provides the centralized SQL database for storing data, generating reports and charts of the response times. 2.Remote Agents, which execute in the background on user workstations to query SNA hosts and generate file transfers with any file servers the user has authorized access to. 3.The ProView-SNA VTAM application which executes in an MVS environment that routes test commands and results between the Master Station and the Remote Agents. In reply to your request I will gladly mail to you literature on our product and a white paper titled, "Response Time Service Levels On Interconnected LANs and WANs-- Where Are They?". Please provide your mailing address. ProView-SNA is vital to network specialists who need to how their network is performing and to validate tuning changes. Regards, -- Jose Carrasco Network Telemetrics, Inc. 27001 Agoura Road Telephone: (818) 878-7300 Suite 280 E-Mail: jcarras@telemtrx.com Calabasas Hills, CA 91301 ...................................................................... Date: Tue, 28 Jun 1994 11:48:18 +0200 From: Ornulf Rodseth <Ornulf.Rodseth@regtek.sintef.no> One very good reference for Ethernet is: D.R. Boggs, J.C. Mogul and C.A. Kent, "Measured Capacity of an Ethernet: Myths and Reality", Proc. ACM Sigcomm '88, Computer Communication Review, Vol 18, No. 4, August 1988, pp.222-234. ISBN 0-89791-279-9 There is also a longer version, containing more figures, that is available as WRL Research Report 88/4 from Digitial Western Research Laboratory 100 Hamilton Avenue Palo Alto, Ca 94301 This can also be got electronically by sending mail to "wrl-techreports@decwrl.dec.com" with "Subject: send postscript 88/4". Could you please e-mail a summary. I do not regularly read these news-groups. Ornulf Jan Rodseth M.Sc. ornulf.rodseth@regtek.sintef.no SINTEF Automatic Control +(47) 7359-4351 (direct) / -4375 (switchboard) N-7034 TRONDHEIM, NORWAY +(47) 7359-4399 (fax) [I got this tech report via e-mail. It works fine. Very interesting. -- FM] ...................................................................... Date: Tue, 28 Jun 1994 12:24:46 +0500 From: barnett@grymoire.crd.ge.com (Bruce Barnett) Here is a copy of my paper. Published at InterOp this year... [7815 lines of PostScript suppressed... here is the title and abstract -- FM] A Multi-level Network Analysis Technique. Bruce Barnett General Electric Corporate Research and Development Center PO Box 8, 1 River Road Schenectady, NY 12301 (518)-387-5220 (Voice) (518)-387-7332 (FAX) <barnett@crd.ge.com> ABSTRACT This paper describes a technique for analyzing low-level network performance data captured using tcpdump. It can categorize gigabyte-level traffic by volume and packets, protocol, port, source, and/or destination. IP fragments information may be placed with the appropriate TCP or UDP session. Raw data is abstracted into sessions, providing duration and transmission in- formation. High-level errors such as dropped packets, received buffer exhausted, etc., are detected. The percentage of elapsed time spent waiting for responses, timeouts, interpacket delays and inter-buffer delays is automatic ally calculated by analyzing state-sensitive delays between packets. This can be used to op- timize distributed applications, and diagnose problem areas. ...................................................................... From: seanf@ngc.com (Sean Finn) Date: Wed, 29 Jun 1994 20:17:10 Francois, I am very interested in this subject as well. I work for Network General, and use our Sniffer product in the assessment of network conditions. I have been able to locate only a few items that I consider worthwhile, such as the DEC WRL 88/4 report from David Boggs, et al. re: measurement of Ethernet capacity. The Jain book on Performance Analysis had some concepts, but not specific to communication issues. I'd be interested in knowing what type of results you find, & perhaps identify any other tidbits that would go towards a Network Performance Analysis resource list. thanks -- Sean (finns@ngc.com) ...................................................................... Date: Thu, 30 Jun 1994 15:46:18 -0400 From: wsmith@etc.com (Randy Smith [Warren Randall Smith]) I have several pieces of advice. First of all, you're never going to get a mathematical or simulation model that will give you a real taste of network performance. In reality little consequences (software and hardware implementation and bugs) get in the way of these nice models. I'm not sure what your goal is, but I'd bet that a little use of mathematical models to get very rough performance estimates followed by some real-world testing is going to give you the best results. You can spend forever trying to model something that you can go out and buy for a fraction of the cost of the models. I've got information on traffic patterns of several real networks for work I did on my Ph.D. thesis (all using several Ethernets). Send me e-mail if you have any questions. -Randy wsmith@etc.com or wsmith@cedar.cic.net [I agree with you, Randy. Modelling will never totally replace real-world testing. But sometimes you really need modelling. -- FM] ...................................................................... That's all folks!  -----------[000266][next][prev][last][first]---------------------------------------------------- Date: 13 Jul 94 18:14:11 GMT From: carlson@dwp.la.ca.us (Carlson Peters) To: comp.protocols.tcp-ip,alt.winsock Subject: Re: Windows screws up as server?  In article <2vvv14$1o5@krel.iea.com> r.phantom.com!hkwu writes:
>In article <droehr.16.0009B73A@borland.com>, droehr@borland.com (Daev Roehr) says:
>
>>>Is this a problem, is it only a problem with particular
>>>implementations, or is it an inherent problem because
>>>windows is non pre-emptive?
>>
>>Windows make a lousy server, mostly because of the coopertive multi-tasking,
>>partly because the 16-bit address space is all shared, and partly because
>>it's not very robust. It does however, make a pretty good WWW reader.<g> The
>
>I dunno, it seems to work fine.  My system is a 386-40 w/8Mb and a
>couple of older Conner 340Mb IDEs.  Using W4Wg 3.11, Trumpet 1.0b, WinQVT
>3.97 FTPServer, and httpd 1.2 on a 28.8 SLIP connection, I've done ftp's
>with QVT's client and ws_ftp and get from 26-35 Kbps transfer rates.  The
>system is still very experimental, but in limited testing transfering
>files and html documents, it hasn't crashed without my deliberately
>screwing with it.

Don't bet anything important on Windows as a server platform.  The
fact that you can deliberately crash it says boatloads.  It might be
passable running one server process with a single client at a time and
nothing else running.  Just try stressing it a little bit and see the
whole thing crash fast.

--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Carlson Peters			carlson@asg.dwp.la.ca.us


-----------[000267][next][prev][last][first]----------------------------------------------------
Date:      Wed, 13 Jul 1994 18:37:29 +0000
From:      tfl@psp.co.uk (Thomas F Lee)
To:        comp.os.ms-windows.networking.tcp-ip,comp.os.ms-windows.programmer.networks,comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject:   Re: DNS

In article <773912743snz@peeras.demon.co.uk>
proyse@peeras.demon.co.uk "Phil Royse" writes:

>
> In article <773834307snz@psp.co.uk> tfl@psp.co.uk "Thomas F Lee" writes:
>
> >A DNS server is a _server_ which resolves _Host Names_ into _IP Addresses_.
> >
> >We played with this a bit during last week and the DHCP stuff works
> >great.  Didn't really have much time to explore WINS though.  Documentation
> >on DHCP can be found on gowinnt.microsoft.com (there is a DHCP.DOC Word
> >document by J Allard - worth reading).
>
> Thomas,  what were using for the DHCP server?  an NTAS system? Beta?

NTAS Beta 1 running on a 486/50.  It all seemed quite easy, really.

> I have got the TCP-32 Beta stack working between my two WfWG 3.11
> PCs here, and I would like to play with DHCP, ahead of advising some
> clients on this.

It's pretty neat stuff, but I am going to have to play with it a bit
more to really understand the relationship between DHCP and WINS.

Thomas
--
+-----------------+---------------------------+
! Thomas F Lee    !  Voice: 0628 850 077      !
! tfl@psp.co.uk   !  Fax  : 0628 850 143      !
+-----------------+---------------------------+


-----------[000268][next][prev][last][first]----------------------------------------------------
Date:      Wed, 13 Jul 1994 19:13:49 GMT
From:      micky@ejv.com (Micky Liu)
To:        comp.protocols.tcp-ip
Subject:   Multiple IP Addresses on One Physical Wire?


I know that it is technically feasible to have a network with
devices that are running different IP addresses on the same
wire in this fashion.

+-----------+                             +-----------+
| 142.9.1.1 |                             | 142.9.1.2 |
|     A     |                             |     B     |
+-----------+                             +-----------+
|                                         |
=============================================================================
|              |                                            |
|        +-----------+                                +-----------+
|        | 135.3.1.1 |                                | 135.3.1.2 |
|        |     C     |                                |     D     |
|        +-----------+                                +-----------+
|
+-----------+
| 135.3.1.9 |
|     R     |
+-----------+

And I only expect A to reach B, and for C to reach D -- and have no
expectation for A to reach either C nor D (same for B).  Meaning
connectivity between machines with similar network addresses.

What I want to know is, does this confuse any of the devices on this
net?  [A-D] are sun workstations, and R is a router.  Given this
configuration will any of these devices have a problem when they
see packets with a 'foreign' network address?

I know that Cisco routers can actually be configured to support
multiple IP addresses out of one physical interface.

Is this 'legal' to do in tcp/ip-land?  Given that it works, is there
any reason that I shouldn't do this?  And if I shouldn't do this,
why does Cisco have this feature?

Micky


-----------[000269][next][prev][last][first]----------------------------------------------------
Date:      13 Jul 1994 19:36:12 GMT
From:      kruckenb@sal.cs.utah.edu (Pete Kruckenberg)
Subject:   [Q] Use one Class C for two networks w/ Novell MPR?

I have a network with the following topology:

IPX 300
----------------------------------
|
|    IPX 400                                     PPP
[MPR]----------------------------[    Linux     ]-----(Internet)
|                           |   [Gateway/Router]
|                           |
|                   [IPX/Ethertalk router]
|                           |
| Ethertalk (Appletalk)     |
-----------------------------

The 300, 400, and Ethertalk segments are all connected into a variety
of Netware servers. What I need to do is route TCP/IP traffic between
the three segments, so a machine on any segment can talk to any other
machine, including external machines through the Linux gateway. Right
now, any machine on the 400 segment can go through the gateway just
fine.

We've got Novell's Multi-Protocol-Router (MPR), a Class C IP (254
hosts) allocation, and connections from the MPR machine to each of the
segments. My (first) question is whether we can do this with a single
Class C, or if we need a class C for each segment (we only need about
100 IP #'s now, so three Class C's would be unnecessary except for
this). Is there a way we can use the subnet mask to spread the Class C
over the three segments? How would I do this (assume no more than
80 hosts on each segment)?

My second question will hopefully be answered by the first, but I'll
ask it anyways. Right now, I've got just two cards in the MPR machine
connected to the 300 and 400 segments. When I configure them (with
INETCFG), I assign them IP addresses: 198.60.81.X. If I make them
different, say X is 253 and 254, I get an error message on boot that
they have to be the same because they are on the same interface. If I
make them the same, say X is 254 and 254, I get an error message that
they have to be unique because they're on the same network. What
gives?

Third question: on the 300/Ethertalk segments will my host's default
gateway be the MPR machine, whose default gateway will be the Linux
box? I know that on the 400 segment, the default gateway will be the
Linux box, but I'm a little unsure about the MPR and hosts on the
other segments.

Any help and/or pointers to help will be greatly appreciated. Email or
post is fine. I have directed follow-ups to comp.sys.novell, as this
deals mostly with the MPR, which is Novell.

Thanks for your help and time!
Pete Kruckenberg
kruckenb@sal.cs.utah.edu

--
------------------------------------------------------------------------
Pete Kruckenberg                       School: kruckenb@sal.cs.utah.edu
University of Utah                       Work: pete@dswi.com
Computer Engineering    For even more addresses, "finger pete@dswi.com"


-----------[000270][next][prev][last][first]----------------------------------------------------
Date:      Wed, 13 Jul 1994 20:28:47 GMT
From:      evansmp@mb52112.aston.ac.uk (Mark Evans)
To:        comp.protocols.tcp-ip
Subject:   Re: Fake network addresses

Karl Auerbach (karl@cavebear.com) wrote:

: The RFC you cited is quite separate from the "test" reserved addresses.

: Class C 192.0.2.x is reserved and should not exists.  I use it as a
: preconfigured address in products I write and I coerce the IP stack into never
: sending from that Class C net number.  This forces the user to configure the
: product.

: I doubt, however, that routers and such would keep such addresses out of their
: routing tables should they accidently appear.

Agreed, especially as there are machines which manage to route 127.x.x.x
(execpt 127.0.0.1) arround.


-----------[000271][next][prev][last][first]----------------------------------------------------
Date:      13 Jul 1994 22:02:48 GMT
From:      art@now.midnight.com (Art Mellor)
To:        comp.protocols.tcp-ip
Subject:   How do you tell if unknown option type is followed by a length byte?


I'm reading the Draft router requirements spec and it says that unknown
options should be ignored. The problem I have is when parsing the options
in an IP packet and you hit a type that you don't know, how do you know
if it is a single byte option or an option followed by a length byte?

Am I missing something in an RFC somewhere that indicates that No Operation
and End of Option List are the only 2 options that are allowed to be
one byte?

--

...............................................................................
Art Mellor       : Midnight Networks Inc. 100 Fifth Avenue Waltham MA 02154
art@midnight.com : Vox 617/890-1001 Fax 0028  The Best in Network Software


-----------[000272][next][prev][last][first]----------------------------------------------------
Date:      Wed, 13 Jul 1994 23:24:00 +0000
From:      mmcmullen@gsfcmail.nasa.gov (steve johnson)
To:        comp.protocols.misc,comp.protocols.tcp-ip,gsfc.network
Subject:   is gosip OFFICIALLY dead?

got an ongoing and rather important debate going with a coworker.  how
true is the following:

1) gosip is officially no longer mandated by the federal government for
use by civil servants and contractors (specifically NASA).

2) you can still use it if you want, but there will be little or no
support for it in the future, so you might as well switch to tcp or
whatever.


-----------[000273][next][prev][last][first]----------------------------------------------------
Date:      Thu, 14 Jul 1994 00:21:18 GMT
From:      marka@syd.dms.CSIRO.AU (Mark Andrews)
To:        comp.protocols.tcp-ip
Subject:   Re: Variable Subnetting

In article <3010f1$h6q@budapest.ozonline.com.au> mike@ozonline.com.au (Michael Bethune) writes: >In article <Css2zx.Ezz@syd.dms.CSIRO.AU>, marka@syd.dms.CSIRO.AU (Mark Andrews) says: >> >>In article <2vpbo6$bbv@budapest.ozonline.com.au> mike@ozonline.com.au (Michael Bethune) writes:
>>>used with say, OSPF based routing.

>>Host which are not multi-homed need know nothing of the network
>>other than how to find their default router. ICMP redirects should get
>>them to the best router regardless of routing protocol being used or
>>whether variable subnets are being used.
>
>Hmm, how about subnets with multiple routers. Don't hosts on these networks
>need to know more about routing than can be supplied by simply a default router entry?
>

No. The first packet to a destination that would not noramally
go via the default router should generate a ICMP Redirect.
Traffic should then go via the optimal router.

>>
>>Host should be using IRDP if available to find the default router.
>
>Umm, whats IRDP?
>

ICMP Router Discovery Protocol. See rfc-1256.

This is supported by CISCO's and Solaris 2.3. There is a version
of a IRDP daemon available from CISCO, look for prindeville,
that will supply host and router services for BSD 4.2/4.3 derived
systems. The IRDP daemon should deal with dead router detection
an removal of bad redirect routing entries. (The kernel really
should time these out anyway, though most don't).

>>
>>Multi-homed hosts are the only hosts that should potentially be
>>listening routing protocols. This is regardless of whether they are
>>acting as a router or not. Be carful with multi-homed machines as most of
>>the current crop of OS's  don't cope with having different netmasks on
>>the same network. (BSD 4.4 derived system do cope with this senario.)
>
>By the same network, what are we referring to here, does that mean the same
>C class or B class network with multiple subnet masks?
>

The above statment was independent of the class of the network
involved. If a network, whether it be classs A, B or C, has
different netmasks applied anywhere on it, the routing
information when installed in a kernel that does not know about
variable network masks can potentially stuff up internal routing
in that network, or choose very sub optimal routes.

>
>
>>Mark
>

Mark.


-----------[000274][next][prev][last][first]----------------------------------------------------
Date:      Thu, 14 Jul 1994 00:52:24 GMT
From:      rstevens@noao.edu (W. Richard Stevens)
To:        comp.protocols.tcp-ip
Subject:   Re: How do you tell if unknown option type is followed by a length byte?

> I'm reading the Draft router requirements spec and it says that unknown
> options should be ignored. The problem I have is when parsing the options
> in an IP packet and you hit a type that you don't know, how do you know
> if it is a single byte option or an option followed by a length byte?
> Am I missing something in an RFC somewhere that indicates that No Operation
> and End of Option List are the only 2 options that are allowed to be
> one byte?

I don't know the exact reference, but I'm pretty sure there exists in
writing somewhere, that other than EOL and NOP there will *never* be
a new option without a length field.

Rich Stevens


-----------[000275][next][prev][last][first]----------------------------------------------------
Date:      Thu, 14 Jul 1994 08:04:32 GMT
From:      albert@dn.itg.telecom.com.au (Albert Fu)
To:        comp.protocols.tcp-ip
Subject:   ARP update mechanism on unix hosts

Could someone please explain how various unix hosts
(eg. Sun, HP, NCR, Dec Ultrix) update the arp entries.

We had a problem with an ethernet board on a router
yesterday, and when the board was replaced and the router
restarted, we lost connectivity with a number of NCR unix
hosts attached to the router's ethernet segments. This
lasted for a few hours.

The router would have ARP'ed the host after the restart
(eg in response to a ping request from our operator).
This ARP request would have been sent to the broadcast
Mac address. However, since we couldn't ping the host,
I suspect the host did not update its ARP entry for the
router with the new Mac address that was contained in
the ARP request, and instead, it sent the ARP response
to the router's old Mac address.

an IP packet? Also, is there a mechanism for the Unix host to
refresh its ARP cache periodically, eg every 10 minutes?

Albert Fu.


-----------[000276][next][prev][last][first]----------------------------------------------------
Date:      14 Jul 1994 16:34:25 -0400
From:      zbig@junior.wariat.org (Zbigniew J. Tyrlik)
To:        comp.protocols.tcp-ip
Subject:   Re: slip--must be 2 nets

In <774184249snz@peeras.demon.co.uk> proyse@peeras.demon.co.uk (Phil Royse) writes:

>In article <2vhvfh$5pj@junior.wariat.org> > zbig@junior.wariat.org "Zbigniew J. Tyrlik" writes: >>Using Livingstone PM series I use one C class to service a dozen hosts >>on Ethernet, and 2 PM's with dial-up lines; no problems assiging >>IP's from this same network, no subnetting in use... >> >> >>_zjt ( wannabe in training ) >Yes, but do you need to use two IP addresses per remote link? No. >one for the actual PC at the remote site and one for the terminal >servers' SLIP port? No. Whole Livingstone lives with one IP, fpr ethernet and all 30 serial lines. >How many simultaneous remote users can you support with one Class C >network address? 254? Assuming that I will use this C class only for slip, 253: one IP for Terminal Server; one IP for remote machine. With limitation that remote units are always single machines. >TIA >-- >Phil Royse Comms Consultant | PRA Consulting Ltd. _zjt ( wannbae in training )  -----------[000277][next][prev][last][first]---------------------------------------------------- Date: Thu, 14 Jul 1994 10:39:59 GMT From: H.J.Snel@ATT.COM (Henk J. Snel) To: comp.protocols.tcp-ip Subject: wanted: tcpping  I am wondering if someone has written a ping program which uses the TCP protocol i.s.o. UDP (i.e. tcpping). This program must have the same capabilities like fping (timeout limit, retry limit, etc.) -- Henk J. Snel | Internet: H.J.Snel@ATT.COM Network Administrator | UUCP: ...!uunet!att!hvlpa!hsnel Room BG-S64 | Phone: +31 35 872311 Larenseweg 50 | Fax: +31 35 875857 1200 BD Hilversum | The Netherlands | "The Wonderful World of UNIX"  -----------[000278][next][prev][last][first]---------------------------------------------------- Date: Thu, 14 Jul 1994 10:44:27 +0000 From: proyse@peeras.demon.co.uk (Phil Royse) To: comp.protocols.tcp-ip Subject: Re: Installing SLIP  In article <2vcc7p$lbv@acsc.com> rao@acsc.com "Rao Srinivasa" writes:

>
> You can connect a host by SLIP without wasting a subnet number for it ...
>
>
>                                130.76.79
>                        -------------------------------------
>                                                    |
>                                                    |
>                  130.76.80.126                     | 130.76.79.100
>---------               ----------              ---------
>Host    | SLIP          |         |             |       |
>to      |---------------|   M1    |             |  M2   |
>connect |               |         |             |       |
>--------                ---------               ---------
> 130.76.80.125              |130.76.80.66            | 130.76.80.65
>                        -------------------------------------

Rao,

Are you saying that a single SLIP connection needs to use up TWO
IP addresses?  one for the remote host (130.76.80.125) and one
(130.76.80.126) for the base connection (is that a terminal server
port?)

If we are setting up many remote dial-in connections using SLIP and
we want each remote PC to have a fixed (dedicated) IP address, then
we need to use twice as many IP addresses as we have remote PCs?

Phil
--
Phil Royse     Comms Consultant  |  PRA Consulting Ltd.
TUDOR HOUSE                      |
Surrey  CR8 4LN (UK)  Tel: (+44) 81 645-9868   proyse@peeras.demon.co.uk


-----------[000279][next][prev][last][first]----------------------------------------------------
Date:      Thu, 14 Jul 1994 11:01:51 +0000
From:      proyse@peeras.demon.co.uk (Phil Royse)
To:        comp.os.ms-windows.networking.tcp-ip,comp.os.ms-windows.programmer.networks,comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject:   Re: DNS

In article <774124649snz@psp.co.uk> tfl@psp.co.uk "Thomas F Lee" writes:

PR> Thomas,  what were using for the DHCP server?  an NTAS system? Beta?
>
>NTAS Beta 1 running on a 486/50.  It all seemed quite easy, really.
>
>It's pretty neat stuff, but I am going to have to play with it a bit
>more to really understand the relationship between DHCP and WINS.
>
>Thomas

Thanks.

Re. WfWG 3.11 and the TCP/IP-32, I have just started playing with the
address assignments and seeing what happens when I configure more
than one IP address for each interface (as one is allowed to do in the

I have had some fairly wierd results, which were inconclusive and
probably due to finger trouble on my part.

It seems that I can easily configure TWO IP addresses to each
Ethernet card on each of my 2 Ethernet connected PCs.  This is confirmed
with the "ipconfig /all" command.

However, in the LMHOSTS. file if I "#PRE" both addresses, then the
interfaces refuse to link at NetBIOS level, ie. WfWG stops talking.
works just like before, but totally ignores the second IP address(s)

But I can perfectly well ping from any PC to BOTH of the IP addresses
on each machine, using ping<IP address>.  When I ping<hostname>, it
grabs the first listed IP address in the HOSTS. file.

It seems that the TCP/IP transport is happy with multiple addresses
on any PC, but WfWG 3.11 (ie. the NetBIOS stuff) doesn't like it?

Why is this?

What is the point of multiple IP addresses on a PC?

Am I missing some interesting functionality here?

Any ideas?

--

Phil Royse     Comms Consultant  |  PRA Consulting Ltd.
TUDOR HOUSE                      |
Surrey  CR8 4LN (UK)  Tel: (+44) 81 645-9868   proyse@peeras.demon.co.uk


-----------[000280][next][prev][last][first]----------------------------------------------------
Date:      Thu, 14 Jul 1994 11:10:49 +0000
From:      proyse@peeras.demon.co.uk (Phil Royse)
To:        comp.protocols.tcp-ip
Subject:   Re: slip--must be 2 nets

In article <2vhvfh$5pj@junior.wariat.org> zbig@junior.wariat.org "Zbigniew J. Tyrlik" writes: >Using Livingstone PM series I use one C class to service a dozen hosts >on Ethernet, and 2 PM's with dial-up lines; no problems assiging >IP's from this same network, no subnetting in use... > > >_zjt ( wannabe in training ) Yes, but do you need to use two IP addresses per remote link? one for the actual PC at the remote site and one for the terminal servers' SLIP port? How many simultaneous remote users can you support with one Class C network address? 254? TIA -- Phil Royse Comms Consultant | PRA Consulting Ltd. TUDOR HOUSE | 12 Woodside Road, Purley Surrey CR8 4LN (UK) Tel: (+44) 81 645-9868 proyse@peeras.demon.co.uk  -----------[000281][next][prev][last][first]---------------------------------------------------- Date: Thu, 14 Jul 1994 11:51:02 +0000 From: proyse@peeras.demon.co.uk (Phil Royse) To: comp.protocols.tcp-ip Subject: Re: IP Usage Billing package ?  In article <1994Jul12.125058.30409@ucl.ac.uk> ucacjon@ucl.ac.uk "Jon Crowcroft" writes: >In article <2vovt0$bjn@hpwin055.uksr.hp.com>, gerryw@hpbrak42.uksr.hp.com
> (Gerry WINSOR) writes:
>|> Hi,
>|>
>|> Anyone aware of a commercially available "TCP/IP Billing" package which'll
>|> use actual IP usage rates as the billing calculation ?
>
>and how will it deal with retransmits ?

[stuff deleted]
>
>charging by usage only makes sense for traffic that must be restrained
> - e.g. real time traffic - bulk data transfer (ftp, email bboards,
> archie, gopher, wais, www, etc) is best not useage charged.....
> it is not optimal...
>
>--
>jon crowcroft (hmmm...)

I agree, charging for infrastructure usage is very problematical
and expensive to do, even when usage is measurable as it is on connection-
oriented networks.

Charging for connectionless networking is even worse. Don't do it.

In any case, usage-charging is a totally artificial mechanism which
isolates the revenue from the actual costs.  Just look at X.25 PDN
charges:  low connection/capital; medium fixed periodic charge; very
high usage-dependent element.

And compare this to the **cost** structure, which is totally different:
Very high capital cost (PSEs); medium high fixed periodic
charges (line rentals & maintenance) and VERY, VERY, VERY low
usage-dependent costs (the extra electricity consumed if more packets
are flowing thru the PSE).

For a large community and a public service (eg. an X.25 PDN) this glaring
inconsistency is generally accepted, but the smaller the community
for which you want to set up charging eg. a group of companies, local
authorities, trade assocn. etc it appears really unfair to some. I've gone
thru this with several clients: you'll never get users all to agree
on what's fair.  And once you've worked out how to do your usage-based
charging, you'll never get agreement on a fair tariff structure.

Then, again, depending on the environment you are planning to serve
you may be constrained to charge something competitive....

Finally, usage-based charging is a nightmare recipe for making
either a huge profit or a huge loss, based on a small change in

Do you really want your revenue stream to be that sensitive to others'
usage?

--

Phil Royse     Comms Consultant  |  PRA Consulting Ltd.
TUDOR HOUSE                      |
Surrey  CR8 4LN (UK)  Tel: (+44) 81 645-9868   proyse@peeras.demon.co.uk


-----------[000282][next][prev][last][first]----------------------------------------------------
Date:      14 Jul 1994 18:38:29 -0400
From:      tal@Warren.MENTORG.COM (Tom Limoncelli)
To:        comp.protocols.tcp-ip
Subject:   Re: Is there a self-aliasing IP address?

In <einste44-1407941544450001@ts6-47.upenn.edu> einste44@wharton.upenn.edu (Eric L. Einstein) writes:

>I connect to the Internet via a SLIP connection, so I have a different IP
>address every time I sign on.  I would like to know if there is a reserved
>IP address that always bounces back to the originator of the signal, no
>matter what the real IP address of that machine is.  This is probably a
>really simple question, but, obviously, I'm IP deficient.  Thanks for your

127.0.0.1 always refers to the "localhost".  "ifconfig -a"
will tell you that 127.0.0.1 is the address of the "loopback"
interface "lo0".  "lo0" is software.

Tom
--
Tom Limoncelli -- tal@warren.mentorg.com (work) -- tal@plts.uucp (play)

The internet is like a box of chocolates.


-----------[000283][next][prev][last][first]----------------------------------------------------
Date:      Thu, 14 Jul 1994 12:19:10 GMT
From:      rstevens@noao.edu (W. Richard Stevens)
To:        comp.protocols.tcp-ip
Subject:   Re: How do you tell if unknown option type is followed by a length byte?

> I don't know the exact reference, but I'm pretty sure there exists in
> writing somewhere, that other than EOL and NOP there will *never* be
> a new option without a length field.

Just found it: RFC 1122, p. 35.

Rich Stevens


-----------[000284][next][prev][last][first]----------------------------------------------------
Date:      Thu, 14 Jul 1994 14:45:17 GMT
From:      knight@henson.cc.wwu.edu (Matthew Scott)
To:        comp.protocols.tcp-ip
Subject:   Help, Should we add IPX routing to our campus IP net?


Hello,

I would like to make a request for information about adding IPX routing to
our campus IP backbone.  This is __NOT__ intended to start any religious wars
(although the topic by definition is one).  I just really need to hear peoples
opinions and fact, and hopefully pointers to documents that address this
situation.

The facts:
Our campus has always been a IP network.  We were a small net with 1 Cisco
router.  Just like everyone else, access to local and Internet resources is
now in high demand.  Many Novell lan's, and even an NTAS lan have shown up
all over campus.  We now have 2 Cisco routers (small <8 ports each) and a
large Cisco 7000 on the way.  There have been, and continue to be networking
plans.  On these plans I have my own feelings about what is the best way to do
things, but then don't we all :-)

The big consideration now is, in an attempt to allow NTAS and Novell
to function better, whether to route IPX along with IP across the entire
campus.

All the individuals involved have their own __IDEAS__ of what is "right"
and what is "wrong".  I am one of those people.  However, I have _always_
argued that we should evaluate the technology and then based upon the
resulting information make a well thought out decision, that is the best
solution based upon technical and empirical information, __NOT__ on
sales hype and peoples personal preferences!

This all being the case I must say that I have a "knowledge deficit" in the
realm of one of these protocols.  Therefore, I would like to get as much
information on the effects of adding IPX routing to an IP only backbone.
Are there huge performance hits, do the networks typically experience
significantly larger amounts of traffic,  do the benefits of routing
multiple protocols out weigh any negative effects?  Any information that I
can use to help educate those (on both sides of the fence) would be
greatly appreciated.

I understand that there are __MANY__ facts about network design that
affect the ability of the network to perform its duty.  These many other
issues will be considered along with the info that I am able to gather from
the collective net wisdom.

Thank you for your time, and hopefully information.
Matt

(This is being posted to comp.protocols.tcp-ip, comp.sys.novell and
comp.dcom.cisco to try and get all sides of the issue.)

---
Matthew Scott - knight@admcs.wwu.edu           Western Washington University
Voice: (206) 650-6839                          Administrative Computing Services
Fax: (206) 650-7323                            Unix sys admin/sys programmer

And you might notice no one is ever free
And maybe, just maybe for now that's how it's supposed to be
Could be so far we've only earned the right to barely see

-Blues Traveler


-----------[000285][next][prev][last][first]----------------------------------------------------
Date:      14 Jul 1994 23:40:04 -0500
From:      mweiss@nwk.cl.nec.co.jp (Michael J. Weiss)
To:        comp.os.ms-windows.networking.tcp-ip,comp.os.ms-windows.programmer.networks,comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject:   What is MBONE?

The subject line says it all: What is MBONE? (not just what the acronym
stands for, either--what IS it?)

Thanks,

--Mike


-----------[000286][next][prev][last][first]----------------------------------------------------
Date:      Thu, 14 Jul 94 23:46:47 -0500
From:      jefrob@delphi.com
To:        comp.protocols.tcp-ip
Subject:   Re: MAP TOP details

Try http://litwww.epfl.ch/~ppvx/mms.html on www

Jeff Robbins
Cycle Software, Inc.
(617) 770-9594


-----------[000287][next][prev][last][first]----------------------------------------------------
Date:      Thu, 14 Jul 1994 15:33:05 GMT
From:      chris@quay.ie (Christopher Davey)
To:        comp.unix.aix,comp.os.ms-windows.networking.tcp-ip,comp.protocols.tcp-ip
Subject:   Linking 2 IP Subnets through SNA

Does anyone know whether it is possible to link 2 IP subnets
through a SNA network. If so, what it required ?

The machines at each end are Windows NT machines.

Is it possible to tunnel IP through using PPP or somesuch ?

Please email me at chris@quay.ie and I will post a summary if

Chris
--
----WNA----------------------------------------------------------------------
Chris Davey                       Internet: chris@quay.ie
Quay Financial Software           Phone   : +353 1 6612377 Fax: +353 1 6607592
The views expressed above do not necessarily reflect those of my employer


-----------[000288][next][prev][last][first]----------------------------------------------------
Date:      14 Jul 94 21:39:48 MDT
From:      jrd@cc.usu.edu (Joe Doupnik)
To:        comp.protocols.tcp-ip
Subject:   Re: Multiple IP Addresses on One Physical Wire?

In article <1994Jul13.191349.658@ejv.com>, micky@ejv.com (Micky Liu) writes:
>
> I know that it is technically feasible to have a network with
> devices that are running different IP addresses on the same
> wire in this fashion.
>
> +-----------+                             +-----------+
> | 142.9.1.1 |                             | 142.9.1.2 |
> |     A     |                             |     B     |
> +-----------+                             +-----------+
>       |                                         |
> =============================================================================
>       |              |                                            |
>       |        +-----------+                                +-----------+
>       |        | 135.3.1.1 |                                | 135.3.1.2 |
>       |        |     C     |                                |     D     |
>       |        +-----------+                                +-----------+
>       |
> +-----------+
> | 135.3.1.9 |
> |     R     |
> +-----------+
>
> And I only expect A to reach B, and for C to reach D -- and have no
> expectation for A to reach either C nor D (same for B).  Meaning
> connectivity between machines with similar network addresses.
>
> What I want to know is, does this confuse any of the devices on this
> net?  [A-D] are sun workstations, and R is a router.  Given this
> configuration will any of these devices have a problem when they
> see packets with a 'foreign' network address?
>
> I know that Cisco routers can actually be configured to support
> multiple IP addresses out of one physical interface.
>
> Is this 'legal' to do in tcp/ip-land?  Given that it works, is there
> any reason that I shouldn't do this?  And if I shouldn't do this,
> why does Cisco have this feature?
>
> Micky
-----------
It's commonly done. The essentials are to not listen to RIP, so
there is no confusion about "this network" and the like. Instead stations
use static routes to the cisco (or equiv) and that in turn knows how to
relay to the target. Doubled network traffic is the frequent result.
The attraction is as you have shown, and frequently in the form
of different subnet masks on each station and those that may be located
behind them. The subnet mask (identity of "this network") need not be
consistent amongst stations on the backbone. If we used a better RIP
replacment (OSPF or whatever) which carried subnet mask information
with it then this kludge would be less attractive.
Just think of it as a fully routed Internet, all on one piece
of coax. But don't think of it if traffic is quite heavy already.
Whether it's fully legal I don't know. I do know that my site
has depended upon it for some time (K's of stations).
Joe D.


-----------[000289][next][prev][last][first]----------------------------------------------------
Date:      Thu, 14 Jul 94 16:12:24 GMT
From:      scott@tdc.rtp.dg.com (John Scott)
To:        comp.protocols.tcp-ip,comp.unix.solaris
Subject:   Re: TCP anomalous (?) behaviour in application

In article <2vvt21$e04@nkosi.well.com> tpa@well.sf.ca.us (Thomas Paul Anderson) writes: >MARCO PACE (MPACE@ESOC.BITNET) wrote: >: Hi, >: can anybody provide some useful advice on the following problem? >: I have two applications (running on a SUN workstation with Solaris 2.3) >: communicating using TCP. One is a server, accepting connections; the >: other is a client, connecting to the server. The client writes some >: data to the server after connecting to it, the server reads the data >: after accepting the connection. >: The behaviour I can't explain is that, if the server dies (is killed) >: after accepting the connection from the client, the client can still >: perform successfully its write without realizing the death of the >: server. In other words, the write primitive returns successfully. >: A second write to the server, on the contrary, fails as expected. >: Why this behaviour ? I think it might be related to the connection >: status (to be checked with the UNIX utility 'netstat') which appears >: to be still existing after the server's death. >: How can I detect the server's death immediately ?? >: Any help will be appreciated. >: Thanks, >: Marco >: ------------------------------------------------------------------------- >: Marco Pace, Software Engineer Tel : +49 6151 903065 >: Vitrociset S.p.A. Fax : +49 6151 904065 >: ESOC, Robert-Bosch-Strasse 5 e-Mail: mpace@esoc.bitnet >: D-64293 Darmstadt, Germany x400: C=DE;A=DBP;P=ESA;O=ESOC;S=PACE;G=MARCO > >I guess it depends which side is which: assuming you are using sockets, then >the "living" side should get a SIGPIPE. In BSD the default action for SIGPIPE >is "ignore", in SVR4 the default action is termination (talk about a subtle >change :-}). > >In any event, I would think it advisable to install a SIGPIPE handler to >allow your applictions to shutdown in an orderly manner. > I'll throw in my$.02.  Most TCP implementations with which I am
familar will buffer a certain amount of data at a new endpoint before
it is accept()ed by the application.  That is part of the reason one
or more client side write()s may succeed when the server dies shortly
after accept()ing the connection.  The other part may be a bit harder
for you to swallow. There is a time lag between when the server dies
and the connection reset arrives at the client host.  write()s which
occur before this notification will "succeed" while write()s that
occur after will fail and generate a SIGPIPE. NOTE: A SIGPIPE is
generate in response to a write() on a disconnected endpoint, not as
a result of the endpoint becoming disconnected.  However, a SIGIO is
generated (assuming you have set asynch I/O on the socket) will be
generated by a disconnect (as well as when data arrives or there is
room to write data).

Depending on your application, you may want to setup receiving
asynch events (SIGIO) so you can be notified as soon as possible when
the connection is lost (i.e. the server dying).

--
John A. Scott                         Data General
Phone: +1 919 248 5995                62 TW Alexander Drive
Email: scott@rtp.dg.com               Research Triangle Park, NC 27709


-----------[000290][next][prev][last][first]----------------------------------------------------
Date:      Thu, 14 Jul 1994 17:21:17 GMT
From:      rstevens@noao.edu (W. Richard Stevens)
To:        comp.protocols.tcp-ip,comp.unix.solaris
Subject:   Re: TCP anomalous (?) behaviour in application

> >: The behaviour I can't explain is that, if the server dies (is killed)
> >: after accepting the connection from the client, the client can still
> >: perform successfully its write without realizing the death of the
> >: server. In other words, the write primitive returns successfully.
> >: A second write to the server, on the contrary, fails as expected.

>>In any event, I would think it advisable to install a SIGPIPE handler to
>>allow your applictions to shutdown in an orderly manner.

> There is a time lag between when the server dies
> and the connection reset arrives at the client host.  write()s which
> occur before this notification will "succeed" while write()s that
> occur after will fail and generate a SIGPIPE.

All of this discussion confirms my claim that the majority of network
programming problems arise from a lack of understanding of the underlying
protocols, and have nothing to do with the interface (TLI or sockets)
or operating system.  (This is why I wrote "TCP/IP Illustrated" before
starting the 2nd edition of "Unix Network Programming.")

Fact: when a process terminates, be it voluntary (i.e., exit()) or
involuntary (i.e., killed by a signal) all open descriptors are closed.

Fact: when an established TCP connection is closed, TCP sends a FIN
and goes through the normal four packet exchange to gracefully close
the connection.  If you read() from a connection that has received a
0 (i.e., end of file).  TCP's FIN gets returned as an EOF.

Fact: TCP purposely provides a half-close facility.  One end can call
shutdown(fd,1) (using sockets; the same thing can be done with TLI).
This causes TCP to send a FIN, but the end calling shutdown can still
receive data, it just can't write any more.  The other end that receives
the FIN won't receive any more data, but it can still write to the
connection.  KEY point here: when you receive a FIN, TCP still lets
you write to the end point because of the half-close capability.
Remember: TCP connections are full-duplex.

Fact: when your end receives a FIN you cannot tell whether the other
end terminated or did a half-close.  If your application protocol
never uses a half-close, then you can assume the other end terminated.

Fact: if you write to a TCP end point that has received a FIN, TCP
gladly sends the data (because of the half-close).

Fact: when TCP receives data for a connection for which a process no
longer exists, TCP responds with an RST segment.  If you issue a read()
on an end point that has received an RST, read() returns -1 and errno
is set to ECONNRESET.

Fact: under Unix when you write() to a TCP end point that has received
an RST, SIGPIPE is sent to the process.

Put all this together and you discover that the first write() after
receiving a FIN succeeds.  But if the process at the other end really
either a FIN or an RST causes a select() on readability to return true,
which is the normal way to detect these scenarios.  I'd guess you
also get SIGIO on the receipt of either, but haven't verified this.

Bottom line: use select() to determine when you receive a FIN in a
network application.  Almost every one of the now-frequent postings
"how can I tell if the other end died" can be solved by using select()
and *always* testing for readability, since the process at the other
end can die at any time, but it'll always cause a FIN to be sent.
Now if you want to tell if the *host* at the other end has died (not
the process) then that takes us back to the keepalive wars ... :-)

Rich Stevens


-----------[000291][next][prev][last][first]----------------------------------------------------
Date:      14 Jul 1994 17:56:14 GMT
To:        comp.protocols.tcp-ip
Subject:   Re: Multiple IP Addresses on One Physical Wire?

In article <1994Jul13.191349.658@ejv.com>, Micky Liu <micky@ejv.com> wrote:
>
>I know that it is technically feasible to have a network with
>devices that are running different IP addresses on the same
>wire in this fashion.

(figure deleted)
>
>And I only expect A to reach B, and for C to reach D -- and have no
>expectation for A to reach either C nor D (same for B).  Meaning
>connectivity between machines with similar network addresses.
>
>What I want to know is, does this confuse any of the devices on this
>net?  [A-D] are sun workstations, and R is a router.  Given this
>configuration will any of these devices have a problem when they
>see packets with a 'foreign' network address?
>
>I know that Cisco routers can actually be configured to support
>multiple IP addresses out of one physical interface.
>
>Is this 'legal' to do in tcp/ip-land?  Given that it works, is there
>any reason that I shouldn't do this?  And if I shouldn't do this,
>why does Cisco have this feature?
>
>Micky
>

I would have thought the only significant problem in doing this is that
any traffic going from, let's say, A to C would have to pass through the
router. The effect is that you double the amount of traffic on the wire
for any such packets.

As long as each host's routing decision making code knows about next hops
for 'foreign' addresses, the packets should be routed correctly in and
back out of the router.  Cisco routers do in fact have the ability to
assign a primary and several so-called secondary addresses to a given
port.

I can't imagine any host on the system having a problem with the existence
of packets with 'foreign' addresses in them.  They shouldn't even ever see
them since a host only pays attention to things arriving with the right MAC

If you have a router there, though, why wouldn't you just use it in the
'normal way' and allocate a port and segment to each group of devices?

Chris Rohrer


-----------[000292][next][prev][last][first]----------------------------------------------------
Date:      14 Jul 1994 19:03:11 GMT
From:      barmar@think.com (Barry Margolin)
To:        comp.protocols.tcp-ip,comp.unix.solaris
Subject:   Re: TCP anomalous (?) behaviour in application

In article <3009q0$ken@mail.fwi.uva.nl> casper@fwi.uva.nl (Casper H.S. Dik) writes: >tpa@well.sf.ca.us (Thomas Paul Anderson) writes: >>I guess it depends which side is which: assuming you are using sockets, then >>the "living" side should get a SIGPIPE. In BSD the default action for SIGPIPE >>is "ignore", in SVR4 the default action is termination (talk about a subtle >>change :-}). >This is the same for BSD and for SVR4. (SunOS 4.x and SunOS 5.x both >terminate, as does 4.x BSD) I think what causes people to think that some Unix versions ignore the error is that the C Shell doesn't print "Broken pipe" when a process terminates due to SIGPIPE. So they execute "something | head", don't see a termination error, and assume the commands both ran to completion. I assume this message was removed because such terminations are so common and normal, and printing an error would make it seem like something had gone wrong. -- Barry Margolin System Manager, Thinking Machines Corp. barmar@think.com {uunet,harvard}!think!barmar  -----------[000293][next][prev][last][first]---------------------------------------------------- Date: 14 Jul 1994 19:27:12 GMT From: nirav@manduca.neurobio.arizona.edu (Nirav C. Merchant) To: comp.protocols.misc,comp.protocols.tcp-ip,comp.dcom.lans.misc Subject: MAP TOP details  Hi, I was looking for details on MAP/TOP and its existing status ... and if it is alive then possible products that are complaint to MAP/TOP standards. Could someone give me pointers for locating such products/information. Thanks, Nirav --  -----------[000294][next][prev][last][first]---------------------------------------------------- Date: 14 Jul 1994 19:48:03 GMT From: einste44@wharton.upenn.edu (Eric L. Einstein) To: comp.protocols.tcp-ip Subject: Is there a self-aliasing IP address?  I connect to the Internet via a SLIP connection, so I have a different IP address every time I sign on. I would like to know if there is a reserved IP address that always bounces back to the originator of the signal, no matter what the real IP address of that machine is. This is probably a really simple question, but, obviously, I'm IP deficient. Thanks for your help. Eric -- Eric L. Einstein einste44@wharton.upenn.edu The Wharton School of the University of Pennsylvania  -----------[000295][next][prev][last][first]---------------------------------------------------- Date: Thu, 14 Jul 1994 21:16:47 GMT From: edward@ece.concordia.ca (Edward Milczarek) To: comp.protocols.tcp-ip Subject: TCP/IP Source Code  I would like to get the source code for the various TCP/IP functions. I would be grateful if someone can help me out. Thanks in advance.  -----------[000296][next][prev][last][first]---------------------------------------------------- Date: Fri, 15 Jul 94 06:14:29 -0500 From: baldwinl@delphi.com To: comp.protocols.tcp-ip Subject: RFC implementation for all TCP/IP vendors?  Is there a document that describes which RFC's the various TCP/IP vendors implement in their TCP/IP's (preferable by product version #). Boy, am I dreaming. Thanks.  -----------[000297][next][prev][last][first]---------------------------------------------------- Date: Thu, 14 Jul 1994 23:31:25 GMT From: marka@syd.dms.CSIRO.AU (Mark Andrews) To: comp.protocols.tcp-ip Subject: Re: Multiple IP Addresses on One Physical Wire?  In article <1994Jul13.191349.658@ejv.com> micky@ejv.com (Micky Liu) writes: > >I know that it is technically feasible to have a network with >devices that are running different IP addresses on the same >wire in this fashion. > >+-----------+ +-----------+ >| 142.9.1.1 | | 142.9.1.2 | >| A | | B | >+-----------+ +-----------+ > | | >============================================================================= > | | | > | +-----------+ +-----------+ > | | 135.3.1.1 | | 135.3.1.2 | > | | C | | D | > | +-----------+ +-----------+ > | >+-----------+ >| 135.3.1.9 | >| R | >+-----------+ > >And I only expect A to reach B, and for C to reach D -- and have no >expectation for A to reach either C nor D (same for B). Meaning >connectivity between machines with similar network addresses. > >What I want to know is, does this confuse any of the devices on this >net? [A-D] are sun workstations, and R is a router. Given this >configuration will any of these devices have a problem when they >see packets with a 'foreign' network address? > >I know that Cisco routers can actually be configured to support >multiple IP addresses out of one physical interface. > >Is this 'legal' to do in tcp/ip-land? Given that it works, is there >any reason that I shouldn't do this? And if I shouldn't do this, >why does Cisco have this feature? > >Micky > This is a pretty standard sort of configuration. With standard configurations A, B and R will communicate between themselves, and C and D between themselves. There are a number of ways you can change the above configuration and have everything talking. 1. The router R should have an address on every network on the ethernet. This will permit A and B to talk to C and D via R. 2. You can optimise the routing by telling A and B that they can reach the other net by installing additional routes by hand. For BSD 4.2 derived system "route add net 135.2.0.0 142.9.1.1 0" will enable A to send packet to C and D directly. Alternatively you could enable "proxy arp" on the router and set the default route to be the local interface i.e. "route add 0.0.0.0 142.9.1.1 0". Mark  -----------[000298][next][prev][last][first]---------------------------------------------------- Date: 15 Jul 1994 00:10:24 GMT From: leonard@telcom.arizona.edu (Aaron Leonard) To: comp.protocols.tcp-ip Subject: Re: Is there a self-aliasing IP address?  In article <304ep5$rfb$1@sdl.Warren.MENTORG.COM>, tal@Warren.MENTORG.COM (Tom Limoncelli) writes: |In <einste44-1407941544450001@ts6-47.upenn.edu> einste44@wharton.upenn.edu (Eric L. Einstein) writes: | |>I connect to the Internet via a SLIP connection, so I have a different IP |>address every time I sign on. I would like to know if there is a reserved |>IP address that always bounces back to the originator of the signal, no |>matter what the real IP address of that machine is. This is probably a |>really simple question, but, obviously, I'm IP deficient. Thanks for your | |127.0.0.1 always refers to the "localhost". "ifconfig -a" |will tell you that 127.0.0.1 is the address of the "loopback" |interface "lo0". "lo0" is software. Well, sure enough 127.0.0.1 will refer to your SLIP client machine from the context of that machine, but from the context of a remote machine, 127.0.0.1 will be THAT machine. So this won't help you much. The real answer is: all providers of dialup SLIP service should provide THE SAME IP address to each client every connection. If you don't do this, nameservice, SMTP, .rhosts, etc., etc. will not work tolerably. Encourage your provider to get his act together. Aaron Aaron Leonard (AL104), <Leonard@Arizona.EDU> University of Arizona Network Operations, Tucson AZ 85721 \ Don't lock yourself into open systems. /  -----------[000299][next][prev][last][first]---------------------------------------------------- Date: Fri, 15 Jul 1994 01:31:57 GMT From: samg@netcom.com (Sam Ghandchi) To: comp.protocols.tcp-ip Subject: Re: Need to Find TTCP???  Sam Ghandchi (samg@netcom.com) wrote: : Hi : I am looking for TTCP. Could you tell me where : I can find it? : TIA, : - Sam Ghandchi : samg@netcom.com Thank you all for your help in your Emails.  -----------[000300][next][prev][last][first]---------------------------------------------------- Date: Fri, 15 Jul 1994 03:49:27 GMT From: biegler@aristotle.cs.uregina.ca (Mark Biegler) To: comp.protocols.tcp-ip Subject: UDP Broadcast with no loopback?  Is it possible to broadcast UDP packets to an ethernet network without having the sending host receive them itself? I'd like my software to only receive packets sent by other systems... not the info it's sending out. FYI, it's running under IRIX4 and eventually SunOS, Linux, and ULTRIX. Thanks in advance. Please mail me at biegler@cs.uregina.ca - Mark --- Mark Biegler (VE5MPB) biegler@cs.uregina.ca Department of Computer Science W: (306) 585-4110 University of Regina H: (306) 522-1770 Regina, Saskatchewan Canada S4S 0A2 Office: CW 307.12  -----------[000301][next][prev][last][first]---------------------------------------------------- Date: 15 Jul 1994 04:12:33 GMT From: lorraine@snrc.uow.edu.au (Lorraine de Vere) To: comp.protocols.tcp-ip Subject: Dynamic IP addressing  Hi, I'm currently trying to track down different protocols that provide dynamic IP address assignment. Pointers to documents describing the dynamic assignment mechanisms would be particularly appreciated. So far I know about DHCP and PPP. If anyone knows which of the RFCs and Internet Drafts that discuss PPP describe dynamic IP addressing that would also help. Thanks in advance Lorraine :-)  -----------[000302][next][prev][last][first]---------------------------------------------------- Date: Fri, 15 Jul 1994 11:27:12 -0400 From: Sean McLinden <sean+@andrew.cmu.edu> To: comp.dcom.modems,comp.protocols.tcp-ip,comp.sys.novell Subject: Q: Motorola CODEX 3260 and Netware DIALUP.EXE  Has anyone a clue as to how to get a CODEX 3260 (V.FC) modem to properly initialize for Novell dialup slip? I seem to have no problem using the modem from a terminal package but the DIALUP.EXE chokes and dies on it. Thanks. Sean  -----------[000303][next][prev][last][first]---------------------------------------------------- Date: 15 Jul 1994 04:55:22 GMT From: cooperb@unixg.ubc.ca (Peter Cooperberg) To: comp.protocols.tcp-ip Subject: network switching  appletalk, ethertalk, Duo, Duodock I have a Duo 230 and 2 Docks. The one at the hospital is on an ethernet but not the one at home. At home it switches back to appletalk. However at work I have to switch back to ethertalk using the control panel "network". Anybody knbow of an easier way. Preferably automatically. Thanks  -----------[000304][next][prev][last][first]---------------------------------------------------- Date: Fri, 15 Jul 1994 07:44:14 GMT From: synopsis@zeus.datasrv.co.il (Synopsis Sys.) To: comp.protocols.tcp-ip Subject: ISO Transport on TCP (RFC1006)  Subject: ISO Transport on TCP (RFC1006) Newsgroups: comp.protocols.tcp-ip Organization: DataServe LTD. (An Internet Access Provider), Israel. Summary: Keywords: Subject: ISO Transport on TCP (RFC1006)? Newsgroups: comp.protocols.tcp-ip Organization: DataServe LTD. (An Internet Access Provider), Israel. Summary: Keywords: Has anyone had any experience with implementing / using ISO Transport on top of TCP/IP as defined in RFC1006? RFC983 mentions that a UNIX version is available from the authors: D.E. Cass & M.T. Rose. Where can I find the sources / How do I contact the autohrs? Thanks, Gal Nachum ------------------------------------------------------------ Gal Nachum Tel: +972-3-7528698 Synopsis Systems Fax: +972-3-7527248 P.O Box 62010 Tel-Aviv 61620 email: synopsis@zeus.datasrv.co.il I S R A E L Compuserve: CSID 100274,1141 ------------------------------------------------------------  -----------[000305][next][prev][last][first]---------------------------------------------------- Date: 15 Jul 1994 09:51:51 GMT From: Erik Molenaar To: comp.os.ms-windows.networking.tcp-ip,comp.os.ms-windows.programmer.networks,comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc Subject: Re: What is MBONE?  In article <9407150439.AA13226@ariake.nwk.cl.nec.co.jp> mweiss@nwk.cl.nec.co.jp (Michael J. Weiss) writes: >The subject line says it all: What is MBONE? (not just what the acronym >stands for, either--what IS it?) > >Thanks, > >--Mike Mike, If WWW lies in you possibilities try the following URL. http://www.eit.com/techinfo/mbone/mbone.html Good luck! Erik Molenaar erik.molenaar@net.iend.wau.nl Wageningen Agricultural University - the Netherlands  -----------[000306][next][prev][last][first]---------------------------------------------------- Date: 15 Jul 1994 12:51:23 GMT From: jbrady@deepriver.East.Sun.COM (John Brady - SunNetworks Consultant) To: comp.protocols.tcp-ip Subject: Re: ISO Transport on TCP (RFC1006)  In article 2710@news.datasrv.co.il, synopsis@zeus.datasrv.co.il (Synopsis Sys.) writes: > >Has anyone had any experience with implementing / using ISO Transport on >top of TCP/IP as defined in RFC1006? Yup, much experience using... You will find that most commercial OSI stack implementations support RFC1006 (OSI TP over TCP/IP) as well as native OSI network protocols (CLNP, X.25). SunSofts' OSI Stack, SunLink/OSI, can support simultaneous connections over CLNP, X.25 & RFC1006-type networks. >>RFC983 mentions that a UNIX version is available from the authors: D.E. >Cass & M.T. Rose. Where can I find the sources / How do I contact the >autohrs? What you are looking for is ISODE (ISO Development Environment). I believe the latest freely distributed version is 8.0. Commercial development of the code was taken over a few years ago by X-Tel (now known as Nexor) in the UK. The free version of ISODE can be found on many anonymous FTP servers, including the one at University College London (where most of the ISODE development took place). ISODE will compile (with no code changes) on most BSD-based UNIXes, but could be ported to other platforms as well. >Thanks, Gal Nachum > >------------------------------------------------------------ >Gal Nachum Tel: +972-3-7528698 >Synopsis Systems Fax: +972-3-7527248 >P.O Box 62010 >Tel-Aviv 61620 email: synopsis@zeus.datasrv.co.il >I S R A E L Compuserve: CSID 100274,1141 >------------------------------------------------------------ You're welcome, -- John Brady, Consultant SunNetworks, A Sun Microsystems, Inc. Business (703) 204-4859 (voice) (703) 204-4782 (fax) john.brady@East.Sun.Com  -----------[000307][next][prev][last][first]---------------------------------------------------- Date: Fri, 15 Jul 1994 13:08:59 GMT From: hbae@cwis.unomaha.edu (Hansang Bae) To: comp.protocols.tcp-ip Subject: Re: network switching  cooperb@unixg.ubc.ca (Peter Cooperberg) writes: >appletalk, ethertalk, Duo, Duodock >I have a Duo 230 and 2 Docks. The one at the hospital is on an ethernet >but not the one at home. At home it switches back to appletalk. However >at work I have to switch back to ethertalk using the control panel "network". >Anybody knbow of an easier way. Preferably automatically. If you get an email answer, could you plz post it! Hansang Bae -------------------------------------------------------- | hbae@unomaha.edu | Data Communication EAB 013C | | hbae@cwis.unomaha.edu | Voice: (402) 554-3769 FAX: (402) 554-3475 | ---------------------------------------------------------------------  -----------[000308][next][prev][last][first]---------------------------------------------------- Date: 15 Jul 1994 16:09:02 GMT From: harri906@raven.csrv.uidaho.edu ( That Harrington) To: comp.protocols.tcp-ip,comp.protocols.ppp,comp.unix.i386,comp.os.386bsd.questions,alt.os.bsdi Subject: SLIP: Setting it up on BSDI 1.1  Hello all, I am struggling to set SLIP up on BSDI 1.1. I don't have a book on it, and man pages stink, so my net friends are the last resort. :) I want to enable users to dialin, login, and type 'slip'...and it will start. Or something. ANY help on it would be appreciated. Dan Harrington  -----------[000309][next][prev][last][first]---------------------------------------------------- Date: 15 Jul 1994 16:09:09 GMT From: kannan@ISI.EDU (Kannan Varadan) To: comp.protocols.tcp-ip,comp.unix.internals Subject: Increasing the number of mbufs in a SunOS4.1.3, sparcstation 10 kernel  I am trying to increase the number of mbufs available to the UNIX kernel in a SUN sparcstation 10, running SunOS 4.1.3 system. I had initially tried adjusting some of the definitions in various include files in <machine/*.h> and rebuilding the kernel from source. I had tried two strategies, one where I tried moving all hard-wired addresses in the kernel that I could find down by 2MB; and another where I stole 2MB from the buffer cache, adjusting addresses in between. In the former, I adjusted KERNELSIZE, KERNELBASE, SYSBASE, MBPOOLBYTES in <machine/param.h> V_WKBASE_ADDR, VA_PERCPU, VA_PERCPUME and other "compatibility" addresses in <machine/devaddr.h> IOMMU_MBUTL_BASE in <machine/iommu.h> AUXIO_REG in <machine/auxio.h> only to get an "Instruction Access Exception". Running it through kadb yields a stack trace on crash which makes scant sense to me. Stealing 2MB from the buffer cache, SYSBASE, MBPOOLBYTES, BUFBYTES in <machine/param.h> V_WKBASE_ADDR, VA_PERCPU, VA_PERCPUME and other "compatibility" addresses in <machine/devaddr.h> IOMMU_MBUTL_BASE in <machine/iommu.h> AUXIO_REG in <machine/auxio.h> In this instance, I get a "Data Access Exception". I would appreciate talking to someone who has achieved this, or can help me figure out what I am missing. Thanks, Kannan Folllowups directed to comp.unix.internals; there is no comp.sys.sun.internals newsgroup.  -----------[000310][next][prev][last][first]---------------------------------------------------- Date: Fri, 15 Jul 1994 19:09:23 GMT From: evansmp@mb52112.aston.ac.uk (Mark Evans) To: comp.protocols.tcp-ip Subject: Re: slip--must be 2 nets  Zbigniew J. Tyrlik (zbig@junior.wariat.org) wrote: : >How many simultaneous remote users can you support with one Class C : >network address? 254? : Assuming that I will use this C class only for slip, 253: : one IP for Terminal Server; The terminal server does not need to use an address from the class C network, it can use it "other" address. : one IP for remote machine.  -----------[000311][next][prev][last][first]---------------------------------------------------- Date: Fri, 15 Jul 1994 20:30:22 GMT From: sybesma@unirsvl.rsvl.unisys.com (Eric Sybesma) To: comp.protocols.tcp-ip Subject: ARP - when does it delete cache entries  Hi all, We have an application which makes frequent TCP/IP connect requests to other hosts. If one of these hosts changes its Ethernet address, by maybe swapping the Ethernet card or the whole host, the TCP/IP software will try to connect to the old Physical Ethernet address because it is still in the ARP cache. The connections continues to time out. My questions: 1) How often is the ARP cache purged? 2) Is there any way to alert the network to a new physical address at an old IP address? Do other hosts typically listen in on ARP requests and update their cache? Any suggestions to keep the latent time to a minimum? es -- Eric Sybesma, Unisys | sybesma@unirsvl.rsvl.unisys.com | (612) 635-3380 | Site Management Products | "Sorry, can't talk right now, I'm non-blocking." | Roseville, MN 55113 | self.am = 0;if (self.mode == thinking) self.am++;|  -----------[000312][next][prev][last][first]---------------------------------------------------- Date: Fri, 15 Jul 94 20:31:24 GMT From: cgh018@tijc02.uucp (Calvin Hayden x2254) To: comp.protocols.tcp-ip,comp.unix.aix Subject: Re: Does a DHCP daemon exist?  From article <2vjvs4INN1ivq@saturn.caps.maine.edu>, by jonbeal@saturn.caps.maine.edu (Jon Beal): > > I am looking for a daemon for the Dynamic Host Configuration Protocol, as > detailed in RFC1541. Does anyone know if a Unix implementation exists > yet? (If so, where can I find it?) > > > Thanks in advance, > > Jon Beal > Me too! Please email info to me as well. Only one I know of is one supported as server in NT. One for Sun on way, but who from, when, which OS, etc... Calvin Hayden cgh018%tijc02@uunet.uu.net -- Calvin Hayden Uucp: uunet!tijc02!cgh018 Siemens Industrial Automation Inet: cgh018%tijc02@uunet.uu.net -- My opinions and mine alone -- cgh018@tijc02.uucp  -----------[000313][next][prev][last][first]---------------------------------------------------- Date: Fri, 15 Jul 1994 22:01:09 GMT From: donp@novell.com (don provan) To: comp.protocols.tcp-ip,comp.unix.solaris Subject: Re: TCP anomalous (?) behaviour in application  In article <1994Jul14.172117.9666@noao.edu> rstevens@noao.edu (W. Richard Stevens) writes: >All of this discussion confirms my claim that the majority of network >programming problems arise from a lack of understanding of the underlying >protocols, and have nothing to do with the interface (TLI or sockets) >or operating system. It's funny, but all of your comments confirms *my* claim that a popular bogus implementation can completely change the semantics of a protocol to the point where the underlaying specification is no longer important. I mean, really, the fact that a violent abortion of a process could generate a graceful close of its open TCP connections is just extraordinary. It virtually negates the advantage of a graceful close, since the peer is no longer sure the application layer protocol was responsible for the close, or a SIGTERM was. don provan donp@novell.com  -----------[000314][next][prev][last][first]---------------------------------------------------- Date: Fri, 15 Jul 1994 23:49:16 GMT From: drhodes@hercules.win.net (Dylan Rhodes) To: comp.protocols.tcp-ip Subject: Q: FTP...how?  A reeeeeaaaal naive question: If I have: - IBM-type PC - Ethernet card - Netware 3.11 network - Off-the-shelf MS-DOS or Windows TCP/IP package, with FTP client/server capability What more do I need to get my machine talking to the outside world in such a manner that I can offer an FTP site? What are my options? Can anybody recommend a text which covers basic stuff such as this? Is there an appropriate FAQL? Thanks. Dylan Rhodes drhodes@hercules.win.net I'm not speaking for my employer at the present moment.  -----------[000315][next][prev][last][first]---------------------------------------------------- Date: 16 Jul 1994 01:02:48 GMT From: jjs@snjst0.pacbell.com (John Sottile(TNM)) To: comp.protocols.tcp-ip Subject: Passive Mode FTP  I'm looking for any examples of FTP commands which describe the Passive Mode File Transfer. I'm able to put the Server into passive mode via the quote pasv command. The RFC describes the Server to Server use of the PASSIVE command (using the quote port ... command) but I can't seem to get it to work. I start 2 FTP commands to 2 different Servers as it describes in the RFC. ftp A (login) quote PASV (get port number) ftp B (login) quote port (port from above) Then I let FTP server a fly with commands (either via get or QUOTE STOR/RETR) and the connection eventually times out. Has anyone out there done this before? Better yet, is there a way to completely initiate the file transfer from a single FTP client? Thanks in advance for any information. ----------------------------------------- John Sottile jjs@snjst0.pacbell.com  -----------[000316][next][prev][last][first]---------------------------------------------------- Date: Sat, 16 Jul 1994 06:23:59 GMT From: samg@netcom.com (Sam Ghandchi) To: comp.protocols.tcp-ip Subject: Re: Need to Find TTCP???  I was asked to summarize my replies on the net. You can find TTCP from ftp.sgi.com Regards, - SamG  -----------[000317][next][prev][last][first]---------------------------------------------------- Date: 16 Jul 1994 21:29:02 -0400 From: jhawk@panix.com (John Hawkinson) To: comp.protocols.tcp-ip Subject: Re: Variable Subnetting  In <CswMBI.K4A@syd.dms.CSIRO.AU> marka@syd.dms.CSIRO.AU (Mark Andrews) writes: >In article <3010f1$h6q@budapest.ozonline.com.au> mike@ozonline.com.au (Michael Bethune) writes:

>>Hmm, how about subnets with multiple routers. Don't hosts on these
>>networks need to know more about routing than can be supplied by
>>simply a default router entry?
>>

>	No. The first packet to a destination that would not noramally
>	go via the default router should generate a ICMP Redirect.
>	Traffic should then go via the optimal router.

I'm not sure if the IDRP daemon handles this case (I've never used it),
but consider the problem of the "mobile" host (M). If host A on
a subnet with routers AA and BB uses AA as a default router, when
it tries to send a packet to M and is ICMP redirected to BB, all is
fine; but then M moves (say it's a PPP connection that dials up in different
areas) such that the path from A to M is via AA. Then A receives a 2nd
ICMP redirect for M, this time to AA; it seems that many implementations
(SunOS 4, for instance), ignore this second ICMP redirect, resulting in
packets going to BB _then_ AA, each time. I can find no justiciation
for this behavior in RFC792...

--
John Hawkinson
jhawk@panix.com


-----------[000318][next][prev][last][first]----------------------------------------------------
Date:      16 Jul 94 18:47:17 GMT
From:      ddl@harvard.edu (Dan Lanciani)
To:        comp.protocols.tcp-ip,comp.unix.solaris
Subject:   Re: TCP anomalous (?) behaviour in application

In article <1994Jul15.220109.17838@novell.com>, donp@novell.com (don provan) writes:
| In article <1994Jul14.172117.9666@noao.edu> rstevens@noao.edu (W. Richard Stevens) writes:
| >All of this discussion confirms my claim that the majority of network
| >programming problems arise from a lack of understanding of the underlying
| >protocols, and have nothing to do with the interface (TLI or sockets)
| >or operating system.
|
| It's funny, but all of your comments confirms *my* claim that a
| popular bogus implementation can completely change the semantics of a
| protocol to the point where the underlaying specification is no longer
| important. I mean, really, the fact that a violent abortion of a
| process could generate a graceful close of its open TCP connections is
| just extraordinary. It virtually negates the advantage of a graceful
| close, since the peer is no longer sure the application layer protocol
| was responsible for the close, or a SIGTERM was.

Historians may wish to note that 2.9 (and, I think, 4.1c) actually
passed a flag to the tcp stack to tell it whether the socket was
being closed at process termination.  (Of course, it didn't tell
whether the process had died gracefully. :()  I suspect the reason
for removing this flag was simply that it made socket handle semantics
different from those of all other handles.  (All other handles were
closed identically by process exit or close().)

Dan Lanciani
ddl@harvard.*


-----------[000319][next][prev][last][first]----------------------------------------------------
Date:      17 Jul 1994 17:56:00 -0500
From:      mflll@uxa.ecn.bgu.edu (Dr. Laurence Leff)
To:        alt.dcom.telecom.ip,comp.protocols.tcp-ip,comp.dcom.servers
Subject:   Livingston Portmaster woes

We are having trouble setting up our account mechanisms on our Livingston
Portmaster 2E.  It is running Version 3.0.1 of the software

We need to support both SLIP users and login id's.

When we create a login user the system correctly connects us to the
default host.  We also can configure it to prompt for a host if desired.

However, When we create a network user,

the system always gives us error message

We specified our network user name and password, we had a screen as shown
below
.

Type: Network User
Protocol: Slip

Routing: Listen

MTU: 100 (created by system)

Compression: Disabled.

There were no filters.

We clicked on create in the radius screen and the system said

In general, we want regular "normal" users to simply be passed through
to our Sun Workstation which is our default user.

Our SLIP users should be asked for an account and password by the sun.
Then, they
should be free to use FTP, Telnet, etc. on their computer to whatever
we want.

We want our normal users to be validated by our Sun and to type
little or nothing to the Portmaster.  However, we need to recognize
our SLIP users.  "They" can be forced to type more information--as they
will be using in with a SLIP MODEM SCRIPT
The normal users should be  allowed to continue on with a minimum of
keystrokes.

How do you suggest handling this.


-----------[000320][next][prev][last][first]----------------------------------------------------
Date:      Sun, 17 Jul 1994 10:42:05 GMT
From:      ke4dpx@gregl.slip.iglou.com (Greg Law)
To:        comp.protocols.tcp-ip
Subject:   Re: KA9Q

In article <301ikd$ql4@lambada.oit.unc.edu> Ajay.Simha@launchpad.unc.edu (Ajay Simha) writes: >Does anyone know about the copyright info on ka9q? >Any other opinions about this software? KA9Q is basically public domain software with commercial restrictions. You can use it, modify it, and distribute it to your heart's content provided you don't sell it. This may vary slightly with specific releases, but all are based on the original public domain code. I'm currently running the JNOS varient (WG7J/PA3DIS) on amateur packet radio and have also experimented with NOSview (PA0GRI) and TNOS. JNOS is more service oriented (loads of clients and servers) while TNOS is more user oriented (built-in tutorial, help files for everything, etc.) and NOSview is easy to get up and running (comes with everything zipped into the proper directories). You can get the latest version of JNOS at pc.usl.edu and other versions at oak.oakland.edu or ftp.ucsd.edu. ============================================================================ 73 de Greg AMPRNet - ke4dpx@ke4dpx.ampr.org [44.106.56.35] AX.25 - ke4dpxg@wi9p.#ncky.ky.usa.noam Internet - gregl@iglou.com ============================================================================  -----------[000321][next][prev][last][first]---------------------------------------------------- Date: 17 Jul 1994 17:01:19 GMT From: roth@panda.dnr.state.mi.us (Dave Roth) To: comp.protocols.tcp-ip Subject: Re: NDIS driver source code  In article <CsvGr4.AoD@csd.cri.dk>, jmi@csd.cri.dk (John Mills) says: > >In article 120794172221@macheha.biochem.mpg.de, heha@biochem.mpg.de (Herbert Hanewinkel) writes: >>Does somebody know where I can find the source code of >>an NDIS driver. I would like to use it as a template. >> >>Herbert Hanewinkel > > >The windows NT Device Driver kit (DDK) has a sample NDIS driver... you can find >it on MSDN level II CD-ROM set (amongst others)... > >Contact MicroSoft for pricing/availability etc... > > But is there something out in the pub dom that could help? I have ripped apart DIS_PKT9.DOS as much as I think can be done and have looked at the NDIS v2 specs, but that doesnt explain the questions I have, just tells me what each call expects. ANYTHING out there? I have tried to track down something in our local university and via the Library of Congress only to fail (but then again, Library of Congress is does not use the friendliest search engine). dave ============================================================================ Dave Roth roth@panda.dnr.state.mi.us System Administrator State of Michigan "These views are mine, not my Department of Natural Resources employer, blah, blah, blah" Wildlife Division  -----------[000322][next][prev][last][first]---------------------------------------------------- Date: 17 Jul 1994 19:40:07 GMT From: aoj@access1.digex.net (aaronjones) To: comp.protocols.tcp-ip Subject: Simple T1 WAN Networking  Greetings Y'all, I have a client who has a T1 running between two points seperated by approximately 1700 miles. They have a LAN at each one of the two locations. The machines on the LANS are an assortment of Macs, Windows PCs, and UNIX boxes (SCO, Solaris 2.3, Motorola 88/Open(yechh), and an RS-6000 thrown in for good measure. The machines on the LANs at both ends are running a mixture of TCP/IP, The LANs are running a mixture of TCP/IP,IPX/SPX, and Ethertalk. What they would like to do is (strangely enough) connect their LANs together over the T1 circuit. They would like to do so at the cheapest possible cost. BTW, The T1 is currently sitting idle awaiting installation of a Frame Relay network, but they need something _now_. I will not be receiving any renumeration for this, but I would like to help out a friend. Any advise as to how they might accomplish this would be greatly appreciated. Aaron Jones Ph: (416) 213-2040 <Witty thought of the day omitted> InterAccess Consulting Fax:(416) 213-5760 Toronto, Ontario Email: aoj@digex.net  -----------[000323][next][prev][last][first]---------------------------------------------------- Date: Mon, 18 Jul 1994 02:14:38 GMT From: marka@syd.dms.CSIRO.AU (Mark Andrews) To: comp.protocols.tcp-ip Subject: Re: Variable Subnetting  In article <30a1gu$3mm@panix.com> jhawk@panix.com (John Hawkinson) writes:
>In <CswMBI.K4A@syd.dms.CSIRO.AU> marka@syd.dms.CSIRO.AU (Mark Andrews) writes:
>
>>In article <3010f1$h6q@budapest.ozonline.com.au> mike@ozonline.com.au (Michael Bethune) writes: >>>Hmm, how about subnets with multiple routers. Don't hosts on these >>>networks need to know more about routing than can be supplied by >>>simply a default router entry? >>> >> No. The first packet to a destination that would not noramally >> go via the default router should generate a ICMP Redirect. >> Traffic should then go via the optimal router. > >I'm not sure if the IDRP daemon handles this case (I've never used it), >but consider the problem of the "mobile" host (M). If host A on >a subnet with routers AA and BB uses AA as a default router, when >it tries to send a packet to M and is ICMP redirected to BB, all is >fine; but then M moves (say it's a PPP connection that dials up in different >areas) such that the path from A to M is via AA. Then A receives a 2nd >ICMP redirect for M, this time to AA; it seems that many implementations >(SunOS 4, for instance), ignore this second ICMP redirect, resulting in >packets going to BB _then_ AA, each time. I can find no justiciation >for this behavior in RFC792... > >-- >John Hawkinson >jhawk@panix.com I could have swarn that I've seen redirects of redirects take under SunOS 4.1. Anyway this is very much a kernel issue rather than a IDRP daemon issue. The IDRP daemon should flush all routes via a gateway once it has stopped announcing its presence. I can see why a IP stack writer may wish to wish to catch this sought of event but I wouldn't do it unless I could also timestamp the redirect route entries. i.e. only clobber the redirect if the last redirect occured with x seconds, x ~30 secs. Redirects of redirects are normal events where there is more that one router attached to the network and any IP statck which does not cope with them is very broken. Mark.  -----------[000324][next][prev][last][first]---------------------------------------------------- Date: Mon, 18 Jul 1994 02:24:00 GMT From: rpk@niagara.edu (Richard P. Kernin) To: comp.protocols.tcp-ip Subject: Security/Firewall FAQ?  Hello, I'm currently in the process of researching the use of a firewall machine to allow our administrative network Internet access, but allow them to stay "secure" from people hacking in (ie. students, etc.). I read awhile back in some document that there was a Firewall FAQ, but I can't find the document anymore, and have been unable to turn it up in my travels on the net. Could someone drop me a line with information on this beastie? Thanks much! Take care, -Rich --------------------------------------------------------------------------- Richard P. Kernin Niagara University - Administrative Computer Center Internet: rpk@niagara.edu or visnurpk@ubvms.cc.buffalo.edu  -----------[000325][next][prev][last][first]---------------------------------------------------- Date: Mon, 18 Jul 94 09:39:05 PDT From: adar0@routers.com To: comp.protocols.tcp-ip Subject: Re: How do I set up routing on SunOS for rempte SLIP users?  > I'm having trouble setting up cslip-2.7 on SunOS 4.1.3. I can get > the line to answer and go into SLIP mode, and my remote station > (running Trumpet Winsock) can use TCP/IP to the host directly, but > they can't see any hosts outside the local domain. FTP, Mosaic, > etc., just time out when they try to connect to a distant host. > > I think its something to do with routing, but I'm not sure. How > should routing be set up on the host to which SLIP users dial in? > In /etc/rc.local, add the -s option to the startup of in.routed and see if that helps. I'm assuming your routered network uses RIP for a routing protocol. Rich adar0@routers.com  -----------[000326][next][prev][last][first]---------------------------------------------------- Date: 18 Jul 1994 11:04:05 -0500 From: pieper@cs.uwp.edu (Nathan Pieper) To: comp.protocols.tcp-ip Subject: BOOTP Help  Does anybody out there know of a dynamic BOOTP server for unix??? Thanks Nathan Pieper pieper@cs.uwp.edu University of Wisconsin Parkside  -----------[000327][next][prev][last][first]---------------------------------------------------- Date: 18 Jul 1994 12:53:00 -0500 From: ross@ndlc.occ.uky.edu (Ross Hayden) To: comp.protocols.tcp-ip Subject: "easy" bootp question  Hi all! I have been struggling to get bootp working on several unix system here on campus, with little luck. I have several DOS pc's running NCSA telnet, along with the packet drivers needed to run it on top of my netware drivers (ie odipkt.com). On my unix systems I've installed various versions of CMU's bootp package. The problem seems to be that replies from the server are never reaching the workstations. The bootp server starts on queue, and tcpdump also indicates this and shows the reply being sent. The pc, however, just sits and continually resends requests as if never having received a reply. If I hard code an IP address into the config file for NCSA telnet, everything works ok. Also, I can't get rarp to work either. So I'm not really sure if I need to examine my network setup, or if there's a problem with NCSA telnet. I've examined my network setup, checking out subnet masks and broadcast addresses. Any ideas on what to check here? I'm stumped. Thanks for any help, Ross -- Ross Hayden, Systems Programmer ross@ndlc.occ.uky.edu The National Distance Learning Center  -----------[000328][next][prev][last][first]---------------------------------------------------- Date: 18 Jul 1994 13:13:18 -0400 From: zbig@junior.wariat.org (Zbigniew J. Tyrlik) To: alt.dcom.telecom.ip,comp.protocols.tcp-ip,comp.dcom.servers Cc: bri@livingston.com Subject: Re: Livingston Portmaster woes  In <30ccu0$ls4@uxa.ecn.bgu.edu> mflll@uxa.ecn.bgu.edu (Dr. Laurence Leff) writes:

>We are having trouble setting up our account mechanisms on our Livingston
>Portmaster 2E.  It is running Version 3.0.1 of the software

>We need to support both SLIP users and login id's.

>When we create a login user the system correctly connects us to the
>default host.  We also can configure it to prompt for a host if desired.

>In general, we want regular "normal" users to simply be passed through
>to our Sun Workstation which is our default user.

>Our SLIP users should be asked for an account and password by the sun.
>Then, they
>should be free to use FTP, Telnet, etc. on their computer to whatever
>we want.

>We want our normal users to be validated by our Sun and to type
>little or nothing to the Portmaster.  However, we need to recognize
>our SLIP users.  "They" can be forced to type more information--as they
>will be using in with a SLIP MODEM SCRIPT
>The normal users should be  allowed to continue on with a minimum of
>keystrokes.

>How do you suggest handling this.

I do handle it on PM2e, with 70+ UUCP accounts, 20+ TCP/IP connections, and
200+ usrs.

1) set up for everyone an account on Sun.

2) Set properly RADIUS. Default for user + UUCp is to be connected wia
TCP/IP wrapper is handy....

3) for SL/IP and PPP prepare an entry for each machine in RADIUS database.

Here is sample:
###
User-Service-Type = Framed-User,
Framed-Protocol = SLIP,
Framed-MTU = 1006,
Framed-Compression = Van-Jacobsen-TCP-IP

User-Service-Type = Framed-User,
Framed-Protocol = PPP,
Framed-Compression = Van-Jacobsen-TCP-IP

###
#
#       UUCP users
#
###
###
###
#
#
#
bbs

is a must ); interactive users are loggin once; SL/IP and PPP users are
handled by PM, but files are living under control of UNIX.

if you need more details, or want me to set it for you - e-mail me
for details ( zbig@wariat.org ).

_zjt  (zbig@wariat.org)
--
********************************************************************
Zbigniew J. Tyrlik       DoD# 0759   VF700C '84      zbig@wariat.org
APK	       Public Access UNI* Cleveland,          (216)-481-9436
Feeds, shell, FTP, telnet, IRC, MUD      Uniboard distribution point
********************************************************************


-----------[000329][next][prev][last][first]----------------------------------------------------
Date:      18 Jul 1994 18:30:54 -0400
From:      goutham@access1.digex.net (S.Goutham)
To:        comp.protocols.tcp-ip
Subject:   Techniques for finding dead nodes in a WAN.

Can anyone point me in the right direction for constantly checking, say
every 5 minutes, what nodes are down/up in a network. I dont want to ping
constantly all the nodes in the net. I want to know if there are specific
techniques to do this. For example we can have each node look at a set
of nodes and then make them report on their status. The ideal solution
would be to know immediately when a node goes down, rather than taking
about 5 to 10 minutes to find that out. Also, I would not want to send
constant node-alive info. from each node as this could consume net bandwidth
if, say evry minute, a set of 100 to 200 or even 1000 nodes start doing this.

Any hints/suggestions/pointers would be greatly appreciated...Goutham.


-----------[000330][next][prev][last][first]----------------------------------------------------
Date:      18 Jul 1994 21:33:49 -0500
From:      mweiss@nwk.cl.nec.co.jp (Michael J. Weiss)
To:        comp.os.ms-windows.networking.tcp-ip,comp.os.ms-windows.programmer.networks,comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject:   Here's the Story With WATTCP

I have been getting a lot of mail inquiring about WATTCP, and I have
seen quite a few posts with the same questions.  Since I am growing
weary of saying the same thing a hundred times, I will post it:

which is precisely why I posted it.  So, please DO NOT EMAIL ME WITH
QUESTIONS, but POST THEM INSTEAD.  If I know the answer, I will email
you.  Besides, there are many people much more knowledgeable than I who

DISCLAIMER: I have absolutely no relationship with WATTCP and its
author(s) other than being a satisfied user.  The contents of this
messag are strictly things that are true to the best of my knowledge and
bear no association with any statements, opinions, etc. made by the
authors.

1) Where can I get WATTCP?

WATTCP and related software can be obtained by anonymous ftp to
dorm.rutgers.edu, in the directory /pub/msdos/wattcp.

The following is a PARTIAL list of files and descriptions:

2) What is WATTCP?

WATTCP stands for Waterloo TCP.  It is a public domain TCP/IP package
for DOS written by Erick Engelke of the University of Waterloo.  The
core of this package is the WATTCP kernel, a cleanly written, compact
TCP/IP library written in Borland C (or Turbo C, same thing).  The
package also comes with some sample applications which use the library
functions, such as FTP, finger, etc.  The source code for the
applications as well as the library is available and in the public domain.

Beginners Explanation:  The WATTCP kernel is a C library which contains
the code for "socket" or networking functions.  It can be used to
compile the existing applications (they are also available precompiled
in APPS.ZIP, see question #1) or to allow you to write your own programs
that run on a network, providing you with an easy to use interface to
functons which will handle all of the larborious details of network
communication.

3) What can I do with WATTCP? or Why would I want to use WATTCP?

There are three main uses I can think of:

i) You can run TCP/IP applications such as telnet, ftp, and finger

In this case, you only need the file APPS.ZIP which contains the
application executables.  You will probably want to compare the WATTCP
applications with others from comparable packages before you decide on a
favorite.  My initial impression is that WATTCP is most useful as a
library for programmers wishing to build on it, rather than an
application package for end users, but I am not an expert, and this is
purely a matter of taste.

ii) You can write a "network-able" application.

Writing an appication that supports network communication is as easy as
learning the interface to the WATTCP functions (see question #4),
library.  If you have never written "socket code" before, you should
take a look at the series of books entitled _Internetworking With
TCP/IP_ by Douglas Comer.

iii) You can modify the WATTCP library to do something else.

This is a relatively rare case, but if you wanted to implement a variant
on TCP/IP, or otherwise change how a TCP/IP library functions, the fact
that the source code is available makes this possible.

3) What do I need to use WATTCP?

If you're going to program, you will obviously need a C compiler.  If
you plan to compile any of the WATTCP code, you will need to use Borland
C or Turbo C (also by Borland).  There is a port available for Microsoft
C, but there doesn't seem to be any support for it, so I wouldn't
reccommend using it.

You will also need a packet driver.  This is a piece of software that
controls the network card.  WATTCP takes data from the application
(telnet, finger, etc.) formats it according to the rules of the TCP/IP
protocols, and then passes it to the packet driver.  The packet driver
then passes the packet to the network hardware (ethernet board, serial
line, etc.)

If you don't have a packet driver for your card, you can obtain one from
the Crynwr Software Packet Driver Collection.  These are available by
anonymous FTP.  For details, see the document HOWTOGET.IT, appended to
the end of this message.

3) What documentation and support is available?

i) There is minimal documentation available with the source code
(in the file WATTCP.ZIP)  Enough to get the applications up
and running and provide background information.

ii) A programmer's guide, which is a relatively casually
written, but well organized document (about 50 pages long) is available
by contacting:

WATTCP Manual
c/o Supro Network Software Inc.
P.O. Box 18,
Warsaw, Ont.

K0L 3A0

PHONE: (705) 652-1572

The price varies depending on where you live, but it is in the
neighborhood of $40-$50 US Dollars.

iii) One of the best resources around is right here, USENET.  Posts to
comp.protocols.tcp-ip.ibmpc are very likely to yield good results.

4) Are there any similar packages I might want to look at?

There is one called CUTCP, which judging by what I have heard, sounds
comparable.  Also, NCSA has comparable software available.  Post to

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

This is starting to look like a FAQ.  If someone wants to start a FAQ,
you are free to use what I have written here.  I will be finishing
(hopefully) this project by the end of August and returning to school,
so I will not be able to make the commitment necessary to do it myself.

Enjoy!

--Mike

of a spur of the moment effort than an edited masterpiece.

which is precisely why I posted it.  So, please DO NOT EMAIL ME WITH
QUESTIONS, but POST THEM INSTEAD.  If I know the answer, I will email
you.  Besides, there are many people much more knowledgeable than I who

KEEP ON READING FOR INFORMATION ON HOW TO GET A PACKET DRIVER:

-- 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 $35 check-cashing fee. 1. Binaries and documentation:$35  /  $40 2. Source code:$60  /  $68 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: US$29.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

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


-----------[000331][next][prev][last][first]----------------------------------------------------
Date:      Mon, 18 Jul 1994 15:26:40 GMT
From:      jra@lawdept.daytonOH.ncr.com (John Ackermann)
To:        comp.protocols.tcp-ip
Subject:   Re: KA9Q

In article <ke4dpx.22.0005B3C0@gregl.slip.iglou.com> ke4dpx@gregl.slip.iglou.com (Greg Law) writes:

>KA9Q is basically public domain software with commercial restrictions. You can
>use it, modify it, and distribute it to your heart's content provided you
>don't sell it. This may vary slightly with specific releases, but all are
>based on the original public domain code.

The answer is a bit more complicated than this, though Greg's pretty close.
The base KA9Q code was written by Phil Karn.  His copyright notice permits
unlimited, free use of the code for amateur radio or education purposes.  Any
other use -- whether the code is freely distributed or not -- requires
negotiation of a license with Phil.

To complicate things further, there are literally dozens of folks who've done
work on Phil's base code, and they have their own, sometimes inconsistent

But in any event, if you're planning to make any non-ham radio,
non-educational use of KA9Q, you need to contact Phil for permission, as well
as possibly contacting others.

John   AG9V
jra@lawdept.daytonOH.ncr.com


-----------[000332][next][prev][last][first]----------------------------------------------------
Date:      Mon, 18 Jul 1994 17:38:15 GMT
From:      ANDY@[144.206.142.199] (Andy A. Savchenkov)
To:        comp.protocols.tcp-ip
Subject:   Wanted: VT1000 emulator for TCP/IP

Hi, wise people!

I have one little question concerning VAX/VMS/DECWindows.
I need to work under DECWindows using my PC as a terminal, but
I don't know how to emulate a VT1000 or greater terminal.

I have two VAX-es and PathWorks on one of them. DECWindows under
Pathworks works perfect, but it is installed only on one VAX.

So the question is : Does the VT1000 terminal emulator (working under
TCP/IP on DOS or/and Windows for Workgroups 3.11) exists?

Of course, I need a "public domain" software 'cause I haven't enough
money to buy it. If you can say me the ftp-server where something like
this emulator exists I would say you "Great Thanks!"

Bye.
+========================================================+
|   Andy A. Savchenkov             Moscow, Russia        |
|========================================================|
| Nuclear Fusion Institute  |   ANDY@[144.206.142.199]   |
| Russian Research Centre   |  k238@ivk-vax.ivk.kiae.su  |
|  "Kurchatov Institute"    |   YOU ARE ALWAYS WELCOME   |
|========================================================|
|     ...Take it easy, baby, take it as it comes...      |
+========================================================+


-----------[000333][next][prev][last][first]----------------------------------------------------
Date:      18 Jul 1994 20:34:04 GMT
From:      mekatako@vela.acs.oakland.edu ( )
To:        comp.protocols.tcp-ip
Subject:   HELP: SunOs TCP/IP setup? how?

I'm running SunOs 4.0.2 on a Sun 386i.  I need to know how I can
get the TCP/IP related stuff setup... I can get to the telnet prompt,
but it does not work right since I dint have the system configed for my

Andrew


-----------[000334][next][prev][last][first]----------------------------------------------------
Date:      18 Jul 1994 20:42:52 GMT
From:      barmar@think.com (Barry Margolin)
To:        comp.protocols.tcp-ip
Subject:   Re: ARP update mechanism on unix hosts

In article <albert.774173072@netboss> albert@dn.itg.telecom.com.au (Albert Fu) writes:
>an IP packet?

Not every time it receives an IP packet, but every time it receives an ARP
packet.  But since an IP packet can't sent until an ARP packet is sent,
this should be equivalent (unless the router has a preconfigured ARP
cache).  Here's what RFC 826 (the ARP specification) says:

Notice that the <protocol type, sender protocol address, sender
hardware address> triplet is merged into the table before the
opcode is looked at.  This is on the assumption that communcation
is bidirectional; if A has some reason to talk to B, then B will
probably have some reason to talk to A.  Notice also that if an
entry already exists for the <protocol type, sender protocol
one.  Related Issues gives some motivation for this.

>	       Also, is there a mechanism for the Unix host to
>refresh its ARP cache periodically, eg every 10 minutes?

This probably depends on the Unix version.  I don't think there's a
built-in timeout in BSD Unix.  You could have a cron job that executes a
script that deletes all the entries in the ARP cache.
--
Barry Margolin
System Manager, Thinking Machines Corp.

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


-----------[000335][next][prev][last][first]----------------------------------------------------
Date:      18 Jul 1994 21:09:44 +0100
From:      dehartog@kwetal.comcons.nl (Hans de Hartog)
To:        comp.protocols.tcp-ip
Subject:   Routing localnet <--> SLIP-provider?

My setup is as follows:
a local lan (ethernet, network-address 222.222.222.0),
one fat linux-box and a few dos-pc's (using soss, lpt, telnet,
bootp and ftp). This worked for months and I want to keep it that way.
Now the linux-box can SLIP to Internet with (static) ip-address
193.78.38.226. The SLIP-provider is 193.78.33.42 (which is supposed
to be gateway and nameserver for me). This also works fine (telnet,
ftp, X-mosaic), but only for the linux-box that made the SLIP-
connection (with dip).
However (and that's the problem), when the SLIP-connection exists,
I want the dos-pc's also be able to acces the Internet (at least
telnet). I do not have routed running yet (is it necessary and if
yes, what to put in /etc/gatewaysi?), but when I try to telnet from
a dos-pc to the outside world, I can see that something is being
sent out via the modem... The answer however is always "hostname
lookup failure", "network unreachable" or simply nothing (hang).

# /etc/hosts:
127.0.0.1	localhost
193.78.38.226	kwetal.hacktic.nl
222.222.222.225	kwetal.comcons.nl	kwetal	linux
222.222.222.226	bommel.comcons.nl	bommel
193.78.33.42	xs4all.hacktic.nl	xs4all
193.78.33.33	news.hacktic.nl		news

# /etc/networks				# /etc/resolv.conf
default		0.0.0.0			domain	comcons.nl
loopback	127.0.0.0		nameserver	193.78.33.42
homelan		222.222.222.0		nameserver	193.78.240.1
hacktic		193.78.33.0

When the SLIP-connection is up, route gives:
Kernel routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
xs4all.hacktic. *               255.255.255.255 UH    0      0        0 sl0
222.222.222.0   *               255.255.255.0   U     0      0    62231 eth0
127.0.0.0       *               255.0.0.0       U     0      0    48227 lo
default         xs4all.hacktic. *               UG    0      0        0 sl0

Thank you for reading, thank you double for helping me.
--
_____________________________________________________________________________
Hans de Hartog, dehartog@comcons.nl, Voice: +31 348033100, Fax: +31 348033181
Committed Consultancy BV, Korenmolenlaan 1b, 3447 GG Woerden, The Netherlands
Home: dehartog@kwetal.comcons.nl, Voice/Data: +31 838038560, CIS: 100121,3301


-----------[000336][next][prev][last][first]----------------------------------------------------
Date:      Tue, 19 Jul 1994 00:20:03 GMT
From:      atkinson@sundance.itd.nrl.navy.mil (Ran Atkinson)
To:        comp.protocols.misc,comp.protocols.tcp-ip,gsfc.network
Subject:   Re: is gosip OFFICIALLY dead?

In article <mmcmullen-1307942324000001@taygeta.gsfc.nasa.gov> mmcmullen@gsfcmail.nasa.gov (steve johnson) writes:
>got an ongoing and rather important debate going with a coworker.  how
>true is the following:
>
>1) gosip is officially no longer mandated by the federal government for
>use by civil servants and contractors (specifically NASA).

I dunno.  I do know that GOSIP did not ever really mandate "use" of
OSI.  It tried (with only mixed success) to mandate "purchase" of OSI.
The DoD does NOT require purchase of OSI in practice and has not
required that for a long time.

>2) you can still use it if you want, but there will be little or no
>support for it in the future, so you might as well switch to tcp or
>whatever.

Smart people will move towards whatever networking technology solves
their problems at the lowest cost.  This will most usually be a
mainstream commercially viable protocol stack (e.g. SPX/IPX, TCP/IP).

Ran
atkinson@itd.nrl.navy.mil
(speaking strictly as a private citizen)


-----------[000337][next][prev][last][first]----------------------------------------------------
Date:      19 Jul 1994 00:11:52 +0100
From:      dehartog@kwetal.comcons.nl (Hans de Hartog)
To:        comp.protocols.tcp-ip
Subject:   Re: "easy" bootp question

Ross Hayden (ross@ndlc.occ.uky.edu) wrote:
| Hi all!

| I have been struggling to get bootp working on several unix system here on
| campus, with little luck.

| I have several DOS pc's running NCSA telnet, along with the packet drivers
| needed to run it on top of my netware drivers (ie odipkt.com).  On my unix
| systems I've installed various versions of CMU's bootp package.  The
| problem seems to be that replies from the server are never reaching the
| workstations.  The bootp server starts on queue, and tcpdump also
| indicates this and shows the reply being sent.  The pc, however, just sits
| and continually resends requests as if never having received a reply.

| If I hard code an IP address into the config file for NCSA telnet,
| everything works ok.  Also, I can't get rarp to work either.  So I'm not
| really sure if I need to examine my network setup, or if there's a problem
| with NCSA telnet.  I've examined my network setup, checking out subnet

| Any ideas on what to check here?  I'm stumped.

| Thanks for any help,
| Ross
| --
| Ross Hayden, Systems Programmer                   ross@ndlc.occ.uky.edu
| The National Distance Learning Center

I just helped somebody else with the same problem. It seems that
NCSA-stuff V2.3.07 doesn't groc the bootpd answer. I'm running
V2.3.03 (aka V2.3b) and I have no problems.
--
_____________________________________________________________________________
Hans de Hartog, dehartog@comcons.nl, Voice: +31 348033100, Fax: +31 348033181
Committed Consultancy BV, Korenmolenlaan 1b, 3447 GG Woerden, The Netherlands
Home: dehartog@kwetal.comcons.nl, Voice/Data: +31 838038560, CIS: 100121,3301


-----------[000338][next][prev][last][first]----------------------------------------------------
Date:      19 Jul 1994 02:07:10 GMT
From:      mathias@solomon.technet.sg (Mathias Koerber)
To:        comp.protocols.tcp-ip,comp.os.linux.help,comp.dcom.lans.ethernet
Subject:   tcpdump analysis prg?

I just installed tcpdump-3.0 from the binaries at sunsite on my linux box.

Now I wonder whether someone has already written some tools to do
analysis and statistics from the tcpdump output.
Something that can run parallel in realtime would be nice,
but I'd also be  happy with something that reads from a filedump.

cheers

--
Mathias Koerber                                       Tel: +65 / 778 00 66 x 29
SW International Systems Pte Ltd                           Fax: +65 / 777 94 01
14 Science Park Drive #04-01                 e-mail: Mathias.Koerber@swi.com.sg
S'pore 0511   <A HREF=http://www.swi.com.sg/public/personal/mathias.html>MK</A>
with the Force of a Thousand Caramels	- ??


-----------[000339][next][prev][last][first]----------------------------------------------------
Date:      Tue, 19 Jul 1994 08:43:53
To:        comp.protocols.tcp-ip
Subject:   Re: Wanted: VT1000 emulator for TCP/IP

In article <25@[144.206.142.199]> ANDY@[144.206.142.199] (Andy A. Savchenkov) writes:
>I need to work under DECWindows using my PC as a terminal, but
>I don't know how to emulate a VT1000 or greater terminal.

Well the current MS-DOS Kermit (on oak.oakland.edu but I forget where) can
be used to emulate a VT-100 et subs or I use the NCSA Telnet. Both of
these can be used with a TCP/IP packet driver though the Kermit setup
is a bit strange.

You may also need the GOLD.COM TSR to be able to use the NumLock key as PF-1
(think it is included with Kermit). Both seem to be Freeware.

Cybernetic Psychophysicist
We also walk dogs
PGP 2.4 Public Key Available


-----------[000340][next][prev][last][first]----------------------------------------------------
Date:      Tue, 19 Jul 1994 12:17:40 -0500
From:      king@acpub.duke.edu (King Rhoton)
To:        comp.protocols.tcp-ip,comp.protocols.ppp
Subject:   routing on SunOS (with dp2.3) for remote PPP users?

> I'm having trouble setting up cslip-2.7 on SunOS 4.1.3.  I can get
> the line to answer and go into SLIP mode, and my remote station
> (running Trumpet Winsock) can use TCP/IP to the host directly, but
> they can't see any hosts outside the local domain.  FTP, Mosaic,
> etc., just time out when they try to connect to a distant host.
>
> I think its something to do with routing, but I'm not sure.  How
> should routing be set up on the host to which SLIP users dial in?
>
> Routing tables
> Destination          Gateway              Flags    Refcnt Use        Interface
> localhost            localhost            UH       4      17440      lo0
> 199.123.192.10       parts                UH       1      33         sl0
> default              199.123.192.1        UG       3      6342       le0
> 199.123.192.0        parts                U        2      308        le0
>
> So, .10 can talk to parts and TCP/IP services on parts, and parts
> can talk to things like ftp.uu.net and www.ncsa.uiuc.edu, etc.,
> but .10 can't talk to ftp.uu.net, etc.

I'm having the exact same problem, only with PPP connections instead of
slip.  I'm entirely baffled.  I've set up an arp entry for my remote
machine, and from the remote machine ping requests to non-dialup-hosts do
go through the PPP link (I see the tx led flicker), but I never get
anything back.  I have full access to the dialup host, though.  I've tried
both Linux (with PPP 2.1.2a) and a Mac (with MacPPP 2.0.1) as clients, and
they behave the same.  It's got to be something in the Sun's
configuration, but I'm out of ideas.  SunOS 4.1.3 and dp2.3pl2.

Anybody?
Thanks,

King Rhoton                                       king@acpub.duke.edu


-----------[000341][next][prev][last][first]----------------------------------------------------
Date:      Tue, 19 Jul 1994 05:37:15 GMT
From:      davidk@csn.org (David Kirkpatrick)
To:        comp.protocols.tcp-ip
Subject:   TCP error message on SCO UNIX

Hi,

I'm porting some DOS/Windows software to use Winsock to communicate with
a daemon running on a SCO UNIX system.  The software is to the point where
it is running, and most communications seem to be OK.  Sometimes though,
when either reading or writing on a socket from the DOS side, I get a
console message on the SCO box that says:

NOTICE: tcp: sum xxxxx yyyyy

xxxxx & yyyyy are hex numbers.  I can't find any specific error information
in the SCO documentation, but I guess this is coming from the tcp driver,
in the "sum" routine (that's all I can find out.)  Does anyone know what
these hex numbers mean?  BTW, the software that causes the message seems
to work correctly, and all the operations have apparently completed.
Another oddity, is that if I use a debugger on the DOS side to see exactly
which call causes the error, the message never occurs!  This leads me to
think that is has something to do with timing or something.  Thus, I'm not
sure which socket call on the DOS client side causes the message.  It occurs
consistently if the section of code runs without a breakpoint....

Also, I don't have source code to the server side daemon, so I don't know
what it's doing when the message occurs.  All I know is that the client
side is in a loop doing sowrite() and soread().

Thanks,

--
------------------------
-- David Kirkpatrick  --
-- Southwest Software --
-- davidk@csn.org     --


-----------[000342][next][prev][last][first]----------------------------------------------------
Date:      Tue, 19 Jul 1994 07:02:08 GMT
From:      bos@surfnet.nl (Erik-Jan Bos)
To:        comp.protocols.tcp-ip
Subject:   Re: Routing localnet <--> SLIP-provider?

Hans de Hartog (dehartog@kwetal.comcons.nl) wrote:
: My setup is as follows:
: a local lan (ethernet, network-address 222.222.222.0),
: one fat linux-box and a few dos-pc's (using soss, lpt, telnet,
: bootp and ftp). This worked for months and I want to keep it that way.
: Now the linux-box can SLIP to Internet with (static) ip-address
: 193.78.38.226. The SLIP-provider is 193.78.33.42 (which is supposed
: to be gateway and nameserver for me). This also works fine (telnet,
: ftp, X-mosaic), but only for the linux-box that made the SLIP-
: connection (with dip).
: However (and that's the problem), when the SLIP-connection exists,
: I want the dos-pc's also be able to acces the Internet (at least
: telnet). I do not have routed running yet (is it necessary and if
: yes, what to put in /etc/gatewaysi?), but when I try to telnet from
: a dos-pc to the outside world, I can see that something is being
: sent out via the modem... The answer however is always "hostname
: lookup failure", "network unreachable" or simply nothing (hang).

Packets from the DOS PCs to the Internet make it okay, but since you are
using a fake IP network number (222.222.222.0) which is not routed on the
Internet packets do not know how to go back.

What you need to do is:
your Linox box (which is acting as a router, you do not need routed,
the Linux kernel is perfectly capable of routing packets).

--
Erik-Jan.


-----------[000343][next][prev][last][first]----------------------------------------------------
Date:      Tue, 19 Jul 1994 07:38:39 GMT
From:      banker1@shakti.ncst.ernet.in (Citicorp Overseas Software Limited. Team FINWARE.)
To:        comp.protocols.tcp-ip
Subject:   TCP/IP implementation benchmarking ?


Hi,
I'm interested in knowing if there are any benchmark figures for
Unix IPC mechanisms ( pipes, FIFOs, message queues, unix domain sockets)
available on the Internet. I would also like to know if the C source code
for any benchmarking programs is available. I'm also interested in statistics
and C code for benchmarking TCP/UDP implementations.

Thanks,
Shailesh
--

(FINWARE Group, Citicorp Software)
Internet : banker1@shakti.ncst.ernet.in


-----------[000344][next][prev][last][first]----------------------------------------------------
Date:      Tue, 19 Jul 1994 08:03:20 GMT
From:      prasert@vast.unsw.edu.au (Prasert Kanthamanon)
To:        comp.protocols.tcp-ip
Subject:   A packet filter software needed?

Hi netters,

Where can I find any packet filter software running on both SUN 4.1.X and
solaris 2.2?  I would like to setup a Sun SPARC working like a gateway that
can filter IP packets based on IP address/network/subnet combinations and
socket numbers.

prasert.

prasert@vast.unsw.edu.au


-----------[000345][next][prev][last][first]----------------------------------------------------
Date:      Tue, 19 Jul 1994 08:48:34 +0000
From:      neil@palnu.demon.co.uk (Neil Motteram)
To:        comp.protocols.tcp-ip,demon.local,comp.protocols.tcp-ip.ibmpc
Subject:   TCP-IP over Ethernet to Omron PLC

Help?

We have a programmable logic controller, that we can connect to an Ethernet
network. The network must be hardware wise IEEE802.3. Software wise we
are using the Ethernet-2 Standard. The PLC Ethernet unit uses TCP/IP. I would
like to coneect a PC to this unit. Therefore I need a TCP/IP driver. I in the
first stage only would like to test the connection of the network, without
writing programs. A PING would be enough. I am interested in commercial
solutions or anything that is available in the net. As a second stage I am
looking for programming libraries/dll(preferably MSC 6/7 or Visual Basic).

I am posting this for a non-networked collegue. I shall scan the newsgroups
but if anyone would like to reach him directly then please e-mail
edwin.holtkamp@ibmmail.ibmx400.nl

--
Neil Motteram - Omron Electronics Europe BV - Hoofddorp, Netherlands
Internet: neil@palnu.demon.co.uk             Compu$lime: 100115,1020 IBM Mail: NLOMRNM0 IBMMAIL Voice: +31 2503 81332 ** If you use Synon/2, and you're on the net, e-mail me! **  -----------[000346][next][prev][last][first]---------------------------------------------------- Date: 19 Jul 1994 17:44:09 -0500 From: nilesh@jaws.wustl.edu (Nilesh Gohel) To: comp.protocols.tcp-ip Subject: Wanted: TCP Finite State Machine implementation for net snooper  We are designing a network snooping tool for client-server communications that use a standard protocol which sits on top of TCP/IP in the protocol stack. The lower layers of software are already in place that generate the raw TCP packet stream between the two nodes involved in a communication. The next layer to be developed would take the raw TCP packet stream and output the "clean" data stream. Many of the functionalities of the TCP layer (input side) are required such as checking checksums, resequencing packets, monitoring handshaking, removal of duplicate packets, striping the headers, etc. Is there any public domain software which performs the task described above of "cleaning up" a TCP packet stream ? Public domain UNIX implementations may be useful, however source code that is less elaborate and more geared to a "snooper" type application would be most desirable. Thanks. Nilesh R. Gohel Research Assistant Electronic Radiology Laboratory Tel. (314) 362-6965 Mallinckrodt Institute of Radiology Fax. (314) 362-6971 510 S. Kingshighway Blvd. St. Louis, MO 63110, U.S.A. E-mail: nilesh@wuerl.wustl.edu  -----------[000347][next][prev][last][first]---------------------------------------------------- Date: 19 Jul 94 14:48:32 From: dave@denali.ccs.neu.edu (David Philip Kormann) To: comp.protocols.tcp-ip Subject: Re: Wanted: VT1000 emulator for TCP/IP  In article <padgett.127.0008BB7B@141.240.2.145> padgett@141.240.2.145 (Padgett 0sirius) writes: > In article <25@[144.206.142.199]> ANDY@[144.206.142.199] (Andy A. Savchenkov) writes: > >I need to work under DECWindows using my PC as a terminal, but > >I don't know how to emulate a VT1000 or greater terminal. [...] > Well the current MS-DOS Kermit (on oak.oakland.edu but I forget where) can > be used to emulate a VT-100 et subs or I use the NCSA Telnet. Both of > these can be used with a TCP/IP packet driver though the Kermit setup > is a bit strange. [...] ummmm, no. the original poster wanted a _vt1000_ emulator. the vt1000 is the DEC X terminal, strangely enough. what he _really_ wants is X server software for MS/DOS. for the original poster: the VT1000 you're using is significantly more than a termninal, and requires a pretty complex set of software to emulate. DECwindows is DEC's implementation of the X window system, a cross-platform GUI. the software running on the VT1000 (and other machines that provide displays for X-based programs) is called an X server. there are, to the best of my knowlege, no freely-available X servers for MS/DOS. however, there are a number of commercial ones. check out Reflection/X (the vendor name escapes me at the moment) or Desqview/X. both of these have the required DEC cruft to do DECwindows, as far as i know. you might want to check out comp.windows.x for more information on this. dk STILL giggling that DEC called its X terminals "VT1000"s.  -----------[000348][next][prev][last][first]---------------------------------------------------- Date: 19 Jul 1994 10:43:20 +0200 From: Frank Hoffmann <fh.muc@sni.de> To: comp.protocols.tcp-ip Subject: Re: TCP error message on SCO UNIX  davidk@csn.org (David Kirkpatrick) writes: >when either reading or writing on a socket from the DOS side, I get a >console message on the SCO box that says: > NOTICE: tcp: sum xxxxx yyyyy SCO says: [CUT] This is a warning message generated by the TCP driver in the kernel. It is generated when the machine receives an Ethernet packet from another machine which has an error in the TCP part of the packet. The 'src' is a hexidecimal representation of the IP address of the remote machine and 'sum' is the checksum of the packet. To convert the hexidecimal value to an IP address use bc(C). At your prompt enter: bc ibase=16 < enter this string for conversion C0 < enter first hexidecimal octet 192 < you get 09 < enter second hexidecimal octet 194 < you get C2 < enter third hexidecimal octet 194 < you get E9 < enter forth hexidecimal octet 233 < you get For example: src C0,09,C2,E9 = 192.9.194.233 The TCP driver places a header on the data to be sent and then checksums the packet and places the checksum in the header. The packet is then passed to the IP layer which agains adds a header including a checksum (the IP checksum is only a checksum of the IP header). The packet then goes to the network adapter driver for sending across the network. On the receiving end, the headers are removed and the checksums checked. This message appears if the checksum in the TCP header does not match the checksum generated on the packet received. This is a non-fatal error. The TCP layer ignores the packet with the checksum error and then receives 'out-of-sequence' data, causing it to request a re-send of the packet. A few of these errors a day on a busy network is to be expected. This has been seen on fast machines (486 and 33Mhz 386) with the 3COM 503 card and SCO TCP/IP Release 1.1.1, however, persistent, nearly constant error messages are most often caused by bad cabling/termination, cable ringing, or a bad card (or simply an incompatable one) on the network. You may also see sporadic occurances when running via SLIP or PPP due to line noise. [CUT] Hope this helps frank How can you tell a marketing guy is lying? - His lips are moving. ------------------------------------------------------------------------------ Frank Hoffmann;Siemens Nixdorf Info-Systems;BU BA NM 14;Rosenh.Str 116\ 81669 Munich; Germany; Email= US:fh.muc@sni-usa.com; !US:fh.muc@sni.de\ UUCP: [not available]; Voice: +49-894-144-7615; Fax: +49-894-144-7746 ------------------------------------------------------------------------------ *$*^$%&N0 CARRIER  -----------[000349][next][prev][last][first]---------------------------------------------------- Date: 19 Jul 1994 21:11:42 -0400 From: debiso@pipeline.com (Joe Debiso) To: comp.protocols.tcp-ip Subject: Re: Problem: our net vs Internet  I have the same problem... Please let me know what the answer is also! Thanx! twallace@mason1.gmu.edu (Todd A Wallace) wrote: > >We are supposed to join the wonderful world of Internet >connectivity. To that end, we have a NetHopper router >and a new upgraded account with Netcom. > >However, we have a problem. > >The IP addresses are totally different from the IP >address we have been assigned from Netcom. > >QUESTION: Is there a way to resolve this problem >without having to >change the IP addresses on every single one of our PCs >and UNIX boxes? > >Thanks for any help/hints. >Todd Wallace  -----------[000350][next][prev][last][first]---------------------------------------------------- Date: Tue, 19 Jul 1994 19:41:48 From: CAMARA@novell.wd.cubic.com (Raland Camara) To: comp.protocols.tcp-ip Subject: connect() and ECONNREFUSED  When issueing the connect() system call, what conditions may exist to generate the error, ECONNREFUSED "The attempt to connect was forcefully refused"? I do not have access to the source code for the connect() system call, so any help will be greatly appreciated. The situation that I am currently debugging exists between a server program residing on a host running hpux and a client program running on an IBM pc running UnixWare. When client and server programs communicate through their perspective ethernet interfaces, everything works fine. When an attempt is made to connect to a similarly configured pc through a SLIP router the above error is encountered. (The hpux system is connected to the ethernet. A netblazer SLIP router is also connected to the ethernet. It is also connected to the serial port of the pc. Both the netblazer and the pc are configured to talk SLIP.) Both the hpux system and the pc are able to communicate through this SLIP router via ping, telnet, ftp, etc. However, the same client/server programs which ran previously through their ethernet connections do not. Any suggestions? Thanks in advance, Raland  -----------[000351][next][prev][last][first]---------------------------------------------------- Date: 19 Jul 1994 15:05:28 GMT From: mjr@tis.com (Marcus J Ranum) To: comp.protocols.tcp-ip Subject: Re: Security/Firewall FAQ?  >I'm currently in the process of researching the use of a firewall machine >to allow our administrative network Internet access, but allow them to >stay "secure" from people hacking in (ie. students, etc.). I read awhile >back in some document that there was a Firewall FAQ, but I can't find >the document anymore, and have been unable to turn it up in my travels on >the net. Could someone drop me a line with information on this beastie? FAQs are archived on rtfm.mit.edu The firewall FAQ and other firewalls related stuff is archived on ftp.tis.com: pub/firewalls or http://www.tis.com mjr.  -----------[000352][next][prev][last][first]---------------------------------------------------- Date: 19 Jul 1994 17:21:14 GMT From: march@indirect.com (Michael March) To: comp.protocols.tcp-ip Subject: Re: KA9Q  : In article <ke4dpx.22.0005B3C0@gregl.slip.iglou.com> ke4dpx@gregl.slip.iglou.com (Greg Law) writes: : The answer is a bit more complicated than this, though Greg's pretty close. : The base KA9Q code was written by Phil Karn. His copyright notice permits : unlimited, free use of the code for amateur radio or education purposes. Any : other use -- whether the code is freely distributed or not -- requires : negotiation of a license with Phil. : To complicate things further, there are literally dozens of folks who've done : work on Phil's base code, and they have their own, sometimes inconsistent : copyright statements. : But in any event, if you're planning to make any non-ham radio, : non-educational use of KA9Q, you need to contact Phil for permission, as well : as possibly contacting others. I want to get a hold of Phil to do JUST that that.. I wrote to his address at qualcomm.com and I have yet to get any response. Does he have a new address? <march> -- Michael F. March-----------KB7EXY (yep...a tech)---------march@indirect.com Internet Direct, Inc., 1366 E. Thomas Rd, Suite 210, Phoenix, AZ 85014-5738 Arizona's Internet Connection------mail info@indirect.com-----(602)274-0100 I am not only the president of Internet Direct, Inc.----I am also a client.  -----------[000353][next][prev][last][first]---------------------------------------------------- Date: Tue, 19 Jul 1994 17:32:58 GMT From: bbosen@netcom.com (Bob Bosen) To: comp.protocols.tcp-ip Subject: Re: Security/Firewall FAQ?  Richard P. Kernin (rpk@niagara.edu) wrote: : Hello, : I'm currently in the process of researching the use of a firewall machine : to allow our administrative network Internet access, but allow them to : stay "secure" from people hacking in (ie. students, etc.). I read awhile : back in some document that there was a Firewall FAQ, but I can't find : the document anymore, and have been unable to turn it up in my travels on : the net. Could someone drop me a line with information on this beastie? : Thanks much! : Take care, : -Rich : --------------------------------------------------------------------------- : Richard P. Kernin : Niagara University - Administrative Computer Center : Internet: rpk@niagara.edu or visnurpk@ubvms.cc.buffalo.edu I hope somebody else will point you at an appropriate FAQ. In addition, you might like to take a look at the animated tutorial software that my company has made available for your VGA-equipped IBM PC. This stuff teaches many important issues regarding firewalls, and it's quite entertaining to watch. It's good for motivating your management team on the importance and functionality of firewalls. It stresses the kinds of firewalls that can positively identify the _people_ that request access to your networks, as opposed to just filtering on protocols. To see it, use anonymous ftp to go to: ftp.netcom.com Then cd to: /pub/bbosen/Enigma/Tutorials/VGA/Grasp/Firewall and /pub/bbosen/Enigma/Tutorials/VGA/Grasp/Cisco Get all of the files in each directory (there are two separate tutorials in those two separate directories). Pay special attention to the "read.me" files to get oriented. Regards, -- Bob Bosen Enigma Logic Inc. 2151 Salvio St. #301 Concord, CA 94520 USA Tel: +1 510 827-5707 Internet: bbosen@netcom.com ************************************************************************** * "It wasn't me!!! Somebody must have captured my username/password!!!" * **************************************************************************  -----------[000354][next][prev][last][first]---------------------------------------------------- Date: Tue, 19 Jul 1994 17:46:15 GMT From: bruceo@loki.isc-br.com (Bruce Oscarson) To: comp.protocols.tcp-ip Subject: How to use setsockopt with TLI?  I am working on a server that supports multiple protocols (a proprietary and tcp/ip). The server was written using the TLI interface and runs on 5.4 Unix. If the server restarts while tcp/ip clients are connected, the port is placed in a FIN_WAIT2 state. This state lasts for about 13 minutes. During this time, the server cannot re-connect to the port. I attempted to set tcp/ip based connections to SO_REUSEADDR to ignore the FIN_WAIT2 state, but the fd returned from the t_open is not a valid socket fd. Does anyone have a suggestion as to how I can get the socket fd? Any suggestions as to how I might solve this 'delay' problem without using SO_REUSEADDR or convert all of my clients to async IO. (With async IO the client would detect the close on from the server and initiate its own close. The TIME_WAIT delay is only about 1 minute.) I would appreciate any suggestions. Thanks. bruceo@mail.isc-br.com -- Bruce Oscarson | bruceo@mail.spk.olivetti.com Olivetti North America | N7RWO | ma-bell (509) 927-5437  -----------[000355][next][prev][last][first]---------------------------------------------------- Date: Tue, 19 Jul 1994 20:31:28 GMT From: p_quinn@ECE.Concordia.CA (Paul Quinn) To: comp.unix.questions,comp.unix.pc-clone.32bit,comp.protocols.ibmpc,comp.protocols.tcp-ip Subject: telnetd: not enough ports.  I recently had to use TCP/IP on a DOS box to connect to an Altos UNIX box. I used LAN Workplace for DOS to get TCP/IP. The network connection appears to be fine. Occationnaly the UNIX system will not allow Telnet sessions and generate the following message (or something very close) telnetd: no network ports availible. Any indeas? Thanks in advance -- ________ Paul Quinn p_quinn@ece.concordia.ca Computer Science: Systems Architecture Concordia University Montreal, QC, CANADA --------  -----------[000356][next][prev][last][first]---------------------------------------------------- Date: Tue, 19 Jul 1994 20:47:45 GMT From: cavenewt@netcom.com (...In Bed) To: comp.protocols.tcp-ip Subject: connection wierdness  I've been using gethostbyname(localhost), where localhost is determined by gethostname(localhost,255) to get the sockadd_in structure infromation for a server I'm making. When I run the server and telnet machinename portnumber then it responds. If I telnet localhost (as in 127.0.0.1) portnumber I get connection refused. Is this normal? How do I make my server accept connections to all local IP addresses (interfaces, whatever). (This is on a Linux machine running net 3 , for what it's worth.)  -----------[000357][next][prev][last][first]---------------------------------------------------- Date: Tue, 19 Jul 1994 21:25:11 GMT From: curt@maroon.tc.umn.edu (Curtis W Griesel) To: comp.protocols.tcp-ip,comp.sys.apple2 Subject: SLIP for apple 2?  Does anyone know if SLIP software exists for an Apple 2e? And, I suppose the next logical question would be, does anyone know of any Internet tools (telnet, ftp, gopher, etc) that would work with SLIP on an Apple 2e? Thanks for any info or pointers. Curt -- Curtis W. Griesel University of Minnesota - Computer and Information Services curt@boombox.micro.umn.edu  -----------[000358][next][prev][last][first]---------------------------------------------------- Date: 20 Jul 1994 00:21:45 GMT From: leng@cougar.vut.edu.au (Leng Kaing) To: comp.protocols.tcp-ip Subject: Help: key mapping  Can someone please help me out. I need to map the vt100 keyboard for MicroFocus cobol running on UNIX Sun-OS 5.3. This situations is as such: M-Cobol needs its own set of key sequences. Each function must be preceded by a "/" (forward slash) and followed by another keystroke. For example, F6 is "/6". The manual that I have access to (PC/TCP Network Software v2.3 - DOS/windows) gives me 2 options: 1. Enclose the remapping sequence in double quotes. So if I do the following, it should work: 0,0x3b,"/6" This causes an error. So may remap file is ignored. 2. Download the function keys from the remote host. So I have create a file with the following: ^[P1;1|17/2F36^[\ (where ^[ is the escape key captured in literal mode.) Then I cat the file. But nothing happens. What I am doing wrong? In summary: can someone please suggest ways of mapping a function to a set of key sequences, not preceded by the escape character. Thanks in great anticipation. Leng. Victoria University of Technology. Footscray Campus.  -----------[000359][next][prev][last][first]---------------------------------------------------- Date: 20 Jul 1994 01:10:24 GMT From: futuretracs@delphi.com (David J. King) To: comp.protocols.tcp-ip Subject: AD- All you need to know!  What's it worth to you to become an expert in Open Systems, LANS, Programming, or UNIX? * Your job? * Your promotion * Your company? Here's what everyone should really know about Unix, Lans, Programming, and Open Systems. If topics such as Portability, Interoperability, and Integration are subjects of discussion at your company, then we can help. FutureTracs is the definitive source for advanced information systems video-based courseware. We offer material developed by independant industry experts. These courses, previously unabailable without attending costly and time consuming off-ste meetings, can educate you on the advantages and problems of Lans, Unix, Open Systems, Programming, and Enterprise Networking at your convenience either at the office or at home. Some courses that are available are: Open System Library: * Open Systems for Managers * Open Systems for Techincal Staff * Client/Server, Distributed Databases and Networks * Introduction to the OSI Reference Model * Introduction to Data Communications Unix Library: * Fundamentals of the Unix System * Unix System Administration v3.2 * Fundamentals of Unix System V v4.0 * Unix System V v4.0 Internals * The Shell Command Language for Programmers * Korn Shell Command and Programming Language * Security for the Unix System "C" Language Library: * C Language for Programmers * C Language for Programmers: The ANSI Standard * Using C++ LAN Library: * Introduction to Data Communication * Local Area Networks (Technical Staff) * Novell 3.11 Systems Administration We also have courses covering Wordprocessing, Spreadsheats, Databases and much more. So if you don't see what you are looking for, then feel free to email us. Demo tapes are available for most courses. Get an edge up on your competition! For more info email: Futuretracs@delphi.com  -----------[000360][next][prev][last][first]---------------------------------------------------- Date: 20 Jul 1994 08:07:07 -0400 From: mascari@cis.ohio-state.edu (michael v mascari) To: comp.protocols.tcp-ip Subject: lpr client  I am attempting to write an lpr client which would redirect printing on an Amiga 4000 to an RS/6000 over a SLIP connection. I do the following: 1) getservbyname() to get information regarding "printer" services 2) gethostbyname() to get host info 3) socket() to allocate/open a socket 4) connect() to establish the connection w/ lpqd I then send the print server a binary 2 followed by the name of the printer "lp", followed by a newline. I am supposed to receive an acknowledgement of a binary 0 back as an okay. Instead, I get back the string: ill-formed FROM address Any clues? Thanks for any info Mike Mascari (mascari@cis.ohio-state.edu)  -----------[000361][next][prev][last][first]---------------------------------------------------- Date: 20 Jul 1994 13:16:34 -0700 From: jbarnes@crl.com (John Barnes) To: comp.protocols.tcp-ip Subject: How to have two processes listen on same port?  Hi, I am writing a program which intercepts SNMP trap messages and processes them. The problem is that the system I am intercepting the messages is also running a NMS. I need to intercept the messages and then pass them onto the NMS. I know some NMS's offer an API but we need this program to work with any NMS. What I plan on doing is changing in /etc/services the port snmp-trap from 162 to some unused port. This should cause the NMS to read from the wrong port. I then will have my program listen on port 162 and then send the trap message on to the port I changed snmp-trap to. The problem is how do I make the header information say that the packet came from the real destination instead of the local system? Please reply to jbarnes@crl.com. Thanks, Jym Barnes  -----------[000362][next][prev][last][first]---------------------------------------------------- Date: 20 Jul 1994 01:49:57 GMT From: breyer@pcsi.com (Larry Breyer) To: comp.protocols.tcp-ip Subject: Dynamic Host Configuration Protocol  Is anyone working on DHCP? I have an applicaton employing SUN workstations as servers to a large number of portable PCs using CDPD wireless communications. I'm looking for a developer in need of Beta sites. thank you +--------------------------------------------------+ | Larry Breyer (breyer@pcsi.com) 619.535.9500.1873 | | Pacific Comm Sciences, Inc. FAX: 619.535.9235 | | 10075 Barnes Canyon Road, San Diego, CA 92121 | +--------------------------------------------------+  -----------[000363][next][prev][last][first]---------------------------------------------------- Date: Wed, 20 Jul 1994 02:28:11 GMT From: alagu@apple.com (Alagu Periyannan) To: comp.protocols.tcp-ip Subject: Public domain FTP code using TLI/XTI ?  Hi, Does anyone know of any public domain code for TCP/IP based applications that use the TLI/XTI interface rather than the BSD sockets interface ? In particular I am interested in obtaining source code for an FTP application. (other popular internet applications such as Telnet, gopher, www, etc. will also be useful.) Any pointers will be appreciated. Thanks. ------------------------------------------------------------------------- Alagu Periyannan alagu@apple.com Advanced Technology Group Apple Computer, Inc. Disclaimer: My opinions are my own, not Apple's ...  -----------[000364][next][prev][last][first]---------------------------------------------------- Date: 20 Jul 1994 03:21:19 GMT From: jtravis@herbie.unl.edu (Drizzt) To: comp.protocols.tcp-ip Subject: TCPIP Shareware for DOS  I am new to this newsgroup so no flames please.. I am looking for some good shareware TCP-IP packages for DOS (similar to Winsock for Windoze) - Any TCP-IP packages would be helpful, but preferred for DOS.. And only shareware - please mail me (jtravis@herbie.unl.edu) Thank ewe..  -----------[000365][next][prev][last][first]---------------------------------------------------- Date: 20 Jul 1994 04:48:24 GMT From: bfriesen@iphase.com (Bob Friesenhahn) To: comp.protocols.tcp-ip Subject: Re: Problem: our net vs Internet  : >We are supposed to join the wonderful world of Internet : >connectivity. To that end, we have a NetHopper router : >and a new upgraded account with Netcom. : > : >However, we have a problem. : > : >The IP addresses are totally different from the IP : >address we have been assigned from Netcom. : > : >QUESTION: Is there a way to resolve this problem : >without having to : >change the IP addresses on every single one of our PCs : >and UNIX boxes? This is solely a routing problem. Your network must be an officially assigned subnet. Also, you should obtain a domain name associated with your subnet. Entries are then placed in the Internet DNS system which advertise the route to your subnet via Netcom. Netcom should be able to handle this for you. In order to make it out of your subnet to the Internet, you will need to configure your hosts such that they know to route through your gateway for addresses outside of the local net. A default route can work for this. Bob --- Bob Friesenhahn, Interphase bfriesen@iphase.com  -----------[000366][next][prev][last][first]---------------------------------------------------- Date: 20 Jul 1994 10:36:45 GMT From: kohlhage@quantum.de (juergen kohlhage) To: comp.protocols.tcp-ip,comp.protocols.tcp-ip.domains,comp.protocols.tcp-ip.ibmpc,comp.os.ms-windows.networking.tcp-ip,comp.os.ms-windows.networking.windows,comp.os.ms-windows.programmer.networks,comp.sys.ibm.pc.hardware.misc,comp.os.os2.networking Subject: Re: WTB: Info on Schneider & Koch ethernet cards  reinken@tu-harburg.d400.de wrote: : In <CsA1CD.M3v@aplcenmp.apl.jhu.edu>, salman@aplcenmp.apl.jhu.edu (Ashfaq salman (703) 516-7616) writes: : >Hello, : > : >I badly need "any info" on the following cards: : > : >They are make by a German company Schneider & Koch and cards are 16-bit : >ethernet adapters. The software tries to identify them as SK-Junior : >boards. : > : >I am particularly interested in getting Novell, Windows, etc. drivers for it. : >I only have netbios software for it. I don't have any other documentation : >on it. Any information about its compatibility or the company will be greatly : >appreciated. Thanks in advance. : > : >-Salman : >salman@lccinc.com : > : The adress of the company is : : Siemensstraáe 23 : D - 76275 Ettlingen : Voice-Mail : 49 7243 / 502 - 0 : Fax : 49 7243 / 502 - 989 : You normaly get all drivers with the card. There is a driver packet called SK - UPPS (universal programmel : prtocol stack) you can use to communicate with novell (ipx, spx) and unix-workstation (tcp/ip) at the same : time. This driver packet should be send with your SK-Junior board i think. : Wolfram Reinken : E- Mail : reinken@tu-harburg.d400.de : or rztwr@molly.rz.tu-harburg.de Hi there, the Company Schneider & Koch has also a mailbox where you can download new drivers and routing software: 49 7243 502 586 Bye Juergen  -----------[000367][next][prev][last][first]---------------------------------------------------- Date: Wed, 20 Jul 94 12:01:22 GMT From: egn@athen.mch.sni.de (Emil Naepflein) To: comp.protocols.tcp-ip Subject: Re: How to use setsockopt with TLI?  In article <1994Jul19.174615.2395@isc-br.isc-br.com> bruceo@loki.isc-br.com (Bruce Oscarson) writes: >I am working on a server that supports multiple protocols >(a proprietary and tcp/ip). The server was written using the TLI >interface and runs on 5.4 Unix. If the server restarts while tcp/ip >clients are connected, the port is placed in a FIN_WAIT2 state. >This state lasts for about 13 minutes. During this time, the >server cannot re-connect to the port. > >I attempted to set tcp/ip based connections to SO_REUSEADDR to >ignore the FIN_WAIT2 state, but the fd returned from the t_open is >not a valid socket fd. > >Does anyone have a suggestion as to how I can get the socket >fd? Any suggestions as to how I might solve this 'delay' problem >without using SO_REUSEADDR or convert all of my clients to >async IO. (With async IO the client would detect the close on from >the server and initiate its own close. The TIME_WAIT delay is >only about 1 minute.) There is an internet protocol specific option called IP_REUSEADDR. Setting this one to T_YES should provide the same behaviour as SO_REUSEADDR. I got this information from the CAE Specification, X/Open Transport Interface (XTI). You may have to check if this option is implemented in your flavour of 5.4 Unix. Emil Naepflein  -----------[000368][next][prev][last][first]---------------------------------------------------- Date: Wed, 20 Jul 1994 13:24:53 GMT From: dbeedle@rs6000.cmp.ilstu.edu (Dave Beedle) To: comp.protocols.tcp-ip,comp.protocols.ppp Subject: Re: routing on SunOS (with dp2.3) for remote PPP users?  King Rhoton (king@acpub.duke.edu) wrote: > > I'm having trouble setting up cslip-2.7 on SunOS 4.1.3. I can get > > the line to answer and go into SLIP mode, and my remote station > > (running Trumpet Winsock) can use TCP/IP to the host directly, but > > they can't see any hosts outside the local domain. FTP, Mosaic, > > etc., just time out when they try to connect to a distant host. > > > > I think its something to do with routing, but I'm not sure. How > > should routing be set up on the host to which SLIP users dial in? > > > > Routing tables > > Destination Gateway Flags Refcnt Use Interfa ce > > localhost localhost UH 4 17440 lo0 > > 199.123.192.10 parts UH 1 33 sl0 > > default 199.123.192.1 UG 3 6342 le0 > > 199.123.192.0 parts U 2 308 le0 > > > > So, .10 can talk to parts and TCP/IP services on parts, and parts > > can talk to things like ftp.uu.net and www.ncsa.uiuc.edu, etc., > > but .10 can't talk to ftp.uu.net, etc. > I'm having the exact same problem, only with PPP connections instead of > slip. I'm entirely baffled. I've set up an arp entry for my remote > machine, and from the remote machine ping requests to non-dialup-hosts do > go through the PPP link (I see the tx led flicker), but I never get > anything back. I have full access to the dialup host, though. I've tried > both Linux (with PPP 2.1.2a) and a Mac (with MacPPP 2.0.1) as clients, and > they behave the same. It's got to be something in the Sun's > configuration, but I'm out of ideas. SunOS 4.1.3 and dp2.3pl2. Same problem here to. We can reach host on the local net but nothing outside that. Would gated or routed have to runn to allow these connections? Anybody got a tip? Thanks! -- Dave Beedle - Unix Support Manager - dbeedle@ilstu.edu - Network Services http://www.ilstu.edu/~dbeedle/ Illinois State University "It is better to think of church in the ale-house than 136A Julian Hall to think of the ale-house in church." - Martin Luther Normal, IL 61761  -----------[000369][next][prev][last][first]---------------------------------------------------- Date: 20 Jul 1994 20:20:04 -0400 From: allen@stone.ucs.indiana.edu (Allen Robel) To: news.announce.newgroups,news.groups,comp.dcom.cell-relay,comp.dcom.isdn,comp.dcom.lans.ethernet,comp.dcom.lans.fddi,comp.dcom.lans.misc,comp.protocols.tcp-ip,bit.listserv.novell Subject: RFD: comp.dcom.frame-relay  REQUEST FOR DISCUSSION NEWSGROUP: comp.dcom.frame-relay UNMODERATED Crossposted to: news.groups news.announce.newgroups comp.dcom.cell-relay comp.dcom.isdn comp.dcom.lans.ethernet comp.dcom.lans.fddi comp.dcom.lans.misc comp.protocols.tcp-ip bit.listserv.novell Given that Frame Relay is beginning to emerge as a mainstream WAN service, and given that discussions of Frame Relay technology are appearing with increasing frequency on other newsgroups such as comp.dcom.cell-relay, perhaps now is the time to create a newsgroup to provide a home for this topic. Below is a draft charter, written by Tom Jones, ex-chair of the Frame Relay Forum and continuing proponent of Frame Relay services and technologies. It is intended as a starting point for discussion over the next month as to what shape a Frame Relay newsgroup might take. Comments are welcome and encouraged. As per Usenet "policy"/tradition, the following timeline will be adhered to: 7/21/94 - 8/21/94 Discussion period 8/21/94 - ~9/21/94 Voting (if it is generally agreed that this group would be a Good Thing). We will defer to the Usenet Volunteer Votetakers at Qualcomm to setup and conduct the vote. Below is the proposed charter. The Followup-To: field has been set to news.groups. Please direct all comments concerning this Request for Discussion there. DRAFT CHARTER: To provide a mechanism for the discussion of issues related to the technology and application of frame relay in communications networks. Topics expected to be discussed include (but are not limited to) the following examples: - frame relay standards and proposed standards - applications of frame relay - user experiences with frame relay - relationship and comparison of frame relay to other technologies, including asynchronous transfer mode (ATM), cell relay, SMDS, X.25 packet switching, IP routing, ISDN, Broadband ISDN, etc. - announcements of conferences, seminars, etc., related to frame relay - news of the availability of frame relay products or services - testing and interoperability of frame relay - information related to performance and implementation of frame relay - research findings - activities of The Frame Relay Forum and other similar organizations with activities related to frame relay - sources of additional information regarding frame relay This newsgroup is not intended to be a forum in which standards are developed, although it may be expected to relate news pertaining to standards and to the progress of recognized standards bodies. regards, -- Allen Robel Internet: robelr@indiana.edu Network Engineer voice: (812)855-0962 Indiana University FAX: (812)855-8299  -----------[000370][next][prev][last][first]---------------------------------------------------- Date: 20 Jul 1994 20:20:10 -0400 From: Bob Smith <bsmith@wci.com> To: news.announce.newgroups,news.groups,comp.dcom.lans.misc,comp.dcom.modems,comp.dcom.telecom.tech,comp.protocols.misc,comp.protocols.tcp-ip,sci.geo.satellite-nav Subject: RFD: comp.dcom.wireless.cdpd  ************************************************************************ REQUEST FOR DISCUSSION (RFD) comp.dcom.wireless.cdpd ************************************************************************ Group Name: comp.dcom.wireless.cdpd Status: Unmoderated Summary: Discussion of all aspects of Cellular Digital Packet Data (CDPD), including discussions of carriers, services, applications, specifications, and noteworthy events. Distribution: World CHARTER ------- CDPD is wireless protocol which offers low cost and ubiquitous radio coverage to TCP-IP networks. The technology uses the idle voice channels available in the existing cellular telephone system for packet data transmission. Application interface to CDPD can be via telnet, SLIP, UDP, or TCP. A CDPD modem uses the AT command set and has an IP address which is assigned by the local cellular company (just as your cellular carrier assigned the phone number to your cellular phone). CDPD may be the preferred remote/mobile WAN since the time and cost overhead of a cellular call establishment is not present. The aim of comp.dcom.wireless.cdpd would be to provide an informal electronic conference for anyone curious about, or involved with CDPD. It is hoped that the group may further the understanding and awareness of CDPD. CDPD's success requires the cooperation and coordination of many diverse players: application developers, system integrators, cellular carriers, infrastructure manufacturers, and modem manufactures. A newsgroup where ideas, suggestions, and questions can be freely exchanged is needed to help tie these players into an industry. The FAQs would be an important part of the newsgroup and would include as a minimum: FAQs about the nature and scope of CDPD a list of CDPD carriers and services offered a list of CDPD modem manufacturers a list of other CDPD products available This newsgroup would allow the rapid and timely discussion of CDPD related issues and events which might otherwise never be fully disseminated. Topics for discussion would include :- Product announcements Press releases of interest to the CDPD community Innovative CDPD applications CDPD deployment issues and plans Interpretation of the CDPD specification Infrastructure hardware: NMS, MDBS, MD-IS, ... Infrastructure software: NMS, MDBS, MD-IS, ... Modems - specifications, opinions, etc. New product ideas Databases, lists of... CDPD security, encryption, and firewalls Announcements/reviews of papers/conferences Comparisons to alternatives such as RAM, Ardis General discussion/opinions/questions. Positions vacant Professional news Economic issues We hope that you will support this group, and look forward to your comments and participation in the discussions in news.groups. Please distribute this proposal to your friends and colleagues. This RFD has been posted to: comp.dcom.lans.misc comp.dcom.modems comp.dcom.telecom.tech comp.protocols.misc comp.protocols.tcp-ip news.announce.newgroups sci.geo.satellite-nav The Process of Creating a Newsgroup - ------------------------------------ (a) RFD: Request for Discussion, i.e.., public hearing to take place in the newsgroup news.groups on Internet for approximately one month (b) CFV: Call for votes (the voting period will be about 25 days) (c) Counting of votes and public display of votes (d) Announcement of new newsgroup (a)-->(b) assumes no major disagreements about this newsgroup during discussion. (c)-->(d) assumes that at least two-thirds of the vote are positive and that the 'yes' votes outnumber the 'no' votes by at least 100. Thank-you, Bob Smith -- Wireless Connect, Inc. Voice: 408.296.1546 Fax: 408.296.1547 Email: bsmith@wci.com or bsmith@rahul.net  -----------[000371][next][prev][last][first]---------------------------------------------------- Date: 20 Jul 1994 14:52:24 GMT From: emv@garnet.msen.com (Edward Vielmetti) To: alt.dcom.telecom.ip,comp.protocols.tcp-ip,comp.dcom.servers Subject: Re: Livingston Portmaster woes  Dr. Laurence Leff (mflll@uxa.ecn.bgu.edu) wrote: : We are having trouble setting up our account mechanisms on our Livingston : Portmaster 2E. It is running Version 3.0.1 of the software There is a mailing list for owners of Livingston Portmaster and IRX hardware; send mail to To: majordomo@mail.msen.com subscribe portmaster-users to join it. thanks Edward Vielmetti, vice president for research, Msen Inc. emv@Msen.com Msen Inc., 320 Miller, Ann Arbor MI 48103 +1 313 998 4562 (fax: 998 4563)  -----------[000372][next][prev][last][first]---------------------------------------------------- Date: 20 Jul 1994 14:53:10 GMT From: nelson@crynwr.crynwr.com (Russell Nelson) To: comp.protocols.tcp-ip.domains,comp.protocols.tcp-ip Subject: Integrating DNS and BOOTP (was Re: Newbie DNS questions)  In article <30f2a3$asj@babs.nsr.hp.com> cricket@nsr.hp.com (Cricket Liu) writes:

Cricket is being modest.  If you have questions about the DNS, you
can't go wrong with the O'Reilly and Associates _DNS and Bind_,
written by Paul Albitz & Cricket Liu.

The BOOTP server doesn't care whether the IP address it's assigning
really maps to the hostname it's assigning in DNS, nor does DNS
care that BOOTP is giving out the information.  I suppose some
vendor may have created a nice system to integrate the management
of these services, but I don't know of one.

Here's some code I wrote for a customer.  It's public domain.  It
parses a named input file, looking for special comments.  Here's an
example of the input.  The host's IP address is remembered, and
combined with the Ethernet address on the BOOTP comment line.

ray8180 IN      A       137.143.111.245
;                       BOOTP   000094573758
ray8152 IN      A       137.143.111.246
;                       BOOTP   AA000400A34F
ray8153 IN      A       137.143.111.247
;                       BOOTP   AA000400A44F
ray9154 IN      A       137.143.111.248
;                       BOOTP   AA000400A24F

#! /bin/sh
# This file is /usr/lib/named/makebootptab
# create /etc/bootptab from /etc/bootptab.head and /var/dss/namedb/named.potsdam
nawk '$2 == "IN" { host =$1
ip = $4 }$2 == "BOOTP" {
if ($3 in addr_to_host) { print "# Duplicate hardware address "$3 " for " host " and " addr_to_host[$3] } else { addr_to_host[$3] = host
}
printf("%s:tc=global.dummy:ht=ethernet:ha=%s:ip=%s:\n", host, $3, ip); }' /var/dss/namedb/named.potsdam >>/tmp/bootptab mv /etc/bootptab /etc/bootptab.bak mv /tmp/bootptab /etc/bootptab exit 0 #and this is all that needs to be in /etc/bootptab.head: global.dummy:\ :sm=255.255.252.0:\ :ds=137.143.110.101:\ :gw=137.143.110.254:\ :to=18000: -- -russ <nelson@crynwr.com> http://www.crynwr.com/crynwr/nelson.html Crynwr Software | Crynwr Software sells packet driver support | ask4 PGP key 11 Grant St. | +1 315 268 1925 (9201 FAX) | What is thee doing about it? Potsdam, NY 13676 | LPF member - ask me about the harm software patents do.  -----------[000373][next][prev][last][first]---------------------------------------------------- Date: Wed, 20 Jul 1994 15:20:55 GMT From: rstevens@noao.edu (W. Richard Stevens) To: comp.protocols.tcp-ip Subject: Re: connect() and ECONNREFUSED  > When issueing the connect() system call, what conditions may exist to generate > the error, ECONNREFUSED "The attempt to connect was forcefully refused"? I > do not have access to the source code for the connect() system call, so any > help will be greatly appreciated. On BSD-based systems this only occurs when the response to the client's SYN is an RST. Normally this is only caused by the server's host receiving a SYN for a server that doesn't exist (i.e., there does not exist a TCP end point in the LISTEN state at the specified port). Rich Stevens  -----------[000374][next][prev][last][first]---------------------------------------------------- Date: Wed, 20 Jul 1994 15:28:19 GMT From: rstevens@noao.edu (W. Richard Stevens) To: comp.protocols.tcp-ip Subject: Re: connect() and ECONNREFUSED  One additional point upon rereading your posting ... it's possible to start a server three different ways on a BSD-based system: (1) accept any connection request to my port, (2) accept any connection request to my port that arrives on a particular local interface, and (3) only accept connections that arrive for my port that originate from a particular client IP address and port. Check out Section 18.11 ("TCP Server Design") of my "TCP/IP Illustrated" (Addison-Wesley, 1994) for additional details. Check that your server (which accepts the incoming connection from the client on the Ethernet) isn't started with either conditions (2) or (3) above. "netstat -a" should show you the status of the server's listening socket. Rich Stevens  -----------[000375][next][prev][last][first]---------------------------------------------------- Date: Wed, 20 Jul 1994 16:43:08 GMT From: vjs@calcite.rhyolite.com (Vernon Schryver) To: comp.protocols.tcp-ip Subject: Re: ARP update mechanism on unix hosts  In article <30epgcINN6ac@early-bird.think.com> barmar@think.com (Barry Margolin) writes: >In article <albert.774173072@netboss> albert@dn.itg.telecom.com.au (Albert Fu) writes: > ... >> Also, is there a mechanism for the Unix host to >>refresh its ARP cache periodically, eg every 10 minutes? > >This probably depends on the Unix version. I don't think there's a >built-in timeout in BSD Unix. You could have a cron job that executes a >script that deletes all the entries in the ARP cache. A quick peak at netinet/if_ether.c would probably be more illuminating that inaccurate speculations. Consider these lines from one version of if_ether.c #define ARPT_KILLC 20 /* kill completed entry in 20 mins. */ #define ARPT_KILLI 3 /* kill incomplete entry in 3 minutes */ Vernon Schryver vjs@rhyolite.com  -----------[000376][next][prev][last][first]---------------------------------------------------- Date: Wed, 20 Jul 1994 16:43:38 GMT From: dtoppin@ucserv.melpar.esys.com (Doug Toppin) To: comp.protocols.tcp-ip Subject: Do UNIX domain sockets cause any disk activity?  We are heavily using Unix domain sockets and regularly notice disk activity on our Sun 4.1.3 systems that I can't attribute to anything else. I don't believe that any disk activity should be related to the domain sockets excepting for the opening of the socket (implemented as a named pipe in the file system). Since the size and mod date/time never change I don't see any reason for this to cause disk activity. Doug Toppin dtoppin@melpar.esys.com  -----------[000377][next][prev][last][first]---------------------------------------------------- Date: 20 Jul 1994 17:00:32 GMT From: kong@pascal.cs.albany.edu (Waiyee L Kong) To: comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc,comp.protocols.domains,comp.os.ms-windows.networking.tcp-ip,comp.protocols.nfs Subject: RPC Gen and ASN.1  hi, everybody, If anybody can tell me where (or which ftp sites) I can get information on RPC, RPC Gen, XDR and ASN.1 (the actual RPC Gen code/compiler and documentation aboutwhat system it supports and the specfications, or which company out there gives such services), I would really really appreciate it. I need it in these 2 days... please email me at kong@cs.albany.edu Thank you very much. Lydia --MAA26433.774723274/pascal.cs.albany.edu--  -----------[000378][next][prev][last][first]---------------------------------------------------- Date: Wed, 20 Jul 94 17:48:51 GMT From: lutz@prodigal.psych.rochester.edu (Dave Lutz) To: comp.protocols.tcp-ip,comp.protocols.ppp Subject: Re: routing on SunOS (with dp2.3) for remote PPP users?  In <1994Jul20.132453.89403@rs6000.cmp.ilstu.edu> dbeedle@rs6000.cmp.ilstu.edu (Dave Beedle) writes: >King Rhoton (king@acpub.duke.edu) wrote: >> > I'm having trouble setting up cslip-2.7 on SunOS 4.1.3. I can get >> > the line to answer and go into SLIP mode, and my remote station >> > (running Trumpet Winsock) can use TCP/IP to the host directly, but >> > they can't see any hosts outside the local domain. FTP, Mosaic, >> > etc., just time out when they try to connect to a distant host. >> > >> > I think its something to do with routing, but I'm not sure. How >> > should routing be set up on the host to which SLIP users dial in? >> > >> > Routing tables >> > Destination Gateway Flags Refcnt Use Interfa ce >> > localhost localhost UH 4 17440 lo0 >> > 199.123.192.10 parts UH 1 33 sl0 >> > default 199.123.192.1 UG 3 6342 le0 >> > 199.123.192.0 parts U 2 308 le0 >> > >> > So, .10 can talk to parts and TCP/IP services on parts, and parts >> > can talk to things like ftp.uu.net and www.ncsa.uiuc.edu, etc., >> > but .10 can't talk to ftp.uu.net, etc. >> I'm having the exact same problem, only with PPP connections instead of >> slip. I'm entirely baffled. I've set up an arp entry for my remote >> machine, and from the remote machine ping requests to non-dialup-hosts do >> go through the PPP link (I see the tx led flicker), but I never get >> anything back. I have full access to the dialup host, though. I've tried >> both Linux (with PPP 2.1.2a) and a Mac (with MacPPP 2.0.1) as clients, and >> they behave the same. It's got to be something in the Sun's >> configuration, but I'm out of ideas. SunOS 4.1.3 and dp2.3pl2. > Same problem here to. We can reach host on the local net but nothing >outside that. Would gated or routed have to runn to allow these connections? >Anybody got a tip? Thanks! I am running the loadable version of cslip-2.7 on a Sun3 running SunOS 4.1.1, and it works fine for some clients, but not for others. When I run cslipper on a PC, then use NCSA telnet, I can telnet to any host I want. If I run an NCR X terminal over the same connection, I can only connect to the slip server. I can't even connect to other hosts in the same network. The routing tables on the server look like this: solace:~% netstat -r Routing tables Destination Gateway Flags Refcnt Use Interface localhost localhost UH 1 789 lo0 slip86 solace UH 0 6 sl0 128.151.80.0 solace U 19 379419 le0 default 128.151.80.24 UG 0 412 le0 Arp shows the following: solace:~% arp -a slip86.psych.rochester.edu (128.151.80.86) at 8:0:20:0:7d:ac permanent published On another system, arp shows: prodigal:~% arp -a | egrep "solace|slip" solace.psych.rochester.edu (128.151.80.53) at 8:0:20:0:7d:ac slip86.psych.rochester.edu (128.151.80.86) at 8:0:20:0:7d:ac I don't know what this all means, but for me it seems to be a client problem, not a server problem. Dave  -----------[000379][next][prev][last][first]---------------------------------------------------- Date: 20 Jul 1994 18:14:44 GMT From: barmar@think.com (Barry Margolin) To: comp.protocols.tcp-ip Subject: Re: connection wierdness  In article <cavenewtCt7GFL.3K7@netcom.com> cavenewt@netcom.com (...In Bed) writes: >I've been using gethostbyname(localhost), where localhost is determined by >gethostname(localhost,255) to get the sockadd_in structure infromation for >a server I'm making. When I run the server and telnet machinename portnumber >then it responds. If I telnet localhost (as in 127.0.0.1) portnumber >I get connection refused. Is this normal? How do I make my server >accept connections to all local IP addresses (interfaces, whatever). Yes, it's normal. You said you only wanted to serve connections to a specific IP address, so connections to other addresses are refused. Use INADDR_ANY as the address in the bind(2) call if you want to accept connections to any of the host's addresses. This is also useful if a host has multiple interfaces. -- Barry Margolin System Manager, Thinking Machines Corp. barmar@think.com {uunet,harvard}!think!barmar  -----------[000380][next][prev][last][first]---------------------------------------------------- Date: 20 Jul 1994 16:06:16 +0300 From: yosi@wiscon.weizmann.ac.il (Yosi Mass) To: comp.protocols.tcp-ip Subject: file transfer facility  I'm looking for a file transfer facility beyond copy (VMS) and FTP over tcp/ip which offers: - An API for add-on applications - Triggering follow-up tasks on reciever's side - Guranteed delivery (e.g if reciever is currently down, recovery from failures) - On the fly compression - Monitoring and statistics Does anybody knows of something that does some or all of the above? -- Yosi Mass Ubique Ltd. -- Yosi Mass Ubique Ltd.  -----------[000381][next][prev][last][first]---------------------------------------------------- Date: 20 Jul 1994 23:17:03 GMT From: jenkins@oils (Jon Jenkins) To: comp.protocols.tcp-ip,comp.protocols.ppp Subject: Re: routing on SunOS (with dp2.3) for remote PPP users?  Dave Beedle (dbeedle@rs6000.cmp.ilstu.edu) wrote: : King Rhoton (king@acpub.duke.edu) wrote: : > > I'm having trouble setting up cslip-2.7 on SunOS 4.1.3. I can get : > > the line to answer and go into SLIP mode, and my remote station : > > (running Trumpet Winsock) can use TCP/IP to the host directly, but : > > they can't see any hosts outside the local domain. FTP, Mosaic, : > > etc., just time out when they try to connect to a distant host. : > > : > > I think its something to do with routing, but I'm not sure. How : > > should routing be set up on the host to which SLIP users dial in? : > > : > > Routing tables : > > Destination Gateway Flags Refcnt Use Interfa ce : > > localhost localhost UH 4 17440 lo0 : > > 199.123.192.10 parts UH 1 33 sl0 : > > default 199.123.192.1 UG 3 6342 le0 : > > 199.123.192.0 parts U 2 308 le0 : > > : > > So, .10 can talk to parts and TCP/IP services on parts, and parts : > > can talk to things like ftp.uu.net and www.ncsa.uiuc.edu, etc., : > > but .10 can't talk to ftp.uu.net, etc. : > I'm having the exact same problem, only with PPP connections instead of : > slip. I'm entirely baffled. I've set up an arp entry for my remote : > machine, and from the remote machine ping requests to non-dialup-hosts do : > go through the PPP link (I see the tx led flicker), but I never get : > anything back. I have full access to the dialup host, though. I've tried : > both Linux (with PPP 2.1.2a) and a Mac (with MacPPP 2.0.1) as clients, and : > they behave the same. It's got to be something in the Sun's : > configuration, but I'm out of ideas. SunOS 4.1.3 and dp2.3pl2. : Same problem here to. We can reach host on the local net but nothing : outside that. Would gated or routed have to runn to allow these connections? : Anybody got a tip? Thanks! you might need to enable ipforwarding and ipgateway on both machines. On OSF/1 this is done by a function called: iprsetup (it just sets two kernel variables: ipforwarding and ipgateway to != 0. The host RFC requires that it NOT be enabled by default. hope this helps jon  -----------[000382][next][prev][last][first]---------------------------------------------------- Date: 21 Jul 1994 01:24:47 GMT From: rao@acsc.com (Rao Srinivasa) To: comp.protocols.tcp-ip Subject: Ethernet card in Promiscuous mode ..?  Hi, Can some one let me know how to set Ethernet card in promiscuous mode on RS6000 machines ... Is it System/OS dependent ...? Thanks in advance ... Rao.  -----------[000383][next][prev][last][first]---------------------------------------------------- Date: Thu, 21 Jul 1994 02:05:07 GMT From: alagu@apple.com (Alagu Periyannan) To: comp.protocols.tcp-ip Subject: BSD sockets to XTI/TLI API conversion code ?  Hi, Does anyone know of public domain source code that converts BSD sockets API to the XTI/TLI API ? I should be able to take any application written for the BSD sockets API and link it with this "magic code" and be able to use the XTI/TLI API instead. (I am looking specifically to use this to port TCP/IP apps like FTP.) Any pointers will be much much much ... appreciated. Thanks in advance. ------------------------------------------------------------------------- Alagu Periyannan alagu@apple.com Advanced Technology Group Apple Computer, Inc. Disclaimer: My opinions are my own, not Apple's ...  -----------[000384][next][prev][last][first]---------------------------------------------------- Date: 20 Jul 1994 10:47:43 +1000 From: yonsei@usenet.hana.nm.kr (Yonsei News Adm) To: comp.protocols.tcp-ip Subject: Call for Paper ICCC95  Following is the FIRST CALL FOR PAPER for ICCC'95 to be held in Seoul Korea 1995. Publicity Chair, ICCC'95 -----------------cut here--------------------------------------------- ---------------------------------------------------------------------- CALL FOR PAPERS ICCC '95 "Information Highways for a Smaller World & Better Living" Seoul, Korea August 21 - 24, 1995 ----------------------------------------------------------------------------------- The ICCC, the International Council for Computer Communication (ICCC), founded in 1972, is an Affiliate Member of the International Federation for Information Processing (IFIP). Its purposes are to foster: · scientific research and the development of computer communication; · progress in the evaluation of applications of computer communication to educational, scientific, medical, economic, legal, cultural and other peaceful purposes; · study of the potential social and economic impacts of computer communcation and of policies which influence those impacts. This 12th conference aims at providing a forum to exchange ideas, discuss key issues and to present the late research results for "Information Highways for a Smaller World & Better Living." The main program includes technical presentations, invited talks, tutorials, and technical visits. TOPICS : Areas of interest include but are not limited to . Strategies, Policies, and User . Wireless Communications Perspectives of Information . Intelligent Networks Superhighways . Personal Communications Systems . Social and Economical Impacts . Broadband Communication of Information Superhighways . ATM Switching . Computer Communication for . International Emergencies Developing Countries . Distance Learning . Network Planning . Optical Communications . Security and Privacy in Computer . Multimedia Communication and its Communications Applications . Evolution towards the High-Speed . High-Speed Protocols Networks including Frame Relay . Network Management and SMDS . Protocol Engineering . Packet Radio Technologies . Satellite Communications SUBMISSION OF PAPERS Prospective authors should send 5 copies of a full paper to the following address; ICCC'95 Dr. Seon Jong Chung ICCC'95 Technical Program Chairman ETRI, Yusong P.O.Box 106, Taejon, Korea, 305-606 Tel: +82-42-860-8630 Fax: +82-42-860-6465 E-mail: iccc95@giant.etri.re.kr The manuscript should not exceed 4000 words in length and should include author's name, affiliation, and addresses(telephone, e-mail, fax), and 150-200 words abstracts in the title page. Also, authors are encouraged to send a Postscript version of their full paper to the Technical Program Committee Chairman by e-mail iccc95@giant.etri.re.kr |-------------------------------| | Important Dates | | Submission of Paper | | February 1st, 1995 | | Notification of Acceptance | | May 1st, 1995 | | Camera-ready Papers | | June 15th, 1995 | |-------------------------------| ----------------------------------------------------------------------------------- Sponsored by The International Council for Computer Communication Hosted by Electronics and Telecommunications Research Institute Korea Information Science Society Under the Patronage of Ministry of Communication, The Republic of Korea Conference Governor Ronald P.Uhlig, Northern Telecom, U.S.A. Conference Organizing Committee Chair : Chongsun Hwang, KISS, Korea Co-Chair : Seungtaik Yang, ETRI, Korea Local Arrangement Dongho Lee, Kwangwoon Unvi., Korea Publication Keosang Lee, Dacom, Korea Publicity Jaiyong Lee, Yon-Sei Univ., Korea Registration Samyoung Suh, NCA, Korea Treasurer Seungkyu Park, Ajou Univ., Korea Tutorial Sunshin An, Korea Univ., Korea Social Program Nosik Kim, KTRC, Korea Secretariate Yanghee Choi, SNU, Korea Jinpyo Hong, ETRI, Korea Technical Program Chair : Seonjong Chung, ETRI, Korea Co-Chairs : Serge Fdida, MASI, France Nicholas Georganas, Univ. of Otawa, Canada Roger Needham, Univ. of Cambridge, U.K. Otto Spaniol, Aachen Tech. Univ., Germany Hideyoshi Tominaga, Waseda Univ., Japan Pramode Verma, AT&T, U.S.A. Members : Byungchul Shin, KAIST, Korea Yongjin Park, Hanyang Univ., Korea Donggyoo Kim, Ajou Univ., Korea Kwangsue Chung, Kwangwoon Univ., Korea Daeyoung Kim, Cheoungnam National Univ., Korea Ilyoung Chung, ETRI, Korea Chimoon Han, ETRI, Korea Woojik Chon, ETRI, Korea Hoon Choi, ETRI, Korea Tadao Saito, Tokyo Univ., Japan Tahahiko Kamae, HP Lab., Japan Reigo Yatsuboshi, Fujitsu Lab., Japan Kinji Ono, NCIS, Japan Michael Diaz, LAAS, France Christophie Diot, INRIA, France Georgio Ventre, Univ. di Napoli, France David Hutchison, Lonchaster Univ., U.K. Augusto Casaca, IST-INESC, Spain Martina Zitterbart, Univ. of Karlsiuhe, Germany Ulf Koerner, Lund Univ., Sweden Albert Kuendig, Swiss Federal Inst. of Tech., Swiss -----------------------------------------------------------------------------------  -----------[000385][next][prev][last][first]---------------------------------------------------- Date: 21 Jul 94 03:57:28 GMT From: ddl@harvard.edu (Dan Lanciani) To: comp.protocols.tcp-ip Subject: Re: connect() and ECONNREFUSED  In article <1994Jul20.152819.17687@noao.edu>, rstevens@noao.edu (W. Richard Stevens) writes: | One additional point upon rereading your posting ... it's possible | to start a server three different ways on a BSD-based system: | (1) accept any connection request to my port, (2) accept any | connection request to my port that arrives on a particular local | interface, and (3) only accept connections that arrive for my port | that originate from a particular client IP address and port. Check | out Section 18.11 ("TCP Server Design") of my "TCP/IP Illustrated" | (Addison-Wesley, 1994) for additional details. I assume your case (2) refers to bind()ing to the particular IP address associated with one of your local interfaces. What this really does is accept connections destined for said IP address, regardless of which interface their SYNs arrive on. Although the difference is subtle, it can be important in some multi-homed situations. Case (3) is not one I've seen supported on typical BSD systems (at least not intentionally :). Can you be more specific? Dan Lanciani ddl@harvard.*  -----------[000386][next][prev][last][first]---------------------------------------------------- Date: 20 Jul 1994 15:04:03 +0800 From: smenda@perth.DIALix.oz.au (Greg Smenda) To: comp.protocols.tcp-ip,comp.protocols.misc Subject: OSPF sources  I am looking for a list of sources for OSPF code, both public domain and private. I am interested in how many people are actually producing implementations of this protocol, given the seemingly large interest in it as a successor to RIP. Greg Please respond to my email address, smenda@dialix.oz.au Thanks -- Greg Smenda Internet : smenda@DIALix.oz.au ACSnet : smenda@DIALix.oz Voice : +61-9-4451888 0800 - 1730 WST - Fishy fishy fishy fish, it would go where ever I did go -  -----------[000387][next][prev][last][first]---------------------------------------------------- Date: 21 Jul 1994 01:30:00 +0200 From: pb@fasterix.frmug.fr.net (Pierre Beyssac) To: comp.protocols.tcp-ip Subject: Re: IP Usage Billing package ?  In article <1994Jul12.125058.30409@ucl.ac.uk>, Jon Crowcroft <ucacjon@ucl.ac.uk> wrote: >there is a "market force" myth going around (some people at INET >in prague were trying to >perpertrate it) that you get more money by doing useage based charging > >this is false, and there are people who even have maths to show it... No need for complicated maths. Charging by usage means billing overhead everywhere in your system... Hence a less efficient use of available ressources. Of course the user has to pay for this overhead. He ends up paying more for the same service... To put it another way, the IP provider ends up with prices higher than the competition for providing a service worse or no better. Guess what the users will do next... This very scenario is currently occuring in France : some IP providers charge by usage, not their competition... Usage charges are still very popular in Europe, probably a legacy of X25. X25 is dying partly for lack of services. Correct me if I'm wrong, but I see a relation between these... -- Pierre Beyssac FreeBSD@home: pb@fasterix.frmug.fr.net FreeBSD, NetBSD, Linux -- Il y a moins bien, mais c'est plus cher. You can also get less bang for more bucks. (translation F. Berjon)  -----------[000388][next][prev][last][first]---------------------------------------------------- Date: 21 Jul 1994 04:53:13 GMT From: bumble@hudson.cse.psu.edu (Marc David Bumble) To: comp.protocols.tcp-ip Subject: TCP/IP over atm performance measurement question?  We are running tcp/ip over an atm network. In addition to testing applications, we would like to take some meaningful network performance measurements. What types of network parameters are good to check and what is the best way of accessing these parameters? thanks, marc BAGnet Gigabit Testbed  -----------[000389][next][prev][last][first]---------------------------------------------------- Date: 21 Jul 1994 18:28:58 -0700 From: zeno@zebu.abstractsoft.com (Sean T. Lamont) To: alt.dcom.telecom.ip,comp.protocols.tcp-ip,comp.dcom.servers Subject: Re: Livingston Portmaster woes  In article <30ccu0$ls4@uxa.ecn.bgu.edu> mflll@uxa.ecn.bgu.edu (Dr. Laurence Leff) writes:
>We are having trouble setting up our account mechanisms on our Livingston
>Portmaster 2E.  It is running Version 3.0.1 of the software
>
>We need to support both SLIP users and login id's.

you may not have the port set up as a login / network port. To do this try:

set port s1 login network dialin

-Sean

--
Abstract Software                        |   Professional collection for NeXT
lamont@abstractsoft.com                  |____________________________________


-----------[000390][next][prev][last][first]----------------------------------------------------
Date:      21 Jul 1994 17:18:50 -0400
From:      brain@msen.com (Jim Brain)
To:        comp.protocols.tcp-ip
Subject:   SIGPOLL SIGIO on TCP on SunOS: Is it there?

I am starting development on a TCP/IP application, and I have heard that
on some systems, you can use the SIGIO/SIGPOLL signal to alert the app
to when data is in the TCP/IP pipe.  I am working on SunOS, so can
somoen point me in the right direction to learn if and how to do this on
SunOS (Solaris 1.1)

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


-----------[000391][next][prev][last][first]----------------------------------------------------
Date:      21 Jul 1994 12:57:40 GMT
From:      jfjr@mbunix.mitre.org (Freedman)
To:        comp.protocols.tcp-ip,comp.protocols.misc
Subject:   SIPP implementations


Since SIPP apparently is winning(won?) I would like to take a close
look at it. I am looking for an implementation (even a partial one)
for KA9Q NOS, Sun 4.1.x, BSD 4.4, or Linux. Anybody got one they want
to share.


-----------[000392][next][prev][last][first]----------------------------------------------------
Date:      Thu, 21 Jul 1994 13:56:11 GMT
From:      dtaylor@empros.com (Dave Taylor)
To:        comp.protocols.tcp-ip
Subject:   Re: Ethernet card in Promiscuous mode ..?

In article <30kiov$ko9@acsc.com>, rao@acsc.com (Rao Srinivasa) writes: |> |> Hi, |> |> Can some one let me know how to set Ethernet card in promiscuous mode |> on RS6000 machines ... |> |> Is it System/OS dependent ...? |> |> |> |> Thanks in advance ... |> Rao. |> |> RTFM. InfoExplorer "Ethernet Device Handler Overview" says: "Note: The Ethernet device handler does not support promiscuous addressing." (Although I understand that a future release will support it.) -- David K. Taylor dtaylor@empros.com Siemens Empros Power Systems Control (612) 553-4717  -----------[000393][next][prev][last][first]---------------------------------------------------- Date: 21 Jul 1994 10:58:53 +0200 From: schneck@GeNUA.DE (Bernhard Schneck) To: comp.protocols.tcp-ip,comp.os.linux.help,comp.dcom.lans.ethernet Subject: Re: tcpdump analysis prg?  mathias@solomon.technet.sg (Mathias Koerber) writes: >Now I wonder whether someone has already written some tools to do >analysis and statistics from the tcpdump output. Take a look at the NNStat package ... it doesn't work on top of tcpdump, though. -- Bernhard Schneck Bernhard.Schneck@GeNUA.DE Gesellschaft fuer Netzwerk- und Unix-Administration mbH Auslaender bleiben, Leoprechtingstr. 13, 81739 Muenchen, Germany Nazis vertreiben!  -----------[000394][next][prev][last][first]---------------------------------------------------- Date: 21 Jul 1994 15:07:06 GMT From: goli@rasii.rchland.ibm.com (Srinivas Goli) To: comp.protocols.tcp-ip Subject: Re: connect() and ECONNREFUSED  In article <1994Jul20.152819.17687@noao.edu>, rstevens@noao.edu (W. Richard Stevens) writes: |> One additional point upon rereading your posting ... it's possible |> to start a server three different ways on a BSD-based system: |> (1) accept any connection request to my port, (2) accept any |> connection request to my port that arrives on a particular local |> interface, and (3) only accept connections that arrive for my port |> that originate from a particular client IP address and port. Check |> out Section 18.11 ("TCP Server Design") of my "TCP/IP Illustrated" |> (Addison-Wesley, 1994) for additional details. |> |> Check that your server (which accepts the incoming connection from |> the client on the Ethernet) isn't started with either conditions |> (2) or (3) above. "netstat -a" should show you the status of the |> server's listening socket. |> |> Rich Stevens How about a concurrent server in the LISTEN state but its LISTEN queue full? I had once created a concurrent server which would accept requests from multiple clients and create a subserver to process the clients request. I was getting ECONNREFUSED for some of the requests while others were working fine. So the solution I used was whenever I get this error I would retry the connect function. It worked fine. Am I right in assumin that the the LISTEN queue was full. It was on ULTRIX but I am not sure about the version. -- \begindata{text,537360512} \textdsversion{12} \template{messages} \bold{Srinivas Reddy Goli,564545} \italic{(goli@rchland)} department 4a6 (BVT Team) IBM Rochester, Minnesota (507)253-3882 t/l 553-3882 \enddata{text,537360512}  -----------[000395][next][prev][last][first]---------------------------------------------------- Date: Thu, 21 Jul 1994 15:44:08 GMT From: rstevens@noao.edu (W. Richard Stevens) To: comp.protocols.tcp-ip Subject: Re: connect() and ECONNREFUSED  > | One additional point upon rereading your posting ... it's possible > | to start a server three different ways on a BSD-based system: > | (1) accept any connection request to my port, (2) accept any > | connection request to my port that arrives on a particular local > | interface, and (3) only accept connections that arrive for my port > | that originate from a particular client IP address and port. Check > | out Section 18.11 ("TCP Server Design") of my "TCP/IP Illustrated" > | (Addison-Wesley, 1994) for additional details. > > I assume your case (2) refers to bind()ing to the particular IP address > associated with one of your local interfaces. What this really does is > accept connections destined for said IP address, regardless of which > interface their SYNs arrive on. Although the difference is subtle, it > can be important in some multi-homed situations. Correct. > Case (3) is not one I've seen supported on typical BSD systems (at > least not intentionally :). Can you be more specific? You are right, this option is not typically found with BSD-based systems. (I must have been thinking of the RFC 793 OPEN, or the BSD UDP connect() scenario.) Indeed, when looking at the table in my book I see the parenthetical note "normally not supported"! Rich Stevens  -----------[000396][next][prev][last][first]---------------------------------------------------- Date: Thu, 21 Jul 1994 15:59:33 GMT From: exujlg@exu.ericsson.se (Jon L. Gauthier) To: comp.protocols.tcp-ip.ibmpc,comp.protocols.tcp-ip Subject: HP JetDirect card in HP4Si Mx printer?  We've been installing HP LaserJet 4Si printers with the HP JetDirect network interface card on our ethernet TCP/IP network for several months now. So far they've been performing flawlessly. Until now, they've all been installed on a single IP subnet (Actually, it's quite a large subnet - 2/3's of our PC network. Since only a few PCs are running TCP/IP, one class C subnet works fine.). They're all configured to use bootp, and it works great. I've got 2 bootp servers on that subnet, overkill, but we need the redundancy. But now, I have two new printers, each one on a different subnet. Our routers have the bootp helper protocol enabled, which works fine for all the PC users on each of those subnets. I get bootp requests from those PC fine, but I never see a single request from either printer, even though bootp is enabled. The only other difference I can see is that the JetDirect firmware on the working printers is version A.02.01, and on the new printers it is A.03.03. HP hasn't been of any help, so I appeal to the netgods for divine guidance...;^) ------------------------------------------------------------------------------ Jon L. Gauthier Ericsson Network Systems, Inc EXU/IS/N Sr. Systems Programmer P.O. Box 833875 +1 214 997-0157 Richardson, TX 75083-3875 e-mail: exujlg@exu.ericsson.se, exu.exujlg@memo.ericsson.se ------------------------------------------------------------------------------  -----------[000397][next][prev][last][first]---------------------------------------------------- Date: 21 Jul 1994 16:16:14 GMT From: swbarnes@slb.com (Simon Barnes) To: comp.protocols.tcp-ip Subject: TTL too small  Sorry if this is a FAQ, but how does one talk to hosts which are more than 30 hops away on the network? Ping works but other Unix programs such as telnet and sendmail either set the IP time-to-live to 30, or else allow it to default to 30. It's not big enough! Simon Barnes Geco-Prakla (Gatwick) swbarnes@slb.com  -----------[000398][next][prev][last][first]---------------------------------------------------- Date: 21 Jul 1994 22:58:25 -0400 From: m-sm0088@cs.nyu.edu (Srinivasu Mandava) To: comp.protocols.tcp-ip Subject: Interconnction 2 LANs using 2 leased lines ?  I need to interconnect 2 LANS using leased line and a pair of routers on either end. As a backup I plan to use 2 such pairs. I.e 2 routers on each LAN even though mean time between failures of a router is reasonably high. Are there any routers in the market which can do the following: 1. When both the lines are functional share the load i.e when both the lines are up the through put should be double that of a single line. 2. Interconnection should be maintained even if a line or a router is down. If I cannot achieve (1) , (2) is essential. Srinivasu Mandava m-sm0088@dopey.nyu.edu  -----------[000399][next][prev][last][first]---------------------------------------------------- Date: 21 Jul 1994 23:57:36 -0400 From: gt2540b@prism.gatech.edu (Tim Shelling) To: comp.protocols.tcp-ip Subject: Re: Security/Firewall FAQ?  bbosen@netcom.com (Bob Bosen) writes: >I hope somebody else will point you at an appropriate FAQ. In addition, >you might like to take a look at the animated tutorial software that >my company has made available for your VGA-equipped IBM PC. This >stuff teaches many important issues regarding firewalls, and it's >quite entertaining to watch. It's good for motivating your management >team on the importance and functionality of firewalls. It stresses >the kinds of firewalls that can positively identify the _people_ that >request access to your networks, as opposed to just filtering on >protocols. To see it, use anonymous ftp to go to: >ftp.netcom.com >Then cd to: >/pub/bbosen/Enigma/Tutorials/VGA/Grasp/Firewall >and >/pub/bbosen/Enigma/Tutorials/VGA/Grasp/Cisco There's absolutely nothing in Cisco. Just checked. >-- >Bob Bosen >Enigma Logic Inc. >2151 Salvio St. #301 >Concord, CA 94520 >USA >Tel: +1 510 827-5707 >Internet: bbosen@netcom.com >************************************************************************** >* "It wasn't me!!! Somebody must have captured my username/password!!!" * >************************************************************************** -- Ultimately, you believe all things because you want to believe you know. FH Argue for your limitations -- and sure enough -- they're yours. RB main(){write(0,"Tim Shelling, CmpE, Sr.\n" "gt2540b@prism.gatech.edu\n",50);}  -----------[000400][next][prev][last][first]---------------------------------------------------- Date: 21 Jul 1994 19:03:11 GMT From: shirono@ssd.csd.harris.com (Roberto Shironoshita) To: comp.protocols.tcp-ip Subject: Re: Problem: our net vs Internet  In article <30iaao$pbi@que.iphase.com> bfriesen@iphase.com (Bob Friesenhahn) writes:

> : >We are supposed to join the wonderful world of Internet
> : >connectivity. To  that end, we have a NetHopper router
> : >and a new upgraded account with  Netcom.
> : >
> : >However, we have a problem.
> : >
> : >The IP addresses are totally different from the IP
> : >address we have been  assigned from Netcom.
> : >
> : >QUESTION: Is there a way to resolve this problem
> : >without having to
> : >change the IP addresses on every single one of our PCs
> : >and UNIX boxes?
>
> This is solely a routing problem.  Your network must be an officially
> assigned subnet.  Also, you should obtain a domain name associated with
> your subnet.  Entries are then placed in the Internet DNS system which
> advertise the route to your subnet via Netcom.  Netcom should be able
> to handle this for you.

Note that the DNS has nothing to do with routing.  The routing information
is exchanged between the diverse routers in the Internet, and is based on
the IP addresses.  The DNS is a system that maps human-friendly domain
names to machine-friendly IP addresses (with a few other things thrown in,
like mail exchangers).

> In order to make it out of your subnet to the Internet, you will need
> to configure your hosts such that they know to route through your
> gateway for addresses outside of the local net.  A default route can
> work for this.

The reply to the original question depends on whether they are using an
assigned IP number.  If they are, then Netcom can add the network to their
routing tables, and that is it, insofar as people "outside" the LAN sending
packets to the LAN.  Then, a default route inside the LAN (pointing at the
Nethopper) would be sufficient to establish two-way communications.

If the LAN was using an un-assigned IP network number, then the only real
choice is to switch to the addresses given out by Netcom.
--

------------------------------------------------------------------------------
DISCLAIMER: The opinions expressed here are my own; they in no way reflect the
opinion or policies of Harris Computer Systems.

In-Real-Life:   Roberto Shironoshita
Harris Computer Systems
Internet:       Roberto.Shironoshita@mail.csd.harris.com
UUCP:           ...!uunet!mail.csd.harris.com!Roberto.Shironoshita


-----------[000401][next][prev][last][first]----------------------------------------------------
Date:      21 Jul 94 19:36:38 GMT
From:      fredn@sunriv.UUCP (Fred Nemecek)
To:        comp.mail.sendmail,comp.mail.misc,comp.protocols.tcp-ip,comp.unix.sysv386,sco.opendesktop,misc.misc
Subject:   Sendmail Help Needed...

Hello Netland,

I am in need of some help with my companies network
more specificly sendmail.  We have a small subnet
the connects to the internet through a FreeBSD PC
running SLIP.  My problem is with the SCO ODT machine,
I need it to deliver local mail to its self and send all
other mail to the FreeBSD machine to be resolved.  The SCO
machine should not be accessible by the outside world
and will receive its mail from the FreeBSD machine via
sendmail.

The system is currently working with the SCO machine doing
some of the resolving.  We have it setup using the /etc/hosts,
/etc/resolv.conf files, and have the routing as "route add default
FreeBSD_machine".  This is a bubble gum and bailing wire setup
at best.

I want to get rid of the /etc/resolv.conf or at least change it
to be simple so the routing is more direct.

Any and all assistance in this manner will be greatly
appreciated.  Flames are also well come, thats how desperate
I am.

root@defender.sunriver.com.

Thanks again...

Fred Nemecek
Technical Support MGR
SunRiver Corporation
(512) 835-8001 x125


-----------[000402][next][prev][last][first]----------------------------------------------------
Date:      21 Jul 1994 20:35:57 GMT
From:      grpjl@iastate.edu (Paul J Lustgraaf)
To:        comp.protocols.tcp-ip
Subject:   Re: TTL too small

In article <30m70e$l1d@gorgon.gatwick.geco-prakla.slb.com>, Simon Barnes <swbarnes@slb.com> wrote: > >Sorry if this is a FAQ, but how does one talk to hosts which are more than >30 hops away on the network? Ping works but other Unix programs such as telnet >and sendmail either set the IP time-to-live to 30, or else allow it to default >to 30. It's not big enough! Buy some modern software? (:-) -- Paul Lustgraaf "It's easier to apologize than to get permission." Network Specialist Grace Hopper Iowa State University Computation Center grpjl@iastate.edu Ames, IA 50011 515-294-0324  -----------[000403][next][prev][last][first]---------------------------------------------------- Date: Thu, 21 Jul 1994 21:59:11 GMT From: drubin@poly.edu (Dave Rubin) To: comp.sys.sun.apps,comp.protocols.tcp-ip,comp.protocols.snmp,comp.dcom.lans.ethernet Subject: Modeling of Network Routing?  I am interested in an environment that would allow modeling of network routing behavior, specifically with OSPF. I would like to create a representation of a specific network topology, ideally in a graphical fashion using a tool such as SunNet Manager. Based on OSPF, the system should be able to identify the routes between various points on the network. Then, I would like to analyze various "what if" scenarios, to see how the routing in the network would be affected by, for example, a router failure. The goal is to identify potential problems and bottlenecks BEFORE the actual network is deployed. Does anyone know of any software, or SunNet Manager add-on, that would do this or some form of network routing modeling? If not, can you point me in the right direction? Thanks ... please respond via E-mail. -- Dave Rubin E-mail: drubin@poly.edu Polytechnic University Phone: (718) 260-3212 Brooklyn, NY FAX: (718) 260-3930  -----------[000404][next][prev][last][first]---------------------------------------------------- Date: 21 Jul 1994 22:40:59 GMT From: carlos@m3isystems.qc.ca (Carlos Perez) To: comp.protocols.tcp-ip,comp.unix.admin Subject: Addresing scheme  My company has branch offices in Chicago, and Pittsburgh. We are part of the Internet in Montreal, Canada. I'm looking for some advice on how to link our branch offices to Montreal. o Would it be a good idea to set up a PPP box in the branch offices and use a private phone line? This way branch offices will be under my domain name and I 'll assign them IP addresses. Will the telecom cost prohibit this scheme? o Would it be better to use a local organization to provides Internet access to the branch offices?. Will they need their own IP adddresses or will the branch offices appear as another node of the Internet service provider? o Any references for Internet services providers in Chicago and Pittsburgh will be appreciated. Where can I get the form to register a domain and request for class C addresses in the US. ================================================================== Carlos Perez carlos@M3iSystems.QC.CA Systemes M3i Inc., 1111, rue St-Charles ouest phone: (514) 928-3386 x-2478 Longueuil, J4K 5G4, Quebec fax: (514) 442-5076 ==================================================================  -----------[000405][next][prev][last][first]---------------------------------------------------- Date: 22 Jul 1994 02:55:29 GMT From: eel@auspost.com.au (Elena Leong) To: comp.protocols.tcp-ip Subject: OSPF on gated  Hi, I trying to implement OSPF using gated on a mesh network of 7 separate LANs - each network has a Primary rate ISDN connection, this is connected to an Ascend access router, which allows us to individually dial every other network from this one ISDN connection - if we didnt have the Ascend router, we would have 6 ISDN connections at each instead. Anyway, the documentation on gated I find hard to understand, and I cant find any examples of what I am trying to do. I have a copy of the O'Reilly book TCP/IP Network Administration with info on gated, but their gated version doesnt have OSPF. Can a kind soul point me to any documentation or books that would tell me how to configure OSPF on gated? Thanks in advance Elena. ============================== Elena Leong System & Network Administrator EDIPost Australia Post ==============================  -----------[000406][next][prev][last][first]---------------------------------------------------- Date: Fri, 22 Jul 94 10:36:51 PDT From: adar0@routers.com To: comp.protocols.tcp-ip,comp.protocols.ppp Subject: Re: routing on SunOS (with dp2.3) for remote PPP users?  > King Rhoton (king@acpub.duke.edu) wrote: > > > I'm having trouble setting up cslip-2.7 on SunOS 4.1.3. I can get > > > the line to answer and go into SLIP mode, and my remote station > > > (running Trumpet Winsock) can use TCP/IP to the host directly, but > > > they can't see any hosts outside the local domain. FTP, Mosaic, > > > etc., just time out when they try to connect to a distant host. > > > > > > I think its something to do with routing, but I'm not sure. How > > > should routing be set up on the host to which SLIP users dial in? > > > > > > Routing tables > > > Destination Gateway Flags Refcnt Use Interfa > > ce > > > localhost localhost UH 4 17440 lo0 > > > 199.123.192.10 parts UH 1 33 sl0 > > > default 199.123.192.1 UG 3 6342 le0 > > > 199.123.192.0 parts U 2 308 le0 > > > > > > So, .10 can talk to parts and TCP/IP services on parts, and parts > > > can talk to things like ftp.uu.net and www.ncsa.uiuc.edu, etc., > > > but .10 can't talk to ftp.uu.net, etc. > > I'm having the exact same problem, only with PPP connections instead of > > slip. I'm entirely baffled. I've set up an arp entry for my remote > > machine, and from the remote machine ping requests to non-dialup-hosts do > > go through the PPP link (I see the tx led flicker), but I never get > > anything back. I have full access to the dialup host, though. I've tried > > both Linux (with PPP 2.1.2a) and a Mac (with MacPPP 2.0.1) as clients, and > > they behave the same. It's got to be something in the Sun's > > configuration, but I'm out of ideas. SunOS 4.1.3 and dp2.3pl2. > > Same problem here to. We can reach host on the local net but nothing > outside that. Would gated or routed have to runn to allow these connections? > Anybody got a tip? Thanks! > It sounds like all three of you have basically the same problem. Its a routing issue in that the Sun host has sufficient knowledge to know where to send packets that are not destined for him. The Sun learns about connected or accessible networks either by being told by other systems and routers via some routing protocols, or, by someone setting a "default route" within the Sun to point to a system or router external to the Sun that DOES know how to reach connected or accessible networks. Either way will work. If the Sun is attached to an Ethernet network with other systems and routers, you can add the '-s' option to the in.routed startup located in /etc/rc.local file. This will force the Sun to transmit and listen to a routing protocol called RIP (the only routing protocol understood by in.routed). If your site does not use the RIP protocol, then your choices are either to run gated or install static routes manually. The gated software understands other routing protocols, however in order for you to have any chance at all in making it work, you need to know exactly what types of routing protocols your company uses. Gated is not easy to set up. If the Sun connects to a terminal server, terminal servers sometimes have parameters to turn on/off the transmission of RIP packets on the serial line. Most Internet providers will charge you to turn this software function on. When it is turned on, then the Sun will listen to the RIP packets and build dynamic routing tables for you. If you cannot make in.routed work, or, if your site does not support RIP, then you will need to install a static default route on the Sun to at least let the Sun know what to do with packets that are not his. See the Sun man pages for the exact syntax; it is something like: route add default [network] [gateway] You can also experiment with other forms of static routes to force the Sun to send all packets that are not his to a gateway (router) that does know how to route your PC packets. If you have arbitrarily picked an IP address and netmask for your PC's, you might have someone that understands your site's network configuration review these to be sure they are consistent with the overall network. There are possibilities that picking wierd addresses and netmasks could also cause the same syptoms. Hope this helps some. If you need more help, send an email with details on all addresses, netmasks, backbone info, etc. Rich Adamson adar0@routers.com  -----------[000407][next][prev][last][first]---------------------------------------------------- Date: 22 Jul 1994 10:54:19 -0400 From: lrogers@oasys.dt.navy.mil (Larry Rogers) To: comp.protocols.tcp-ip Subject: RIP-OSPF Conversion  Hi, I am looking for a router that supports a RIP network on one interface and an OSPF network on a second interface. The key is that the translation from OSPF to RIP must retain the advertisement of multiple subnets of a Class B. The RIP OSPF to RIP conversion must not aggregate the subnets into the larger Class B. Example: RIP OSPF 10.10.5.0 10.10.5.0 10.10.6.0 10.10.6.0 NOT 10.10.0.0 If you know of a mainstream stand alone implementation please let me know. Larry  -----------[000408][next][prev][last][first]---------------------------------------------------- Date: 22 Jul 94 06:55:15 GMT From: yc23@uk.co.gec-mrc (Trevor Wright) To: comp.protocols.tcp-ip,comp.sys.ibm.pc.hardware.networking Subject: Sun PC-NFS 5.1 License Violation Detection - Cisco setup problem?  Having installed the new 5.1 release of Sun PC-NFS, we immediately get a License Violation Detection - with the indicated 'other' machine being the one we are on. It seems Sun have changed the LVD broadcast from all F's to xxx.xxx.xxx.255 where the x's are your local class C subnet - if this is the way your net is formed. Sun are being most helpful but at present we are the only customer with the problem - everyone else is OK. There was one customer a while back - who thought it was some problem with the setup of some Cisco routers, leading to a reflection of the LVD broadcast packet. We can't get in touch with him at present. Would any users with knowledge of this problem please sound out. We will publish the fix to the problem when found for the benefit of others. Apart from this problem 5.1 looks fine. Trevor Wright Operations Manager Computer Resources Dept. -- Trevor Wright,Computer Resources | Tel: +44 245 473331 x 3224 + Answerphone GEC-Marconi Research Centre | Fax: +44 245 475244 or 478639 GEC-Marconi Ltd, Great Baddow | uucp: <world>!uknet!gec-mrc!wright Chelmsford,Essex. UK CM2 8HN | Other: wright@gec-mrc.co.uk  -----------[000409][next][prev][last][first]---------------------------------------------------- Date: Fri, 22 Jul 1994 11:56:07 From: kcroll@iac.net (Kenneth Croll) To: comp.protocols.tcp-ip Subject: tcpdump on sVr4?  Does anyone know if tcpdump will run on Unix sVr4? I have collected the files to make tcpdump from the Internet, but the documentation only seems to refer to BSD flavors of Unix. Since it comes from Lawrence Berkeley Labs I guess they favor BSD. I thought I would ask if anyone had used this product on AT&T Unix before I took the time to compile and test this thing.  -----------[000410][next][prev][last][first]---------------------------------------------------- Date: 22 Jul 1994 20:08:37 -0700 From: cgi@crl.com (Paul Smith) To: comp.protocols.tcp-ip Subject: Re: TCP/IP Source Code  Edward Milczarek (edward@ece.concordia.ca) wrote: : I would like to get the source code for the various TCP/IP : functions. I would be grateful if someone can help me out. Get a copy of one of the MANY free (or real cheap) Unixes out there; FFreeBSD, Linux etc that come with source.  -----------[000411][next][prev][last][first]---------------------------------------------------- Date: 22 Jul 1994 20:13:47 -0700 From: cgi@crl.com (Paul Smith) To: comp.protocols.tcp-ip Subject: ??NPI/TP0 Streams info??  I have the task of writing a streams module on Unix SVR4.2 to host the NPI/TP0 interface to an OSI upper layer(s). Where can I get understandable DOC for the NPI etc interface?? Does anyone have sample, working NPI streams module (SVR4.2 or any other ??) source?? Any help or advice. Thanks...  -----------[000412][next][prev][last][first]---------------------------------------------------- Date: 22 Jul 1994 20:15:25 -0700 From: cgi@crl.com (Paul Smith) To: comp.protocols.tcp-ip Subject: ??NPI/TP0 Streams Mod. Source??  I'm looking for a streams module that delivers NPI+TP0 for hosting OSI upper layer services. The target is SVR4.2 or any SVR4.x. Thanks.  -----------[000413][next][prev][last][first]---------------------------------------------------- Date: 22 Jul 1994 16:59:40 -0400 From: brain@msen.com (Jim Brain) To: comp.protocols.tcp-ip Subject: Just can't get TCP/IP Client-Server down...  I really need a person to sit with me and help me through this stuff with TCP/IP. The books I am reading assume I know what is going on, and I do not. I need to implement a C/S prg, and I am stumped. Notable questions: My server program only needs to respond to one client, but there may be multiple copies of my server running. I want all the servers to use the same port, and all the clients could be on one machine. Can they all use that port? Or do they need to request a new port for all subsequent traffic from client, so that more clients can talk on the original port number? I want to use UNIX inetd server to run my code. However, my server code needs some parms to be passed to it. Can I pass those through inetd somehow? I am looking at ftpd explanations to help me understand this, but it isn't easy. For one thing, I just can't understand what inetd is doing. I know it listens on all the ports in the inetd.conf file, and does a select on all the socket handles, but that is as far as I get. Let me explain: Suppose inetd is running on machine A. A person at machine B wants to run ftp. Another person on machine B wants to run ftp. The first ftp request comes in on port 21. inetd select call comes out and (I assume spawns a shell that runs ftpd, and maps the socket into stdin and stdout) runs ftpd. ftp and ftpd then open a new connection between ftp and port 20. Now, here is where I am stumped. If they continue to use 21 and 20, wont the inetd select call keep popping? Does ftp and ftp allocate two new sockets on the server end to use, which inetd is not listening on? The next ftp request comes in. I assume inetd is listening for it, but if it is listening on the next ftp request, it must not be listening to the old ftp request any longer. How is that? I am stumped. This is preceisely the scenario my server needs to operate, and I am more confused as I go on. HELP..... -- Jim Brain, Embedded Systems Designer, Brain Innovations. brain@msen.com Dabbling in VR, Old Commodore Computers, and Good Times! "The above views DO reflect my employer, since I am my employer" - Jim Brain  -----------[000414][next][prev][last][first]---------------------------------------------------- Date: 22 Jul 1994 17:29:39 -0400 From: ezy@panix.com (Ezra Story) To: comp.protocols.tcp-ip Subject: Re: Just can't get TCP/IP Client-Server down...  In article <rN1CkmoZjGZJ064yn@msen.com>, Jim Brain <brain@mail.msen.com> wrote: > >The first ftp request comes in on port 21. inetd select call comes out and >(I assume spawns a shell that runs ftpd, and maps the socket into stdin and >stdout) runs ftpd. ftp and ftpd then open a new connection between ftp and >port 20. > >Now, here is where I am stumped. If they continue to use 21 and 20, wont >the inetd select call keep popping? Does ftp and ftp allocate two new >sockets on the server end to use, which inetd is not listening on? The key to all this is that sockets that are being used to listen for connections are never used for the connections themselves. Every time accept() is called on the server socket (sitting at port 21, for example) a -new- socket is created for that connection. So, what inetd does, is open up a socket, bind it to port 21 and listen for connections. When a connection attempt comes in, it accept()s on that socket, which creates a new socket that refers to the new connection..and calls ftpd. After the accept() the server socket (on port 21) is free to accept more connections. -- | Ezra Story | ezy@panix.com | Ezy (IRC) | *********************** | | Penguins! Get yer ice cold penguins here! Free alien monster | | with every purchase! Money back guarantee! | +++++++++++++++++++ |  -----------[000415][next][prev][last][first]---------------------------------------------------- Date: Sat, 23 Jul 94 00:19:00 -0700 From: philip.burton@spacebbs.com (Philip Burton) To: comp.protocols.tcp-ip Subject: PCs as IP routers  Does anyone have experience with PC-based TCP/IP packages that can do IP routing? under DOS? under Windows? What kind of machine is necessary for what level of performance? Can I used a dusty old '286 with 1 MB RAM for a DOS-based router? What about Windows? Intuitively performance should be better under DOS than Windows? Any experience here? Which protocols are supported? Any experience with a PC-based router talking to a Wellfleet or Cisco? Thanks in advance. Phil Burton -- Phil Burton -- philip.burton@spacebbs.com - Palo Alto, CA - --- þ CMPQwk #1.4þ UNREGISTERED EVALUATION COPY  -----------[000416][next][prev][last][first]---------------------------------------------------- Date: Fri, 22 Jul 1994 12:54:43 GMT From: ccadda@beluga.upe.ac.za (Daryl Anderson) To: comp.protocols.tcp-ip Subject: Re: "easy" bootp question  Helo, You have hit the same problem as quite a few people. I develope the NCSA code and have fixed BOOTP, amoungst other things. You can mail me but I am finding support difficult when I uuencode and send executables all around the globe. I have feed back that it does not work, when in fact we use it on campus for all our DOS Telnet/Ftp needs :-(. Also my configuration files will be different to everone elses, so thats another source of problems, although I have made the TCP/IP kernel configuration file independant. You can mail me or sit tight and wait for my announcement. I have just set up an anonymous FTP site on campus, and will make available my binaries and source. I have Telnet working, ftpbin, finger and a few surprises :-). Regards Daryl It is of course true that the older versions work. Little functionality was added to the 2.3.07 release. If you look at the code it was more like disfunctionality. This last comment was NOT meant to offend the official NCSA developer. If it did, sorry Ryan. >Ross Hayden (ross@ndlc.occ.uky.edu) wrote: >| Hi all! >| I have been struggling to get bootp working on several unix system here on >| campus, with little luck. >| I have several DOS pc's running NCSA telnet, along with the packet drivers >| needed to run it on top of my netware drivers (ie odipkt.com). On my unix >| systems I've installed various versions of CMU's bootp package. The >| problem seems to be that replies from the server are never reaching the >| workstations. The bootp server starts on queue, and tcpdump also >| indicates this and shows the reply being sent. The pc, however, just sits >| and continually resends requests as if never having received a reply. >| If I hard code an IP address into the config file for NCSA telnet, >| everything works ok. Also, I can't get rarp to work either. So I'm not >| really sure if I need to examine my network setup, or if there's a problem >| with NCSA telnet. I've examined my network setup, checking out subnet >| masks and broadcast addresses. >| Any ideas on what to check here? I'm stumped. >| Thanks for any help, >| Ross >| -- >| Ross Hayden, Systems Programmer ross@ndlc.occ.uky.edu >| The National Distance Learning Center >I just helped somebody else with the same problem. It seems that >NCSA-stuff V2.3.07 doesn't groc the bootpd answer. I'm running >V2.3.03 (aka V2.3b) and I have no problems. >-- > _____________________________________________________________________________ > Hans de Hartog, dehartog@comcons.nl, Voice: +31 348033100, Fax: +31 348033181 > Committed Consultancy BV, Korenmolenlaan 1b, 3447 GG Woerden, The Netherlands > Home: dehartog@kwetal.comcons.nl, Voice/Data: +31 838038560, CIS: 100121,3301 +--------------------------------------------------------------------+ Daryl Anderson Internet: ccadda@beluga.upe.ac.za Network Consultant Tel: +27 41 5042321 University of Port Elizabeth Fax: +27 41 5042574 "A program that works first time contains a more subtle bug" - DLS +--------------------------------------------------------------------+  -----------[000417][next][prev][last][first]---------------------------------------------------- Date: 22 Jul 1994 13:23:06 GMT From: tzs@u.washington.edu (Tim Smith) To: comp.protocols.tcp-ip Subject: IP address for a local network?  I'm going to be connecting a Mac and a PC together via ethernet. They will be the only things on the ethernet, and shall communicate via TCP/IP. If this were the end of the story, I would suppose that I could just pick any IP addresses I wanted for these two machines (as long as they match in the network portion of the address, of course). However, there is a slight complication. These machings aren't quite isolated. The Mac occassionally establishes a SLIP connection over a modem to a commercial SLIP provider so that it can fetch news from an NNTP server (and sometimes so I can FTP things). When that connection is established, it is given an IP address that is not fixed--I get a different one each time I call. In such an environment, how should I obtain IP addresses for use on my ethernet? Do I have to obtain an offical network number, or is there something "safe" I can use? --Tim Smith  -----------[000418][next][prev][last][first]---------------------------------------------------- Date: 22 Jul 1994 15:07:08 GMT From: tzs@u.washington.edu (Tim Smith) To: comp.protocols.tcp-ip Subject: Re: IP address for a local network?  I wrote: >I'm going to be connecting a Mac and a PC together via ethernet. They ... >However, there is a slight complication. These machings aren't quite >isolated. The Mac occassionally establishes a SLIP connection over a >modem to a commercial SLIP provider so that it can fetch news from an ... >In such an environment, how should I obtain IP addresses for use on my >ethernet? Do I have to obtain an offical network number, or is there >something "safe" I can use? Based on email I've received, I seem to have left out something that is important. The Mac is running A/UX, and the PC will be running Linux or FreeBSD when it is running TCP/IP. The email I received pointed out that I might have problems on the Mac because the IP software for the Mac OS apparently does not like the idea of being connected to different networks by different ports at the same time. A/UX should have no problem in that area. --Tim Smith  -----------[000419][next][prev][last][first]---------------------------------------------------- Date: Fri, 22 Jul 94 16:37:19 GMT From: lff@sequent.com (Lou Fernandez) To: comp.protocols.tcp-ip Subject: Re: Techniques for finding dead nodes in a WAN.  In article <30evqu$p56@access1.digex.net>,
S.Goutham <goutham@access1.digex.net> wrote:
>Can anyone point me in the right direction for constantly checking, say
>every 5 minutes, what nodes are down/up in a network.

Since you mentioned WAN, I'll assume that you are talking about a
network in which the nodes are connected to each other through

I suggest you have each node continuously verify that it can communicate
with each of its neighboring nodes and report a failure if it can't.  If
a single link fails, both nodes at its endpoints will report that it
failed.  If a node fails, all of the node's neighbors will report that
links to that node failed.  At the management system, analyze the link
failure reports to decide whether a node has failed or a link has
failed.

Note that if a node is connected to the rest of the network through only
one link, if communication stops, you can't tell whether the link failed
or the node failed.  However, this is true for any in-band management
strategy.

I would also have each node report its operational state to the
management system at a slow rate, say every few minutes.  This allows
you to catch failures where the node is keeping its links up but is
otherwise failing to do work.  You could also have the management
station poll each node periodically.  This would double the amount of
management traffic but would allow the management system to control the
rate.

Good luck,
...Lou
--
Louis F. Fernandez			Sequent Computer Systems
lfernandez@sequent.com			Beaverton, OR 97006-6063


-----------[000420][next][prev][last][first]----------------------------------------------------
Date:      Fri, 22 Jul 1994 17:27:35 GMT
From:      bjork@telebit.com (Steven Bjork)
To:        comp.protocols.tcp-ip
Subject:   Re: TTL too small

In article <30m70e$l1d@gorgon.gatwick.Geco-Prakla.slb.com> swbarnes@slb.com writes: >Sorry if this is a FAQ, but how does one talk to hosts which are more than >30 hops away on the network? Ping works but other Unix programs such as telne >Simon Barnes The current RFC specifies a ttl of 64, I think. On an earlier sunos you had to adb vmunix and search for something like _tcp_ttl and set it that way. Newer sunos does something different. ../Steven  -----------[000421][next][prev][last][first]---------------------------------------------------- Date: 22 Jul 1994 18:24:38 GMT From: raj@cup.hp.com (Rick Jones) To: comp.protocols.tcp-ip Subject: Re: TTL too small  Simon Barnes (swbarnes@slb.com) wrote: : Sorry if this is a FAQ, but how does one talk to hosts which are : more than 30 hops away on the network? Ping works but other Unix : programs such as telnet and sendmail either set the IP time-to-live : to 30, or else allow it to default to 30. It's not big enough! It probably depends on which software you are running. rick jones  -----------[000422][next][prev][last][first]---------------------------------------------------- Date: 22 Jul 1994 17:38:36 +0100 From: maral@csv.warwick.ac.uk (Mr A C Rocha) To: comp.protocols.tcp-ip Subject: FAQ ???  Can anybodu tell me where is the FAQ for this newsgroup please ?? Cheers, andre  -----------[000423][next][prev][last][first]---------------------------------------------------- Date: 22 Jul 1994 19:41:59 GMT From: parprods@ecn.uoknor.edu (Dorwin Shields) To: comp.protocols.tcp-ip Subject: Help with htons, htonl--problem with a sun  Hi --I'm working on a distributed mandelbrot program--the program works using stream sockets , and select between to linux pc's and an alpha machine--but when I try to add a sun the program dies--it seems that the sun gets garbled data--I read and write on the streams using the read and write calls--do I need to use htonl and htons--if so How?--I'm sending arrays of integers and doubles over the sockets--thanks for any help--Dorwin  -----------[000424][next][prev][last][first]---------------------------------------------------- Date: Fri, 22 Jul 1994 20:28:22 GMT From: piercarl@sabi.demon.co.uk (Piercarlo Grandi) To: comp.protocols.tcp-ip Subject: Re: Routing localnet <--> SLIP-provider?  >>> On 18 Jul 1994 21:09:44 +0100, dehartog@kwetal.comcons.nl (Hans de Hartog) said: Hans> My setup is as follows: [ ... a linux box with two interfaces: a slip one with an officially assigned number, and one on an ethernet with a bunch of PCs with "invented" numbers ... ] Hans> However (and that's the problem), when the SLIP-connection exists, Hans> I want the dos-pc's also be able to acces the Internet (at least Hans> telnet). You have two stark choices: never ever route at the TCP/IP level, and keep the two interfaces isolated (I dearly hope that you are not running with IP forwarding enabled), and use application level gateways, or requesting an official class C network number, register your domain with the DNS, and start IP forwarding between the slip and the ethernet interfaces, having set up routing somehow (statically, as suggested in another followup, or using gated). If you go for application level gatewaying you need proxy daemons on the Unix machine. Something like that is readily available from ftp.tis.com, under /pub/firewalls, and several other places.  -----------[000425][next][prev][last][first]---------------------------------------------------- Date: 22 Jul 94 21:36:17 GMT From: ddl@harvard.edu (Dan Lanciani) To: comp.protocols.tcp-ip Subject: Re: connect() and ECONNREFUSED  In article <1994Jul21.154408.3307@noao.edu>, rstevens@noao.edu (W. Richard Stevens) writes: | > Case (3) is not one I've seen supported on typical BSD systems (at | > least not intentionally :). Can you be more specific? | | You are right, this option is not typically found with BSD-based systems. | (I must have been thinking of the RFC 793 OPEN, or the BSD UDP connect() | scenario.) Indeed, when looking at the table in my book I see the | parenthetical note "normally not supported"! Well, see, you should always carefully read your book before posting. :) Seriously, what BSD system does implement this? (There must be at least one for it to make it into the table...) It is a potentially useful feature. Dan Lanciani ddl@harvard.*  -----------[000426][next][prev][last][first]---------------------------------------------------- Date: 23 Jul 1994 00:22:21 GMT From: masaru@lis.pitt.edu (Masaru Okuda) To: comp.protocols.tcp-ip Subject: [Q] Broadcast/Multicast  How does TCP react to a corrupted broadcast/multicast message? Does the source retransmit the message as a point-to-point addressing mode? What would happen if tans of retransmission requests arrived? Masaru  -----------[000427][next][prev][last][first]---------------------------------------------------- Date: Sat, 23 Jul 1994 04:55:56 GMT From: ibottema@alkaid.sce.carleton.ca (Ike Bottema) To: comp.protocols.tcp-ip Subject: ICMP Subnet Mask Request/Reply  Can anyone confirm whether cisco and/or Wellfleet (or for that matter other router vendors) will respond to a ICMP Subnet Mask Request with the proper Subnet Mask Reply as specified in RFC 950? I understand that many products do not implement all ICMP messages. Ike Bottema  -----------[000428][next][prev][last][first]---------------------------------------------------- Date: Sat, 23 Jul 94 18:45:32 EST From: stein@gcomm.com To: comp.protocols.tcp-ip Subject: Ephemeral ports  Anyone know how one might use Berkeley Sockets API to determine a good ephemeral port number to use before instigating the passive side of a TCP connection? This is required when implementing an FTP client to fill in the last 2 of the 6 parameters of the PORT command. The client has to passively listen() for the data connection that the server actively makes with connect(). But the client is supposed to specify a "non-default data port before each transfer command is used" (RFC 1123, Host Requirements, 4.1.2.5). How does the client ask its API to cough up an ephemeral port number that isn't currently in use, and that isn't in the TIME_WAIT state? -- Bob Stein Internet mail: stein@gcomm.com ______________________________________________________________________ | | | Galacticomm, Inc. (305) 583-5990 (voice) | | 4101 SW 47 Avenue, Suite 101 (305) 583-7846 (FAX) | | Ft Lauderdale, Florida, USA, 33314 (305) 583-7808 (BBS) | |______________________________________________________________________| -- ============================================================================== | ... The Galacticomm Demo System - 305/583-7808 - Home of The Major BBS ... | ==============================================================================  -----------[000429][next][prev][last][first]---------------------------------------------------- Date: 23 Jul 1994 20:41:02 GMT From: darrell@cse.ucsc.edu (Darrell Long) To: comp.protocols.tcp-ip Subject: Mobile94 Workshop --- deadline 8/20  CALL FOR PARTICIPATION WORKSHOP ON MOBILE COMPUTING SYSTEMS AND APPLICATIONS DECEMBER 8-9 1994 DREAM INN, SANTA CRUZ, CA Sponsored by the IEEE Computer Society TCOS (in cooperation with ACM SIGOPS and USENIX Association) General Chair Darrell Long, University of California, Santa Cruz Program Chair M. Satyanarayanan, Carnegie Mellon University Exhibits Peter Honeyman, University of Michigan Finance & Registration Richard Golding, Hewlett-Packard Publication Luis-Felipe Cabrera, IBM Almaden Program Committee Dan Duchamp, Columbia University Peter Honeyman, University of Michigan Randy Katz, UC Berkeley & ARPA Jay Kistler, DEC SRC Krishan Sabnani, AT&T Holmdel M. Satyanarayanan, Carnegie Mellon University Amal Shaheen, IBM Austin Marvin Theimer, Xerox PARC Rich Wolff, Bellcore A major challenge of this decade is the effective exploitation of two symbiotic technologies: portable computers and wireless networks. Harnessing these technologies will dramatically change the computing landscape. But realizing the full potential of the resulting mobile computing systems will require advances in many areas such as: hardware communications scalability power management security data access user interfaces location sensitivity The goal of this workshop is to foster exchange of ideas in mobile computing among workers in the field. Attendance will be limited to about 60 participants, based on the position papers submitted. Submissions should be fewer than 5 pages in length and may expose a new problem, advocate a specific solution, or report on actual experience. In addition, we will be hosting a small number of novel hardware and software exhibits relevant to mobile computing. The exhibits may be research prototypes or commercial products. Interested parties should submit technical descriptions of their exhibits. Online copies of the position papers will be made available via anonymous FTP prior to the workshop. A printed proceedings will be published after the workshop, and mailed to participants. A small number of graduate students will be granted a waiver of the registration fee. In return, these students will be required to take notes at the workshop and help put together the proceedings. Students who wish to be considered for the waiver must send in a brief description of their current research, and an explanation of how participation in the workshop is likely to help them. Send 10 copies of position papers to: M. Satyanarayanan Email: satya@cs.cmu.edu School of Computer Science Phone: (412)-268-3743 Carnegie Mellon University Fax: (412)-681-5739 Pittsburgh, PA 15213 Send exhibit descriptions to: Peter Honeyman Email: honey@citi.umich.edu CITI Phone: (313)-763-4413 University of Michigan Fax: (313)-763-4434 Ann Arbor, MI 48103-4943 IMPORTANT DATES Submissions due August 20 1994 Acceptance Notification October 1 1994 Camera-ready copy due November 15 1994  -----------[000430][next][prev][last][first]---------------------------------------------------- Date: 24 Jul 1994 07:01:36 GMT From: tli@cisco.com (Tony Li) To: comp.protocols.tcp-ip Subject: Re: Interconnction 2 LANs using 2 leased lines ?  In article <30nckh$ett@dopey.cs.nyu.edu> m-sm0088@cs.nyu.edu (Srinivasu
Mandava) writes:
I need to interconnect 2 LANS using leased line and a pair of
routers on either end. As a backup I plan to use 2 such pairs.
I.e 2 routers  on each LAN even though mean time between failures
of a router is reasonably high.

Are there any routers in the market which can do the following:
1. When both the lines are functional share the load i.e when
both the lines are up the through put should be double that of
a single line.
2. Interconnection should be maintained even if a line or
a router is down.

If I cannot achieve (1) , (2) is essential.

Almost all routers on the market today can do (2).  Today, the problem is
finding hosts which are smart enough to figure out that their router died.
(1) is challenging because half of the hosts have to know to use each line.

Assuming that you have dumb hosts, and don't mind your packets taking an
extra LAN hop, you can do a credible job of approximating this by
designating one of the two routers as the "lead" router and having all
metrics so that both paths look to be equal cost _to the lead router_.

Tony


-----------[000431][next][prev][last][first]----------------------------------------------------
Date:      24 Jul 1994 07:05:00 GMT
From:      tli@cisco.com (Tony Li)
To:        comp.protocols.tcp-ip
Subject:   Re: ICMP Subnet Mask Request/Reply

In article <ibottema.774939356@alkaid.sce.carleton.ca>
ibottema@alkaid.sce.carleton.ca (Ike Bottema) writes:
Can anyone confirm whether cisco and/or Wellfleet (or for that matter other
router vendors) will respond to a ICMP Subnet Mask Request with the proper
Subnet Mask Reply as specified in RFC 950?  I understand that many products
do not implement all ICMP messages.

replies are pretty dangerous and are disabled by default.  You need to

Tony


-----------[000432][next][prev][last][first]----------------------------------------------------
Date:      24 Jul 1994 11:39:56 GMT
From:      sager@asys-h.de (Peter Sager)
To:        comp.protocols.tcp-ip
Subject:   Re: Just can't get TCP/IP Client-Server down...


The secret is that there is a difference between the LISTEN socket,
on which inetd is doing the SELECT, and which is bound to port 21
on the server machine, and the socket for the ftp control connection.
Every time a new connect-request comes in from a client, the TCP/IP
software on the server creates a new socket which is at this time
already connected to the foreign socket of the client, and puts it
onto the QUEUE OF INCOMING CONNECTIONS of the LISTEN socket.
The inetd process is notified of the new connection by means of
the select system call ("Something ready to read on the LISTEN socket")
Inetd then fetches the next incoming connection from the queue with
ACCEPT. Depending on the LISTEN socket, inetd recognizes "This is for ftpd"
from its configuration tables, and forks the ftpd process, handing the
socket fd of the CONNECTED socket over to the daemon on stdin/out.

But how can the system handle two sockets with identical local port number ?
The answer is, there can be more than one socket be associated with the same local port, provided that they can be distinguished by their foreign address/port.
Every incoming UDP or TCP-Packet carries its source address/port as well
(This is the one you gave the LISTEN socket with bind) AND a foreign address/port, if
it is connected. This way the system is able to find out the right socket
for incoming packets.

The actual mechanisms are more complicated, but from the API user's
view this info should be sufficient.

Douglas Comer                          Internet Networking with TCP/IP
Leffler/McKusick/Karels/Quarterman     The Design and Implementation of
the 4.3BSD UNIX Operating System

and of course in the sources of the NETBSD distribution.

o-----------------------------------------------------------o
|   Peter Sager                     sager@asys-h.de         |
|   Advanced Systems Software GmbH                          |
|   Vahrenwalder Strasse 7          VOICE: +49 511 9357390  |
|   D-30165 Hannover                FAX:   +49 511 9357100  |
o-----------------------------------------------------------o


-----------[000433][next][prev][last][first]----------------------------------------------------
Date:      Sun, 24 Jul 1994 14:28:05 GMT
From:      rstevens@noao.edu (W. Richard Stevens)
To:        comp.protocols.tcp-ip
Subject:   Re: Ephemeral ports

> How does the client ask its API to cough up an ephemeral port number that
> isn't currently in use, and that isn't in the TIME_WAIT state?

bind() a port number of 0.  If you then want to know the ephemeral
port that was assigned, call getsockname().

Rich Stevens


-----------[000434][next][prev][last][first]----------------------------------------------------
Date:      24 Jul 1994 17:01:08 GMT
To:        comp.protocols.tcp-ip
Subject:   1:Winsock.H->Pascal; 2:Telnet Startup Codes

Hi!
I have two questions; if U have 1 or 2 answers, jump in.
I'm starting to work with WinSock and I've managed to
make a small Telnet program, in less than an hour after
spending some 6 hours converting WINSOCK.H to a suitable
Borland Pascal Unit.

Q1: What are the sizes for C data types? What is the
difference between 'short integer' and 'integer' ?
I think their the same, but in some places it seems
more suitable to use a 'word' (unsigned integer) for
short integer...
Q2: When I logged into my account on a UNIX machine with
my fresh new Telnet program, I wasn't able to comunicate
with it, unless I sent the ascii codes 255, 252, 24 in
response to the 255, 253, 24 that I got on from the machine
on startup. The UNIX machine then sent me a few more
sequences of three byte codes started with 255, and I was

Email to a friends account: rupino@mercurio.uc.pt

TKS,


-----------[000435][next][prev][last][first]----------------------------------------------------
Date:      Sun, 24 Jul 1994 20:36:41 GMT
From:      aboba@netcom.com (Bernard Aboba)
Subject:   comp.protocols.tcp-ip.ibmpc Frequently Asked Questions (FAQ), part 1 of 3

Archive-name: ibmpc-tcp-ip-faq/part1

comp.protocols.tcp-ip.ibmpc:
FAQ Posting, part 1, 8/1/94

#################  Legalese #################

This document is Copyright (C) 1993,1994 by Bernard Aboba, except where
the copyright is retained by the original author(s). This document
may be distributed non-commercially, provided that it is not
modified in any way. However, no part of this publication may be
sold or packaged with a product for sale in any form without the
prior written permission of Bernard Aboba.

This FAQ is presented with no warranties or guarantees of ANY KIND
including correctness or fitness for any particular purpose. The
author(s) of this document have attempted to verify correctness of the
data contained herein; however, slip-ups can and do happen.  If you use
this data, you do so at your own risk. While we make every effort to
keep this FAQ up to date, we cannot guarantee that it is, and we will
not be responsible for any damages resulting from the use of the information
or software referred to herein.

Unless otherwise stated, the views expressed herein are my own.  Last
time I looked, I had not been appointed official spokesperson of any
of the following:

The Planet Earth
The U.S.Government
The State of California (not so good)
The University of California, Berkeley
The City of Berkeley (bringing you Riot of the Week(SM))
Publisher's Group West
Any major or minor breakfast cereal (not even oatmeal!)

This FAQ will be posted monthly. In between it will be
available as:
file://ftp.netcom.com/pub/mailcom/IBMTCP/ibmtcp.zip

################# HTML version goes online #################

This FAQ is now fully HTML compatible, and is
being automatically converted to HTML.
This means that if you have a WWW browser,

This is how I read the FAQ myself, and it is
highly recommended. To get at the HTML
version, use:
http://www.zilker.net/users/internaut/forth.html#upd

################# Citation entry  #################

This FAQ may be cited as:

Aboba, Bernard D.(1994) "comp.protocols.tcp-ip.ibmpc Frequently
file://ftp.netcom.com/pub/mailcom/IBMTCP/ibmtcp.zip,
57 pages.

################# Change History  #################

Changes from 7/1/93 posting:
FAQ now available in HTML format. Entries
changed in last two FAQs sport a *.

################# Related FAQs #################

There is a FAQ available on features of TCP/IP
Packages for DOS and Windows. This is available at:
file://ftp.cac.psu.edu/pub/dos/info/tcpip.packages.

The Windows Sockets Faq is posted to alt.winsock, and
is available at:
ftp://SunSite.UNC.EDU/pub/micro/pc-stuff/ms-windows/winsock/FAQ

The PC-NFS FAQ is available at:
file://seagull.rtd.com/pub/tcpip/pcnfs.FAQ.v1.4.Z or pcnfsfaq.zip
file://ftp.york.ac.uk/pub/FAQ/pcnfs.FAQ

The SNMP FAQ is regularly posted to comp.protocols.snmp

The TCP/IP FAQ is posted to comp.protocols.tcp-ip, and is
maintained by mailto:gnn@netcom.com.

The "How To Get It" FAQ on the Crynwr packet driver
collection is irregularly posted to comp.protocols.tcp-ip.ibmpc
by Russ Nelson, mailto:nelson@crynwr.com.

################# Book info  #################

A bunch of you have requested information on the
book I am working on.  Here is the basic info:

Title: The PC-Internet Connection, TCP/IP
Networking for DOS and Windows
Authors: Bernard Aboba and Britt Bassett
Pages: 800 (estimated), 7" by 9"
Distributor: Publisher's Group West
ISBN: 1-883979-00-5
Price: $32.95 (est), includes Chameleon Sampler software, WS-Gopher, PC-Eudora. Estimated release: October, 1994 To look at sample chapters from the book, check out the following WWW page: http://www.zilker.net/users/internaut/forth.html For those of in North America who *must* have a look at the book before it comes out, and are willing to comment on it, send me$25 to cover
copying and postage, and I'll send you a copy.
If you send back comments, I'll return the $25. Since this is a big book, be prepared to spend some time looking at it. For those outside North America, sorry but we're on a tight deadline, and so we will not be able to include you. ################# EXAMPLE CONFIG FILES ################# Many thanks to Dave Fetrow (fetrow@biostat.washington.edu) for creating an archive of setup files. The archive is particularly oriented toward sets of applications that are somewhat tricky, such as combinations involving different driver sets, mixtures of NetWare, TCP/IP, and W4WG, etc. Please include not only the setup and configuration files but some directions. Comments included with the setup files are highly desirable. The files can include your name if you desire. Please mail submissions to ftp@ftp.biostat.washington.edu. The archive itself is located at: ftp://ftp.biostat.washington.edu/ftp/pub/msdos/network.setups Late breaking development: the archive has crashed, and files have been lost. TABLE OF CONTENTS A. Components of a TCP/IP solution A-1. What do I need to run TCP/IP on the PC? A-2. What are packet drivers? Where do I get them? A-3. What is Winsock? Where can I get it? A-4. What is Trumpet Winsock? How do I get it to dial? A-5. What publicly distributable TCP/IP applications are there for DOS? Windows? A-6. What software is available for doing SLIP? Compressed SLIP? PPP? For DOS? For Windows? A-7. What about the software included with various books? A-8. What diagnostic utilities are available to find problems with my connection? Where can I get them? A-9. Is there a CD-ROM with the software included in this FAQ? A-10. Does Windows NT support SLIP? PPP? A-11. Where can I take a peak at the WFW v3.11 VxD beta? A-12. How do I get my BBS to run over TCP/IP? A-13. Are there graphical TCP/IP servers out there? A-14. What methods of dynamic address assignment are available? A-15. How can I set up PPP server on a UNIX host? A-16. What is WinSNMP? B. Questions about drivers B-1. What do I need to know before setting up SLIP or PPP? B-2. How do I configure SLIPDISK? B-3. How do I install packet drivers for Windows applications? B-4. When do I need to install WINPKT? B-5. How to do I run both WinQVT and ODI? B-6. Is it possible to use BOOTP over SLIP? B-7. How do SLIP drivers work? B-8. When do I need to install PKTMUX? B-9. Can NDIS be used underneath multiple protocol stacks of the same type? B-10. Is there an NDIS over packet driver shim? B-11. How do I run NetBIOS over TCP/IP? B-12. How do I run NFS and another TCP/IP application? B-13. How do I run Trumpet Winsock along with KA9Q or NFS? B-14. Sample Stick Diagrams B-15. Strange and wonderful configuration files submitted by readers C. KA9Q Questions C-1. What version of KA9Q should I use and where do I get it? C-2. What do I need to run KA9Q? Why won't it do VT-100 emulation? C-3. How do I configure KA9Q as a SLIP dialup connection? C-4. How do I configure KA9Q as a router? C-5. How do I get KA9Q to support BOOTP? C-6. How do I get KA9Q to support PPP? C-7. How do I get KA9Q to support SLIP dialin? C-8. Can I use KA9Q as a packet filter? D. Hints for particular packages D-1. How do I get DesQView X to run over the network? D-2. Why is NFS so slow compared with FTP? D-3. Where can I get information on running NetWare and TCP/IP concurrently? D-4. What NetWare TCP/IP NLMs are out there and how do I get them to work? D-5. How do I get a telecom package supporting Int 14h redirection to work? D-6. How do I run SLIP/PPP with Windows For Workgroups TCP/IP? D-7. How do I get Windows For Workgroups to work alongside NetWare? D-9. How come package X doesn't support the AppleTalk packet driver? D-10. NCSA Telnet doesn't reassemble fragments. What should I do? E. Information for developers E-1. What publicly distributable TCP/IP stacks are there that I can use to develop my own applications? E-2. Where can I get a copy of the Windows Sockets FAQ? --------------------- FAQ Begins Here --------------------------- A. Components of a TCP/IP solution A-1. What do I need to run TCP/IP on the PC? To run TCP/IP on the PC you will need: * Appropriate hardware, such as: Ethernet card Token Ring card AppleTalk card Serial Port Any other network card with a packet driver or NDIS or ODI driver, (such as Arcnet), will also work. If your card supports NetBIOS, this is also acceptable, since you can run a packet-driver-over- NetBIOS shim. * Drivers for your hardware. Your card probably came with one or more of the following drivers: Network Device Interface Specification (NDIS) drivers [spec. by 3Com and Microsoft, used by LAN Manager, Windows for Workgroups, and Windows NT. LAN Manager uses NDIS 2.0, Windows NT uses 3.0, and WFW supports 2.0 and will support 3.0] ODI Drivers [spec. by Novell, abbreviation for Open DataLink Interface] Packet Drivers [spec. by FTP Software] TCP/IP stacks have been written for each of these driver interfaces, so the important thing is whether your chosen stack is compatible with the interface available for your card. A shim is software that runs on top of one set of drivers to provide an interface equivalent to another set. This is useful, for example,if you are looking to run software requiring an NDIS driver(such as Chameleon NFS) alongside software requiring a packet driver interface (such as KA9Q, Gopher, Popmail, NCSA Telnet, etc.), or run software intended for, say, a packet driver over an NDIS driver instead. Shims are available to run packet drivers over NetBIOS, ODI, or NDIS, in order to run software expecting a packet driver over NDIS, ODI, or NetBIOS instead. There are also shims to run NDIS over ODI (ODINSUP), and ODI over Packet Drivers (PDETHER). * A TCP/IP protocol stack. The TCP/IP protocol stack runs on top of the driver software, and uses it to access your hardware. If you are running a TCP/IP protocol stack that requires drivers that aren't available for your hardware, you're in trouble. Check into this before purchasing! * If running Windows applications that require it, WINSOCK.DLL. Windows Sockets is a sockets interface which was created as a Windows DLL. Each TCP/IP implementation requires its own version of Windows Sockets. Trumpet Winsock and VxDTCP are the only two publicly distributable Windows Sockets implementations. WINSOCK.DLL provides 16-bit support; WSOCK32.DLL provides 32-bit support. * Applications software. Although most of us in this newsgroup seem to spend our time looking for working combinations of applications,WINSOCK.DLLs, Windows Sockets compliant TCP/IP implementations, shims, drivers, and hardware, ultimately your goal is eventually to run an application successfully. If and when that happens, please send me a note, so I can add it to this FAQ. A-2. What are packet drivers? Where do I get them? Packet drivers provide a software interface that is independent of the interface card you are using, but NOT independent of the particular network technology. As Frances K. Selkirk (fks@vaxeline.ftp.com) notes: "That's one reason they're easier to write than ODI drivers! If you write a class three (802.5 Token Ring) driver, you will need to use software that expects a class three driver, not software that expects a class 1 (DIX ethernet) driver. There are a few drivers that fake class 1. I believe only class 1 and class 6 (SLIP) drivers are supported by freeware packages." The chances are fair that your Ethernet card came with a packet driver, and if so, you should try that first. If not, then you can try one of the drivers from the Crynwr collection (formerly called the Clarkson Drivers). See the Resource listing for info. For 3COM drivers, try ftp ftp.3com.com. For technical information, try info@3com.com. For marketing and product info, try leads@hq.3mail.3com.com.The packet driver specification is available from vax.ftp.com in packet-d.ascii The following vendors have packet drivers with source available for their pocket lan adaptors: D-Link - +1-714-455-1688 Solectek - +1-619-450-1220 Accton - +1-415-266-9800 Compulan - +1-408-922-6888 (soon Kodiak's Noteport - +1-408-441-6900) You can obtain a complete library of packet drivers from many of the Simtel20 mirror sites, including: file://oak.oakland.edu/pub/msdos/pktdrvr/pktd11.zip, file://oak.oakland.edu/pub/msdos/pktdrvr/pktd11c.zip. A-3. What is Windows Sockets? Where can I get it? The idea for Windows Sockets was born at Fall Interop '91, during a Birds of a Feather session. From the Windows Sockets specification: [courtesy of Mark Towfiq, mailto:towfiq@Microdyne.COM]: The Windows Sockets Specification is intended to provide a single API to which application developers can program and multiple network software vendors can conform. Furthermore, in the context of a particular version of Microsoft Windows, it defines a binary interface (ABI) such that an application written to the Windows Sockets API can work with a conformant protocol implementation from any network software vendor. Windows Sockets will be supported by Windows, Windows for Workgroups, Win32s, and Windows NT. It will also support protocols other than TCP/IP. Under Windows NT, Microsoft will provides Windows Sockets support over TCP/IP and IPX/SPX. DEC will be implementing DECNet. Windows NT will include mechanisms for multiple protocol support in Windows Sockets, both 32-bit and 16-bit. Mark Towfiq writes: "Files and information related to the Windows Sockets API are available via ftp://sunsite.unc.edu/pub/micro/pc-stuff/ms-windows/winsock, which is a mirror of /pub/winsock on Microdyne.COM (SunSite has a much faster connection to the Internet, so you are advised to use that). If you do not have FTP access to the Internet, send a message with the word "help" in the body to either mailto:ftpmail@SunSite.UNC.Edu, or mailto:ftpmail@DECWRL.DEC.Com, to obtain information about the FTP to Mail service there." Alternative sources for the Windows Sockets specification include rhino.microsoft.com (an FTP server running NT), as well as the Microsoft forum on CompuServe (go msl). Currently NetManage (NEWT), Distinct, Spry, FTP and Frontier are shipping Winsock TCP/IP stacks, as is Microsoft (Windows NT and TCP/IP for WFW), Beame & Whiteside Software (v1.1 compliant), and Sun PC-NFS. If you are looking for a Winsock.dll, you should first contact your TCP/IP stack vendor. Novell has one in beta for their Lan Workplace for DOS. A-4 What is Trumpet Winsock? How can I get it to dial? Peter Tattam has released a shareware Windows Sockets compliant TCP/IP stack. You can obtain it via file://ftp.utas.edu.au/pc/trumpet/winsock/winsock.zip, file://ftp.utas.edu.au/pc/trumpet/winsock/winsock.zipwinapps.zip, or file://biochemistry.bioc.cwru.edu/pub/trumpwsk/winsock.zip. The first thing to do after you download WINSOCK.ZIP is to create a directory for Trumpet Winsock, such as C:/TRUMPWSK, and put it in your DOS PATH statement. Trumpet Winsock operates over packet drivers, or over a serial port using its own built-in SLIP/CSLIP. If you are using a network adapter, this means that you will have to locate a packet driver for your adapter, and load it. Trumpet Winsock also comes with WINPKT, and this is loaded next, via the command WINPKT.COM 0x60 [or whatever the software interrupt for your packet driver] You will then enter Windows, and create a group in the Program Manager for all the files that come with Trumpet Winsock. The stack itself is loaded by executing TCPMAN. Applications that come with it include WinCHAT, a chatting program; PINGW, a ping utility; FTPW for FTP, WINARCH for Archie. When you first execute TCPMAN, you will be asked to fill out the setup information for the stack. Select whether you will be using a network adapter or SLIP; you cannot use both. Since Trumpet Winsock does not yet support PPP, you will need to load the EtherPPP driver and WINPKT prior to running Windows. EtherPPP is available via file://merit.edu/pub/ppp/etherppp.zip. This is an Ethernet simulation driver, so you will configure Trumpet Winsock as though it were running over an Ethernet Packet driver, i.e. by loading WINPKT 0x60, and setting the packet driver vector in TCPMAN to 60. EtherPPP comes with its own dialer, so you will need to create a dialing script. If your TCP/IP address will be changing, you will also need to write a little batch script to capture the assigned IP address, and insert it into Trumpet's initialization file. EtherPPP takes up too much RAM (121K), but otherwise works fine. If for some reason you don't like Trumpet Winsock's scripting language, you can use any other comm program that doesn't drop carrier on exit, or the DIALER program, available via: file://ftp.cica.indiana.edu/pub/pc/win3/util/dialexe.zip. As for Trumpet Winsock's built-in scripting language, the default dialout script is LOGIN.CMD. A sample LOGIN.CMD file from Geoff Cox (mailto:geoff@satro.demon.co.uk): # # initialize modem # output atzm0\13 input 10 OK # # set modem to indicate DCD # output at&d2&c1\13 input 10 OK\n # # send phone number # output atdt0813434848\r # # my other number # #output atdt241644\13 # # now we are connected. # #input 30 CONNECT # # wait till it's safe to send because some modem's hang up # if you transmit during the connection phase # #wait 30 dcd # # now prod the terminal server # #output \13 # # wait for the username prompt # input 30 ogin: username Enter your username output \satro\r # # and the password # input 30 assword: password Enter your password output \my password\r # # we are now logged in # input 30 otocol: # # see who on for informational reasons. # output SLIP\r input 30 HELLO A-5. What publicly distributable TCP/IP applications are there for DOS? Windows? Right now there are a wealth of publicly distributable TCP/IP applications running under DOS. Windows also has a wealth of programs available, including implementations of Gopher, Mail (POP3/SMTP), FSP, Mosaic, Telnet, FTP, IRC, and WAIS. See the Resource listings for information. A-6. What software is available for doing SLIP? Compressed SLIP? PPP? For DOS? For Windows? For OS/2? For SLIP or CSLIP use with DOS, I recommend using SLIPPER or CSLIPPER. These are packet drivers that can be used along with a dialer. For PPP, I recommend the EtherPPP packet driver described above. There is a special version of NCSA Telnet for PPP, available from ftp://merit.edu/pub/ppp. KA9Q supports SLIP/CSLIP, but unfortunately can not be used as a TCP/IP protocol stack to run other apps. I have heard good things about IBM's TCP/IP for OS/2, but haven't used it msyelf. Please see the FAQ from news:comp.os.os2.networking for details. IBM, FTP Software, Beame & Whiteside, Frontier, SPRY and Netmanage also offer SLIP support in their products. See the resource listings for details. A-7. What about the software included with various books? The software included with various books (including mine) is usually Chameleon Sampler from NetManage. Sampler supports SLIP/CSLIP/PPP, but not connection over a network, and includes software for FTP, Telnet, TN3270, and Mail. The stack included with Sampler (NEWT) is Winsock compatible, so you can run any Windows Sockets-compatible application over it. Installation is quite a bit simpler compared with going the Trumpet Winsock route, so this is probably the best way to go assuming that you are a dialup IP user. A-8. What diagnostic utilities are available to find problems with my connection? Where can I get them? Frequently used diagnostic utilities include ifconfig (checks the configuration of the network interfaces), ping (tests IP layer connectivity), traceroute (traces the route that a packet takes between two sites), netstat (checks the routing table), tcpdump (protocol analyzer), arp (looks at the IP to Ethernet address mappings). KA9Q includes ifconfig, ping and traceroute functions. In KA9Q hop check is the equivalent of traceroute. The Trumpet TCP/IP stack also has a hopchk2 command that is a traceroute equivalent. Etherload is very useful for network profiling, while Etherdump can be used for packet catching, although I wish it would give more information, along the lines of TCPDUMP. Trumpet Winsock comes with Windows implementations of Ping and Traceroute. A-9. Is there a CD-ROM with the software included in this FAQ? The Packet Driver, WinSock & TCP/IP CD-ROM is available from CDPublishing for$29.95. This includes the packet drivers of course,
but also lots of other DOS and Windows TCP/IP stuff, including
Windows Sockets applications. It also includes the text of all
the RFCs. This is now somewhat out of date (it was cut in
December), but is otherwise highly recommended.

CDPublishing, (604)874-1430, (800)333-7565, fax: (604)874-1431,
mailto:info@CDPublishing.com, ftp://ftp.CDPublishing.com/,
Gopher site: gopher://gopher.CDPublishing.com/, WWW: http://www.CDPublishing.com/

A-10. Does Windows NT support SLIP? PPP?

The "Daytona" release of Windows NT will include support for
PPP (client and server) and SLIP (client), both including
support for Van Jacobson header compression.

A-11. Where can I take a peak at the WFW v3.11 VxD beta?

This is a beta release of the forthcoming 32 bit-TCP/IP stack for
Windows for Workgroups v3.11. This is looking *very* good; it's
fast, and has worked fine for me. It also supports a host of very
nice new features, including DHCP automatic configuration, WINS
name resolution, and Windows Sockets v1.1. However, plesae not that
it does not offer SLIP or PPP support.
The final beta release is now available via:
ftp://ftp.microsoft.com/PerOpSys/WFW/tcpip/

A-12. How do I get my BBS to run over TCP/IP?

First off, let's clarify what we mean by "over TCP/IP." Usually
this means "accessible via Telnet." Be aware that doing this will
not necessarily work well, since few BBSes have been tested running
over TCP/IP. As a result you may experience frequent crashes, or
abominable transfer rates. For example, I have seen transfer rates
as low as 100 characters/second over a 14.4 Kbps PPP connection
which routinely supports 1600 cps transfers with FTP.

This situation might be improved by running an FTP server instead.
This could be accomplished for example by running KA9Q in another
window under DesQView, or by putting the files on an NFS-mounted
drive, then using another machine as the FTP server.

One way to hook up a multi-line BBS is to use a terminal server,
and hook up the BBS's serial ports to that. The disadvantage of this is that
if your BBS is really big you will need multiple terminal servers
which will each have their own domain names and TCP/IP addresses.
Confusing.

Brian Clements of Murkworks has a better solution, called BBSnet.
It provides a Telnet interface that looks like a FOSSIL driver.  The first
version runs partly as an NLM; some of the code resides on the server.
For info, contact

BBSnet,MurkWorks, Inc., P.O. Box 631,Potsdam, NY 13676,
+1 315 265 4717, mailto:info@MurkWorks.com

eSoft has also recently announced that they are working on a TCP/IP
compatible version of TBBS. Look for this to be shown at OneBBS
Con '94 in Atlanta.

A-13. Are there graphical servers out there?

Yes! For Windows there is a graphical SMTP daemon which is not very
functional (it can't do as much as KA9Q); several Web servers, including
a Windows version of NCSA's HTTP, and SerWeb.

For Windows NT, The European Microsoft Windows Academic Consortium (EMWAC) has
released Windows NT servers for Gopher, WAIS, and WWW. These servers
are easy to install, and fast, and offer the full complement of capabilities,
installation as a Windows NT service, etc.

See the resource section for details.

A-14. What methods of address assignment are available?

Methods of address assignment include client/server protocols
(RARP, BOOTP, DHCP), as well as script-based methods
supports assignment of addresses from the server.

As part 2 of this FAQ discusses, there are RARP and BOOTP clients
and servers available for DOS. Typically the clients work by stashing
the IP address in a DOS environmental variable. It is then your responsibility
to modify the appropriate config files to reflect this
address. This can be done using a DOS batch script and a utility such as
DOS awk. This same approach can be used to modify config files when using
EtherPPP; this does not place the IP address into a variable, but the output
of EtherPPP can be piped to a file and the IP address picked off and inserted
in the appropriate locations. If this sounds complicated, it is; be warned.

Trumpet Winsock supports script-based assignment of addresses. Microsoft
supports a DHCP client in WFW TCP/IP, and both client and server in Windows NT.
There is also a forthcoming DHCP server for Sun.

A-15. How can I set up PPP server on a UNIX host?

This is not the appropriate place to address that question, but lots
of info on this is available in the comp.protocols.ppp FAQ.

A-16. What is WinSNMP?

WinSNMP is an API which provides a standard interface to to the
Simple Network Management Protocol (SNMP) for network
management applications running under Windows. Applications written to
WinSNMP can run on any WinSNMP-compatible implementation.

Vendors supporting WinSNMP include FTP Software, which supports it
in both OnNet 1.1, and PC/TCP 3.0.

B-1. What do I need to know before setting up SLIP or PPP?

Before setting up your SLIP or PPP connection, you should
have available the following information:

dynamically, or from the server.
* If from the server, whether you will be using RARP, BOOTP or DHCP.
* The domain name and TCP/IP address of your machine (if you are not
configuring the address dynamically or via BOOTP)
* The domain name and TCP/IP address of the primary and secondary
Domain Name Server.
* The domain name and TCP/IP address of an NNTP server.
* Whether your host supports POP, and if so, what version.
* Whether the host supports compressed or uncompressed SLIP, or PPP.
* The size of the Maximum Receivable Unit (MRU).

Do not attempt to connect to your host before you have this
information, since it will just waste your time and money, and may
cause problems for the network.  In particular, do not attempt to
initiate a connection using a made up TCP/IP address! It is possible

This is probably the quickest way to get people very angry at you.

be the same. This makes it easy to configure your setup files.
Dynamic addressing means that the host will send you a message
and inserting it into the setup files. If not, then you may have
to edit your setup files every time you log on. Yuck!

Chameleon NFS includes a version of SLIP which can handle dynamic
DOS does as well.

You can also retrieve your address using RARP, BOOTP or DHCP. RARP
is only available to those on the same LAN as the RARP server, since
it uses broadcasting. BOOTP clients can access BOOTP servers on other
LANs via BOOTP relay. DHCP is a BOOTP extension, which allows
complete configuration of a client from info stored on a DHCP server, and in
DHCP frames are very similar to BOOTP frames, devices supporting BOOTP relay
will also support DHCP relay.

Of course, for DHCP or BOOTP to work, you will need to set up a DHCP
or BOOTP server. DHCP servers are available for UNIX, and Windows NT.

PPP also supports server assignment of TCP/IP addresses.

B-2. How do I configure SLIPDIAL?

From Ashok Aiyar, mailto:ashok@biochemistry.bioc.cwru.edu:

PHONE Script Files:

PHONE comes with several scripts (for various modems) and for the
University of Minnesota Terminal server built into it.  The command
PHONE WRITE writes these scripts to an ASCII file called PHONE.CMD,
which can be edited to your needs (modem and slip server)

The documentation that accompanies PHONE, provides good instructions on
writing script files to get PHONE to dial SLIP servers other than
the University of Minnesota server.  For example here is a script
that I use to dial a CISCO server at the University that I attend.

Background:  To start a SLIP connection, I dial our terminal server,
session with the following command "slip username-slip.dialin.cwru.edu",
followed by my password -- again.

Here then is the relevant portion of the PHONE.CMD script file -
#
# CWRU-TS2 SLIP login script by Ashok Aiyar 3/26/93
# Last revised 3/28/93
TimeOut 60      'CWRU-TS2 terminal server is not responding'
Message         "CWRU-TS2 SLIP login script -- Version 1.1"
Message         'Waiting for SLIP server to respond'
Quiet ON
Expect 'Verification'
Message         'Request for User Verification Received from CWRU-TS2'
Quiet OFF
Send '%u<'
Private
Send '%p<'
TimeOut 30    'SLIP server did not respond to your validation request'
Expect 'CWRU-TS2>'
Send 'SLIP<'
TimeOut 10    'SLIP server did not respond to SLIP command'
Send '%u-slip.dialin.cwru.edu<'
TimeOut 10 'SLIP server did not respond to hostname'
Send '%p<'
TimeOut 10
Message 'Login to CWRU SLIP server successful'
Wait 1.0
#
#
Procedure      Host.CWRU.LogOut
# Nothing special needs to be done to logout
EndProcedure   Host.CWRU.LogOut
#
#   End of Script file
#
----------------------------------------------------------------------
How to use packet drivers other than UMSLIP with PHONE?

The quick answer -- there is no "clean" way.  Below is a batch file
hack that I wrote to use PHONE with other packet drivers.  In this
example, the packet driver is Peter Tattam's CSLIPPER.  To use a
batch file like this, you must know the parameters with which you
plan to use the packet driver -- i.e interrupt vector, baud rate,
port address, and IRQ.  This batch file requires UMSLIP.COM,
CSLIPPER.EXE, and TERMIN.COM to be in the same directory

All that the BATCH file does is to let you dial the SLIP connection
using PHONE, load the appropriate packet driver, hangup the
connection, and unload the driver when you are done ...

-- being CWRUSLIP.BAT --
@echo off
rem   this batch file is an ugly hack of U. of Minn. "SLIP.BAT"
rem   awaiting a version of C/SLIPPER that can directly interact
rem   with PHONE
rem   CWRUSLIP.BAT file is used with PHONE.EXE to start a SLIP
rem   connection on CWRU-TS2

@echo off
cls
goto start

:start
if %1. == ?.         goto help
if %1. == help.      goto help
if %1. == setup.     goto setup
if %1. == dial.      goto forceD
if %1. == hangup.    goto forceH
if %1. == quit.      goto forceH
if %1. == HELP.      goto help
if %1. == SETUP.     goto setup
if %1. == DIAL.      goto forceD
if %1. == QUIT.      goto forceH
goto bogus

:forceH
termin 0x60
umslip >nul
phone force hangup

:slipper
termin 0x60
REM  the following line must be changed to reflect the COM port,
REM  IRQ, baud rate, and software interrupt
lh c:\packet\cslipper com1 vec=60 baud=57600 ether
goto end

:forceD
termin 0x60
umslip >nul
phone force dial
goto slipper

:setup
termin 0x60
umslip >nul
phone setup
goto help

termin 0x60
goto end

:bogus
echo %1 is not a valid command.
echo Try "cwruslip help" for a list of valid commands
echo.

:help
echo --------------------------------------------------------------
echo           Case Western Reserve University SLIP Setup
echo                  using Univ. of Minnesota PHONE
echo --------------------------------------------------------------
echo cwruslip setup     modem settings, phone number, username etc.
echo.
echo cwruslip dial      DIAL and establish the SLIP connection
echo cwruslip quit      HANGUP the phone and unload the driver
echo cwruslip help      this screen
echo.

:end
-- end CWRUSLIP.BAT --

B-3. How do I install packet drivers for Windows applications?

How do I install packet drivers for Windows applications?

The secret is to load the packet driver, then run Windows. If you
are running Trumpet Winsock, you will also have to load WINPKT
before running Windows, as follows:

winpkt 0x60

If you are running DOS applications within a virtual DOS session
follows:

PKTMUX 4 [or however many sessions you want]

Then within each DOS session, load PKTDRV, the virtual packet driver.

If you are running Trumpet Winsock along with other DOS apps in a
virtual DOS session, then you will need to load PKTDRV prior to

PKTMUX 4
PKTDRV 0x62
WINPKT 0x62
PKTDRV 0x60
WIN

TCPMAN will then find the virtual packet driver at 0x62.

B-4. When do I need to install  WINPKT?

PKTMUX and WINPKT both accomplish the same thing: allowing you to
connect to a DOS packet driver running in real mode from a virtual
DOS session under Windows. PKTMUX is useful when you are running
more than one TCP/IP stack, and since it takes up more RAM and is
slower than WINPKT, you should only use it when you want to run more
than one stack at a time. If you are running only one DOS app,
or are using Trumpet Winsock, stick with WINPKT.

James Harvey (mailto:harvey@iupui.edu) notes:
Winpkt is only useful running DOS applications with built-in TCP/IP
stacks under Windows, and for some Windows-based stacks (like the
Trumpet winsock.dll).  When an application registers with a packet
driver TSR to receive packets of a specified protocol type, one of the
things it hasto pass as a parameter to the packet driver in the call
is the address of a routine in the application that the packet driver
is to call when it has a packet to pass back to the application.  In
the case of an application running in 386 enhanced mode in a DOS shell
under Windows that is using a packet driver loaded in real mode before
Windows was loaded, the packet driver must ensure that Windows has the
application in memory when it does the callback, otherwise the callback
jumps off into space and your system locks up.  Winpkt does a Windows
system call to force the app into memory before the callback is done.

Erick Engelke (mailto:erick@development.uwaterloo.ca) notes:
Windows in enhanced mode uses the protected mode of the
386 CPU to create multiple virtual machines.  Winpkt tells
Windows to switch to the correct virtual machine before
trying to pass up the packet.  This reduces the chances of
Windows crashing.

B-5. How to do I run both WinQVT and ODI?

My advice is to use the Windows Sockets version of WinQVT/Net, Trumpet
Winsock, and ODIPKT. ODIPKT will allow you to run packet driver software
over ODI. You will also need to load WINPKT for Trumpet Winsock.

NE2000.COM [or other ODI driver]
IPXODI [IPX version supporting ODI]
NETX
ODIPKT 1 96
WINPKT 0x60
WIN [run windows]

Then run Trumpet Winsock, and load WinQVT/Net.

B-6. Is it possible to use BOOTP over SLIP?

Yes, but it is easier to use dynamic address assignment to get
before switching to SLIP.

If you need BOOTP, then you should run a BOOTP server on the SLIP
server so that it can tell which SLIP connection originated the
request. Of course, the BOOTP server will ignore the hardware address
of the request originator, but instead will keep track of the SLIP
interface the request came in on. See the question on adding BOOTP to
KA9Q for info on how to handle this on the PC. Under UNIX, you may
have to add BOOTP capability to your slip driver, and rebuild the
kernel. (Not recommended for the squimish).

B-7. How do SLIP drivers work?

Some TCP/IP applications are written to only support Class 1 (Ethernet)
packet drivers, but do not support Class 6 (SLIP). For these applications, you
need software to make the application think it is dealing with a class 1
SLIP or PPP packets and stripping the headers off outgoing packets.

B-8. When do I need to install PKTMUX?

PKTMUX is needed to allow you to use more than one TCP/IP stack at the same
time. This is useful if you have applications that require different stacks.
Note that you do not need PKTMUX to run different protocols, since packet
drivers only look at packets in the protocol they're designed to handle,
and therefore you can use more than one of these at a time without conflict.
You also don't need PKTMUX if all your applications use the same TCP/IP stack.

PKTMUX works by looking at outgoing datagrams, and caching information on
source and destination ports and addresses. Using this information, PKTMUX
tries to sort incoming datagrams by TCP/IP stack. If it can't figure out
which stack to send a datagram to (as might be the case if you were running
a server application on a well-known port, and had not sent any outgoing
packets yet), PKTMUX will send the datagram to all stacks. If all stacks
do not complain about the datagram, PKTMUX will throw away the ensuing outgoing
ICMP error message, assuming that one of the stacks correctly received
the datagram. If all stacks complain, it will send a single ICMP message
and throw the rest away.

While PKTMUX does its job very well, there are some situations that it cannot
handle, such as port conflicts. If two applications open the same TCP port,
chaos is inevitable, and there is little that PKTMUX can do to help.

B-9. Can NDIS be used underneath multiple protocol stacks of the same type?
No. There is no equivalent to PKTMUX for NDIS.

B-10. Is there an NDIS over packet driver shim?
Joe Doupnik writes:

"No. Packet Drivers work by having an application register
for a particular packet TYPE, such as 0800 for IP. NDIS works much
differently, by offering a peekahead of every packet to applications in turn,
a polling operation. The only way NDIS could gracefully sit on a PD would
be to run the Packet Driver in all-types mode and let NDIS see all pkts
not used by other clients. Needless to say, that's an undesirable situation.
The quick solution, costing about US\$100 (at least at my place,
more at yours) is a second Ethernet board in the client together with a

B-11. How do I run NetBIOS over TCP/IP?

NetBIOS over TCP/IP is discussed in RFCs 1001 and 1002, which defines
three types of NetBIOS nodes:

* B nodes, which use UDP broadcast packets to distribute datagrams and
resolve names.
* P nodes, which use point-to-point communications and which
require NetBIOS Datagram Distribution (NBDD) and NetBIOS Name
Servers (NBNS). P nodes do not listen to or use broadcast
services, so they cannot be used alongside B nodes. Unfortunately NBNS,
and NBDD servers were not widely implemented, and those
that do exist (such as an implementation from Network Telesystems)
are not inexpensive.
* M nodes, which use both point-to-point and broadcast.

B node technology cannot be used on an IP internet without extensions,
since UDP broadcast packets are not forwarded through routers. This
is not a problem with use of NetBIOS over IPX/SPX, since in IPX/SPX

However, until very recently, M and P node technology was not supported
by popular TCP/IP implementations. For example, PC/TCP supports
B node technology with extensions such as a broadcast file, host file,
or DNS resolution of NetBIOS names. Windows NT and WFW TCP/IP uses an
LMHOSTS file for resolving names.

According to Chip Sparling of FTP Software:

"From what I remember from our discussions of a few years ago, P
nodes were only implemented by Ungermann Bass and 3COM (and they
required you to use a NetBIOS name resolver which was non-rfc 1001, 1002 compliant),
nobody did M nodes (as far as I remember) and PC-LAN, Lantastic and
LanManager used B node.  Also, if you did a P or M node it wouldn't be
compatible with a B node NetBIOS.  We decided that we could give the
compatibility and functionality (routability) with a B node plus
extensions implementation.  So, that's what we did."

Without implementation of M and P node technology, the only way
to run over an IP internet is to to implement B node technology
with extensions, as FTP Software does in PC/TCP. According to Chip,
"one way to handle large numbers of hosts on multiple networks is
like nnn.nnn.nnn.255. which will cover an entire subnet."

Assuming you don't need any of the extensions to RFC NetBIOS
Microsoft created to make NetBIOS work smoothly in a routed environment
(available only in their IP stack), you can choose from a wide variety of
commercial vendors. For example, FTP Software's PC/TCP includes RFC NetBIOS
support; Performance Technologies has a NetBIOS that runs over packet drivers,
as does Accton (LANSoft).

If any other vendors are reading this, I'd love to have information
on how *you* implement NetBIOS over TCP/IP, and whether you'll be
supporting WINS, the new P-node technology name resolution service
from Microsoft.

WINS will be included in the next WFW TCP/IP release, which is currently

B-12. How do I run NFS along with another TCP/IP application?

The DOS NFS implementation by M. Durkin now supports a built-in
packet multiplexer that can handle NFS plus another stack loaded
simultaneously. If you need to load more stacks, then you will need
to run PKTMUX as well.

See the resource section for details.

B-13. How do I run Trumpet Winsock along with KA9Q or NFS?

The secret is to load WINPKT on top of the PKTDRV virtual
packet driver, if you are running PKTMUX.

B-14. Sample Stick Diagrams

It has been proposed that we begin to collect some diagrams of working
combinations of hardware, drivers, shims, stacks, and applications. I'm
game, and have made a start below. If you've got some other exotic
configuration that works (or if you've tried one of the configurations below
and discovered it doesn't work, drop me a line).

Running an individual DOS application under Windows

NCSA telnet / DOS Trumpet / POPmail/ PC Gopher III
|
DOS Session
|
Windows 3.1
|
WinPKT
|
Packet driver or Shim
|
DOS
|

DOS Trumpet, NCSA Telnet, and WinQVT/Net over Ethernet under Windows

QVT/NET
|
TRUMPET                    NCSA telbin        |
|                             |             |
PKTDRV1                     PKTDRVn           |
|                             |             |
DOS Session                DOS Session    Windows Session
+-----------+-----------------+             |
|                               |
+                               |
WINDOWS 3.1 .............        WINDOWS 3.1
|                               |
|                      PKTINT(QVT/NET own)
|                               |
|                           PKTDRVx
+-------------------------------+
PKTMUX n
|
Packet Driver or SHIM
|
DOS
|

PC Gopher III, NCSA Telnet over CSLIP under Windows

PC Gopher III                 NCSA telbin
|                             |
PKTDRV1                     PKTDRVn
|                             |
DOS Session                DOS Session
+-----------+-----------------+
|
+
WINDOWS 3.1
|
|
|
|
+
PKTMUX n
|
CSLIPPER
|
DOS
|
Serial Port

PC Gopher II and NetWare on a LAN - Alternative I
[Didn't work for me, but it's supposed to be OK]

NetWare
PC Gopher        |
III            |
|             |
DOS Session    NETX
|             |
Windows 3.1     |
|           PDIPX
WINPKT        /
\         /
\       /
\     /
\   /
Packet Driver
|
DOS
|

PC Gopher III and NetWare on a LAN - Alternative II

PC-Gopher III
|
DOS Session
|
Windows 3.1
|
|
NetWare            |
\            /
NETX         WINPKT
\        /
IPXODI   ODIPKT
\   /
\ /
|
|
ODI driver
|
DOS
|

WinQVT/Net and PC Gopher II and NetWare over a LAN - Alternative I

PC Gopher
III
|             Win QVT/Net
PKTDRV1            |
|                |
DOS session      Windows 3.1
|                |
Windows 3.1      PKTINT (QVT/NET own)
|                |
|             PKTDRVn
WinPKT             |
|                |          NetWare
+----------------+            |
|                             |
|                             |
PKTMUX n                      NETX
|                             |
\                          PDIPX
\                           |
\                          |
\                         |
\                        |
Packet Driver --------------+
|
DOS
|

WinQVT/Net, PC Gopher III and NetWare over a LAN - Alternative II

QVT/Net
PC Gopher III                 NCSA telbin        |
|                             |             |
PKTDRV1        .....        PKTDRVn           |
|           |                 |             |
DOS Session                DOS Session    Windows Session
+-----------+-----------------+             |
|                               |
|                               |
WINDOWS 3.1 .......................WINDOWS 3.1
|                               |
|                      PKTINT(QVT/NET own)
|                               |
|                           PKTDRVx
|	                           |
|		                   |
|		                   |
|		                   |
+------------------+------------+
|
NetWare            |
\            /
NETX         PKTMUX n (use if >1 TCP/IP app)
\        /
IPXODI   ODIPKT
\   /
\ /
|
|
ODI driver
|

PC Eudora and Windows Trumpet over CSLIP under Windows using Trumpet Winsock

PC Eudora    Windows Trumpet
\         /
\       /
\     /
\   /
TCPMAN
|
Windows 3.1
|
WINPKT 0x60
|
DOS
|
Serial Port

PC Eudora and Windows Trumpet supporting Ethernet and CSLIP under Windows
using NDIS supporting stack [Chameleon]

[Please note: this is not possible under Trumpet Winsock, since it can
only handle a single interface; it requires a stack that routes]

PC Eudora    Windows Trumpet
\         /
\       /
\     /
\   /
Chameleon NEWT
|
Windows v3.1
|
+------------------+
|                  |
Protocol Manager         |
|                  |
NDIS Mac Driver     Serial Port
|
DOS
|
Ethernet card

PC Eudora, Windows Trumpet, and KA9Q under Windows

WinTrump   PC Eudora
\     /
\   /
KA9Q         \ /
|           |
PKTDRV      TCPMAN
\         |
\       /
\     /
\   /
\ /
Windows
|
PKTDRV 0x62
|
PKTMUX 2
|
Packet Driver
|
DOS
|
Ethernet Card

HGopher, PC Eudora, and WinTrumpet Under Windows
(Whether the TCP/IP stack is loaded before or
after Windows depends on the stack)

HGopher
|
|
PC    |
Eudora  |  WinTrumpet
\   |   /
\  |  /
\ | /
\|/
TCPMAN
|
Windows 3.1
|
WINPKT
|
Packet Driver
|
DOS
|
Ethernet Card

B-15. Strange and wonderful configuration files submitted by readers

Robert Clift (mailto:clifta@sfu.ca) writes:

"I have WinQVT/Net 3.4, PC Gopher III (including NCSA DOS Telnet), KA9Q
(gopher and FTP server), and POPMail all running together under Windows
over PKTMUX on a 3C503 packet driver (and Ethernet card)."

Here is the stick diagram (yikes!):

Win/QVTNet 3.7     KA9Q Gopher      PC POPMail 3.2     PC Gopher III 1.01
on interrupt 65    & FTP Server           \                    /
\                  |                    \                /
\                |                      \            /
\              |                        \        /
\          PKTDRV                       PKTDRV
\          |                            /
\      DOS Session               DOS Session
\      |                        /
\    |    -------------------
\  |  /
Windows 3.1
|
PKINT
|
PKTDRV on Int 65 no listeners set
|
PKTMUX 1.2 with 3 channels
|
Clarkson 3C503 Packet Driver
|
DOS
|
|
Ethernet

NOTES:

Win/QVTNet must be loaded as the very first Windows application and must be
kept operating as long as your are in Windows.  It appears that its TCP/IP
stack does some strange things when it disconnects and kills access to the
actual packet driver.

I run PC gopher and POPMail alternatively, so they share one channel which
is allocated via PKTDRV before running the application and deallocated
after the application is finished (I usually throw in a reset command to
PMTMUX as well just to be safe).

To explain what is happening (as best I can since a lot of this came from
experimentation):

1.  The packet driver is loaded
2.  PKTMUX is run over the packet driver in order to multiplex it (in this
case three channels).
3.  A virtual packet driver is loaded for Win/QVTNet on interrupt 65 and
the packet driver is told that it is not to listen for any server
requests.
4.  PKINT is loaded over top of the virtual packet driver
5.  Start Windows and run Win/QVTNet as the first application, it must be
kept running throughout the Windows session.
6.  Load a virtual packet driver from a DOS session and start KA9Q.  I use
the following batch file to do this:

c:\network\pktdrv 63 /l
h:
cd \
net091b
c:\network\pktdrv 63 /uu
c:\network\pktmux /r

7.  Load a virtual packet driver and run PC Gopher or POPMail as needed.  I
use the following batch files for PC Gopher and POPMail respectively:

c:\network\pktdrv 63
h:\goph-cli\gopher /T=h:\goph-cli\text /X=h:\goph-cli\binary
c:\network\pktdrv 63 /uu

c:\network\pktdrv 66 /c
h:\popmail\popmail /noems
c:\network\pktdrv 66 /uu

8.  The only problem seems to be that the NNTP module in Win/QVTNet will
not operate correctly if POPMail is operating.  Otheriwse it seems to
work okay without too many problems.

C. KA9Q Questions

C-1. What version of KA9Q should I use and where do I get it?

There are so many releases of KA9Q that it is a significant amount of
work just to keep track of them all. This has occurred partly because
KA9Q does not support extended or expanded memory, and therefore many
people have needed to customize it with the features relevant to them
in order to allow it to do what they want as well as fit into memory.
The primary difference among the various releases is whether they
include code for a BBS, packet radio support (AX.25), synchronous cards (for
use with leased lines), NNTP, CSO or Gopher servers, packet filtering, DNS,
RIP or PPP support.

The three primary KA9Q releases at this time are those managed by Ashok Aiyar
(ashok@biochemistry.bioc.cwru.edu), those put out by Demon Internet
Services (DIS), and the JNOS distribution. JNOS is the primary packet radio-
oriented release; the other two major releases do not include AX.25 support.
Since JNOS does not include several features important to non-packet radio
users (DNS/Gopher/CSO server, hop check), try one of the other two releases
if you're not interested in packet radio.

Ashok's release is based on the N1BEE 0.85-beta which in turn
is based on PA9GRI 2.0m NOS. Version 11c includes support for NTP, CSO,
gopher, FTP, FINGER, HTTP and SMTP/POP2/POP3 servers, plus VT102 and packet
filtering support. Please not that this release does *not* include radio or
synchronous card support, unlike the standard KA9Q release, and only support
SLIP/CSLIP. Also, there is no DNS server support, and the tip command has been
removed, so that you need to use an external dialer to make the connection.

Available as:

file://biochemistry.bioc.cwru.edu/pub/nos/nos11c.exe,
file://biochemistry.bioc.cwru.edu/pub/nos/nos11c.txt,
file://biochemistry.bioc.cwru.edu/pub/nos/nos11c.map,
file://biochemistry.bioc.cwru.edu/pub/nos/nos192.txt,
file://biochemistry.bioc.cwru.edu/pub/nos/nos_1229.man,
file://biochemistry.bioc.cwru.edu/pub/nos/vt102.zip,
file://biochemistry.bioc.cwru.edu/pub/nos/filter.txt,
file://biochemistry.bioc.cwru.edu/pub/nos/autoexec.nos

The TextWin version from Demon Internet Services includes support for DNS server, packet filtering, FTP, SMTP/POP2/POP3 servers, NNTP server, VT102 support, NTP, BBS, SLIP/CSLIP,PPP (I don't know anyone who has gotten this to work), demand dial, ping, hop
check (traceroute equivalent).

From mailto:mike@childsoc.demon.co.uk (Michael Bernardi):

"Demon Internet Services have a dialin Internet service in the UK.
They also support a customised version of KA9Q optimised for
dialup, they also support the PCElm mailer, SNEWS news reader and
a customised front end. There is also a combined NEWS and MAIL
program called CPPNEWS and an alternative MAIL program called
VIEW, these last are unsupported by mailto:Internet@demon.co.uk but other
DIS users do support them. All these programs can be found on
ftp://ftp.demon.co.uk/pub/ibmpc/ and are written to
work with KA9Q (specifically the DIS version)."

Anthony McCarthy has added a multi-windowing system to KA9Q that
supports the mouse, which has been recommended. See Resource
listings for info.

The DIS release includes three versions, small, medium and large.
The large version includes everything but the kitchen sink, including
an NNTP server. I also believe it includes the KA9Q BBS code, and

Editorial: To my mind, the time has come for the major releases to combine
their code bases and produce a version with the best features of all of them.
To my mind, the ideal KA9Q release would be a release combining the improved
server support of the CWRU release with a working PPP implementation, demand
dial, and DNS server support.

C-2. What do I need to run KA9Q? Why won't it do VT-100 emulation?

KA9Q is usually run from a startup script, such as my script
startnos.bat:

\nos\drivers\8003pkdr
\nos\net -d \nos

Here I first load the packet drivers for my 8003 Ethernet card, then
run KA9Q (known as net.exe).

The KA9Q package then reads commands from a configuration file, called
AUTOEXEC.NOS in some implementations, AUTOEXEC.NET in others.

For VT100 emulation with KA9Q, try using Giles Todd's VT102.COM,
available via ftp://ftp.demon.co.uk/pub/ibmpc/DIS.

C-3. How do I configure KA9Q as a SLIP dialup connection?

Here is a sample CSLIP only configuration file, which was
written for Demon Internet Service's version of KA9Q (as
are all other KA9Q sample configs in this FAQ):

# This config file is for use with the large TextWin
# version of KA9Q available from ftp.demon.co.uk
#
# Set the host name
#
hostname foobar.com
#
# Configure COM3 on Interrupt 5, at 38400 bps with
# RTS/CTS (c) and Van Jacobsen Compression (v) and
# MTU = 1008
#
attach asy 0x3e8 5 vjslip sl0 8092 1008 38400 cv
dialer sl0 dialer.sl0
#
#
# route all packets over sl0 by default (sl0 is the route
# to the Internet)
#
#
# Time To Live is the maximum number of hops a packet
# can take before it is thrown away.  This command
# prevents packets from looping infinitely.
#
ip ttl 255
#
# The Maximum Segment Size is the largest single
# transmission that you care to receive.  An mss of 216
# will force folks to send you packets of 256 characters
# or less (counting the overhead).
#
tcp mss 1048
#
# The Window parameter establishes the maximum number
# of bytes that may be outstanding before your system
# expects an ack. If window is twice as big as mss,
# for example, there will be two active packets on the
# channel at any given time.  Large values of window
# provide improved throughput on full-duplex links, but
# are a problem on the air.
# Keep  mss <= window <= 2*mss if you're on the air.
#
tcp window 6888
#
# and will record the server activity of your system.  If
# you don't want a log, comment out this line; if you do,
# make sure you have a \spool directory!
#
log \textwin\spool\net.log
#
# Each of the servers (services you will provide) must
# be turned on before they will be active.  The
# following entries turn all of them on.  To turn any
# function off use the command 'stop' after NET gets
# fired up, or just comment out the line here.
#
start ftp
ftpopt binary
start echo
# start telnet
start smtp
# This machine uses primary and seconary DNS servers
# Command indicating presence of IBM AT
isat on
#
smtp gateway 140.174.7.1
#
#
# THE END

dialer.sl0 file:

# Configuration section.
#
configure:
init "ATZ\r"
dial_cmd "ATDT"
ld_code ""
number "15108658169"
retries 5
#
# Execution section.
#
execute:
#
# Toggle DTR.
#
control down
wait 2000
control up
wait 2000
#
# Initialize the modem.
#
init
wait 3000 "OK"
#
# Dial and wait for connection.
#
dial
wait 45000 "CONNECT"
#
#
wait 60000 "ogin:"
wait 1000
send "userID\r"
wait 60000 "word:"

After executing this setup file, you should hear the modem dial out
to your SLIP host. Assuming that the dialing script is correct,
it should login and go into SLIP mode.

Type RESET at the prompt. This kills any residual processes that
may be operating.

At this point you should have a functioning connection. You might
try to ping your host via the command:
If this works, you will then see the round trip time to your host,
in milliseconds.

Other possible diagnostic commands:

ASYSTAT <interface>	Gives statistics on packets received, sent, etc.
TRACE <interface> 1011	Shows incoming characters
RIP TRACE 1		Traces RIP packets
HOP CHECK <address>	Traces the route to the designated system. Useful
for figuring out routing problems.

C-4. How do I configure KA9Q as a router?

The KA9Q configuration that follows uses two interfaces, one a PPP
interface (pp0), the other an Ethernet interface (lan). Here I
am implementing dial on demand, and can also be doing packet
filtering, and DNS serving on the same box.

Please note the strange interrupt settings (Interrupt 5, port is COM3).  One of
the nice things about KA9Q is that it is flexible enough to deal with
such situations.

Here is a sample router configuration file:

# This config file is for use with the large TextWin
# version of KA9Q available from ftp.demon.co.uk
#
# Set the host name
#
hostname gate.foobar.com
#
# Configure COM3 on Interrupt 5, at 38400 bps with
# RTS/CTS (c) and PPP
#
attach asy 0x3e8 5 ppp pp0 8092 576 38400 c
dialer pp0 dialer.ppp demand
#
ppp pp0 trace 2
ppp pp0 quick
ppp pp0 lcp open
ppp pp0 ipcp open
#
# Packet driver installed at software interrupt
# number 0x60.
#
attach packet 0x60 lan 2 1500
#
#
# The local Ethernet has a Class C network address so
# route all IP addresses beginning with 192.187.157 to
# it.
#
# Time To Live is the maximum number of hops a packet
# can take before it is thrown away.  This command
# prevents packets from looping infinitely.
#
ip ttl 255
#
# The Maximum Segment Size is the largest single
# transmission that you care to receive.  An mss of 216
# will force folks to send you packets of 256 characters
# or less (counting the overhead).
#
tcp mss 576
#
# The Window parameter establishes the maximum number
# of bytes that may be outstanding before your system
# expects an ack. If window is twice as big as mss,
# for example, there will be two active packets on the
# channel at any given time.  Large values of window
# provide improved throughput on full-duplex links, but
# are a problem on the air.
# Keep  mss <= window <= 2*mss if you're on the air.
#
tcp window 6888
#
# and will record the server activity of your system.  If
# you don't want a log, comment out this line; if you do,
# make sure you have a \spool directory!
#
log \textwin\spool\net.log
#
# Each of the servers (services you will provide) must
# be turned on before they will be active.  The
# following entries turn all of them on.  To turn any
# function off use the command 'stop' after NET gets
# fired up, or just comment out the line here.
#
start ftp
ftpopt binary
start echo
start telnet
start smtp
# This machine will act as a DNS server;
# Boot file is c:\textwin\named.boo, configuration
# goes in c:\textwin\spool\zones
domain startdns
# Command indicating presence of IBM AT
isat on
#
smtp gateway 192.187.157.2
#
# Use Router Information Protocol (RIP) to inform
# the router at 192.187.147.253 about the existence
# of the local network. Send RIP packets every 240
# seconds. Only useful for dedicated routers.
#
# THE END

dialer.ppp file:

# Configuration section.
#
configure:
init "ATZ\r"
dial_cmd "ATDT"
ld_code ""
number "15108658169"
retries 5
#
# Execution section.
#
execute:
#
# Toggle DTR.
#
control down
wait 2000
control up
wait 2000
#
# Initialize the modem.
#
init
wait 3000 "OK"
#
# Dial and wait for connection.
#
dial
wait 45000 "CONNECT"
#
#
wait 60000 "ogin:"
wait 1000
send "userID\r"
wait 60000 "word:"

Here is another routing configuration file, using CSLIP and proxy arp:

# This config file is for use with the large TextWin
# version of KA9Q available from ftp.demon.co.uk
#
# Set the host name
#
hostname gate.foobar.com
#
# Configure COM3 on Interrupt 5, at 38400 bps with
# RTS/CTS (c) and Van Jacobsen Compression (v) and
# MTU = 1008
#
attach asy 0x3e8 5 vjslip sl0 8092 1008 38400 cv
dialer sl0 dialer.sl0
#
#
#
# Packet driver at 0x60; probably an Ethernet card
#
attach packet 0x60 lan 2 1500
#
# route all packets over sl0 by default (sl0 is the route
# to the Internet)
#
#
# The local Ethernet has a Class C network address so
# route all IP addresses beginning with 157.151.64 to it.
#
#  Use Proxy ARP
arp publish 157.151.64.1 ether 00:00:c0:33:f3:13
arp publish 157.151.64.254 ether 00:00:c0:33:f3:13
#
# Time To Live is the maximum number of hops a packet
# can take before it is thrown away.  This command
# prevents packets from looping infinitely.
#
ip ttl 255
#
# The Maximum Segment Size is the largest single
# transmission that you care to receive.  An mss of 216
# will force folks to send you packets of 256 characters
# or less (counting the overhead).
#
tcp mss 576
#
# The Window parameter establishes the maximum number
# of bytes that may be outstanding before your system
# expects an ack. If window is twice as big as mss,
# for example, there will be two active packets on the
# channel at any given time.  Large values of window
# provide improved throughput on full-duplex links, but
# are a problem on the air.
# Keep  mss <= window <= 2*mss if you're on the air.
#
tcp window 6888
#
# and will record the server activity of your system.  If
# you don't want a log, comment out this line; if you do,
# make sure you have a \spool directory!
#
log \textwin\spool\net.log
#
# Each of the servers (services you will provide) must
# be turned on before they will be active.  The
# following entries turn all of them on.  To turn any
# function off use the command 'stop' after NET gets
# fired up, or just comment out the line here.
#
start ftp
ftpopt binary
start echo
# start telnet
start smtp
# This machine uses primary and seconary DNS servers
#
smtp gateway 157.151.0.2
#
# Command indicating presence of IBM AT
isat on
#
#
#
# THE END

dialer.sl0 file:

# Configuration section.
#
configure:
init "ATZ\r"
dial_cmd "ATDT"
ld_code ""
number "15108658169"
retries 5
#
# Execution section.
#
execute:
#
# Toggle DTR.
#
control down
wait 2000
control up
wait 2000
#
# Initialize the modem.
#
init
wait 3000 "OK"
#
# Dial and wait for connection.
#
dial
wait 45000 "CONNECT"
#
#
wait 60000 "ogin:"
wait 1000
send "userID\r"
wait 60000 "word:"

C-5  How do I get KA9Q to support BOOTP?

The CWRU NOS version has a working BOOTP client and server built-in,
and is the best version if you are looking for BOOTP support.
[Does Textwin offer full BOOTP support?]
If you are using another version of KA9Q that does not support BOOTP,
try the following:

Steven L. Johnson (mailto:johnson@TIGGER.JVNC.NET) notes:

KA9Q does have a bootp client but it is not compiled in by default.
It has a bug that truncates the returned ip address to 16 bits
which must be corrected before it will work.  It also complains
about bootp servers that only support RFC 951 bootp without RFC
1084 (or 1048) vendor extensions.  Other than that it seems to work
for me.

To enable the bootp client, add the following line to config.h:

#define BOOTP 1

To correct the ip address truncation problem, in bootp.c change:

^^^^^problem
at line 188 to:

^^^^^^^solution

And of course, recompile.

This worked on the src1229 (1991) version and may work on the
most recent version.  I did check to make sure that the bug still
exists, but I haven't rechecked whether there are additional
problems in the new version.

C-6.  How do I get KA9Q to support PPP?

Although I haven't gotten this to work yet, there is hope.
The only major version of KA9Q supporting PPP is the TextWin versio`