# The 'Security Digest' Archives (TM)

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

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

START OF DOCUMENT

-----------[000000][next][prev][last][first]----------------------------------------------------
Date:      Sat, 1 May 1993 12:34:33 GMT
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.domains,comp.protocols.tcp-ip.ibmpc
Subject:   TCP-IP Technical Professional wanted to Teach

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

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

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

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

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

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

Thanks

Jim Leeper


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

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

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

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

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


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

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

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

--

John Robert Breeden, Hughes Lan Systems

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

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

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


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

Hello, networld.

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

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

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

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

Rune Mossige

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


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

Just a small correction...

In article <1rs62r$shg@genesis.ait.psu.edu> I write: >If I am in the domain "math.uwaterloo.ca" (logged on, say, cantor), and I >say "telnet gauss", the resolver will first try "gauss.math.uwaterloo.ca" >If that exists, it will return that. It will then try "gauss.uwaterloo.ca". >If that exists, it will return that. Failing that, it will return "host >unknown". If say "telnet joe.cs", the resolver will first try >"joe.cs.math.uwaterloo.ca", then "joe.cs.uwaterloo.ca". If the resolver is passed a hostname with a dot in it, then it will (after going through RES_DNSRCH) will try to see if it is an FQDN. So, the final check the resolver would take would be to see if "joe.cs." is a valid address. (In Czechoslovakia) --Dave -- System Administrator, Penn State Population Research Institute #define ENOTTY 25 /* Not a typewriter */  -----------[000005][next][prev][last][first]---------------------------------------------------- Date: 1 May 1993 20:28:17 GMT From: barmar@think.com (Barry Margolin) To: comp.protocols.tcp-ip Subject: Re: NIS & DNS questions  In article <4.473.362.0N565040@euronetis.no> rune.mossige@euronetis.no (Rune Mossige) writes: >I have also set up two of the Sun's (one on each side of the >router...) with NIS, and stumbled into a problem when I was going to >add the other unix boxes to NIS. First, the login shell problem. From >what I understand, the NIS passwd map will be the same on all >machines, so all users must use the same login shell. But, SUN have >the C-shell as default and have not even included the Korn shell, >while the RS have the Korn shell as default. Korn shell is available for Suns; I think we got it from the AT&T Toolchest. I believe it's bundled with Solaris 2.x as well. > We have had these >nachines for a couple of years now, and the users have gotten used to >the default login shells. So the question is: Should I force all users >to use the C-shell, or is there a way around this? Set everyone's shell to /usr/local/bin/default_shell. Then on each machine, make a symbolic link from /usr/local/bin/default_shell to whichever shell you want as a default on that machine. Also, make sure you add /usr/local/bin/default_shell to /etc/shells everywhere. > The applications >run on the Sun's depend very heavily on that the users use the C- >shell, while the RS applications depend on that the users use the Korn >shell. Does anyone have a good suggestion? How do applications depend on the shell that they were called from? -- Barry Margolin System Manager, Thinking Machines Corp. barmar@think.com {uunet,harvard}!think!barmar  -----------[000006][next][prev][last][first]---------------------------------------------------- Date: 2 May 93 11:08:37 CST From: phe@kuhub.cc.ukans.edu To: comp.protocols.tcp-ip Subject: Internet connection  Hi: One of my friends wants to set up an Internet connection. In his location, there are about 30 - 40 PCs ( they are on Ethernets running on IPX and some other stacks). My advice to him is that he needs to apply for a class-C IP address and gets an Internet feed from someone (He is working for a commertial company located at Kansas City area -- Overland Park.) He is writing a proposal and needs your help... 1. Who provides Internet services in the area? 2. Hardware: -leased phone line ( fractional T1?), -router ( Cisco routers ...) -server machine ( Sun station in order to set up a ftp server and news server? how about a fast PC to be a server? any ftp server and news server software running on a PC?) -other suggestions? 3. Software: -news server -other common servers (NFS, FTP, Telnet and etc. if a PC can be a server machine) -other suggestions? 4. Whom should he talk to? ( someone who can provide this kind of simple Internet design info.) Thank you in advance for any of your suggestions. P.S. please send your suggestions directly to me since my friend doesn't have Internet access -- not yet :-) BTW, do you know any other news groups I should post this message to? Ping  -----------[000007][next][prev][last][first]---------------------------------------------------- Date: Sun, 2 May 93 12:14:00 +0200 From: rune.mossige@euronetis.no (Rune Mossige) To: comp.protocols.tcp-ip Subject: Re: NIS & DNS questions  Subject: BMRM´Korn shell is available for Suns; I think we got it from the AT&T RM´Toolchest. I believe it's bundled with Solaris 2.x as well. I know it is bundled with Solaris 2.x, but the applications we run will not run under Solaris for at least another month. I don't have FTP access, so I have not been able to get a Korn shell for the sun's. BMRM´Set everyone's shell to /usr/local/bin/default_shell. Then on each Very good idea. I'll look into this as soon as possible. BMRM´How do applications depend on the shell that they were called from? It's probably me that was unclear. What I meant was that all documentation, manuals and tutorials are based on one shell (c-shell on Sun and K-shell on the RS) and have alot of environment variables set and other examples. Users just follow the book, and don't really understand the different shells. I guess some more taining is needed...Your comment made me think, and I agree with you. I think I have to modify the way all these environment variables are set. Thanks for the comment. Rune Mossige * 1st 1.10b #274 * Keyboard not found...THINK F1 to continue.  -----------[000008][next][prev][last][first]---------------------------------------------------- Date: 2 May 93 18:10:59 GMT From: art@acc.com (Art Berggreen) To: comp.protocols.tcp-ip Subject: Re: Wanted: to identify routers in a path  In article <C69ItC.9Gt@aaahq05.aaa.com> mikel@aaahq05.aaa.com writes: >There was a program I've seen at USENIX (which I think comes from Solbourne) >which tells you the names (or addresses) of the routers allong a certain path. > >You give it an address, like "kgbvax.kgb.org.su" and it will identify all >of the routers allong the path taken. Sounds like you are talking about "traceroute" (originally created by Van Jacobsen). >Can anyone tell me where I can get this? Check with an Archie server for an FTP server near you. Art  -----------[000009][next][prev][last][first]---------------------------------------------------- Date: 2 May 93 19:13:21 GMT From: guy@Auspex.COM (Guy Harris) To: comp.protocols.tcp-ip Subject: Re: SUN's TCP BUG ??  >Years ago we found that logins were slow because the system had to >check the quota of all NFS mounted partitions. We fixed this by making >/usr/ucb/quota a do nothing routine. You can also mount the file systems on the client with the "noquota" option (i.e., the *NFS* mount done by the *client* should have the "noquota" option; that's unrelated to the "quota" option, which, when used on the *server*, specifies that quotas should be used). That option causes the "quota" program not to bother checking whether the user is over quota on that particular file system. The *server* will still check whether they're over quota, of course....  -----------[000010][next][prev][last][first]---------------------------------------------------- Date: Mon, 3 May 1993 02:09:25 GMT From: rlm@helen.surfcty.com (Robert L. McMillin) To: comp.protocols.tcp-ip Subject: Re: NIS & DNS questions  On 1 May 1993 20:28:17 GMT, barmar@think.com (Barry Margolin) said: > In article <4.473.362.0N565040@euronetis.no> rune.mossige@euronetis.no (Rune Mossige) writes: >>I have also set up two of the Sun's (one on each side of the >>router...) with NIS, and stumbled into a problem when I was going to >>add the other unix boxes to NIS. First, the login shell problem. From >>what I understand, the NIS passwd map will be the same on all >>machines, so all users must use the same login shell. But, SUN have >>the C-shell as default and have not even included the Korn shell, >>while the RS have the Korn shell as default. > Korn shell is available for Suns; I think we got it from the AT&T > Toolchest. I believe it's bundled with Solaris 2.x as well. Another solution to this problem is to force everyone to use GNU bash, which (IMHO) is better than either the C shell or the Bourne shell; it retains the Bourne shell's robustness with the C shell's history mechanism, and skips the C shell's lamer extensions. -- Robert L. McMillin | Surf City Software | rlm@helen.surfcty.com | Dude! "What's taking so long? It's only typing!" -- a marketing manager posing as a software manager  -----------[000011][next][prev][last][first]---------------------------------------------------- Date: Mon, 3 May 1993 04:43:48 GMT From: andy@research.canon.oz.au (Andy Newman) To: comp.protocols.tcp-ip Subject: Re: Summary: ALLO and FTP  Last week I posted a query on the use of the ALLO command in various FTP servers and clients. Here is a summary of the (two) responses ;-) To sum up you can say that the ALLO command is generally ignored as not many real systems require it. Only MVS-hosted servers were noted as requiring it. Thanks to Gordon C. Spoelhof <spoelhof@Kodak.COM> Stephen C. Trier <trier@slc6.INS.CWRU.Edu> --------------------------------------------------------------------- > I have a question about the ALLO ("allocate") command in FTP. Although > there is a brief mention of ALLO in the RFC that's about all I can > find. The wording is rather loose... Basiclly it is provided for servers which "can" use it and clients which know that servers should use it... Although required in RFC 1122, most servers return the 202 reply (vacuuous support) rather than the 200 reply (supported positive response)... > We have a system that is a potential FTP server but due to the simple > file system it uses space must be allocated prior to sending the file. > I've been over the RFCs and can find very little mention of ALLO but > I'm sure others have come across this before. > > Questions: > > What other FTP servers require ALLOs? Few modern servers require the use of ALLO. The notion of cheap disk space in this new "virtual" resource world has virtually %^) wiped out its use... Except for servers like mine, and yours... Of those which implement ALLO, the only ones I have seen are those which use the basic form of ALLO -- "ALLO <bytes>". I have never seen a server which requires the record format: "ALLO <records> R <bytes> > How do they handle this at the user interface? Since few servers support it, few clients support it as well. > Do they force the users to use the QUOTE command? Yes, although I am fortunate as most of my users are automated or known, in which case I put the ALLO command in the .netrc (unix based clients)... I now work with default allocations depending on transfer type, for example I start with 32K for ASCII files and 1MB for binary files. I have been working toward providing file growth capabilities. This effort has proved helpful in working around resource problems (as above) but also enabled me to improve I/O and reduce buffer copying -- a real boon to FTP performance! Example: New code (my own I/O) took 4 weeks to design, document, develop, and test. Binary transfer rates went from 600KByte/sec to 850+KByte/sec... Only 500 lines of C code to implement on small real time kernel... I hope to eleminate the absolute need default allocations (or required use of ALLO) for my server soon. I will keep default allcations (albiet smaller sizes) and ALLO available for performance reasons, however. ---------------------------------------------------------------------------- From: Stephen C. Trier <trier@slc6.INS.CWRU.Edu> MVS requires it. It, too, requires preallocation of files in an effort to avoid fragmentation. Every FTP client I've seen requires use of the quote command in order to use ALLO. I'd guess the MVS FTP client uses it, but I just managed to get myself locked out of my MVS account, so I can't check. :-( The FTP server on our Suns accepts ALLO but ignores it, as does our local DOS FTP server. -- Andy Newman (andy@research.canon.oz.au) "gentle suggestions being those which are written on rocks of less than 5lbs" Tracy Nelson in comp.lang.c  -----------[000012][next][prev][last][first]---------------------------------------------------- Date: 3 May 93 06:44:50 GMT From: melman@FibHaifa.com (David Melman) To: comp.protocols.tcp-ip Subject: Comer's/Stevens's TCP implementation  I am interested in hearing from anybody who has used or considered using this TCP (just TCP, not IP etc...) implementation from Comer/Stevens "Internetworking with TCP/IP Volume II in a real product, e.g. a router? Can this code be considered "commercial quality"? Are there good alternatives? Thanks for sharing, David Melman Fibronics Matam Industrial Park Haifa 31905, Israel Internet: melman@FibHaifa.com Tel: Intl+972+4-313313 Direct: Intl+972+4-313642 Fax: Intl+972+4-550550 Telex: 46857 FIBRO IL  -----------[000013][next][prev][last][first]---------------------------------------------------- Date: Mon, 3 May 1993 06:58:53 GMT From: ben@rex.uokhsc.edu (Benjamin Z. Goldsteen) To: comp.protocols.tcp-ip Subject: Proper TCP/IP ports for LPD  I am looking into using the PLP print spooler. It looks pretty good, but now I finding these weird inconsistencies in the general protocol (or rather the way it is implemented). According to the RFC (don't have # handy, sorry), all ports must be in [721,731] (I think that was the range). This jived with what I was seeing when I tried to test various things out -- I couldn't contact other machines when I tried to work outside that range. A small change to the source and things were on there way again...except...now, other machines are trying to access PLP on a reserved port outside that range...and it is refusing... So my question is: what is the standard? Should I just make PLP stick to [721,731] for initiating, but allow any connection < 1024? It seems my other machines are acting the exact opposite way -- initiating connections on any port, but only accepting on [721,731]... Thanks P.S.Other machines include SGI w/Berkeley LPD and VAX/VMS w/UCX 2.0. I hanv't tried my SVR4 machine...nor my AIX box since we only have one and that is the machine where I am trying PLP first.... -- Benjamin Z. Goldsteen  -----------[000014][next][prev][last][first]---------------------------------------------------- Date: Mon, 3 May 1993 08:01:02 GMT From: skl@wimsey.bc.ca (Samuel Lam) To: comp.unix.sysv386,comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc,comp.sys.novell Subject: Re: SCO TCP/IP <> Netware TCP/IP problem  In article <3@mhinfo.UUCP>, carrato@mhinfo.UUCP (Tony Carrato) wrote: >It appears that either a) the SCO system is set up wrong somehow ... That's probably it. Check the SCO box's subnet mask to make sure it's using the correct value. Also check its routing table for a route to the other network via the Novell router. ...Sam -- <skl@wimsey.bc.ca> -- Connectivity Technology Inc. "NetNews on CD's" product information: <NewsCD@CDPublishing.COM>  -----------[000015][next][prev][last][first]---------------------------------------------------- Date: 2 May 1993 20:02:52 +0930 From: hart@flash.pax.tpa.com.au (Leigh M Hart) To: comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc Subject: PC-Based Terminal Server Software: In Production  I have read several postings in tcp-ip newsgroups regarding the (non)existence of PC based terminal server software (that is, software running on an IBM PC, with network card, and multi-port serial board, to act as a terminal server - similar to xyplex/annex/etc). I did some hunting around, and as far as I know there are no PC terminal server packages around, so I have started production on a PC based terminal server. The server will include the stanard features that most existing (real) termainl servers have - TCP/IP and DECNET/LAT support, SLIP and standard interactive lines, multi-level help, multiple sessions, support for a wide variety of multi-port cards (ie: Stallion cards, etc). Any suggestions anyone might have will be taken into consideration, as it is often the users of such products that come up with the good ideas, not the programmers! The server is as yet un-named, so name suggestions are also welcome. The server currently supports 2-4 standard RS232 ports, TCP/IP (telnet, rlogin). It is definately still in the infancy stage. There is one suggestion that I have received that I still am not sure about - that is to allow the PC to monitor the sessions - ie: at a touch of a key, display what is happening on any given port. I would appreciate any input on the moral/legal/whatever implications the above "feature" would have :) Email replies prefered. Leigh -- Leigh M Hart (hart@pax.tpa.com.au) -- Leigh M Hart (hart@pax.tpa.com.au) Ph: +61-8-267-5966 (W) --------------------- The Fluffy Rabbit rides again  -----------[000016][next][prev][last][first]---------------------------------------------------- Date: Mon, 3 May 1993 14:05:44 GMT From: burt@hart.Princeton.EDU (Burton Rosenberg) To: comp.protocols.tcp-ip Subject: Two IP networks -> one physical network  Is it possible for a single physical ethernet to be associated with two or more IP networks? In our situation, as it is, if the sender's IP network address matches that of any of several IP addresses, ARP should be queried for the ethernet address of the destination host. As a receiver, a single ethernet port should be able to receive packets with any of two or more IP addresses. We are in the process of merging networks and this would permit this operation to go smoothly, without reassigning IP addresses to machines on defunct networks, as well as allow us to maintain "control" over a network, essentially for assigning IP addresses out of our private subnet IP addresses. Thanks. -burt  -----------[000017][next][prev][last][first]---------------------------------------------------- Date: Mon, 3 May 1993 14:21:18 GMT From: heka@ost.NoSubdomain.NoDomain (hedie kamoun) To: comp.protocols.tcp-ip Subject: Toggle of Nagle option  Hi TCP-wiz:es, I turning to this community in hope that you'll be able to help me out with a few things (clear things up). I've been told that it is possible to turn on/off the Nagle- algoritm using berkeley sockets, in my case SunOS. My question is if anybody out there might have any experience with "toggling" of this alleged socket-option for which I can't find any documentation. I'd also appreciate a hint on where to find some pragmatic info on this algoritm. My second question is maybe even less well defined but I'll give it a shot anyway. Does anybody know how to read an allocated socket from the kernels memory, I guess with /dev/kmem, but if so where what offset should I use if this is at all possible. Thank you for any light you might shed on these subjects, whatever you and are willing to share bordering this area. Best regards Hedie Kamoun Email: heka@ppvku.ericsson.se  -----------[000018][next][prev][last][first]---------------------------------------------------- Date: 3 May 93 21:20:53 MDT From: jrd@cc.usu.edu (Joe Doupnik) To: comp.protocols.tcp-ip Subject: Re: Two IP networks -> one physical network  In article <1993May3.140544.20097@Princeton.EDU>, burt@hart.Princeton.EDU (Burton Rosenberg) writes: > Is it possible for a single physical ethernet to be associated > with two or more IP networks? In our situation, as it is, if > the sender's IP network address matches that of any of several > IP addresses, ARP should be queried for the ethernet address > of the destination host. As a receiver, a single ethernet > port should be able to receive packets with any of two or more > IP addresses. > > We are in the process of merging networks and this would permit > this operation to go smoothly, without reassigning IP addresses > to machines on defunct networks, as well as allow us to maintain > "control" over a network, essentially for assigning IP addresses > out of our private subnet IP addresses. > > Thanks. > > -burt ----------- It's called "multiple homing" and few machines support it. Instead take your friendly router (say a cisco or equivalent) and ask it to fake the second network on the same wire. That's a popular trick, even if it is to be regretted technically. Different IP "networks" result in ARPing for a router rather than a host. If you can most of us would recommend bringing net.sanity to the wire with but one IP "network" on it. Having multiple nets on the same wire characteristically doubles the network traffic: pkt to the router, pkt back from the router to the destination. Joe D.  -----------[000019][next][prev][last][first]---------------------------------------------------- Date: 3 May 93 17:35:48 GMT From: my00@gte.com (Michael Yuen) To: comp.protocols.tcp-ip Subject: rfc for ip protocol ID  Can someone refer me to a RFC that documents all the ip protocol id's? Thanks in advance. -Mike -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Michael Yuen Tel - (617)466-2919 GTE Labs Internet - my00@gte.com 40 Sylvan Road FAX - (617)466-2130 Waltham, MA 02254  -----------[000020][next][prev][last][first]---------------------------------------------------- Date: Mon, 03 May 1993 22:04:52 GMT From: gryphon@openage.openage.com (The Golden Gryphon) To: comp.unix.sysv386,comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc,comp.sys.novell Subject: Re: SCO TCP/IP <> Netware TCP/IP problem  skl@wimsey.bc.ca (Samuel Lam) writes: >In article <3@mhinfo.UUCP>, carrato@mhinfo.UUCP (Tony Carrato) wrote: >>It appears that either a) the SCO system is set up wrong somehow ... >That's probably it. Check the SCO box's subnet mask to make sure >it's using the correct value. Also check its routing table for a >route to the other network via the Novell router. I think not. Your Novell is probably acting as a learning bridge. It knows which machines are on each side of the LAN as soon as they talk. If you moved PC-1 to the non-SCO segment and rebooted the Novell server and tried again, then you could be sure this was the case if it worked. -- The Golden Gryphon gryphon@openage.COM "The Crown Jewel of the American Prison System." - President Bill Clinton on living in The White House. Openage - The Premier SCO UNIX integrator in the Washington D.C. area  -----------[000021][next][prev][last][first]---------------------------------------------------- Date: Mon, 3 May 1993 23:45:11 GMT From: sekine@gumby.dsd.trw.com (Nancy Y. Sekine) To: comp.protocols.ibm,comp.protocols.misc,comp.protocols.tcp-ip Subject: Printing from an IBM mainframe to printers on an Ethernet backbone  I'm looking for info on products that will enable printing from IBM mainframe applications to various printers on an Ethernet backbone (AppleTalk printers, Banyan VINES printers, UNIX lpd-served printers, etc.). Right now we're evaluating Interlink Computer Sciences' Enterprise Print Services software which runs on the mainframe and implements lpr and lpd through a TCP/IP interface. We've investigated lpd servers to serve the printers (Incognito Software's UNIX-to-VINES Print Service to provide lpd capability to Banyan VINES printers; CAP on a UNIX platform to provide lpd capability to AppleTalk printers; etc....). We have Interlink's SNS/TCPaccess providing the TCP/IP capability on the mainframe. Our SNA network is separate from our Ethernet backbone (i.e., we're not running SNA over Ethernet). Our goal is to find a solution to allow our customers to print from any mainframe application (such as report generation facilities on TSO and various transactions on IMS) to their "local" network printers, no matter what protocol. I realize that there may be some "adjustments" involved (such as implementing lpd servers on the customer side in the case I mentioned above), but I'm open to any potential solutions out there. It's been a while since I've checked what's out there, so I was wondering if there are any new products that will provide this capability, or maybe there are some older products that I missed... Thanks! And please send replies directly to me at sekine@gumby.dsd.trw.com. Nancy Sekine TRW Space and Electronics Group Communications Services One Space Park Redondo Beach, CA 90278 sekine@gumby.dsd.trw.com  -----------[000022][next][prev][last][first]---------------------------------------------------- Date: 4 May 1993 01:42:50 GMT From: trier@odin.ins.cwru.edu (Stephen C. Trier) To: comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc,comp.sys.novell Subject: Re: SCO TCP/IP <> Netware TCP/IP problem  In article <1993May03.220452.28684@openage.openage.com> gryphon@openage.openage.com (The Golden Gryphon) writes: >I think not. Your Novell is probably acting as a learning bridge. Novell servers route. They don't bridge, even though older Novell manuals call NetWare IPX routers "bridges". When they handle TCP/IP, they definitely route. -- Stephen Trier (trier@ins.cwru.edu) Star Trek dialog mistake of the week: Network Software Engineer "We've tried every decryption key IRIS/INS/T on record, Captain." Case Western Reserve University - Geordi LaForge, ST:TNG, 5/1/93  -----------[000023][next][prev][last][first]---------------------------------------------------- Date: Tue, 4 May 1993 04:05:28 GMT From: vjs@rhyolite.wpd.sgi.com (Vernon Schryver) To: comp.protocols.tcp-ip Subject: Re: Two IP networks -> one physical network  In article <1993May3.140544.20097@Princeton.EDU>, burt@hart.Princeton.EDU (Burton Rosenberg) writes: > Is it possible for a single physical ethernet to be associated > with two or more IP networks? In our situation, as it is, if > the sender's IP network address matches that of any of several > IP addresses, ARP should be queried for the ethernet address > of the destination host. As a receiver, a single ethernet > port should be able to receive packets with any of two or more > IP addresses. > > We are in the process of merging networks and this would permit > this operation to go smoothly, without reassigning IP addresses > to machines on defunct networks, as well as allow us to maintain > "control" over a network, essentially for assigning IP addresses > out of our private subnet IP addresses. Yes, this technique works great for such transitions. There are some oddities associated with machines seeing broadcasts for the wrong network, but none that are likely to be noticed during a few weeks or even months during renumbering. It's often easier to just use two different ethernet interfaces on your router, both connected to the same physical wire to manage the gatewaying between the old and the new IP networks. Vernon Schryver, vjs@sgi.com  -----------[000024][next][prev][last][first]---------------------------------------------------- Date: Tue, 4 May 1993 04:10:56 GMT From: dls@mentor.cc.purdue.edu (David L Stevens) To: comp.protocols.tcp-ip Subject: Re: Comer's/Stevens's TCP implementation  In article <690@ariadna.FibHaifa.com>, melman@FibHaifa.com (David Melman) writes: > .... > Comer/Stevens "Internetworking with TCP/IP Volume II in a real > product, e.g. a router? > > Can this code be considered "commercial quality"? > Well, I wrote it, and I can say "no." It wasn't designed to be a commercial product-- it's designed to illustrate the concepts of the protocol suite and the issues involved in implementing them. It is not particularly fast (not extremely slow, either), and there are certainly places where both space and time optimizations could be made, but most at the expense of clarity. It also has not been through 10 years of production use, and has not had the benefit of hundreds of people debugging and improving it and exercising it on tens of thousands of machines, like, for example, the BSD code. Nor does it have the kind of support that commercial products do-- it has one person working on it very occasionally in his spare time. That said, it is small, and probably better documented (by the book) than any other implementation, and it should be fairly easy to modify. That makes it a good choice for developing new protocols, or extending and testing old ones. It also may help in understanding what other implementations are doing in a different way to get the same effect. It has been used in commercial products, usually where its small size and simplicity is a necessity, but if you're looking for highly reliable, high-performance networking code, you really want a commercial implementation. Or perhaps the Berkeley code and someone who knows it well to maintain it for you. -- +-DLS (dls@mentor.cc.purdue.edu)  -----------[000025][next][prev][last][first]---------------------------------------------------- Date: 4 May 93 11:55:43 From: jim@cs.strath.ac.uk (Jim Reid) To: comp.protocols.tcp-ip Subject: Re: Two IP networks -> one physical network  In article <hmb423s@rhyolite.wpd.sgi.com> vjs@rhyolite.wpd.sgi.com (Vernon Schryver) writes: In article <1993May3.140544.20097@Princeton.EDU>, burt@hart.Princeton.EDU (Burton Rosenberg) writes: > Is it possible for a single physical ethernet to be associated > with two or more IP networks? There are some oddities associated with machines seeing broadcasts for the wrong network, but none that are likely to be noticed during a few weeks or even months during renumbering. Er... I hope you don't consider a broadcast storm as something that's likely to go unnoticed. If you have two or more IP networks on the once cable, *everyone* has to take care over broadcast addresses. Suppose something like routed or rwhod broadcasts on one of the IP networks. A host on another IP network will see this broadcast - it's on the same cable. If it's not configured properly, the host may decide to forward this packet back into the network it came from, causing a flurry of broadcasts. [It might even forward the broadcast packet that it sent too....] This can lead to an infinite loop and a saturated network. Even if you can avoid the broadcast problems, you may need to think carefully about ICMP redirects and routing between the IP networks. It's probably better and safer all round if you separate the IP networks on to physically separate networks. Jim  -----------[000026][next][prev][last][first]---------------------------------------------------- Date: Tue, 4 May 1993 07:49:00 GMT From: karl@empirical.com (Karl Auerbach) To: comp.protocols.tcp-ip Subject: Re: Interoperability Convention  > Does anyone has the info on the interoperability convention ? (tie, date, location, > etc.) Or did I miss it ? Thank you. Are you talking about the TCP/IP bakeoff? If so, you missed it. The first annual TCP/IP bakeoff was held -- let me read my t-shirt -- Feb 8-12 of this year at FTP Software. It was sponsered by TGV, Empirical Tools and Technologies, FTP, and Intercon. Overall, it was a pretty useful event. There will be another bakeoff. Notice will be posted far and wide. --karl--  -----------[000027][next][prev][last][first]---------------------------------------------------- Date: Tue, 4 May 1993 09:49:46 GMT From: queloz@bernina.ethz.ch (Ronald Queloz) To: comp.protocols.tcp-ip,comp.unix.programmer Subject: Broadcast using TCP/IP sockets, how to do?  Hi netlanders, Can somebody tell me how to do a broadcast send using berkeley sockets running on a tcp/ip protocol stack? Is there some sample code available? Anybody having some experience in doing this with XTI/TLI? Thanks in advance Ron.  -----------[000028][next][prev][last][first]---------------------------------------------------- Date: Tue, 4 May 1993 11:26:25 GMT From: frisicej@ldoc03.ldc.dupont.com To: comp.protocols.tcp-ip Subject: question Regarding BIN  We are currently testing TGV Multinet V3.2 with the load balancing feature for VAX Clusters. The way this works is that the cluster IP name is defined in the authoritative DNS as a list of NS records, each pointing to a cluster member. The query from a resolver is answered by TGV with the list of cluster members in order of preference. The TTL of those records is 5 secondes. Now this is where the problem starts. The first query is coming from TGV via a number of Name Servers and has the original TTL of 5 sec. Subsequent queries, however, are answered by the Name Servers from their cache and the TTL is 5 Minutes, due to the BIND V 4.8.1 minimum TTL. We asked TGV to use a TTL of 0 so that (RFC 1035) it signals the Name Servers and resolvers not to cache the record. This is what they answered: "BIND (basically what 99.9% of the nameservers on the Internet are based on) doesn't properly handle records with zero TTL. The BIND implementation takes all responses and caches them, and then generates answers from that cache. It would be difficult to fix BIND to take zero TTL records and let them bypass this cache, and it would be impossible to get every nameserver on the Internet upgraded." I wonder if this is really true and if so how come that the vendors are not following RFC 1035. Does anybody have any input on this? I would be glad to receive some socond opinions. A second issue. Does anybody know about DNS resolver implementations (PC TCP/IP stacks, workstations, Terminal Servers, etc.) that cache answers to DNS queries? Thank you.  -----------[000029][next][prev][last][first]---------------------------------------------------- Date: Tue, 4 May 1993 11:49:36 GMT From: petervc@sci.kun.nl (Peter van Campen) To: comp.protocols.tcp-ip Subject: Re: RARP through a Router?  In <fred_sC5vKwt.GL7@netcom.com> fred_s@netcom.com (Frederick Scott) writes: >tli@cisco.com (Tony Li) writes: >>In article <1qeqbaINNkka@charnel.ecst.csuchico.edu> >>dpike@oavax.csuchico.edu (Dan Pike) writes: >> Why am I not able to RARP across a router? I have a bridge and our >> management station on the same Cabletron MMAC, but I'm still not able to >> RARP an IP address to the bridge. The two devices are in different >> subnets (one is in .78.xxx and the other is in .80.xxx). Interface 0 of >> our AGS+ goes to a port on the FOMIM which also connects all of our >> buildings via fiber. The subnet mask of each of the buildings on campus >> is set up as though it was a class c address. Why will the router not >> allow the management station to RARP an IP address to the bridge? Any >> help you can offer would be greatly appreciated. >> >>RARP is an unroutable protocol. It must be bridged. >More specifically, I believe RARP is a *broadcast* protocol (at least the >request is). Broadcast packets are not normally routed, the reasoning being >that if they were, one broadcast on some little net somewhere would eventually >make its way to every net in the universe. Worse yet, any redundant network >routed links (and we know there are plenty in the Internet), they would >rebroadcast them 'round and 'round forever (as RARP has no time-to-live >counter, as IP does) repeating them back to their source and everywhere else >on every cycle, eventually destroying the network. Bridges have protection >against this phenomenon designed in. I thought it could be of interest to share my experiences: - Some time ago we booted a diskless Sun-SLC (SunOS4.0.3) through a cisco AGS+, without any help from a server on its own subnet, just to see if it worked. It did! Of course we needed to bridge RARP, and forward some other UDP-broadcasts to a server on a different subnet. - When we tried it out again on SunOS4.1.2 the SunOS rarpd refused to give a RARP reply, because the client was not on his subnet. I think a rarpd should not know anything about subnet-masks, since RARP is not IP, but I'm not sure whether Sun will change this. Regards, Peter van Campen ----------------------------------------------------------------------------- Peter van Campen, petervc@sci.kun.nl, Computer and Communications Department Faculty of Science, University of Nijmegen, 6525 ED NIJMEGEN, The Netherlands -----------------------------------------------------------------------------  -----------[000030][next][prev][last][first]---------------------------------------------------- Date: 4 May 93 20:42:32 -0500 From: harvey@indyvax.iupui.edu To: comp.protocols.tcp-ip Subject: Re: Two IP networks -> one physical network  In article <1993May4.195123.25003@frcs.Alt.ZA>, paul@frcs.Alt.ZA (Paul Nash) writes: > jim@cs.strath.ac.uk (Jim Reid) writes: > >> Er... I hope you don't consider a broadcast storm as something that's >> likely to go unnoticed. If you have two or more IP networks on the >> once cable, *everyone* has to take care over broadcast addresses. > > I recently saw something like this with two IP subnets on the same > physical wire, a PC-Router with two legs onto that wire, and RIP. > Whenever a big Cisco sent out a RIP update, one leg would pick it > up, re-broadcast out the other leg, which the first would pick up > again, and re-broadcast ... until the hopcount exceeded 16. This > would take a second or two at a time, and was quite fun to watch. If you are using Ciscos you can have multiple subnets on one physical cable by setting a "secondary address" on that subnet on the interface on that cable. Each Cisco on the physical cable has to have a secondary address set on its interface on that cable. I don't know how it works with RIP but it works fine with IGRP. We've used this feature here at IUPUI mostly for bridging a new subnets onto the backbone until a building's router is in place. It would seem to be ideal for migrating from one set of addresses to another as well. I would expect that other brands of dedicated routers have similar features. -- James Harvey IUPUI OIT Technical Support -- VMS/Unix/Networks harvey@iupui.edu uucp:iugate!harvey bitnet:harvey@indyvax  -----------[000031][next][prev][last][first]---------------------------------------------------- Date: Tue, 4 May 1993 12:57:37 GMT From: sls@tct.com (Scot Schneebeli) To: comp.protocols.tcp-ip Subject: tcp checksum errors  I'm not sure that this is the correct place for the following question, but there didn't seem to be a better one, so ..... I've been getting checksum errors when sending data to other machines on our network. I've RTFM and it's useless (unless you need to know how to ping). What is weird is that if the file I'm transmitting has a size >= 4096 it gets the checksum errors on the other side and keeps resending/getting errors until it times out. I can _receive_ a file of _any_ size, no problem. Small files transmit without problems. NFS works. I've swapped out ethernet cards, no help. I've compared kernel configurations with other computers here which don't have the problem. Can't see any real differences which should cause these problems. I'm running Interactive's V.3 on a 486, the other machines are 386s. I'm not knowledgeable enough to know if this would cause problems. HELP! I'm open to any suggestions on how to solve this or if there is a better place to ask this question. Thanks. Scot Schneebeli <sls@tct.com>  -----------[000032][next][prev][last][first]---------------------------------------------------- Date: 4 May 1993 14:10:51 GMT From: dwolfe@lerc.nasa.gov To: comp.protocols.tcp-ip Subject: DCE RPC vs ONC RPC ?  Could someone post a summary of these ? What level of interoperability, if any... Session layer protocol differences .... Thanks. =========================================================================== Dana Wolfe dwolfe@lerc.nasa.gov Telecommunications and Networking NASA Lewis Research Center Phone: (216) 433-8270 Cleveland, OH FAX: (216) 433-8000 ===========================================================================  -----------[000033][next][prev][last][first]---------------------------------------------------- Date: Tue, 4 May 1993 14:11:41 GMT From: vjs@rhyolite.wpd.sgi.com (Vernon Schryver) To: comp.protocols.tcp-ip Subject: Re: Two IP networks -> one physical network  In article <JIM.93May4115543@lister.cs.strath.ac.uk>, jim@cs.strath.ac.uk (Jim Reid) writes: > In article <hmb423s@rhyolite.wpd.sgi.com> vjs@rhyolite.wpd.sgi.com (Vernon Schryver) writes: > In article <1993May3.140544.20097@Princeton.EDU>, burt@hart.Princeton.EDU (Burton Rosenberg) writes: > > Is it possible for a single physical ethernet to be associated > > with two or more IP networks? > > There are some oddities associated with machines seeing > broadcasts for the wrong network, but none that are likely > to be noticed during a few weeks or even months during > renumbering. > > Er... I hope you don't consider a broadcast storm as something that's > likely to go unnoticed. If you have two or more IP networks on the > once cable, *everyone* has to take care over broadcast addresses. > Suppose something like routed or rwhod broadcasts on one of the IP > networks. A host on another IP network will see this broadcast - it's > on the same cable. If it's not configured properly, the host may > decide to forward this packet back into the network it came from, > causing a flurry of broadcasts. [It might even forward the broadcast > packet that it sent too....] This can lead to an infinite loop and a > saturated network. > > Even if you can avoid the broadcast problems, you may need to think > carefully about ICMP redirects and routing between the IP networks. > > It's probably better and safer all round if you separate the IP > networks on to physically separate networks. > > Jim Sure, and it's better to have just one IP network to not waste IP numbers. It's better and safer to not have any misconfigured machines. While we're wishing for nice things, let's also make me rich. Broadcast storms can be a problem, but if your routers are so broken that they forward broadcasts, then you don't need to have two networks on one wire to have problems. If you need to renumber a few hundred or even a just a few dozen hosts, to move them logically but not physically from one IP network to another, the hack of using 2 IP networks on one wire is in fact the most reliable solution. The other solutions are: -string another wire, and as each host is renumbered, physically move it, probably leaving the old wire in place when finished. It's obviously far more expensive and quite unreliable to pull a new wire, not to mention fiddling with drop cables and so on. If you're using hubs (e.g. 10BaseT), you could buy a second hub, and re-punch each host as it's renumbered. Hubs are not cheap, take precious closet space and power, and at least with some punch down blocks, you only get a few punches before they must be replaced. Punch down blocks are cheap, but the labor to replace them is anything but cheap. The inevitable hassles when someone makes the wrong new punches are worse than when some uses the wrong new host number. -renumbering all of the hosts at once. This works fine for a handful of machines, or if all of the machines are toys or there are other reasons why no one cares if they work for a week. In real life, where the machines must stay up, you simply can't use red letter days. I've seen and helped with moves with all 3 techniques, and the clear winner has been kludging the IP addresses, not extra hardware or red-letter days. Vernon Schryver, vjs@sgi.com  -----------[000034][next][prev][last][first]---------------------------------------------------- Date: 4 May 93 19:32:08 From: amoss@shuldig.cs.huji.ac.il (Amos Shapira) To: comp.protocols.tcp-ip,comp.unix.programmer Subject: Re: Broadcast using TCP/IP sockets, how to do?  queloz@bernina.ethz.ch (Ronald Queloz) writes: Can somebody tell me how to do a broadcast send using berkeley sockets running on a tcp/ip protocol stack? Is there some sample code available? Anybody having some experience in doing this with XTI/TLI? You mean TCP broadcast?? No such thing. UDP broadcast means you either "connect" to the broadcast address (that's virtual since you don't actually connect to this address but tell the kernel that this is the address for packets, so you can use write(2) and send(2)) or do sendto(2) to the broadcast address. Old BSD systems required superuser and doing "setsockopt(s, ..., SO_BROADCAST)" to make broadcasts work, "newer" systems (most of the "common" systems today, as far as I know) will let any user just do "sendto" to the broadcast address. Maybe you would like to look in the examples from Stevens' and/or Comer which should be available for anonymous from ftp.uu.net. Hope this helps, --Amos -- --Amos Shapira (Jumper Extraordinaire) | "It is true that power corrupts, C.S. System Group, Hebrew University, | but absolute power is better!" Jerusalem 91904, ISRAEL | amoss@cs.huji.ac.il | -- the Demon to his son  -----------[000035][next][prev][last][first]---------------------------------------------------- Date: Tue, 4 May 1993 16:15:17 GMT From: erick@sunee.uwaterloo.ca (Erick Engelke) To: comp.protocols.tcp-ip Subject: Re: Two IP networks -> one physical network  vjs@rhyolite.wpd.sgi.com (Vernon Schryver) writes: >, jim@cs.strath.ac.uk (Jim Reid) writes: >> vjs@rhyolite.wpd.sgi.com (Vernon Schryver) writes: >> burt@hart.Princeton.EDU (Burton Rosenberg) writes: >> > Is it possible for a single physical ethernet to be associated >> > with two or more IP networks? >> >> There are some oddities associated with machines seeing >> broadcasts for the wrong network, but none that are likely >> to be noticed during a few weeks or even months during >> renumbering. >> >> Er... I hope you don't consider a broadcast storm as something that's >> likely to go unnoticed. >> ... >> causing a flurry of broadcasts. [It might even forward the broadcast >> packet that it sent too....] This can lead to an infinite loop and a >> saturated network. Actually, no. IP's TTL means you would have to have a pretty broken router to have such an infinite loop. In practice, even with lots of unknown hardware and software, it works out pretty easy. >> It's probably better and safer all round if you separate the IP >> networks on to physically separate networks. This is really not so bad. There is a lot of extra traffic, but it's workable for the period of renumberring, say a few days up to a month or so. I've had to do this several times too, Vernon's method is simple and workable. My only advice is to keep a network monitor on the net and look at your biggest packet producers if they seem to be excessive. And the only special attention has to be paid to devices which connect the two subnets, like routers. Erick -- Networking is the concept of having data, finding it somewhere else and thinking that it's a good thing. A distributed environment just means you are less picky about where it ends up before calling the whole process a success. Plumbers call it a leak.  -----------[000036][next][prev][last][first]---------------------------------------------------- Date: Tue, 4 May 1993 16:22:26 GMT From: cpearce@nemesis.acs.unt.edu (Chris Pearce) To: comp.unix.admin,comp.protocols.tcp-ip,alt.internet.access.wanted Subject: Help with non-conformant IP addresses  Please excuse me if I have posted this article to an inappropriate group. It concerns a subject for which I could not determine a completely appropriate newsgroup. I'm currently trying to get my company connected to the Internet. The problem is that we currently have an IP network in place that uses IP addresses not assigned to our company by NIC. This network of about 200 machines may require significant effort to reconfigure to conform to the class C address currently assigned to us. One possibility I've been looking into is that of using a router to hide non-conformant addresses from the Internet. Hosts that can connect to the Internet would have conformant IP addresses, of course, but it should be possible to set up a router so that if a local host wished to talk to one of the non-conformant machines, the router could place the packet on the non-conformant network. This, of course, would create a blind spot for us in the Internet, but such a blind spot is an acceptable loss. However, I am not sure whether this scheme does not have costs of its own. Several questions remain in my mind. Would such a scheme have other, more dangerous side effects? How high would the maintenance costs of such a scheme be? Would this scheme work at all? Does anyone have any horror stories about maintaining a non-conformant IP address? And how does this scheme balance against the short-term pain of bringing our IP network into conformance? If you know of a more appropriate group to post this question, please let me know. I prefer email replies to posted replies, but if that means you won't reply, then by all means post! Eagerly awaiting your comments, Chris Pearce, cpearce@nemesis.acs.unt.edu -- Chris Pearce -- cpearce@nemesis.acs.unt.edu How do you say delicious? How do you say delovely? How do you say delectable, define? How do you say - deGORgeous? How do you say dewith-it? How do you say Delite?  -----------[000037][next][prev][last][first]---------------------------------------------------- Date: 4 May 1993 18:50:54 GMT From: eoq@vthnw.cvm.msu.edu (Edward Quillen) To: comp.protocols.tcp-ip Subject: Remote BACKUP server software  Is there anything out there that is wide spread and well defined that handles backing up systems from different platforms. More specifically, a TCP/IP server program (like FTPD or RCPD) that accepts backup requests from clients and backs up data and/or files from the clients. I'm about to begin developing one, but thought I would check the net first. Some things it would handle: +Multi-user/security (different clients use same server) +Files with arbitrary data attached (permissions-unix,trustees-novell,...) +Storage to files or devices (at server) +Backup,Restore,List,... from client or server Any references would be greatly appreciated! =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= | ED (Edward Quillen) (517) 336-1293 || "I'll see you again when the | | Vet Teaching Hosp. System Admin. || stars fall from the sky" | | Email: quillen@cps.msu.edu || U2 / ONE TREE HILL | =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=  -----------[000038][next][prev][last][first]---------------------------------------------------- Date: 4 May 93 19:51:23 GMT From: paul@frcs.Alt.ZA (Paul Nash) To: comp.protocols.tcp-ip Subject: Re: Two IP networks -> one physical network  jim@cs.strath.ac.uk (Jim Reid) writes: > Er... I hope you don't consider a broadcast storm as something that's > likely to go unnoticed. If you have two or more IP networks on the > once cable, *everyone* has to take care over broadcast addresses. I recently saw something like this with two IP subnets on the same physical wire, a PC-Router with two legs onto that wire, and RIP. Whenever a big Cisco sent out a RIP update, one leg would pick it up, re-broadcast out the other leg, which the first would pick up again, and re-broadcast ... until the hopcount exceeded 16. This would take a second or two at a time, and was quite fun to watch. It was equally fun to watch the person who had re-arranged the cabling be re-arranged by one of the technicians, wielding a fibre-optic repeater. Paul Nash network grunt and bit-pusher extraordinaire paul@frcs.alt.za PO Box 12475, Onderstepoort, 0110 South Africa  -----------[000039][next][prev][last][first]---------------------------------------------------- Date: 4 May 1993 20:56:45 GMT From: marmary@kaa.informatik.rwth-aachen.de (Mahmoud-Reza Nazeman) To: comp.protocols.tcp-ip Subject: unnecessary Retransmission Timeouts  I am running a simulation program, where two workstations on different ethernet-segments are interconnected through a satellite link. There I am wondering, why so many unnecessary TCP-Retransmission-Timeouts occur, even under the assumption of an error-free (!) connection. The RTO-value is always calculated as in the revised paper of V. Jacobsen ('88) is suggested (for bandwidth-dominated paths): RTO = SRTT + 4 * RTT_VAR . Here's an example, which is representative: As a segment ist sent, the most recent values are: RTT ~= 0.58 s SRTT ~= 0.58 s DEV ~= 0.02 s => RTO ~= 0.67 s The acknowledgement for that segment arrives after about 0.7 s (e.g. because of a suddenly increased load/traffic in the ethernet), so it is just 0.03 seconds too late. An unnecessary Timeout has occured (=> Slow Start => Throughput will go down). My suggestion (for discussion): How about taking the most recent calculated RTO-value, even for segments which are sent in the past. In the example above that would mean, that for the decision, wether a Timer has expired I would not take into account the 0.67 seconds which I have calculated in the past, but I would look at the most recent RTO-value which represents the presnt traffic. In this example the last RTO was about 0.95 seconds. That means that there is no reason for a timer to expire at this time. Any comments about this suggstion are appreciated. Which are the disadvantages of this suggestion? Did I make any logical mistake? thanks in advance, - marmary marmary@kaa.informatik.rwth-aachen.de  -----------[000040][next][prev][last][first]---------------------------------------------------- Date: 4 May 93 22:57:11 GMT From: wca0@ns1.cc.lehigh.edu (W. Cody Anderson) To: comp.protocols.tcp-ip Subject: Re: Printing from an IBM mainframe to printers on an Ethernet bac  In article <1993May3.234511.28914@gumby.dsd.trw.com>, sekine@gumby.dsd.trw.com ( Nancy Y. Sekine) writes: > > >I'm looking for info on products that will enable printing from IBM >mainframe applications to various printers on an Ethernet backbone >(AppleTalk printers, Banyan VINES printers, UNIX lpd-served printers, etc.). > >Right now we're evaluating Interlink Computer Sciences' Enterprise Print >Services software which runs on the mainframe and implements lpr and lpd >through a TCP/IP interface. We've investigated lpd servers to serve >the printers (Incognito Software's UNIX-to-VINES Print Service to >provide lpd capability to Banyan VINES printers; CAP on a UNIX platform [etc...] BAH! Who needs commercial software?? Use Simple Queue Transfer Protocol (SQTP). The systems programmers here at Lehigh developed it for multi-platform print-sharing. The SQTP distribution is available via anonymous ftp from ftp.lehigh.edu:/pub/sqtp/sqtp34.tar.Z. Use it in good health!! It works VERY WELL in Lehigh's distributed environment. Cody A --$ drink < bottle; opener
bottle: cannot open
panic: restarting...

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


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

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

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

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

Most importantly, easy to configure.

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


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

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

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

Vernon Schryver,  vjs@sgi.com


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

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

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

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

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

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


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

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


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

Hello,

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

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

Are there any software available for this purpose ?

Sorry for wasting the bandwidth here since I don't know which news group

Thomason FAN.

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


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

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

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

Any help appreciated, preferably by email.

Thanx.

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


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

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

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

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

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


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

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

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

What is correct?

Hans.


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

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

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

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

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

Thanks for any help

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


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

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

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

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

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

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

Any ideas appreciated.

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


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

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

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

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

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


-----------[000052][next][prev][last][first]----------------------------------------------------
Date:      Wed, 5 May 1993 18:00:38 GMT
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject:   IP over ARDIS?

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


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

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

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

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

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

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


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


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

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

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

Thanks...
--

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


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

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

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

Substantially, I believe it's correct.

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

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

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

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

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

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

Fred


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

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

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

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

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

thanks,
--

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


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

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

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

mjr.


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

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

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

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


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

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

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

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

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

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

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


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

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

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

- Steve


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

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

Thanks!

Remy Le Flem
Polytechnic University
New York


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

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

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

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

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

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


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

In article <1s6lad$m5@urmel.informatik.rwth-aachen.de> marmary@kaa.informatik.rwth-aachen.de (Mahmoud-Reza Nazeman) writes: >I am running a simulation program, where two workstations on different >ethernet-segments are interconnected through a satellite link. > >There I am wondering, why so many unnecessary TCP-Retransmission-Timeouts >occur, even under the assumption of an error-free (!) connection. > >The RTO-value is always calculated as in the revised paper of V. Jacobsen ('88) >is suggested (for bandwidth-dominated paths): > > RTO = SRTT + 4 * RTT_VAR . Hmmm, I wonder if Van ever considered that as RTT_VAR approeaches 0, that RTO approaches SRTT (creating a potential race condition). Seems like this function should be bounded such that RTO is never less than, say, 1.25 SRTT. Art  -----------[000064][next][prev][last][first]---------------------------------------------------- Date: 5 May 93 22:46:37 GMT From: jaques@alantec.com (Robert Jaques) To: comp.protocols.tcp-ip Subject: should a router reply to this arp request  router with proxy arp configured on. Should it reply to this arp packet>>> ... partial arp packet sender hardware address: the requester boxes ethernet address sender Protocol address: 0.0.0.0 targer hardware address: 00-00-00-00-00-00 target protocol address: senders proposed ethernet address The RFC is a little ambigous on this. thanks bob  -----------[000065][next][prev][last][first]---------------------------------------------------- Date: 5 May 93 22:47:46 GMT From: art@acc.com (Art Berggreen) To: comp.dcom.sys.cisco,comp.protocols.tcp-ip Subject: Re: Cisco IP filtering, the "established" criterion, and FTP  In article <1993May5.172508.17650@unipalm.co.uk> tim@unipalm.co.uk (Tim Goodwin) writes: >Cisco routers can filter TCP packets according to whether they >relate to an established connection (on the basis of the ACK and RST >bits). > >I hoped to use this as the basis of a filtering scheme for a Cisco >connecting a LAN to the Internet: only "established" packets are >permitted onto the LAN (plus, for instance, any TCP packet to port 25 >on the mail server). > >When I put this in place, FTP suddenly stopped working. A quick >glance at RFC 959 suggest that FTP works in a somewhat bizarre way. >When I type "get file", my client obtains an unprivileged port from >the OS, sends the address of that port down the control channel, and >waits for the server to initiate a data connection from port 20 back >to that unprivileged port. (Are these details correct?) > >So far as I can see, this completely foils my use of the "established" >filter criterion. The only way I can find to reinstate FTP is to >permit any packets going to unprivileged ports (the Cisco can only >filter on destination port). > >Is my reading of the situation correct? Is there a better solution? Even worse if the server uses an arbitrary socket at it's end. The FTP data transfer then happens between two random sockets. So even if you filter on source and destination sockets, FTP can be a big problem. Art  -----------[000066][next][prev][last][first]---------------------------------------------------- Date: Thu, 6 May 1993 04:59:24 +0000 From: vadim@cix.compulink.co.uk (Vadim Lebedev) To: comp.protocols.tcp-ip Subject: Re: Two IP networks -> one phy  In-Reply-To: <JIM.93May4115543@lister.cs.strath.ac.uk> jim@cs.strath.ac.uk (Jim Reid) In article : <JIM.93May4115543@lister.cs.strath.ac.uk> jim@cs.strath.ac.uk (Jim Reid) writes: > > In article <hmb423s@rhyolite.wpd.sgi.com> vjs@rhyolite.wpd.sgi.com (Vernon Schryver ) writes: > > In article <1993May3.140544.20097@Princeton.EDU>, burt@hart.Princeton.EDU (Burto n Rosenberg) write > s: > > Is it possible for a single physical ethernet to be associated > > with two or more IP networks? > > There are some oddities associated with machines seeing > broadcasts for the wrong network, but none that are likely > to be noticed during a few weeks or even months during > renumbering. > > Er... I hope you don't consider a broadcast storm as something that's > likely to go unnoticed. If you have two or more IP networks on the ..... I wonder if that broadcast storm problem could bot be resolved by using ethernet MULTICASTING instead of BROADCASTING. E.G. configure all host to the IP net 1 to use MULTICAST ADRESS1 in place of BROADCAST and all hosts on the IP net 2 to use MULTICAST ADDRESS 2.... That way the broadcasts from one 'net' will not be visible on the second 'net'... Vadim.  -----------[000067][next][prev][last][first]---------------------------------------------------- Date: 6 May 93 05:40:36 GMT From: claude@bauv.unibw-muenchen.de (Claude Frantz) To: comp.unix.admin,comp.protocols.tcp-ip,alt.internet.access.wanted Subject: Re: Help with non-conformant IP addresses  cpearce@nemesis.acs.unt.edu (Chris Pearce) writes: >Please excuse me if I have posted this article to an inappropriate group. It >concerns a subject for which I could not determine a completely appropriate >newsgroup. >I'm currently trying to get my company connected to the Internet. The problem >is that we currently have an IP network in place that uses IP addresses not >assigned to our company by NIC. This network of about 200 machines may >require significant effort to reconfigure to conform to the class C address >currently assigned to us. Sure, but it's probably the most simple and economical method.  -----------[000068][next][prev][last][first]---------------------------------------------------- Date: 6 May 93 11:44:39 From: jim@cs.strath.ac.uk (Jim Reid) To: comp.protocols.tcp-ip Subject: Re: Two IP networks -> one phy  In article <memo.195372@cix.compulink.co.uk> vadim@cix.compulink.co.uk (Vadim Lebedev) writes: In-Reply-To: <JIM.93May4115543@lister.cs.strath.ac.uk> jim@cs.strath.ac.uk (Jim Reid) > In article <hmb423s@rhyolite.wpd.sgi.com> vjs@rhyolite.wpd.sgi.com (Vernon Schryver ) writes: > In article <1993May3.140544.20097@Princeton.EDU>, burt@hart.Princeton.EDU (Burto n Rosenberg) write > s: > > Is it possible for a single physical ethernet to be associated > > with two or more IP networks? > > There are some oddities associated with machines seeing > broadcasts for the wrong network, but none that are likely > to be noticed during a few weeks or even months during > renumbering. > > Er... I hope you don't consider a broadcast storm as something that's > likely to go unnoticed. If you have two or more IP networks on the ..... I wonder if that broadcast storm problem could bot be resolved by using ethernet MULTICASTING instead of BROADCASTING. Not really. All that would do is shift the goalposts. First of all, IP multicasting is somewhat experimental and few commercially available TCP/IP implementations support it. E.G. configure all host to the IP net 1 to use MULTICAST ADRESS1 in place of BROADCAST and all hosts on the IP net 2 to use MULTICAST ADDRESS 2.... That way the broadcasts from one 'net' will not be visible on the second 'net'... Alas no. To transmit an IP broadcast on ethernet, the IP packet is encapsulated in an ethernet frame which has the broadcast ethernet destination address: ff:ff:ff:ff:ff:ff. EVERY host on that physical network will see that broadcast packet. The network interfaces will pull the packet off the wire and hand it to the IP software in the kernel. Depending on the addressing information in the IP packet, this software will choose to discard the IP packet or forward it or pass it up to some higher-level software such as TCP and then to a telnet application (say). Wth multicasting, the IP multicast address is usually encapsulated inside an ethernet broadcast packet. This means that, as far as the ethernet is concerned, there is no real difference between the IP broadcast and multicast. It follows that it is up to each host's IP software to make sense of the IP packet and drop/process/route the packet. The bottom line is that each host has to know the broadcast and multicast addresses for each IP network on the ethernet and, critically, know not to forward these packets. This is not much different from telling each host about the other IP networks sharing the cable. Jim  -----------[000069][next][prev][last][first]---------------------------------------------------- Date: Thu, 6 May 1993 07:07:55 GMT From: kaiwan@ee.fit.edu (Kaiwan Hongladaromp.) To: comp.protocols.tcp-ip Subject: How to determine the path of each packet?  Hi all.... As the subject said.. How can I acquire the path that my packet go thru? I like to know (if possible) from both side views, ie. sender and receiver. And is this possible both on datadram and connected-orientd protocol.. I'd be appreciated if the answer is directly to my mbox (kaiwan@ee.fit.edu). Because this group is not my regular basis group :-) anyway I'll keep looking from time to time... Thanks..  -----------[000070][next][prev][last][first]---------------------------------------------------- Date: Thu, 6 May 1993 08:13:31 GMT From: ddr@informatik.uni-rostock.de (Detlef Drewanz) To: comp.protocols.tcp-ip Subject: Re: RARP enet protocol number 8035, 0806 or both?  In article <hans.17.0@anest4.anest.ufl.edu>, hans@anest4.anest.ufl.edu (Hans van Oostrom) writes: > The RARP protocol uses the same packet as the ARP protocol, but with > different op-codes. Does the standard specify that I have to use ethernet > protocol number 8035 or can I also use 0806? > > I see some RARP packets on my net that use 0806, and they are being > interpreted by some tcp/ip implementation as ARP packet, inserting an > address of 00:00:00:00:00:00 in the table. > There are other implementations that do not handle rarp packets with type > 0806. > > What is correct? I think that 8035 is correct. Most rarp-codes (and /usr/include/netinet/if_ether.h ) use this code and it would be the best to use this. -- Detlef +---------------------------------------------------------------+ | Detlef Drewanz e-mail: ddr@informatik.uni-rostock.de | | University of Rostock, Dept. of CS, Germany | +---------------------------------------------------------------+  -----------[000071][next][prev][last][first]---------------------------------------------------- Date: Thu, 6 May 1993 08:16:24 GMT From: ddr@informatik.uni-rostock.de (Detlef Drewanz) To: comp.protocols.tcp-ip Subject: ETHERNET-TYPCODES  Where can I get all the used the Ethernet-Typcodes. Is there a rfc or .. where are the Codes are listed ? - Detlef +---------------------------------------------------------------+ | Detlef Drewanz e-mail: ddr@informatik.uni-rostock.de | | University of Rostock, Dept. of CS, Germany | +---------------------------------------------------------------+  -----------[000072][next][prev][last][first]---------------------------------------------------- Date: Thu, 6 May 1993 10:39:22 GMT From: ddr@informatik.uni-rostock.de (Detlef Drewanz) To: comp.sys.hp,comp.protocols.tcp-ip Subject: Diskless Hp-Bootprotocol  Hi, i have a question to HP 9000/series300: Does anybody know, which protocol the diskless HP 9000/3xx use for loading the kernel. The motivation is to boot a HP from a SUN or DECstation. Our HP-Server is very slow (nfs,...) and we think that we can get more availability for our HP-workstations, if we could boot and serve they by faster machines. Thanks in advance. -- Detlef +---------------------------------------------------------------+ | Detlef Drewanz e-mail: ddr@informatik.uni-rostock.de | | University of Rostock, Dept. of CS, Germany | +---------------------------------------------------------------+  -----------[000073][next][prev][last][first]---------------------------------------------------- Date: 6 May 1993 13:30:54 GMT From: mjr@tis.com (Marcus J Ranum) To: comp.dcom.sys.cisco,comp.protocols.tcp-ip Subject: Re: Cisco IP filtering, the "established" criterion, and FTP  >I hoped to use this as the basis of a filtering scheme for a Cisco >connecting a LAN to the Internet: only "established" packets are >permitted onto the LAN >When I put this in place, FTP suddenly stopped working. A quick >glance at RFC 959 suggest that FTP works in a somewhat bizarre way. Correct. FTP is rather unique in its use of the network. ;) Generally this problem is solved either by putting a proxy FTP service on your firewall machine, or by jiggering FTP to only bind ports (on the client side) within a specified range, and then permitting the screening router to let them through. The latter approach means you can still be reached via non-established connections on a small range of ports - which has a certain risk associated with it. There are lengthy discussions of this issue archived in the firewalls mailing list archives, on ftp.greatcircle.com. mjr.  -----------[000074][next][prev][last][first]---------------------------------------------------- Date: Thu, 6 May 1993 14:35:55 GMT From: clfang@csie.nctu.edu.tw (Chien-Lu Fang) To: comp.protocols.tcp-ip Subject: HELP: socket buffer overflow ?  How to solve the problem that ... In the condition that many processes send MESSAGE to one process at the same time. Cause the "socket buffer overflow" , when using "socket UDP" protocal. How to increase the "socket buffer size" ? Help !!!..... Wood Chen woodchen@csie.nctu.edu.tw woodchen@arch9.csie.nctu.edu.tw  -----------[000075][next][prev][last][first]---------------------------------------------------- Date: Thu, 6 May 1993 15:00:51 GMT From: vjs@rhyolite.wpd.sgi.com (Vernon Schryver) To: comp.protocols.tcp-ip Subject: Re: Two IP networks -> one phy  I also doubt that it would be practical to change the broadcast address to a MAC multicast address. Setting asside how you might convince most implementations to use anything other than their usually hard-coded ff:ff:ff:ff:ff:ff as the MAC address for IP or ARP broadcasts, the whole reason to use the 2-IP-networks-on-one-wire kludge was to avoid having to re-configure a lot of machines simultaneously. However, ... In article <JIM.93May6114439@lister.cs.strath.ac.uk>, jim@cs.strath.ac.uk (Jim Reid) writes: > ... > Wth multicasting, the IP multicast address is usually encapsulated > inside an ethernet broadcast packet. This means that, as far as the > ethernet is concerned, there is no real difference between the IP > broadcast and multicast. It follows that it is up to each host's IP > software to make sense of the IP packet and drop/process/route the > packet. This is false, at least for any reasonable TCP/IP implementation, or any unreasonable TCP/IP implementation that wants to multicast to or from a reasonable TCP/IP implemenation. (Of, course, you use multicast addresses with UDP/IP datagrams, not TCP/IP segments.) An IP multicast packet should be transmitted using the appropriate class-D address, which should be translated into the appropriate Ethernet or FDDI MAC-level multicast address with simple masking operations. See, for example, RFC-1112 and RFC-1075. For a real application, try, for example, the Internet "mbone" audio and video. It is also false that all machines on a wire hear all multicasts. The whole purpose of using multicast instead of broadcast is to reduce the number of machines that receive the packets. Very old hardware (e.g. VAX's) were unable to listen for more than a small number of multicast addresses at one time. Some newer hardware is similarly crippled. However, reasonable, modern hardware and/or firmware can filter at least dozens of multicast Ethernet or FDDI addresses at the speed of the media. > The bottom line is that each host has to know the broadcast > and multicast addresses for each IP network on the ethernet and, > critically, know not to forward these packets. This is not much > different from telling each host about the other IP networks sharing > the cable. Depending on what is intended, this is partly false. The Host Requirements RFC requires that a host or router pay attention to to the multicast bit in the MAC address that came with an IP packet, and to refuse to forward the packet if the MAC address was a multicast or broadcast address. (Subject, of course, to the special considerations of forwarding class D IP addresses.) Vernon Schryver, vjs@sgi.com  -----------[000076][next][prev][last][first]---------------------------------------------------- Date: Thu, 6 May 1993 15:02:43 GMT From: yost@netcom.com (David Yost) To: comp.protocols.ppp,comp.protocols.tcp Subject: bad ppp telnet performance  I used MacPPP for the first time yesterday. It's a neat thing, and I want to thank its authors and all the contributors to PPP. There's just this one thing that I hope can be improved: If I start up an ftp, then go back to my telnet window while the ftp is still going, the telnet performance goes to hell. It appears that the echoes for the characters I type get queued up as single packets and delivered as such, interleaved with the ftp packets, and delayed by several seconds! Such packets should be coalesced in the queue so that when the data finally can be sent, it all goes at once. Furthermore, it seems to me there really should be some way of prioritizing streams, or at least a way of designating one stream as higher priority than all others. I realize that this may be a hard problem because it may require cooperation among different layers and across the connection, and that this may seem inelegant, but the principle of User Centered Design suggests that the most dominant concern for elegance here should be the fact that the performance is so bad for humans. Anyone know how to fix this? Is ther any ongoing work? --dave yost P.S. The host software is SunOS 4.1.3. Don't know what PPP we're running.  -----------[000077][next][prev][last][first]---------------------------------------------------- Date: Thu, 6 May 1993 15:49:19 GMT From: vjs@rhyolite.wpd.sgi.com (Vernon Schryver) To: comp.protocols.tcp-ip Subject: Re: Wanted: to identify routers in a path  In article <1993May2.181059.26699@acc.com>, art@acc.com (Art Berggreen) writes: > In article <C69ItC.9Gt@aaahq05.aaa.com> mikel@aaahq05.aaa.com writes: > >There was a program I've seen at USENIX (which I think comes from Solbourne) > >which tells you the names (or addresses) of the routers allong a certain path. > > > >You give it an address, like "kgbvax.kgb.org.su" and it will identify all > >of the routers allong the path taken. > > Sounds like you are talking about "traceroute" (originally created by > Van Jacobsen). Traceroute is good for identifying gateways on the out-bound path. Traceroute doesn't help on the return path, unless you can log onto the remote machine and fire traceroute back toward your home. ping -R (see recent BSD source) works on both directions, provided the round trip path is not too long, and the remote end and all intermediates do not mess up the record-route option. In recent years, it seems few systems mess up the RR option. Vernon Schryver, vjs@sgi.com  -----------[000078][next][prev][last][first]---------------------------------------------------- Date: 6 May 93 15:53:54 GMT From: art@acc.com (Art Berggreen) To: comp.protocols.tcp-ip Subject: Re: How to determine the path of each packet?  In article <kaiwan.736672075@yacht> kaiwan@ee.fit.edu (Kaiwan Hongladaromp.) writes: >Hi all.... > >As the subject said.. How can I acquire the path that my packet go thru? >I like to know (if possible) from both side views, ie. sender and receiver. >And is this possible both on datadram and connected-orientd protocol.. > >I'd be appreciated if the answer is directly to my mbox (kaiwan@ee.fit.edu). >Because this group is not my regular basis group :-) anyway I'll keep looking >from time to time... > >Thanks.. The most common first order approximation is to run the traceroute program from both ends. If there is really only one possible path, this works well. Be aware though, that every IP packet is routed independently and the paths taken by two packets may differ. Traceroute doesn't really deal with this because it sends a whole series of packets. With the growth of the Internet and the use of more intelligent routing and loadsharing, this phenonmenon is likely to become more common. The most accurate way to capture this information would be to use the Record Route IP option, but the size of the Internet has long since exceeded the capability of that mechanism (except in very short paths). As for CO vs DG protocol traffic, it is all carried by IP at the network level, and IP is inherently datagram based. Art  -----------[000079][next][prev][last][first]---------------------------------------------------- Date: 6 May 93 17:16:15 GMT From: jessea@u013.me.vp.com (Jesse W. Asher) To: comp.unix.admin,comp.protocols.tcp-ip Subject: Matching netstat display with process ids.  If I do a netstat and see some connections that I know shouldn't be there (like they are hung, etc) how can I match what I see in the netstat display with a process id so I can kill the offending process? Any ideas on how to do this?? -- Jesse W. Asher (901)762-6000 Varco-Pruden Buildings 6000 Poplar Ave., Suite 400, Memphis, TN 38119 Internet: jessea@vpbuild.vp.com UUCP: vpbuild!jessea  -----------[000080][next][prev][last][first]---------------------------------------------------- Date: Thu, 6 May 1993 17:18:41 GMT From: Carlos Reed <creed@fse.ulaval.ca> To: comp.protocols.tcp-ip Subject: CAPS on phase I, I can't see my server on localtalk  Hi gang! I'm posting the following mesage from a friend of mine. Hello CAP managers! I have installed CAP Native EtherTalk on a SUN IPC SunOS4.1.2 with NIS. Everything look fine but I can't see my SUN from any of my Macs ,on the lacaltalk side. It is like if the NBP of appletalk don't registed me on the localtalk side.. Where is the NBP service in CAP and how can I configure it? We are using phase I , if it can help . Thanks! Louis Demers Universite Laval Tel: (418)656-2074 FAX: (418)656-2018 louis@mobil.arc.ulaval.ca Here a ouput of my system: mobil# aarpd "le0" "EtherTalk" mobil# atis abInit: [ddp: 0.00, 18], [GW: 0.00, 4] starting 11:35:28 05/06/93 Reply num max for lkup reply is 5 (based on 104) mobil# snitch -S -f "SUNMobil" mobil# aufs Apple Unix File Server (mobil Aufs:AFPServer@*) starting mobil# atlook abInit: [ddp: 0.40, 18], [GW: 0.40, 26] starting Looking for =:=@* ... 1 - Martin:-BroadCast@* [Net: 0.6 Node: 27 Skt:252] 2 - GSTH (Mac):AFPServer@* [Net: 0.40 Node: 16 Skt:248] 3 - MMGP:AFPServer@* [Net: 0.6 Node: 22 Skt:251] 4 - Quadra Martin:AFPServer@* [Net: 0.6 Node: 27 Skt:249] 5 - S_CCISD:AFPServer@* [Net: 0.52 Node:129 Skt:129] 6 - S_CLIENT:AFPServer@* [Net: 0.40 Node:215 Skt:129] 7 - S_CTI:AFPServer@* [Net: 0.40 Node:168 Skt:129] 8 - S_FACMED:AFPServer@* [Net: 0.6 Node:128 Skt:129] 9 - S_LAVAL_2:AFPServer@* [Net: 0.40 Node:129 Skt:129] 10 - YDas (Mac):AFPServer@* [Net: 0.40 Node:125 Skt:248] . . . ... 63 - gwfsg:ciscoRouter@EtherTalk [Net: 0.250 Node: 2 Skt:254] 64 - gwjdu.Ethernet0:ciscoRouter@EtherTalk [Net: 0.54 Node: 1 Skt:254] 65 - gwpde:ciscoRouter@EtherTalk [Net: 0.52 Node: 1 Skt:254] mobil# getzones abInit: [ddp: 0.40, 18], [GW: 0.40, 26] starting Count is 52 ZONE FORESTERIE . . . ... ZONE FSA_AGRICULTURE ZONE ETHERTALK ZONE COMTOIS  -----------[000081][next][prev][last][first]---------------------------------------------------- Date: Thu, 6 May 93 17:57:26 BST From: pjc@cc.ic.ac.uk (Peter Churchyard) To: comp.protocols.tcp-ip Subject: Re: multiple control packets  This thread reminded my of a feature of reliable protocols with error recovery (also applicable to other areas where error recovery is in use) which is that often the error processing and recovery activity often masks implementation failures since these can also be taken as 'line noise' etc. So just because it works, doesn't mean that it not generating spurious packets/frames as well. With pocket ether adapters I have used I have found them to be slow and sometimes get connections timed out. Since I don't know how these adapters talk over the parallel port I have always assumed that the parallel port was the bottleneck. Pete.  -----------[000082][next][prev][last][first]---------------------------------------------------- Date: Thu, 6 May 1993 19:43:12 GMT From: sls@tct.com (Scot Schneebeli) To: comp.protocols.tcp-ip Subject: Re: tcp checksum errors  In article <4299@bsu-cs.bsu.edu> sam@bsu-cs.bsu.edu (B. Samuel Blanchard) writes: >In article <C6I6o1.67s@tct.com> sls@tct.com (Scot Schneebeli) writes: >> >> I've been getting checksum errors when sending data to other machines on our >> network. I've RTFM and it's useless (unless you need to know how to ping). >> >> What is weird is that if the file I'm transmitting has a size >= 4096 it >> gets the checksum errors on the other side and keeps resending/getting errors >> until it times out. I can _receive_ a file of _any_ size, no problem. Small >> files transmit without problems. NFS works. I've swapped out ethernet cards, >> Scot Schneebeli <sls@tct.com> > >Is there a MTU/MRU smaller than your Max Packet. We have a Motorola using >slip (unsupported) where the MRU is < MTU's smallest value on connected >system. The motorola can send files/etc fine. Keystrokes to the motorola >are fine. Try varying the data sent with ping until you start getting >errors. > >Detail attempt: > sys-one MRU = 100 > sys-two MTU = 110 > > ping data size <=100 from sys-two to sys-one will work. > ping data size between 101 and 110 will fail, sys-one will only get 100 bytes. > seems reasonable that checksum would fail. crc(110bytes) != crc(100bytes) > >I also agree with prior posting, more info might help if this does not work. Ok here is the info for this and the other posting. I'm using rcp and ftp. There are no sockets, the TCP/IP is going over a local ethernet network, and is on the same segment. We know there are checksum errors due to the fact that error messages came up on the console of one of the machines that I send data to. We have already tried the ping with different packet sizes (1470 would send 1471+ wouldn't) and I have no idea what the MRU and MTU are, they don't exist in the kernel tunable parameters for my system. >-- >B. Sam Blanchard sam@bsu-cs.bsu.edu >418 Winfield Dr (317) 284-7131 work >Greenfield, IN 46140 -- Scot Schneebeli <sls@tct.com>  -----------[000083][next][prev][last][first]---------------------------------------------------- Date: 6 May 1993 20:26:05 GMT From: barmar@think.com (Barry Margolin) To: comp.dcom.sys.cisco,comp.protocols.tcp-ip Subject: Re: Cisco IP filtering, the "established" criterion, and FTP  In article <1sb3ue$4ep@sol.TIS.COM> mjr@tis.com (Marcus J Ranum) writes:
>	Correct. FTP is rather unique in its use of the network. ;)

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

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


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

In article <C6M0Jw.LFs@csie.nctu.edu.tw>, clfang@csie.nctu.edu.tw (Chien-Lu Fang) writes:
|>    How to solve the problem that ...
|>
|>      In the condition that many processes send MESSAGE to
|>
|>    one process at the same time. Cause the "socket buffer
|>
|>    overflow" , when using "socket UDP" protocal.
|>
|>      How to increase the "socket buffer size" ?

Try using setsockopt() call using SO_SNDBUF, SO_RCVBUF parameters.
This call allows the process to set the receive and trasmit buffers for
socket.
- Amod
|>
|>      Help !!!.....
|>
|>
|>
|>      Wood Chen
|>          woodchen@csie.nctu.edu.tw
|>          woodchen@arch9.csie.nctu.edu.tw
|>

--

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


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

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

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

Vernon Schryver,  vjs@sgi.com


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

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

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

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

implementation is doing something special (see below), the packets are
being transmitted across the PPP link in the order they were received.

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

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

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

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

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


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

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

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

Anyone have any experience with keep alive packets on Suns?

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


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

yost@netcom.com (David Yost) writes:

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

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

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

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

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

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

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

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

Ian Donaldson

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

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


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

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

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

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

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

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

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

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

Ran
atkinson@itd.nrl.navy.mil


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

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

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

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

A couple of questions

Are the retransmit timeouts the source of the problem?

What is their significance?

What can I do about them?

The host is a Sun SPARC2 running SunOS 4.1.3

Bob Beattie


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

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

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


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

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

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

--

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


-----------[000093][next][prev][last][first]----------------------------------------------------
Date:      7 May 93 06:11:31 GMT
From:      lars@spectrum.CMC.COM (Lars Poulsen)
Subject:   Re: Help with non-conformant IP addresses

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

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

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

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

Exactly. You can do it right up front, or pay more to do it later. You
cheated and did not do it up front. Now you pay the price. Please smile
--
/ Lars Poulsen, SMTS Software Engineer	Internet E-mail: lars@CMC.COM
CMC Network Products / Rockwell Int'l	Telephone: +1-805-968-4262
Santa Barbara, CA 93117-3083		TeleFAX:   +1-805-968-8256


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

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

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

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


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

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

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

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


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

Hi

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

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

Regards
Armand


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


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

/Hans
--
joho@pfbs.philips.se


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

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

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

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

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

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

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

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

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

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

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

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

2. New features

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

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

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

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

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

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

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

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

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

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

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

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

3. Setting up a bridge

In order to build our bridge, you need:

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

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

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

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

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

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

4. Building the EPROM

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

ml -VM -Duse_filters -Dno_loops bridge.asm

which produces a bridge.com file of about 20K

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

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

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

5. Monitoring the network.

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

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

6. Future extensions

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

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

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

- the OSU KarlBridge program, which can be obtained via anonymous ftp
from nisca.acs.ohio-state.edu, 128.146.1.7, in /pub/kbridge.  Please

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

--- end of file ---


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

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

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

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

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

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


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


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

like sun post solaris and Silicon graphics on unix systems, and at
least ftp s/w on PCs...

>Wth multicasting, the IP multicast address is usually encapsulated
>inside an ethernet broadcast packet. This means that, as far as the
>ethernet is concerned, there is no real difference between the IP

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

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

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

and IGMP tells everyone nicely about the presence of multicast groups
and group members using the well known multicast address concept...

cheers

jon


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

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

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

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

#
#
#
#
#
#


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

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

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

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

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

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


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

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

147.11.22.33	hal
165.11.22.33	hal-sl

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

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

--

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


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

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

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

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

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

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

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


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

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

: >That's probably it.  Check the SCO box's subnet mask to make sure
: >it's using the correct value.  Also check its routing table for a
: >route to the other network via the Novell router.
:
: I think not.  Your Novell is probably acting as a learning bridge.  It knows
: which machines are on each side of the LAN as soon as they talk.  If you moved
: PC-1 to the non-SCO segment and rebooted the Novell server and tried again,
: then you could be sure this was the case if it worked.

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

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

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


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

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

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

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

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

where

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

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

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

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

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

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

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

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

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

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

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


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

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

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

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


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

Hello!

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

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


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

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

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

Vernon Schryver,  vjs@sgi.com


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

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

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

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

??? = ivs

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


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

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

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


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

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

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

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

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

Ran
atkinson@itd.nrl.navy.mil


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

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

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

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

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

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

Vernon Schryver,  vjs@sgi.com


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

Hi,

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

Thanks,
David


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

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

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

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

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

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


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

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

>The important thing the hashmark tells you is
>which is nice to know if your firewall or the ftp server occasionally
>drops sessions.

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

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


-----------[000117][next][prev][last][first]----------------------------------------------------
Date:      8 May 93 20:01:32 GMT
To:        comp.protocols.snmp,comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject:   SNMP capable KA9Q, anyone done it?

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

Thanks.

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


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

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

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

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

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

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

program (and a stock in.ftpd server program on my ppp host). If I run
the regular ftp client program, I'm back to a plugged link...

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


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

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

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

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

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

For an RPC request, the fields in the header are   like this

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

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

For an RPC reply, the fields are like this :

32 bit xid;
32 bit direction field, 1 for REPLY
32 bit reply status, either 0 (MSG_ACCEPTED) or
1 (MSG_DENIED)

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

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

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

Abhijit
File Systems Group, Transarc, Pittsburgh.


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


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

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

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

Thanks

jan@ifs.univie.ac.at


-----------[000121][next][prev][last][first]----------------------------------------------------
Date:      9 May 1993 19:31 MST
To:        comp.protocols.tcp-ip
Subject:   WIRELESS LAN Vendors, this is your golden opportunity of the day.

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

If showing your stuff to several hundred health-care facility
representatives, with the auspices of several major VARs who

gavron@sunquest.com

Or call at
+1 602 570 2546

Thanks

Ehud

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


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

I am looking for info on SONET (DQDB) protocol, specifically on t
he two layers

masami@cs.mtu.edu

Mohammed Sami


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

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

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

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

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

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

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

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

Geert Jan


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

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

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

Thanks.


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

>>Bash even makes csh look fast.

Heck, bash makes tcsh look small :-)

Just another happy Tenex csh user.

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


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

Request For Discussion    RFD

Name: comp.protocols.dicom

Charter:

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

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

Moderated: No

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

Call for Votes: Anticipated around June 6, 1993.

dsc@xray.hmc.psu.edu

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


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

joho@kobe (Hans ter Horst) writes:

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

>/Hans
>--
>  joho@pfbs.philips.se

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


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

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

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

Do you use softwareflowcontrol or hardwareflowcontrol?

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

Regards,
Jan Frederik


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

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

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

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

Cheers,
--
vato@csv.warwick.ac.uk  ...!uknet!warwick!vato        those who disapprove but
@c=GB@o=University of Warwick@ou=Computing Services@cn=Ian Dickinson      read


-----------[000130][next][prev][last][first]----------------------------------------------------
Date:      Mon, 10 May 1993 15:40:48 GMT
From:      drubin@poly.edu (Dave Rubin)
Subject:   NIS/NFS firewall?


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

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

Thanks ... please respond via E-mail.

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


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


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

-robert

------------------------------------------------------------------------------
Robert Thompson                       |  Storage Technology Corporation
Redwood Digital Hardware Design Team  |  2270 South 88th. Street
(303) 673-7747   FAX: (303) 673-2568  |  Louisville, Colorado 80028-0211
--------------------------------------+---------------------------------------
------------------------------------------------------------------------------


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

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

I don't truly know.

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

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

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

Cheers,
--
vato@csv.warwick.ac.uk  ...!uknet!warwick!vato        those who disapprove but
@c=GB@o=University of Warwick@ou=Computing Services@cn=Ian Dickinson      read


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

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

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

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

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


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

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

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

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

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


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

Networld,

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

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

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

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

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

Any help would be appreciated.

Thanks,

Todd			heberlei@cs.ucdavis.edu


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

In article <1sm8i3$ip3@terminator.rs.itd.umich.edu>, Jim.Rees@umich.edu writes: > In article <C6qnAG.M77@cunews.carleton.ca>, mikey@yoho.carleton.ca (Mike G McFaul) writes: > > The real > culprit is the window size that is set in the TCP/IP software layer on > your machines. Its usually set to around 4096 bytes, this is fine for > a 10Mbit/sec ethernet, but way too high for a slow speed ppp link > (remember everything is relative!). > > Window size is not a fixed number. It changes to adapt to the link. Some > implementations of tcp have an initial or maximum window size, or both, and > tuning these is sometimes required for low speed links. > > I suppose there are probably still some old, obsolete implementations of tcp > with fixed windows out there, but you should replace them rather than try to > tune them. Big windows can cause problems. Consider a case, where IP gateways between fast media (e.g. ethernet) and slow (e.g. 56k leased line) have big queues, but not as big as the TCP windows used by the end points. Say the end points workstations have a name that sounds like a flower and use default windows of 60K and the gateways have cute little orange suspension bridges painted on them and use queues of around 56KBytes. Imagine starting a big file transfer over such a route. At the same time, start running a ping (the BSD or BRL variety that runs continually). TCP slow start starts the congestion window small, and ping will report delays on the order of 1 or 2 seconds. Slow start gradually opens the congestion window, and ping will report steadily increasing round trip delays. When the delays reach between 10 and 12 seconds (!), they'll suddenly drop to zero, and after a few seconds start building toward 10-12. This sawtooth pattern continues indefinitely. The 10-12 second delays reported by ping seem much longer if you are trying to use the link for interactive work. What is happening is that as the queue in the nearest gateway fills, the RTT increases. Finally packets are dropped, but the sender does not realize until a long time as has passed, and the gateway's queue is empty. The solution is one or more of: - reduce the default window size in the worstations from 60K to 2-4K. This is the best solution, although it does destroy TCP/FDDI performance, pushing it below 50Mbit/sec. Unfortunately, this solution requires reconfiguring all workstations that might use the slow link. - put a little program in ~guest/.cshrc and similar accounts on machines to which that applies the setsockopt() to fd 0. This works fine, except that you can never seem to find all of the servers that people rcp to or from, and does nothing for FTP. - reduce the queues in the gateways to ~8K. This keeps the congestion window from bloating up, and keeps the delays from getting out of hand. It does mean that some bandwidth is wasted. Vernon Schryver, vjs@sgi.com P.S. want to guess who set the default window size to 60K for FDDI and now spends hours/day using such a wide area link?  -----------[000137][next][prev][last][first]---------------------------------------------------- Date: Tue, 11 May 1993 01:26:15 GMT From: copeland@sdf.lonestar.org (Charles Copeland) To: comp.protocols.tcp-ip Subject: TFTP missing some *.h files?  I got a copy of tftp from stanford and it is missing several .h files. paradigmMon.h, pd_globram.h, pd_i82586.h, asmdef.h, paradigm.h, globram.h Does anybody know where I can get a *full* copy of tftp and tftpd? -- copeland@sdf.lonestar.org *************************  -----------[000138][next][prev][last][first]---------------------------------------------------- Date: Tue, 11 May 93 02:53:40 GMT From: nelson@crynwr.com (Russell Nelson) To: comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc,comp.dcom.lans.ethernet,comp.sys.novell,bit.listserv.novell Subject: Packet Driver FAQ  1. What are they? A packet driver is a terminate-and-stay-resident program for PCs running MS-DOS. Packet drivers hide the differences between network adapter, and they permit multiple protocol stacks to access the same network adapter at the same time. They also make it easier to install new networking software because the driver is already installed and working. On a more technical note, they allow programs to send packets, receive packets, and determine the adapter's address. Packet drivers, by themselves, do not provide any application-level services. Some application is needed which will make use of the low-level packet driver services. 2. What happens without a packet driver? Without a packet driver, network software must access the adapter directly. Every adapter is different, so the network software must be programmed for each adapter. And because each program is writing to adapter memory, setting I/O ports, handling interrupts, etc., unfriendly programs do not work together. When you use a packet driver, it handles the details, not the network software. It doesn't matter if an adapter is I/O mapped, memory mapped, or bus mastering. In addition, because only one program is accessing the adapter, multiple protocol stacks can gain access through the packet driver. 3. What don't they do? They don't hide the difference between network technologies. An ARCNET driver needs ARCNET support, an Appletalk driver needs Appletalk support, etc. Having just said that, some packet drivers emulate Ethernet, e.g. IBMTOKEN, ARCETHER, ETHERSLIP. They also don't let you run multiple identical protocol stacks. That means that you can't run two TCP/IP stacks at the same time, e.g. NCSA Telnet and PC-NFS. Each program has its own TCP/IP stack, and each expects to receive IP and ARP packets. Even if the packet driver was modified to deliver the packets to both stacks, you still have the problem of determining which stack should reply to which packets. 4. Where do they come from? The Packet Driver Specification (PDS) was written by FTP Software. Some companies have written their own packet drivers. The majority of packet drivers were written by individuals, and have been collected by Russell Nelson while he was at Clarkson University. This collection used to be called the Clarkson Packet Driver Collection. Clarkson is now completely disassociated with any packet driver collection, so the collection is now called the Crynwr Packet Driver Collection. 5. What do they work with? There are many applications that use the packet drivers, too many to list here. Any such list would be incomplete because new applications are constantly being written. Therefore, we will name the most popular and list the rest in the collection's SUPPORT.DOC file. Freely copyable software: NCSA Telnet -- NCSA's Telnet. Provides VT-100 terminal emulation. KA9Q aka NOS aka NET -- Phil Karn's complete TCP/IP package. Free to some users. Trumpet -- Usenet news reader using NNTP. WNQVTNET -- Windows Telnet, FTP, news reader. Shareware. BYU and Intel have free packet driver clients for NetWare's IPX. Commercial software: TCP/IP -- FTP Software, The Wollongong Group, Beame & Whiteside, SunConnect, James River Group. Only a very few TCP/IP stacks do not support packet drivers. NetWare -- BYU and Intel have free packet driver clients for NetWare's IPX. Monitors -- FTP Software, Intel, Klos Technologies, US Networx, General S'ware Others -- Performance Technology, WEBos, Invisible LAN, LANsoft and Banyan. 6. Support? The packet drivers in the Crynwr collection are freed software. They are available from many places for the cost of copying them. However, they do not come with support unless purchased directly from Crynwr Software. We accept purchase orders and checks drawn in US funds via mail, FAX, and telephone. Terms of the support are available on request. 7. How do I get them? Crynwr Software distributes supported drivers only. You can get unsupported drivers from the following locations. Mail: Columbia University distributes packet drivers on PC diskette by postal mail. Please call (212) 854-3703 for ordering information, or write to: Kermit Distribution, Dept PD; Columbia University Center for Computing Activities; 612 West 115th Street; New York, NY 10025 or send e-mail to kermit@watsun.cc.columbia.edu (Internet) or KERMIT@CUVMA (BITNET/EARN). FTP/email: The packet driver collection has its own directory devoted to it, pd1:<msdos.pktdrvr>. The drivers are there, along with many free programs that use the packet drivers. SIMTEL20 files are also available from mirror sites OAK.Oakland.Edu, wuarchive.wustl.edu, ftp.uu.net, nic.funet.fi, src.doc.ic.ac.uk or archie.au, or by e-mail through the BITNET/EARN file servers. Modem: If you cannot access them via FTP or e-mail, the packet drivers are also available for downloading from Detroit Download Central (313) 885-3956. This is a subscription system with an average hourly cost of 17 cents. It is also accessible on Telenet via PC Pursuit and on Tymnet via StarLink outdial. 8. What about the Novell/Unix connection? There is no problem transporting both Novell (actually, NetWare) and Unix (actually, TCP/IP) packets over the same network at the same time. NetWare packets have one magic number, TCP/IP another. The trick, for DOS users, is to run both at the same time on the same PC. NetWare servers and clients can be configured for standard Ethernet II packets, or left alone for nonstandard NetWare packets. This configuration process is done by a program called econfig. NetWare's drivers access the adapter directly, which will cut off packet driver access to the adapter. The way to convince NetWare to avoid stomping on your packet driver is to use a version of IPX that accesses the adapter through a packet driver. There are two such IPXes, both of them freely copyable. Brigham Young University (BYU) wrote one back in April of 1989. Intel wrote one more recently, and is continuing to modify it as needed. With BYU PDIPX, you must either econfig or use the packet driver's -n switch. In any case, BYU requires that you econfig the client. The Intel PDIPX lets you choose to econfig your network or not. 9. Are there alternatives to packet drivers? After the packet driver specification had been published, Microsoft and Novell devised their own driver specifications, NDIS and ODI (aka ODLI). LAN Manager requires an NDIS driver, and newer versions of NetWare require an ODI driver. The specifications for NDIS drivers are freely copyable, but writing an ODI driver requires a multi-thousand dollar toolkit from Novell. There are several "shims" that convert one specification into the other: dis_pkt, which emulates a packet driver using an NDIS driver, odipkt, which is a packet driver over ODI, and pdether, which is an ODI driver over packet driver. Crynwr Software distributes these, although we do not support them. -russ <nelson@crynwr.com> What canst *thou* say? Crynwr Software Crynwr Software sells packet driver support. 11 Grant St. 315-268-1925 Voice | LPF member - ask me about Potsdam, NY 13676 315-268-9201 FAX | the harm software patents do.  -----------[000139][next][prev][last][first]---------------------------------------------------- Date: 11 May 1993 11:14:28 -0400 From: mkc@Graphics.Cornell.edu (Mitch Collinsworth) To: comp.protocols.tcp-ip,comp.mail.mime Subject: Re: Commercial Multimedia Software for teleconferencing  In <C6otqs.69w@ra.nrl.navy.mil> atkinson@itd.nrl.navy.mil (Ran Atkinson) writes: >In article <1sei34INNbnb@rex.graphics.cornell.edu> mkc@Graphics.Cornell.edu (Mitch Collinsworth) writes: >[ Re: DECspin, a commercial proprietary networking multimedia tool ] >>The current version does work over ethernet, though I agree that you >>have to keep the window size down and cut the frame rate back. >>Depending on what you want to see it still might be good enough. We've >>tried it with FDDI and it's a little better, though not what we expected. >>From what little I've been able to find out, the next version is supposed >>to include video compression, which should help a lot. Also the new FDDI >>controller has about 2-3 times the throughput of the old one, so that >>alone could help a lot. >I's amusing to read the above. It must be nice to be so easily amused. > The _free_ implementations being done by the folks working with the >IETF on audio/video conferencing have had compression for some long >while now. Those versions only need about 40-64 Kbps of bandwidth if >you go with 8-bit greyscale at 6-8 frames/second and high quality >voice (a bit more when you move to color and more frames/second but >still easy to fit on an Ethernet shared with normal traffic). Like I said, DECSPIN's bandwidth goes down when you cut its frame rate back and switch to b/w, too. Big suprise there. When the compressed version is out the bandwidth will probably be in the same ballpark. Equal amounts of data are equal amounts of data. > So the versions that use the audio/video protocols being developed >by the IETF are not only cheaper (free) but also work better. Makes >one wonder how DEC is selling this product... I don't know that they are, but I also don't know why you seem to be so negative about it. I would like to see the latest version of the IETF software. The last time I saw it (maybe a year ago) it was a long way from the picture quality of DECSPIN. You listed several programs (sd, vat, wb, nevot, nv) and mentioned a rem-conf and a mbone mailing list. Where can these programs be obtained from? Which ones run on the DECstation 5000/240? How does one subscribe to the mailing lists? -Mitch Collinsworth mitch@graphics.cornell.edu  -----------[000140][next][prev][last][first]---------------------------------------------------- Date: 11 May 93 13:47:47 From: amoss@shuldig.cs.huji.ac.il (Amos Shapira) To: comp.protocols.tcp-ip Subject: Re: Out Of Band data  heberlei@cs.ucdavis.edu (Louis Todd Heberlein) writes: Is there a rule of thumb used to determine if your server should be prepared to handle out-of-band data? (For example, should only long-lived connections worry about it?) Depends on the protocol you want to use over TCP/IP. In an environment like telnet/rlogin, what would be the cause/purpose of out-of-band data? (Is it mainly used by the client to re-synch the connections? Are there any user actions which would cause out-of-band data?) OOB on telnet connections is used mainly to simulate interrupts. Is there a "generally" accepted method to handle out-of-band data? (From the quick glance that I took, it looked like the telnetd just kept the out-of-band data in-line with the normal data, and the server just ignored everything from the out-of-band signal until the actual out-of-band data. Is it application-dependent?) It is application dependent. I don't know about any "generally accepted method". Any help would be appreciated. You might want to read the Telnet RFC's (dozens of them, there was this basic TELNET protocol and then lots of options added each with its own RFC). Thanks, Todd heberlei@cs.ucdavis.edu --Amos -- --Amos Shapira (Jumper Extraordinaire) | "It is true that power corrupts, C.S. System Group, Hebrew University, | but absolute power is better!" Jerusalem 91904, ISRAEL | amoss@cs.huji.ac.il | -- the Demon to his son  -----------[000141][next][prev][last][first]---------------------------------------------------- Date: 11 May 1993 10:09:56 GMT From: Dieder Bylsma <bylsma@unixg.ubc.ca> To: comp.protocols.tcp-ip Subject: HELP TCP/IP tunneling Novell net  I need to find out ASAP about the possibilities of connecting various clients to a Novell server connected solely through the use of a TCP/IP connection. The setup is on a very large Japanese campus with a fiber-optic backbone, through which TCP/IP is used...a number of NEC 9801 PCs across the campus must connect to a central server....any help as to how this could be done would be greatly appreciated....I need an answer ASAP...please e-mail me directly...I don't read the groups as often as I would like... Thanks, Dieder B. bylsma@unixg.ubc.ca  -----------[000142][next][prev][last][first]---------------------------------------------------- Date: Tue, 11 May 1993 12:45:47 GMT From: djn@csc.liv.ac.uk (David Nixon) To: comp.sys.hp,comp.protocols.tcp-ip Subject: Re: Diskless Hp-Bootprotocol  In article <C6LpLn.9II@informatik.uni-rostock.de>, ddr@informatik.uni-rostock.de (Detlef Drewanz) writes: > Hi, > > i have a question to HP 9000/series300: > > Does anybody know, which protocol the diskless HP 9000/3xx use for > loading the kernel. The boot ROM on a discless node communicates with an 'rbootd' server process on the cluster server to down-load HP-UX: The protocol employed is called remote Maintenance Protocol (RMP). I am not sure if this protocol is an in-house HP product. > The motivation is to boot a HP from a SUN or DECstation. > Our HP-Server is very slow (nfs,...) and we think that we can get more > availability for our HP-workstations, if we could boot and serve they by > faster machines. Even if you could down-load HP-UX via RMP your file server then would have to talk HP's Discless (DUX) protocol to serve file I/O from the discless node. So all you would need is to port the DUX device driver to run as part of your SUN's kernel. ... I believe an HP source licence is a bit expensive. David Nixon -- University of Liverpool, Computer Science dept.  -----------[000143][next][prev][last][first]---------------------------------------------------- Date: 11 May 1993 14:19:53 GMT From: trier@slc6.ins.cwru.edu (Stephen C. Trier) To: comp.protocols.tcp-ip Subject: Re: Out Of Band data  In article <C6tvJB.IL6@ucdavis.edu> heberlei@cs.ucdavis.edu writes: >Do many TCP/IP servers support out-of-band data? Don't put too much reliance on Berkeley "out-of-band" semantics. It's a tweak of the TCP Urgent mechanism, and even Loeffler et al admits it was a stretch to turn TCP Urgent into the socket out-of-band data abstraction. :-) >Is there a rule of thumb used to determine if your server >should be prepared to handle out-of-band data? Yes. It will be specified in the protocol spec. Some protocols don't bother with urgent data. What you will find in Unix is that the Berkeley protocols (like rlogin) use urgent data with the Berkeley out-of-band semantics, but the IETF protocols use it with standard "urgent" semantics. That may be part of the reason it seems confusing. > (For example, should only long-lived connections worry about it?) No! If the protocol spec says urgent data is permissible, you haven't implemented the spec until you can handle urgent data. Connection length doesn't matter. (For example, I don't think anyone worries about urgent data in their finger clients, but it is of minor importance in FTP, greater importance in telnet, and is essential for rlogin.) >Is there a "generally" accepted method to handle out-of-band data? It is protocol dependent, and the semantics of urgent data (such as whether it is in-band or out-of-band) differs depending on who invented the protocol. :-) Take a look at the Telnet and FTP RFCs and you'll get an idea of how urgent data is used in standard protocols. Stephen -- Stephen Trier (trier@ins.cwru.edu) Star Trek dialog mistake of last week: Network Software Engineer "We've tried every decryption key IRIS/INS/T on record, Captain." Case Western Reserve University - Geordi LaForge, ST:TNG, 5/1/93  -----------[000144][next][prev][last][first]---------------------------------------------------- Date: 11 May 1993 14:24:58 GMT From: trier@slc6.ins.cwru.edu (Stephen C. Trier) To: comp.protocols.tcp-ip Subject: Re: HELP TCP/IP tunneling Novell net  In article <1snu1kINNjnk@iskut.ucs.ubc.ca> Dieder Bylsma <bylsma@unixg.ubc.ca> writes: [How to tunnel Novell through an IP-only backbone?] Check the _Novell NetWare v3.11 TCP/IP Transport Supervisor's Guide_, appendix A. It came with your NetWare 3.11 server. -- Stephen Trier (trier@ins.cwru.edu) Star Trek dialog mistake of last week: Network Software Engineer "We've tried every decryption key IRIS/INS/T on record, Captain." Case Western Reserve University - Geordi LaForge, ST:TNG, 5/1/93  -----------[000145][next][prev][last][first]---------------------------------------------------- Date: Tue, 11 May 1993 15:51:34 GMT From: mahmood@lambda.msfc.nasa.gov (Rafique Mahmood) To: comp.protocols.tcp-ip Subject: WHERE TO FIND THE TCPVIEW FOR SUN SPARC2?  I LIKE TO GET THE SOURCE CODE OR EXECUTABLE FOR TCPVIEW. ONE OF OUR USER GOT IT FROM THE NET SOMEWHERE. BUT IT DOES NOT HAVE THE SOURCE CODE. I INSTALLED IT ACCORDING TO THE INSTALL DOCUMENT BUT WHEN I RUN IT IT SAYS: Warning: ... found while parsing 's <Key>osfLeft:key-select(left)' Warning: translation table syntax error: Unknown keysym name: osfLeft Warning: ... found while parsing '<Key>osfLeft:backward-character()' Warning: translation table syntax error: Unknown keysym name: osfRight Warning: ... found while parsing 's c <Key>osfRight:forward-word(extend)' Warning: translation table syntax error: Unknown keysym name: osfRight Warning: ... found while parsing 'c <Key>osfRight:forward-word()' Warning: translation table syntax error: Unknown keysym name: osfRight Warning: ... found while parsing 's <Key>osfRight:key-select(right)' Warning: translation table syntax error: Unknown keysym name: osfRight Warning: ... found while parsing '<Key>osfRight:forward-character()' Warning: translation table syntax error: Unknown keysym name: osfUp Warning: ... found while parsing 's c <Key>osfUp:backward-paragraph(extend)' Warning: translation table syntax error: Unknown keysym name: osfUp Warning: ... found while parsing 'c <Key>osfUp:backward-paragraph()' Warning: translation table syntax error: Unknown keysym name: osfUp Warning: ... found while parsing 's <Key>osfUp:process-shift-up()' Warning: translation table syntax error: Unknown keysym name: osfUp Warning: ... found while parsing '<Key>osfUp:process-up()' and much more warning. It brings out the window and I captured some packets but I don't know where did it stored. If anyone is using TCPVIEW please email me the response. Thanks a lot Rafique email: mahmood@lambda.msfc.nasa.gov  -----------[000146][next][prev][last][first]---------------------------------------------------- Date: Tue, 11 May 1993 15:53:02 GMT From: heka@ost.ericsson.se (hedie kamoun) To: comp.protocols.tcp-ip Subject: sockoptions in TLI  Dear net-wizards, I have a question (and a problem) that I wonder if somebody out there could help me with. I have a system which is built around TLI (SunOS). Since the transport provider I'm using (tcp) is configured with the Nagle-algoritm option disabled (The TCP_NODELAY for sockets) and my system sends out a lot of small packets I'd like to set the TCP_NODELAY option thus enabling the Nagle algoritm (which I learned from this group, by the way). However I suspect that TLI internally uses a different socket towards tcp, thus the socket I recieve from t_open is not the one for which I should set the socket option. Could somebody shine light on how to set a socketoption using TLI in general and for the TCP_NODELAY in particular, or if not possible indicate so. Hoping for an answer, Best regards Hedie Email:heka@ppvku.ericsson.se  -----------[000147][next][prev][last][first]---------------------------------------------------- Date: 11 May 1993 16:15:27 GMT From: Jim.Rees@umich.edu To: comp.protocols.ppp,comp.protocols.tcp Subject: Re: bad ppp telnet performance  In article <hqpsv8k@rhyolite.wpd.sgi.com>, vjs@rhyolite.wpd.sgi.com (Vernon Schryver) writes: Big windows can cause problems... The solution is one or more of: [ reduce max window size or gateway queue size ] I don't like either of those solutions. What you really would like is for tcp to set its window size to the number of bytes actually in flight, rather than that number plus all the queue sizes on intermediate gateways. I'm not up on all the latest tcp research but I don't know of any implementation that does this, and I can't even think how you would do it in the absence of forward/reverse congestion bits. Expecting the administrator of each end system to guess the appropriate maximum window size is not just unrealistic, it's impossible.  -----------[000148][next][prev][last][first]---------------------------------------------------- Date: 11 May 1993 16:53:16 GMT From: mjr@tis.com (Marcus J Ranum) To: comp.protocols.tcp-ip Subject: Re: Where I can find information about firewalls ?  >Any suggestions of where I can find infomration about network security >issues (related to Internet), especially about firewall-technique ? Check out the firewalls mailing list (firewalls@greatcircle.com) and its archive (ftp.greatcircle.com). There are also several good sources of articles on: ftp.greatcircle.com pub/firewalls research.att.com dist/internet_security decuac.dec.com pub/doc/firewall moink.nmsu.edu firewalls 'Practical UNIX Security' by O'Rielly and associates describes a basic simple screening firewall. mjr.  -----------[000149][next][prev][last][first]---------------------------------------------------- Date: Tue, 11 May 1993 16:58:19 GMT From: stewart@oin.cis.udel.edu (John Stewart) To: comp.protocols.tcp-ip Subject: Re: Where I can find information about firewalls ?  In article <9305111250.AA16961@kymmene.fi> gronja@kymmene.fi writes: > >Our site is going to connect to Eunet (probably with IBM 6611), which >provides us Internet access. What I need right now is information how >to prevent unauthorized persons accessing our network (somewhere I >have seen spoken about firewalls). > >Any suggestions of where I can find infomration about network security >issues (related to Internet), especially about firewall-technique ? > >Thanks for any help and sorry if this is FAQ. There is a mailing list "raptor@delmarva.com" (subscription requests should go to "raptor-request@delmarva.com") which discusses the Eagle Secure Gateway made by Raptor Systems, as well as firewalls in general. On the host "ftp.delmarva.com" in "/pub/security", there is a collection of security-related documents. Good luck. /jws  -----------[000150][next][prev][last][first]---------------------------------------------------- Date: 11 May 1993 16:59:48 GMT From: adiwan@bbn.com (Arif Diwan) To: comp.protocols.tcp-ip Subject: Looking for OSPF packet trace programs  Does anyone have a program which would promiscuously listen for and grab OSPF packets and then give a formatted output? Has anyone modified tcpdump or tcpview to give a formatted OSPF packet output? Please email to me and I will post the compendium. -- -- Arif Diwan (adiwan@bbn.com) 617/873-6274  -----------[000151][next][prev][last][first]---------------------------------------------------- Date: 11 May 93 18:00:47 GMT From: adiwan@bbn.com (Arif Diwan) To: comp.protocols.tcp-ip Subject: Re: Looking for OSPF packet trace programs  In article <1993May11.125623@bbn.com>, adiwan@bbn.com (Arif Diwan) writes: |> Does anyone have a program which would promiscuously listen for |> and grab OSPF packets and then give a formatted output? Has anyone |> modified tcpdump or tcpview to give a formatted OSPF packet output? ... Ooops! FYI -- tcpdump2.2.1 has ospf packet parsing. -- -- Arif Diwan (adiwan@bbn.com) 617/873-6274  -----------[000152][next][prev][last][first]---------------------------------------------------- Date: Tue, 11 May 1993 14:50:38 +0200 (WET) From: gronja@kymmene.fi To: comp.protocols.tcp-ip Subject: Where I can find information about firewalls ?  Our site is going to connect to Eunet (probably with IBM 6611), which provides us Internet access. What I need right now is information how to prevent unauthorized persons accessing our network (somewhere I have seen spoken about firewalls). Any suggestions of where I can find infomration about network security issues (related to Internet), especially about firewall-technique ? Thanks for any help and sorry if this is FAQ. ---- Jan-Erik Gron Email: gronja@kymmene.fi Kymmene Corporation, Finland Fax: +358 51 402 2241  -----------[000153][next][prev][last][first]---------------------------------------------------- Date: Wed, 12 May 93 05:20:00 PDT From: amc@cup.portal.com (Alan - Crawley) To: comp.protocols.tcp-ip Subject: Need wireless LAN bridge code  Looking for spanning tree bridge code for 802.11 wireless LAN applications. Other wireless LAN roaming software? Perpetual royalties possible. E-mail please.  -----------[000154][next][prev][last][first]---------------------------------------------------- Date: 11 May 93 23:01:20 GMT From: carrato@mhinfo.UUCP (Tony Carrato) To: comp.protocols.tcp-ip Subject: SCO subnetting problem  In article <3@mhinfo.UUCP> I wrote: >Here's the problem: > > Segment 1 Segment 2 > ================================ ========================== > " " " " " " " > SCO RS6000 PC 1 w/ Netware PC 2 w/ PC 3 w/ > LAN WG w/ Novell LAN WG LAN WG > for DOS TCP/IP for DOS for DOS > >In this configuration, PC 1 can ping/telnet to the SCO box. If you >move it to segment 2, it can't. However, on either segment, PC 1 >(and the other PC's) can easily ping/telnet to the RS6000. It turns out the problem was the subnetwork addressing on the SCO box. as soon as we went to a subnet mask of 255.255.255.0 things started working fine. It could well be that on the SCO TCP/IP implementation that partial byte subnetting simply doesn't work. (The RS6000 worked just fine in either configuration.) Thanks very much to everyone who wrote with suggestions. Tony  -----------[000155][next][prev][last][first]---------------------------------------------------- Date: Wed, 12 May 1993 00:16:26 GMT From: Mark_Hebets@ccmail.radian.com (Mark Hebets) To: comp.protocols.tcp-ip Subject: Scripted FTP for unattended transfers  I need a way to run an FTP transfer unattended, at a particular time every day. Is there a good example of how to do this? I know I could run the ftp command with input re-directed, but this would require a little work to fake the keyboard input for the password, and it would not be too robust. Is there a way to run it from a script, that would allow me to handle error messages and retry the transfer? Thanks for any help you can give. I'll summarize here if the answers look generally useful.  -----------[000156][next][prev][last][first]---------------------------------------------------- Date: Wed, 12 May 1993 00:44:54 GMT From: pwb@newt.phys.unsw.edu.au (Paul W. Brooks esq.) To: comp.protocols.tcp-ip Subject: Re: unnecessary Retransmission Timeouts  In article <1993May5.223910.7681@acc.com>, art@acc.com (Art Berggreen) writes: > In article <1s6lad$m5@urmel.informatik.rwth-aachen.de> marmary@kaa.informatik.rwth-aachen.de (Mahmoud-Reza Nazeman) writes:
> >I am running a simulation program, where two workstations on different
> >ethernet-segments are interconnected through a satellite link.
> >
> >There I am wondering, why so many unnecessary TCP-Retransmission-Timeouts
> >occur, even under the assumption of an error-free (!) connection.
> >
> >The RTO-value is always calculated as in the revised paper of V. Jacobsen ('88)
> >is suggested (for bandwidth-dominated paths):
> >
> >                RTO = SRTT + 4 * RTT_VAR        .
>
> Hmmm, I wonder if Van ever considered that as RTT_VAR approeaches 0, that RTO
> approaches SRTT (creating a potential race condition).  Seems like this function
> should be bounded such that RTO is never less than, say, 1.25 SRTT.

If RTT_VAR approaches zero,if means your path is extremely consistent in
its transmission delay, so you expect the acknowledgement to arrive very
soon after SRTT time. Why would you want the extra delay caused by
putting a lower limit on RTT_VAR?
Note that in the paper, the algorithm when implemented in
integer arithmetic ensures RTT_VAR >= 1 through integer round-off
'errors'.

Paul Brooks        |Internet: pwb@newt.phys.unsw.edu.au
Uni. of N.S.W.     |          paul@abccomp.oz.au
Kensington NSW 2033|
AUSTRALIA          | Microwave ovens: God's gift to bachelors


-----------[000157][next][prev][last][first]----------------------------------------------------
Date:      Wed, 12 May 1993 00:49:23 GMT
From:      pwb@newt.phys.unsw.edu.au (Paul W. Brooks esq.)
To:        comp.protocols.tcp-ip
Subject:   Re: RARP through a Router?

In article <1993May7.193913.5280@nstn.ns.ca>, daniel@nstn.ns.ca (Daniel MacKay) writes:
> In <C6I3Io.BoF@sci.kun.nl> petervc@sci.kun.nl (Peter van Campen) writes:
>
> >- When we tried it out again on SunOS4.1.2 the SunOS rarpd refused to
> >  give a RARP reply, because the client was not on his subnet.
>
> Hey, I just discovered this for myself a couple weeks ago!!  I have a whole
> slew of Ether bridges that need RARP, but I can't put a server on every
> segment.  Does anyone have any suggestions?

So how does the rarpd detect the client was not on its subnet? the RARP
query doesn't have any IP numbers in it, just the hardware address of
the client.

Paul Brooks        |Internet: pwb@newt.phys.unsw.edu.au
Uni. of N.S.W.     |          paul@abccomp.oz.au
Kensington NSW 2033|
AUSTRALIA          | Microwave ovens: God's gift to bachelors


-----------[000158][next][prev][last][first]----------------------------------------------------
Date:      Wed, 12 May 1993 02:01:15 GMT
From:      tcooper@bnr.ca (Terry Cooper)
To:        comp.sys.hp,comp.protocols.tcp-ip
Subject:   Re: Diskless Hp-Bootprotocol

In article <C6v4sB.BA4@compsci.liverpool.ac.uk> djn@csc.liv.ac.uk (David Nixon) writes:
>In article <C6LpLn.9II@informatik.uni-rostock.de>, ddr@informatik.uni-rostock.de (Detlef Drewanz) writes:
>> Hi,
>>
>> i have a question to HP 9000/series300:
>>
>> Does anybody know, which protocol the diskless HP 9000/3xx use for
>
>The boot ROM on a discless node communicates with an 'rbootd' server
>process on the cluster server to down-load HP-UX: The protocol employed
>is called remote Maintenance Protocol (RMP). I am not sure if this protocol
>is an in-house HP product.
>
>>                   The motivation is to boot a HP from a SUN or DECstation.
>> Our HP-Server is very slow (nfs,...) and we think that we can get more
>> availability for our HP-workstations, if we could boot and serve they by
>> faster machines.
>
>Even if you could down-load HP-UX via RMP your file server then would have to
>talk HP's Discless (DUX) protocol to serve file I/O from the discless node.
>
>So all you would need is to port the DUX device driver to run as part of your
>SUN's kernel.
>
>... I believe an HP source licence is a bit expensive.
>
The DUX stuff is proprietary (as pointed out in another thread) so you can't
use it with non-HP systems.  If you have a bunch of HPs you will get much
better response by clustering the HPs and getting rid of NFS.  If this is
done properly (ie: no more than 20 workstations/server and each cluster
behind a filtering bridge) you will see a lot of performance increase on
both the HPs and the LAN.

HP gives stats that say that NFS is 300% slower than local disk and that DUX
is about 15% slower than local.  My experience tells me that this is probably
pretty close, although I haven't measured it.
measured it

--
=========================================================================
Terry Cooper
Northern Telecom               "Opinions expressed are personal and"
Ottawa, Ontario                "are not those of Northern Telecom  "


-----------[000159][next][prev][last][first]----------------------------------------------------
Date:      Wed, 12 May 1993 03:07:21 GMT
From:      jwb@capek.rdt.monash.edu.au (Jim Breen)
To:        comp.protocols.misc,comp.protocols.ibm,comp.protocols.iso,comp.protocols.tcp-ip
Subject:   Re: SONET Protocol

masami@mtu.edu (MOHAMMED A. SAMI) writes:

>I am looking for info on SONET (DQDB) protocol, specifically on t
>he two layers

Hmmm. SONET and DQDB are *very* different things. SONET is
the (new US) digital transmission hierarchy. DQDB is a MAN protocol
annointed as IEEE802.6, atc.  Which do you want?
--
Jim Breen          [ジム.ブリーン@モナシュ大学]
Department of Robotics & Digital Technology. Monash University.
Wellington Rd, Clayton VIC 3168 Australia (ph) +61 3 565 3298
(fax) +61 3 565 3574  AARNet/Internet:j.breen@rdt.monash.edu.au


-----------[000160][next][prev][last][first]----------------------------------------------------
Date:      12 May 1993 11:48:09 -0500
From:      bryan@wuarchive.wustl.edu (Bryan O'Connor)
Subject:   New wuarchive ftp server available

The Washington University Office of the Network Coordinator is pleased
to announce the release of a new version of the wuarchive FTP server.
This server includes many security enhancements and new features.

This release includes full documentation for installation and
configuration, and is also very easy to compile and install.  See
to install and operate this ftp server.

The server may be retrieved via anonymous FTP from wuarchive.wustl.edu
in the directory /packages/wuarchive-ftpd.  There are two distribution
formats, a tar file and a shar file.  Fetch one of the files, and use
the appropriate method to extract it -- the individual files will be
stored in a new subdirectory called "wu-ftpd-2.1".

ADDITIONS AND CHANGES IN VERSION 2.1
====================================

-- upload: default was to not allow uploads ever.  This is backwards, if
no upload keywords are given, it should act like a normal server.

-- double conversion: double conversion stuff works now.  Included is a
gzip2comp (in util) for converting from gzip format to compress.

-- cwd_beenhere(): now calls realpath(".", cwd) to figure out the path.
This works for people in directories that are private.  That
is that some component of their path is not readable by them.
(cwdir() fails in such a case.)

-- upload: trying to set a file mode of 0000 would fail.  This is now
possible.

-- makedir: Did not work properly for real users.

-- getgrent.c: removed the need for getgrent.c from the support library.
This caused problems with systems running yellow pages (NIS).
All gids in the private file are now parsed before the chroot().
This gives us one less open file descriptor.

-- upload/truncate: STORE was not properly trunctating files when
overwriting them.

-- upload failing with directories in makedir/put commands: STORE and
MAKEDIR were failing when giving full path names.

-- process ids: multiple process ids were written into the pid-files when
usage counts.

-- %E magic cookie: the %E cookie gets replaced with the "email" string
from the ftpaccess file.

-- %F magic cookie: added trivial support for Solaris 2.1 (at least).
If you fix this for your system, send me a patch.

-- %N magic cookie: did not work after the chroot().  The pid file has
to remain open for the duration of the server's life now in
order for this to work.

-- support/paths.h: removed the need for this file.  It caused more
problems than it was worth.  The two #defines that were used
were moved to src/pathnames.h

-- upload * no dirs: you can now specify a directory that does not allow
uploads but does allow the creation of directories.

-- alias list: you can now get a listing of what aliases are available.
at the ftp prompt type "quote site alias".

-- cdpath: you can now specify a cdpath (like the csh variable).  You
can get a listing of the cdpath at the ftp prompt by typing
"quote site cdpath".

-- email: you can specify an email address for the maintainer of the
archive.  This string will be used for the %E magic cookie.

-- xferstats: updated version written by Dave Datta (datta@cs.uwp.edu).

-- host access: added ftphosts file that explicitly allows or denies

-- support for many more systems.

--
Bryan D. O'Connor                            Internet: bryan@fegmania.wustl.edu
Software Engineer, wuarchive development        UUCP: ...!uunet!wuarchive!bryan
Office of the Network Coordinator                    BITNET: bryan@wunet.bitnet
Washington University in Saint Louis                     Phone: +1 314 935 7048


-----------[000161][next][prev][last][first]----------------------------------------------------
Date:      Wed, 12 May 1993 05:12:23 GMT
From:      fred_s@netcom.com (Frederick Scott)
To:        comp.protocols.tcp-ip
Subject:   Re: RARP through a Router?

pwb@newt.phys.unsw.edu.au (Paul W. Brooks esq.) writes:

>In article <1993May7.193913.5280@nstn.ns.ca>, daniel@nstn.ns.ca (Daniel MacKay) writes:
>> In <C6I3Io.BoF@sci.kun.nl> petervc@sci.kun.nl (Peter van Campen) writes:
>>
>> >- When we tried it out again on SunOS4.1.2 the SunOS rarpd refused to
>> >  give a RARP reply, because the client was not on his subnet.
>>
>> Hey, I just discovered this for myself a couple weeks ago!!  I have a whole
>> slew of Ether bridges that need RARP, but I can't put a server on every
>> segment.  Does anyone have any suggestions?
>
>So how does the rarpd detect the client was not on its subnet? the RARP
>query doesn't have any IP numbers in it, just the hardware address of
>the client.

No, but one would expect the rarpd's database has the IP numbers, otherwise
with what was it going to fill in the reply?

Fred


-----------[000162][next][prev][last][first]----------------------------------------------------
Date:      11 May 93 15:13:31 +1000
From:      baylissb@topaz.ucq.edu.au
To:        comp.protocols.tcp-ip
Subject:   problem with TCP/IP packet size

Hi,

I have come across the following problem while using TCP/IP, and was wondering
if others have come across this also, and if so, what are the possible
solutions.

Situation
---------
- the backing up of PCs onto tape, using both DECnet and TCP/IP
- the packet size for both protocols was set at 512.
- when using TCP/IP, it was found that at a packet size of 512, DECnet ran
approximately 10 times faster.

Solutions Tried
---------------
- in order to speed up the TCP/IP transfer, the following were tried
- swapping the server and client ends.
- changing from a connection and a connectionless set-up.
- changing the receive and send call functions.
- changing the packet size

Problem
-------
- when adjusting the packet size, the following was noticed.  on transferring
the same information, with different packet sizes, the following was
obtained.

size of packet                     time taken
--------------                     ----------
256                           approx.  2 sec
512                           approx. 24 sec
1024                           approx. 14 sec

Note
----
- i have changed the programs to handle the situation of using a packet
size of 256, while still creating a usable TAR file.

If anyone has come up with another possible solution, i'd be interested in
hearing it.  I can be contacted on the below e-mail addresses (it may be
best as i don't often use NEWS).

baylissb@topaz.ucq.edu.au
baylissb@jasper.ucq.edu.au       <- i check this one each working day.


-----------[000163][next][prev][last][first]----------------------------------------------------
Date:      12 May 93 09:36:18 GMT
From:      Rainer.Blaes@erno.de (Rainer.Blaes)
To:        comp.protocols.tcp-ip
Subject:   3270 Terminal Emulation

Dear experts,

is there any 3270 emulator for VAX/VMS 5.x available which can be used with
'TCP/IP services for VMS' ?

We would like to use this emulation on the VAX which is connected by Ethernet to
our TCP/IP IBM mainframes.

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
| Dr. Rainer Blaes                   | Rainer.Blaes@erno.de                |
| Senior System Manager              |                                     |
| ERNO Raumfahrttechnik GmbH         | "In any organization there          |
| Huenefeldstrasse 1-5               | will always be one person           |
| 2800 Bremen 1 Germany              | who knows what is going             |
| Voice: (0421) 539-4132             | on. This person must be             |
| Fax:   (0421) 539-4424             | fired."                             |
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=


-----------[000164][next][prev][last][first]----------------------------------------------------
Date:      Wed, 12 May 1993 11:40:56 GMT
From:      leilabd@syma.sussex.ac.uk (Leila Burrell-Davis)
To:        comp.protocols.tcp-ip
Subject:   Re: Scripted FTP for unattended transfers

: I need a way to run an FTP transfer unattended, at a particular
: time every day.  Is there a good example of how to do this?

: I know I could run the ftp command with input re-directed, but this
: would require a little work to fake the keyboard input for the password,
: and it would not be too robust.  Is there a way to run it from a
: script, that would allow me to handle error messages and retry the
: transfer?

: look generally useful.

There's a package called autoftp that looks as if it might do the
job. I got it from src.doc.ic.ak in
packages/unix-c/networks/autoftp2.tar-z
but I expect you can find it at a site near you.

Leila

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


-----------[000165][next][prev][last][first]----------------------------------------------------
Date:      Wed, 12 May 1993 11:55:19 GMT
From:      Graham Barlow <gkb1@tower.york.ac.uk>
To:        comp.protocols.tcp-ip
Subject:   problem printing-lpr (QVTNET3.4) on VAX(CMUTEK)

Can anyone help? I am trying to print using lpr on a PC using WIN/QVTNET v3.4
with lpd running on a VaxStation 3100 using lpd from CMUTEK - OpenVMS/IP 6.6-5.

QVTNET seems to be sending junk for the forms type... can anyone tell
me how to fix this on either end, perhaps by getting CMUTEK to forget/
ignore the forms specifier or QVTNET to do the right thing.

I have set up hosts.lpd OK and have an entry in printcap.txt :

--------
sys$print "opus.york.ac.uk" "opus.york.ac.uk" opus:: default define-logicals -------- The following is an extract from lpd-d-mmm-yy.log file ------------ 4-MAY-1993 11:49:22.76 Request 11:49:22.73 Created 4-MAY-1993 11:49:22.99 Request 11:49:22.73 Open Requested 4-MAY-1993 11:49:23.11 Request 11:49:22.73 Connection open Remote '', 144.32.128.191 (724) 4-MAY-1993 11:49:23.22 Request 11:49:22.73 Connection open Local '................................................................................................................................', 144.32.128.147 (515) 4-MAY-1993 11:49:23.42 Request 11:49:22.73 Please Add Entry, Printer 'SYS$Print'
4-MAY-1993 11:49:23.52 Request 11:49:22.73, Sent ACK on Command
4-MAY-1993 11:49:23.74 Request 11:49:22.73 Recv Control File Name 'LPD$SPOOL_DIR:cfA008chempc10_york_ac_uk;1', Size 146 4-MAY-1993 11:49:23.90 Request 11:49:22.73 Sent Control File Size ACK 4-MAY-1993 11:49:24.03 Request 11:49:22.73, Recv Control File 4-MAY-1993 11:49:24.15 Request 11:49:22.73 Recv ACK for Control File 4-MAY-1993 11:49:24.28 Request 11:49:22.73 Control File Host Name is 'chempc10.york.ac.uk' 4-MAY-1993 11:49:24.40 Request 11:49:22.73 Control File User Name is 'SYSTEM' 4-MAY-1993 11:49:24.54 Request 11:49:22.73 Control File Job Name is 'autoexec.bat' 4-MAY-1993 11:49:24.65 Request 11:49:22.73 Control File Form Name is 'chempc10.york.ac.uk.york.ac.uk' 4-MAY-1993 11:49:24.78 Request 11:49:22.73$SNDJBCW Create_Job IOSB status = 0004814C
4-MAY-1993 11:49:24.92 LPD Dying abnormally
4-MAY-1993 11:49:25.05 Status = '%JBC-F-INVFORNAM, invalid form name'

-----------

.______________________________________________________________________.
|  Dr. Graham Barlow   |                                               |
|  NMR Service         |                                               |
|  Dept. of Chemistry  |    JANET mail:        gkb1@UK.AC.YORK         |
|  Univ. of York, UK   |    Internet mail:     gkb1@tower.york.ac.uk   |
+----------------------+-----------------------------------------------+


-----------[000166][next][prev][last][first]----------------------------------------------------
Date:      Wed, 12 May 1993 13:47:43 GMT
From:      gandalf@Csli.Stanford.EDU (Juergen Wagner)
To:        comp.protocols.tcp-ip
Subject:   Re: RARP through a Router?

You have to bridge RARP in the router connecting the subnets. Some
routers have the capability to bridge Ethernet protocols based on
Ethertype of packets.

--Juergen

J_Wagner@iao.fhg.de
gandalf@csli.stanford.edu


-----------[000167][next][prev][last][first]----------------------------------------------------
Date:      Wed, 12 May 1993 13:52:38 GMT
From:      pwb@newt.phys.unsw.edu.au (Paul W. Brooks esq.)
Subject:   802.3 SNAP ethernet under SunOS ?

Could someone please tell me if it is possible to configure a Sun IPX
to use 802.3 SNAP ethernet framing instead of Ethernet_II for a TCP/IP
network? Is it possible to configure it with two logical networks
through the same interface, one for each ethernet frame format, so it
will route between them?

Thanks for any pointers - drew a blank with TFM.

Paul Brooks        |Internet: pwb@newt.phys.unsw.edu.au
Uni. of N.S.W.     |          paul@abccomp.oz.au
Kensington NSW 2033|
AUSTRALIA          | Microwave ovens: God's gift to bachelors


-----------[000168][next][prev][last][first]----------------------------------------------------
Date:      Wed, 12 May 1993 14:15:47 GMT
From:      ignatios@theory.cs.uni-bonn.de (Ignatios Souvatzis)
To:        comp.dcom.modems,comp.sys.sun.misc,comp.protocols.tcp-ip,comp.protocols.ppp
Subject:   Re: Fast modems and dialup SLIP/PPP

In article <C6t6up.749@sci.kun.nl>, janf@sci.kun.nl (Jan Frederik Nipshagen) writes:

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

Yeah, thats why you should be using PPP, as appropriate for discussions in this
newsgroup :-).

--
Ignatios Souvatzis
ignatios@cs.uni-bonn.de souva@astro.uni-bonn.de
Cute quote: "You should also consider that the ST comes fully equipped with a
text adventure. It's called ST Basic." Amylaar@meolyon.hanse.de


-----------[000169][next][prev][last][first]----------------------------------------------------
Date:      Wed, 12 May 1993 14:48:04 GMT
From:      dtalleri@maestro.mitre.org (David Tallerico)
To:        comp.protocols.tcp-ip
Subject:   Re: sockoptions in TLI

hedie kamoun writes:

>I have a system which is built around TLI (SunOS). Since the transport
>provider I'm using (tcp) is configured with the Nagle-algoritm option disabled
>(The TCP_NODELAY for sockets) and my system sends out a lot of small packets
>I'd like to set the TCP_NODELAY option thus enabling the Nagle algoritm

//this works on a SunOS 4.1.x
//see sys calls man entry for fcntl

#include <fcntl.h>

...

int flags = O_NDELAY;

int transportEndpoint = t_open("/dev/tcp", flags, NULL);

...

Hope this helps,

-David


-----------[000170][next][prev][last][first]----------------------------------------------------
Date:      12 May 1993 16:33:09 GMT
From:      ch981@cleveland.Freenet.Edu (Tony Alicea)
To:        comp.protocols.tcp-ip
Subject:   BISYNC/TCP Conversion, Looking for...


Does anyone know of a software and/or hardware product to convert

Thanks,

Tony Alicea
talicea@arinc.com


-----------[000171][next][prev][last][first]----------------------------------------------------
Date:      12 May 93 16:37:03 GMT
From:      art@acc.com (Art Berggreen)
To:        comp.protocols.tcp-ip
Subject:   Re: unnecessary Retransmission Timeouts

In article <1993May12.004454.24655@usage.csd.unsw.OZ.AU> pwb@newt.phys.unsw.edu.au (Paul W. Brooks esq.) writes:
>
>If RTT_VAR approaches zero,if means your path is extremely consistent in
>its transmission delay, so you expect the acknowledgement to arrive very
>soon after SRTT time. Why would you want the extra delay caused by
>putting a lower limit on RTT_VAR?

Because I'd like to operate a little further from the cliff edge.  With an RTO that
close to the SRTT you have little or no room to accomodate any change in local
processing delay, remote processing delay, or path delay without taking a spurious
timeout.  This results in unneccesary retransmission of data and a reduction in the
TCP window.  With a higher bound on RTO, we have some operating room to deal with
small fluctuations in SRTT and also to adapt to any small permanent changes in SRTT.
Also, the SRTT measurement is not perfect.  I've seen situations with low speed
links where an SRTT estimate is built from an exchange of small packets that give
a low variance figure.  But because of the low speed link, the SRTT is actually
dependent on the packet size and the SRTT is underestimated for the first few large
packets, until the SRTT estimate adapts.  Worse yet, the RTT samples are usually
discarded while retransmissions are occuring, delaying the acquisition of a proper
SRTT for the large packet traffic.  This is not uncommon for interactive traffic
(remote echo of keystrokes followed by a screen refresh).  And low speed links are
where you most want to avoid spurious retransmissions.

>	Note that in the paper, the algorithm when implemented in
>integer arithmetic ensures RTT_VAR >= 1 through integer round-off
>'errors'.

But if the ratio between SRTT and clock tick granularity is large, then an RTT_VAR
of 1 may be little different from 0.  Remember that the size of the RTO interval
is only a factor if a packet is lost or believed lost.  The trick is to balance
timely recovery from loss against spurious retransmissions.  The TCP world lived
it's first several years with a fixed beta of 2.

Art


-----------[000172][next][prev][last][first]----------------------------------------------------
Date:      Wed, 12 May 1993 18:24:20 GMT
From:      copeland@sdf.lonestar.org (Charles Copeland)
To:        comp.protocols.tcp-ip,comp.protocols.ibmpc,comp.sources.wanted
Subject:   repost: help with tftp code

I have been trying to find a *complete* copy of tftp with no luck.
Does anybody know where I can get a copy that includes the missing .h files:

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


-----------[000173][next][prev][last][first]----------------------------------------------------
Date:      12 May 1993 18:47:20 GMT
From:      Jim.Rees@umich.edu
To:        comp.dcom.modems,comp.sys.sun.misc,comp.protocols.tcp-ip,comp.protocols.ppp
Subject:   Re: Fast modems and dialup SLIP/PPP

In article <1993May12.141547.9340@olymp.informatik.uni-bonn.de>, ignatios@theory.cs.uni-bonn.de (Ignatios Souvatzis) writes:

> One thing that I found out is that SLIP requires a fully
> transparant channel, which makes it impossible to use softwareflowcontrol.

Yeah, thats why you should be using PPP, as appropriate for discussions in this
newsgroup :-).

No, that's why you should be using out-of-band ("hardware") flow control.
The async map in ppp is a software workaround for buggy hardware.


-----------[000174][next][prev][last][first]----------------------------------------------------
Date:      Wed, 12 May 1993 23:35:47 GMT
From:      clarkm@slab.pr.erau.edu (Michael Clark)
To:        comp.protocols.tcp-ip
Subject:   Tracing the Origin of an FTP Download

To All FTP gurus -

Does anyone know how to keep track of the origin of an FTP download or
to encode a header specifying where it came from.  Ultimately, I would
like to be able to download multiple text files from various sites, then
allow users who download my files to be able to know where the files
originated.  Each individual file would need a header associated with it.

- Mike Clark
clarkm@slab.pr.erau.edu


-----------[000175][next][prev][last][first]----------------------------------------------------
Date:      Thu, 13 May 1993 00:58:43 GMT
From:      mikey@yoho.carleton.ca (Mike G McFaul)
To:        comp.protocols.ppp,comp.protocols.tcp
Subject:   Re: bad ppp telnet performance

In article <1sm8i3$ip3@terminator.rs.itd.umich.edu> Jim.Rees@umich.edu writes: >In article <C6qnAG.M77@cunews.carleton.ca>, mikey@yoho.carleton.ca (Mike G McFaul) writes: > > The real > culprit is the window size that is set in the TCP/IP software layer on > your machines. Its usually set to around 4096 bytes, this is fine for > a 10Mbit/sec ethernet, but way too high for a slow speed ppp link > (remember everything is relative!). > >Window size is not a fixed number. It changes to adapt to the link. Some >implementations of tcp have an initial or maximum window size, or both, and >tuning these is sometimes required for low speed links. > >I suppose there are probably still some old, obsolete implementations of tcp >with fixed windows out there, but you should replace them rather than try to >tune them. Well I should learn to read my old code *before* writing about it. Jim is absolutely correct, its not the window size, its the send and receive buffer sizes that you change. These are set to 4096 bytes (at least on SunOS 4.x), what I've done is to reduce this size to a small number a factor of 10 reduced... The options I've used on my SET_SOCKOPT calls are: SO_SNDBUF and SO_RCVBUF. With the SET_SOCKOPT calls its possible to adjust a single connection to whatever you want, a small number means that the device input/output queue's are always small. By device I mean the 'ppp0' devices, this means that during my ftp transfer, the output queue of packets is very small and my telnet packets get transmitted very quickly. Try hacking a bit -- you'll see what I mean... but remember when you reduce the buffer sizes, you must set the SO_NODELAY on that socket, to get the ACK's back as quickly as possible.  -----------[000176][next][prev][last][first]---------------------------------------------------- Date: 13 May 93 01:31:54 GMT From: edhall@rand.org (Ed Hall) To: comp.dcom.modems,comp.sys.sun.misc,comp.protocols.tcp-ip,comp.protocols.ppp Subject: Re: Fast modems and dialup SLIP/PPP  In article <1srgnp$4md@terminator.rs.itd.umich.edu> Jim.Rees@umich.edu writes:
>In article <1993May12.141547.9340@olymp.informatik.uni-bonn.de>, ignatios@theory.cs.uni-bonn.de (Ignatios Souvatzis) writes:
>
>   > One thing that I found out is that SLIP requires a fully
>   > transparant channel, which makes it impossible to use softwareflowcontrol.
>
>  Yeah, thats why you should be using PPP, as appropriate for discussions in this
>  newsgroup :-).
>
>No, that's why you should be using out-of-band ("hardware") flow control.
>The async map in ppp is a software workaround for buggy hardware.

Real helpful response, there.  Some of us either don't own every piece
of equipment involved in a connection, or don't want to spend the money
to replace equipment or wiring which is otherwise functional.

SLIP is a hack.  The RFC it was defined in says as much.  It's "good
enough" for a lot of people's purposes, but it falls short in many other
situations.  PPP widens the field of possible applications considerably.
In the past it has suffered somewhat from a certain lack of focus on the
part of its designers (most committee efforts seem to have this problem)
but the current design is robust, well-defined, and extensible.  SLIP is
none of these.

-Ed Hall
edhall@rand.org


-----------[000177][next][prev][last][first]----------------------------------------------------
Date:      13 May 1993 04:35:18 GMT
To:        comp.protocols.tcp-ip
Subject:   Just a test

aaaaaaaaaaaaaa


-----------[000178][next][prev][last][first]----------------------------------------------------
Date:      13 May 1993 05:10:33 GMT
To:        comp.protocols.tcp-ip
Subject:   information wanted

Hi,
I am working on characterizing wide-area conversations on an Internet.
appreciate.

Mandy


-----------[000179][next][prev][last][first]----------------------------------------------------
Date:      Thu, 13 May 1993 05:35:31 GMT
From:      Monty Solomon <monty%roscom@think.com>
To:        comp.protocols.appletalk,comp.sys.mac.comm,comp.protocols.tcp-ip
Subject:   Looking for sockets for MacTCP

We are looking for sockets libraries for MacTCP.

Anyone have any info or pointers?

Thanks.

Monty

--
# Monty Solomon / PO Box 2486 / Framingham, MA  01701-0405
# monty%roscom@think.com


-----------[000180][next][prev][last][first]----------------------------------------------------
Date:      13 May 93 06:55:24 GMT
From:      J.Crowcroft@cs.ucl.ac.uk (Jon Crowcroft)
To:        comp.protocols.tcp-ip
Subject:   Re: Commercial Multimedia Software for teleconferencing


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

the DEC product is quite cute - the other big difference between it (and
most 'products') and the ietf
ones is that it started out on ether and fddi and tuned its bandwidth
down, whereas the ones in use on the Internet started out in the wide

>(sd, vat, wb, nevot, nv) and mentioned a rem-conf and a mbone mailing
>list.  Where can these programs be obtained from?  Which ones run on the
>DECstation 5000/240?  How does one subscribe to the mailing lists?

rem-conf-request@es.net
mbone-request@isi.edu

most those work on decstations,

i would add ivs, which interworks with known h.261 video codec
hardware using h.261 standard coding

all these take advantage of internet wide area (experiemtnalish) multicast
in fairly smart ways, which makes their model of multi-party audio
and/or video (and whiteboarding) conferencing  non-contralised (i.e. network
partition tolerant), again crucially  unlike most products...

again suitable in extremis for the internet

jon


-----------[000181][next][prev][last][first]----------------------------------------------------
Date:      Thu, 13 May 1993 08:09:37 GMT
From:      evansmp@uhura.aston.ac.uk (Mark Evans)
To:        comp.protocols.tcp-ip
Subject:   Re: RARP through a Router?

Paul W. Brooks esq. (pwb@newt.phys.unsw.edu.au) wrote:
: In article <1993May7.193913.5280@nstn.ns.ca>, daniel@nstn.ns.ca (Daniel MacKay) writes:
: > In <C6I3Io.BoF@sci.kun.nl> petervc@sci.kun.nl (Peter van Campen) writes:
: >
: > >- When we tried it out again on SunOS4.1.2 the SunOS rarpd refused to
: > >  give a RARP reply, because the client was not on his subnet.
: >
: > Hey, I just discovered this for myself a couple weeks ago!!  I have a whole
: > slew of Ether bridges that need RARP, but I can't put a server on every
: > segment.  Does anyone have any suggestions?
:
: So how does the rarpd detect the client was not on its subnet? the RARP
: query doesn't have any IP numbers in it, just the hardware address of
: the client.

Becuase what is looked at is the source address from the ethernet header.

An IP router cannot forward RARP becuase it is not IP.

What is needed is to forward the whole packet with it's ethernet headers
intact, in both directions. A bridge or a simple repeater will do this.

One answer would be to use bootp, which dosn't have this problem (also
any machine running a correct suite of IP can act as a bootp server).
Here the ethernet address of the sending machine is contained inside a UDP
packet, so it dosn't matter what is in the ethernet header which the server
gets.

:
: Paul Brooks        |Internet: pwb@newt.phys.unsw.edu.au
: Uni. of N.S.W.     |          paul@abccomp.oz.au
: Kensington NSW 2033|
: AUSTRALIA          | Microwave ovens: God's gift to bachelors

--
-------------------------------------------------------------------------
Mark Evans                                   |evansmp@uhura.aston.ac.uk
+(44) 21 429 9199  (Home)                    |evansmp@cs.aston.ac.uk
+(44) 21 359 6531 x4039 (Office)             |


-----------[000182][next][prev][last][first]----------------------------------------------------
Date:      13 May 1993 15:10:58 -0400
From:      clark@umbc.edu (Ms. Kathleen Clark)
To:        comp.protocols.tcp-ip
Subject:   source code on ftp sites?


I have looked around on some ftp sites, but I was wondering
if anyone knows of where I can find some source code to help
me with writing a program that simulates a router?

Thanks!
Kathy
clark@umbc.edu


-----------[000183][next][prev][last][first]----------------------------------------------------
Date:      13 May 93 11:37:09 GMT
From:      sp_ppm@space.alcbel.be (Paul Moore)
To:        comp.protocols.tcp-ip
Subject:   Info on high-speed transport protocols requested

Hello,

I don't know if this is the best place to put this request.

We are looking at an application that will involve distributing high-speed data
across a range of network types.

We have looked at using TCP, but its maximum transmission speed using a Sparc
over Ethernet is not fast enough for us. Also TCP is stream-oriented. TP4 is message-
oriented, but for the same hardware configuration, it is slower than TCP. We
cannot use XTP, because we need to have IP compatibility.

So we are looking for other transport protocols that might be available, and
preferably implemented on dedicated hardware, such as for the VME bus.

Are there any transport protocols that have been implemented to take advantage of
the much higher data rates achievable with FDDI? One that we know of is the
Versatile Message Transaction Protocol, or VMTP designed at Stanford University,
but are there any commercial implementations of this?

Also, what is the current state-of-the-art of TCP implementations, either built
into the operating system such as UNIX, or implemented on dedicated hardware?

Our proposed implementation looks like the following, with the transport protocol
X working over IP. In some cases, distribution is across a local LAN. In this case,
it may be possible to get by without using IP, although we would prefer a general solution which also works for the LAN/WAN case.

Data ------+                                                 +-----> Data
|                                                 |
v                                                 |
+-------+                                         +-------+
|       |                                         |       |
| Host  |                                         | Dest. |
| ----  |                                         | ----  |
|       |                                         |
|-------|                                         |-------|
| Appl. |                                         | Appl. |
|-------|                                         |-------|
|   X   |                                         |   X   |
|-------|     +-----+     +-----+     +-----+     |-------|
|  IP   |     | IP  |     | IP  |     | IP  |     |  IP   |
|-------|     |-----|     |-----|     |-----|     |-------|
|  DL   |     | DL  |     | DL  |     | DL  |     |  DL   |
+-------+     +-----+     +-----+     +-----+     +-------+
|          ^   |       ^   |       ^   |          ^
|          |   |       |   |       |   |          |
+----------+   +-------+   +-------+   +----------+

Paul

---
Paul Moore,                      email: sp_ppm@space.alcbel.be
ALcatel Bell Telephone,
Berkenrodelei 33,                phone: (+32) 3/829.5024
2660 Hoboken,
Belgium.                         fax: (+32) 3/829.5579


-----------[000184][next][prev][last][first]----------------------------------------------------
Date:      Thu, 13 May 1993 13:18:16 GMT
From:      wmp@ornl.gov (W. Mac Post)
Subject:   Re: New wuarchive ftp server available

If anyone runs a ftpmail server I would like to know about it.  Better yet,
if anyone has a list, or knows the location of a list of ftpmail servers
I would like to get a copy.  We have a service that maintains and distributes
data for global climate and carbon cycle research.  Some individuals interested
in getting this information do not have ftp capabilities so we would like
to be able to provide them with a list of ftpmail servers.  I'll post
the list I compile if there is not one somewhere already.

Thanks,

Mac Post
wmp@ornl.gov


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

In article <1sl8jjINNpdn@spatula.csv.warwick.ac.uk> cudep@csv.warwick.ac.uk (Ian Dickinson) writes:
>I have a Sun3/50 running SunOS4.1.1u1 and a V.32/V.42 Hayes compatible modem.

And the slight lack of Hayes compatibility turned out to be the main problem.
A bit of hacking on CR versus LF and I've got it sorted.

However, I did find I needed RTS/CTS as suggested here, and I now have that
working.

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

The net has come up trumps here - I now have a set of patches which make
cslip-2.6 a dynamically loadable module, and I'm told that ppp-1.2 can do
the same, and more importantly, that they happily co-exist.

I'm a happy dialer now.

Cheers,
--
vato@csv.warwick.ac.uk  ...!uknet!warwick!vato        those who disapprove but
@c=GB@o=University of Warwick@ou=Computing Services@cn=Ian Dickinson      read


-----------[000186][next][prev][last][first]----------------------------------------------------
Date:      13 May 1993 16:07:54 GMT
From:      Jim.Rees@umich.edu
To:        comp.dcom.modems,comp.sys.sun.misc,comp.protocols.tcp-ip,comp.protocols.ppp
Subject:   Re: Fast modems and dialup SLIP/PPP

In article <16771@rand.org>, edhall@rand.org (Ed Hall) writes:

Real helpful response, there.  Some of us either don't own every piece
of equipment involved in a connection, or don't want to spend the money
to replace equipment or wiring which is otherwise functional.

Sounds like you agree with me here.  If you have buggy hardware, and can't
fix it, then the async map in ppp can help.

but the current design is robust, well-defined, and extensible.  SLIP is
none of these.

I'll agree with you on two out of three, but I don't see how you can claim
that ppp is robust.  Certainly many of the implementations of ppp are not
robust, as a quick glance through comp.protocols.ppp will demonstrate.  It's
possible that the protocol itself could be considered robust now that it has
matured a bit.


-----------[000187][next][prev][last][first]----------------------------------------------------
Date:      13 May 93 18:19:28 GMT
From:      rryan@panix.com (Rob Ryan)
To:        comp.dcom.modems,comp.sys.sun.misc,comp.protocols.tcp-ip,comp.protocols.ppp
Subject:   Re: Fast modems and dialup SLIP/PPP

In <BOB.93May10144815@volitans.MorningStar.Com> bob@MorningStar.Com (Bob Sutterfield) writes:

>In article <1sl8jjINNpdn@spatula.csv.warwick.ac.uk> cudep@csv.warwick.ac.uk (Ian Dickinson) writes:
>   I have a Sun3/50 running SunOS4.1.1u1 and a V.32/V.42 Hayes
>   compatible modem.  I've found that the SunOS tip doesn't understand
>   hayes modems faster than 2400.
>
>Don't worry about whether it's a Hayes or anything else.  Just try
>putting a line like this into your /etc/remote:
>	cua:dv=/dev/cua:br#38400:
> ...

Personally, I found that I had to include a "nt" field in /etc/remote
file to have tip (even when I set hardwareflow) not send ^S's and ^Q's.
I'm running SunOS 4.1.3.  But, with that, I'm successfully using tip
at 38400, using a 14400 V.42bis modem.

-- Rob


-----------[000188][next][prev][last][first]----------------------------------------------------
Date:      Thu, 13 May 1993 19:03:27 GMT
From:      Tom Sheppard <toms@bnr.ca>
To:        comp.protocols.tcp-ip
Subject:   Ethernet Out-of-Band Reset?

Is there any known or standardized way of using OOB for Ethernet?
Specifically, if my Ethernet peripheral is presumed to be brain-dead,
can I do anything over Ethernet to force a H/W reset?  Since I'm
developing the logic board for the peripheral, I can be somewhat
creative.  However, I do have to use a standard protocol chip.

I can think up some screwball schemes but I would prefer to know if
there is a standard.  If not, I'd still be interested in how you may have
done the same thing.

Security is a concern (not sure how important yet).  I would also like
any scheme to be useable from any workstation vendor.  Does your method
prevent any old bozo from resetting the peripheral?

Oh, did I mention I may also want to reset the peripheral over a WAN?  :-)

---------------------------------------------------------------------------
Tom Sheppard     Bell-Northern Research Ltd. "Got a minute..."
613-763-4053 [W] P.O. Box 3511, Station C    Translation: I'm about to dump
toms@bnr.ca      K1Y 4H7                     ...Sally Forth comic strip


-----------[000189][next][prev][last][first]----------------------------------------------------
Date:      Thu, 13 May 1993 19:32:53 GMT
From:      bob@MorningStar.Com (Bob Sutterfield)
To:        comp.dcom.modems,comp.sys.sun.misc,comp.protocols.tcp-ip,comp.protocols.ppp
Subject:   Re: Fast modems and dialup SLIP/PPP

In article <1stroq$ocp@terminator.rs.itd.umich.edu> Jim.Rees@umich.edu writes: In article <16771@rand.org>, edhall@rand.org (Ed Hall) writes: ...but the current design is robust, well-defined, and extensible. I'll agree with you on two out of three, but I don't see how you can claim that ppp is robust. Certainly many of the implementations of ppp are not robust, as a quick glance through comp.protocols.ppp will demonstrate. How many of the comp.protocols.ppp questions are really about the PPP protocol, and ways in which it needs to be changed or updated? How many more are about system-specific installation problems, or network configuration questions like routing or ARP hacks? Many of the questions in comp.protocols.ppp are from people using code that is largely unchanged from Drew Perkins' original proof-of-concept implementation, written four years ago while RFC 1134 was being ironed out by Drew and the other programmers/protocol designers (notably Russ Hobby), who were also working on their own independent proof-of-concept implementations. I haven't looked at dp-2.3, but I suspect the guts of its PPP protocol engine haven't changed much since it was called "patchlevel 5", by which time its guts hadn't changed much since Drew's original 4.2BSD code. Yes, more recent maintainers have done a lot of porting work and bug fixes, and they've apparently added modern VJ negotiations, but the guts are showing their age. The IETF PPP Working Group (defines the protocol) and the PPP Consortium (industry group that conducts formal interoperability tests) have learned a *lot* since RFC 1134 was published, and RFC 1331 shows it. Every finite-state-machine change, no matter how subtle, reflects that increase in the collective wisdom. The remarkable thing is that, even considering the vintage of the guts of the freely-available PPP implementations, we don't see more questions on comp.protocols.ppp about how its PPP engine is broken, or lacks modern features, or whatever. From that, I infer that even that ancient PPP implementation is pretty robust! It's possible that the protocol itself could be considered robust now that it has matured a bit. Everything takes some shaking down. Now, if only the popular free implementations would also mature along with the protocol... -- Bob Sutterfield, Morning Star Technologies +1 614 451 1883 1760 Zollinger Rd, Columbus Ohio USA, 43221-2856 +1 800 558 7827 bob@MorningStar.Com +1 614 459 5054 (FAX)  -----------[000190][next][prev][last][first]---------------------------------------------------- Date: 13 May 1993 21:23:15 GMT From: WEINTRAU@arizvm1.ccit.arizona.edu To: comp.protocols.tcp-ip Subject: TN3270 from qvtnet33  I just downloaded QVTNET33.zip from FTP.CICA.INDINIA.EDU. Looking at the documentation I find that it only supports ASCII terminals. Is there a way for it to support 3270 (tn3270) for access to our IBM mainframe? ----------------------------------------------------------------------------- DAVID B. WEINTRAUB | VOICE: 602-626-0876 | SYSTEMS PROGRAMMER - SENIOR | FAX: 602-626-4884 | OFFICE OF MEDICAL COMPUTING | EMAIL: WEINTRAU@ARIZVM1.CCIT.ARIZONA.EDU | 1501 N. CAMPBELL AVE #2104 | | TUCSON, ARIZONA 85724 | | ---------------------------------------------------------------------------- DISCLAIMER: THE ABOVE STATEMENTS ARE THE AUTHORS AND DO NOT REPRESENT THE OPINIONS OF THE UNIVERSITY OF ARIZONA.  -----------[000191][next][prev][last][first]---------------------------------------------------- Date: Thu, 13 May 1993 23:43:40 GMT From: Mark_Hebets@ccmail.radian.com (Mark Hebets) To: comp.protocols.tcp-ip Subject: SUMMARY: Scripted FTP  I asked: > I need a way to run an FTP transfer unattended, at a particular > time every day. Is there a good example of how to do this? > I know I could run the ftp command with input re-directed, but this > would require a little work to fake the keyboard input for the password, > and it would not be too robust. Is there a way to run it from a > script, that would allow me to handle error messages and retry the > transfer? Thanks! I got answers from 10 of you, they broke down into three categories: 1) RTFM. There is a .netrc file that ftp reads, I should have known about this :(. Ftp will read the login/password data (and possibly a file transfer script?) from$HOME/.netrc.  Then stdin redirection would
work for the rest of the transfer.

(Still not too robust, I'm looking at a noisy connection, with
dropped connections and retries likely.)

2) Use a special ftp program

- bftp (batch ftp) from gatekeeper.dec.com in /.3/net/ip/applic

- autoftp from src.doc.ic.ak in packages/unix-c/networks/autoftp2.tar-z

- "There was also a program called "xtp" posted to alt.sources a
few years ago (like 1989 or 1990).  It is a command-line
front-end for ftp."  Maybe on a big archive site?

3) Use a general-purpose scripting program.

- perl

- mirror.tar.Z from sunsite.unc.edu:pub/packages/ftp-archive

- tcl and expect from ftp.uu.net in /languages/tcl

I don't have ftp access at this site, so I haven't had a chance to
track any of this down yet.  Tcl/expect got the most recommendations,
sounds like I should learn about it.

Thanks to:

Stephen Trier        trier@ins.cwru.edu
John Sottile         jjs@cblph.att.com
Arnt Gulbrandsen     agulbra@pvv.unit.no
Bruce Barnett        barnett@alydar.crd.ge.com
Philippe Oechslin    oechslin@ltisun.epfl.ch
John R. Zavgren      gte.com!ganges!jrz0
Mark D. Eggers       mdeggers@wdi.disney.com
Leila Burrell-Davis  leilabd@syma.sussex.ac.uk

----
Mark Hebets
Phone: 512-454-4797


-----------[000192][next][prev][last][first]----------------------------------------------------
Date:      Fri, 14 May 1993 00:18:13 GMT
From:      ggm@brolga.cc.uq.oz.au (George Michaelson)
To:        comp.protocols.tcp-ip
Subject:   Re: Commercial Multimedia Software for teleconferencing


[rumor mode] when I installed the Internet mm suite on a dec 5000/25
and de-installed DECspin the users stated:

oh wow. it works.

previously, nice glossy video was being shipped at the expense of audio
quality. since most people view (sorry) this stuff as a videoPHONE that
is voice with occaisionally useful images, rather than an audioMOVIE with
nice images and occaisionally useful sound, methinks DEC got the code wrong.

I am also less than impressed with being told to buy alpha to achieve useful
proprietary mm performance. everyone else is crowing about how SMALL a box
they can pack mm onto (pc/mac announcements being common) yet DEC sing about
how BIG a box you need to reaaly see thier code work...

-george
--
George Michaelson
G.Michaelson@cc.uq.oz.au The Prentice Centre      | There's no  market for
University of Queensland | hippos in Philadelphia
Phone: +61 7 365 4079    QLD Australia 4072       |          -Bertold Brecht


-----------[000193][next][prev][last][first]----------------------------------------------------
Date:      Fri, 14 May 1993 01:18:41 GMT
From:      cproto@cs.curtin.edu.au (Computer Protocol)
To:        comp.protocols.tcp-ip
Subject:   Telnet EOR option?

I wonder if any of you TCP-IP experts could help me with a Telnet
problem I've been having - or refer me to another source.  Let us
assume two Telnet NVTs are talking to each other across a network
(I hope I have this right I am no Telnet expert):

Host side
+-----+                                 +-----+
| NVT |<------------------------------->| NVT |----[terminal]
+-----+                                 +-----+

Anyway both Telnets have EOR option set.  How should a terminal connected
to the client NVT see the incoming data stream in character and in line
mode?  What sort of packets should be coming across the line.  I have
access to a LAN analyser so I can find out what is going across the line
but the problem is I don't know what is supposed to be going across the
line.

In character mode, should each character be sent with an EOR tacked onto
the end of each character sent?  In line mode, should the EOR be tacked
onto the end of each line?  Does EOR work in a different way, is my view
of the problem to simplistic?

george.
-----------------
cproto@cs.curtin.edu.au


-----------[000194][next][prev][last][first]----------------------------------------------------
Date:      14 May 1993 01:53:16 GMT
From:      vern@horse.ee.lbl.gov (Vern Paxson)
To:        comp.protocols.tcp-ip
Subject:   Paper on wide-area TCP growth trends available for ftp

The following paper is now available via anonymous ftp to ftp.ee.lbl.gov.

Growth Trends in Wide-Area TCP Connections
Vern Paxson
Lawrence Berkeley Laboratory and
EECS Division, University of California, Berkeley
vern@ee.lbl.gov

We analyze the growth of a medium-sized research laboratory's
wide-area TCP connections over a period of more than two years.
Our data consisted of six month-long traces of all TCP connections
made between the site and the rest of the world.  We find that
{\em smtp\/}, {\em ftp\/}, and {\em X11} traffic all exhibited
exponential growth in the number of connections and bytes
transferred, at rates significantly greater than that at which the
site's overall computing resources grew; that individual users
increasingly affected the site's traffic profile by making
wide-area connections from background scripts; that the proportion
of local computers participating in wide-area traffic outpaces the
site's overall growth; that use of the network by individual
computers appears to be constant for some protocols ({\em telnet})
and growing exponentially for others ({\em ftp\/}, {\em smtp\/});
and that wide-area traffic geography is diverse and dynamic.

If you have trouble printing it let me know and I'll mail you hardcopy.

Vern

Vern Paxson				vern@ee.lbl.gov
Systems Engineering		        ucbvax!ee.lbl.gov!vern
Lawrence Berkeley Laboratory		(510) 486-7504


-----------[000195][next][prev][last][first]----------------------------------------------------
Date:      Fri, 14 May 1993 06:08:59 GMT
From:      schlege@lips2.ecn.purdue.edu (Kevin L Schlegelmilch)
To:        comp.protocols.tcp-ip
Subject:   TCP calculation

Question:
If a sender of TCP has a window size limit of 4096 bytes and the
receiver has a limit of 8196 bytes, the two are connected via a
1544000bps (t-1) link, for what distances are the window sizes a
bottleneck, and for what distances is the link a bottleneck?
(Express the distance in microseconds.)  If the speed of light
is 3 times 10 to the 8th meters/second, how long is the cable at
the threshold?

Kevin


-----------[000196][next][prev][last][first]----------------------------------------------------
Date:      14 May 93 16:52:15 -0600
From:      system@condor.navsses.navy.mil (Mike Jacobi; NAVSSES 012C; VAX SYSTEM MANAGER)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP calculation

In article <C70xGr.IsF.1@cs.cmu.edu>, cmaeda+@cs.cmu.edu (Christopher Maeda) writes:
> In article <C706F0.31M@noose.ecn.purdue.edu> schlege@lips2.ecn.purdue.edu (Kevin L Schlegelmilch) writes:
>>Question:
>>  If a sender of TCP has a window size limit of 4096 bytes and the
>>receiver has a limit of 8196 bytes, the two are connected via a
>>1544000bps (t-1) link, for what distances are the window sizes a
>>bottleneck, and for what distances is the link a bottleneck?
>>(Express the distance in microseconds.)  If the speed of light
>>is 3 times 10 to the 8th meters/second, how long is the cable at
>>the threshold?
>
> What is the airspeed velocity of an unladen swallow?
>

African or European swallow?

>
>
> --
> Chris Maeda, Grad Student and RetroGrouch <cmaeda@cs.cmu.edu>
> "A unix signature isn't a return address, it's the ASCII equivalent of
> a black velvet clown painting. It's a rectangle of carets surrounding
> a quote from a literary giant of weeniedom like Heinlein or Dr. Who."
--
Mike Jacobi
NAVSSES VAXCluster system manager
System@Eagle.Navsses.Navy.Mil
System@Condor.Navsses.Navy.Mil

Disclaimer - I speak for myself.  No-one else.


-----------[000197][next][prev][last][first]----------------------------------------------------
Date:      Fri, 14 May 1993 11:34:01 GMT
From:      debiso@westfield.win.net (Joe DeBiso)
To:        comp.protocols.tcp-ip
Subject:   Problem with remote printing

I am having a problem mounting a printer on my SCO box from a PC
using PC-NFS.  I have other systems in the NET and have no
problems printing from or to the SCO box.  Any suggestions would be
greatly appreciated.


-----------[000198][next][prev][last][first]----------------------------------------------------
Date:      Fri, 14 May 1993 13:42:04 GMT
From:      carlson@steam.Xylogics.COM (James Carlson)
To:        comp.protocols.tcp-ip
Subject:   Re: Specs on rlogin? now where are dey?


In article <1svsdhINN1hq@flash.pax.tpa.com.au>,
hart@flash.pax.tpa.com.au (Leigh M Hart) writes:
|> Now, either I didn't look hard enough or I'm blind, but for the life of
|> me I can't find the specifications for the rlogin protocol.  The RFC's
|> don't seem to cover it (unless I missed it) - any ideas?

You did -- RFC 1282.

--
James Carlson <carlson@xylogics.com>            Tel:  +1 617 272 8140
Annex Software Support / Xylogics, Inc.               +1 800 225 3317
53 Third Avenue / Burlington MA  01803-4491     Fax:  +1 617 272 3159


-----------[000199][next][prev][last][first]----------------------------------------------------
Date:      Fri, 14 May 1993 13:58:51 GMT
From:      fred_s@netcom.com (Frederick Scott)
To:        comp.protocols.tcp-ip
Subject:   Re: RARP through a Router?

evansmp@uhura.aston.ac.uk (Mark Evans) writes:

>Paul W. Brooks esq. (pwb@newt.phys.unsw.edu.au) wrote:
>: So how does the rarpd detect the client was not on its subnet? the RARP
>: query doesn't have any IP numbers in it, just the hardware address of
>: the client.
>
>Becuase what is looked at is the source address from the ethernet header.
>
>An IP router cannot forward RARP becuase it is not IP.

Perhaps I'm mistaken but I thought the original question stemmed from
a situation where multiple subnets were on the same wire.  Since the RARP
packet was addressed as an ethernet broadcast on the MAC level, no routing was
necessary but the rarpd server was ignoring the client not on his subnet
anyway.

Assuming I'm mistaken and the original poster meant that the subnets are
actually on different wires:

>What is needed is to forward the whole packet with it's ethernet headers
>intact, in both directions. A bridge or a simple repeater will do this.

Of course, you have changing your entire IP addressing scheme or (if
applicable) subnet mask to bridge between ethernet segments rather than
route them...

>One answer would be to use bootp, which dosn't have this problem (also
>any machine running a correct suite of IP can act as a bootp server).
>Here the ethernet address of the sending machine is contained inside a UDP
>packet, so it dosn't matter what is in the ethernet header which the server
>gets.

Yes, but the destination address on a bootp request can not normally be
present.  It's usually filled in with the IP broadcast address or all zeroes
(depending on the implementation - I think someone told me the RFD actually
recommends using 255.255.255.255).  Therefore, bootp requests cannot be
routed (by standard, run-of-the mill IP routers) either, unless you have
specific software and an administrative database to do it.  (In short, unless
you have a "bootp router".)

Fred


-----------[000200][next][prev][last][first]----------------------------------------------------
Date:      Fri, 14 May 1993 15:53:14 GMT
From:      cmaeda+@cs.cmu.edu (Christopher Maeda)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP calculation

In article <C706F0.31M@noose.ecn.purdue.edu> schlege@lips2.ecn.purdue.edu (Kevin L Schlegelmilch) writes:
>Question:
>  If a sender of TCP has a window size limit of 4096 bytes and the
>receiver has a limit of 8196 bytes, the two are connected via a
>1544000bps (t-1) link, for what distances are the window sizes a
>bottleneck, and for what distances is the link a bottleneck?
>(Express the distance in microseconds.)  If the speed of light
>is 3 times 10 to the 8th meters/second, how long is the cable at
>the threshold?

What is the airspeed velocity of an unladen swallow?

--
Chris Maeda, Grad Student and RetroGrouch <cmaeda@cs.cmu.edu>
"A unix signature isn't a return address, it's the ASCII equivalent of
a black velvet clown painting. It's a rectangle of carets surrounding
a quote from a literary giant of weeniedom like Heinlein or Dr. Who."


-----------[000201][next][prev][last][first]----------------------------------------------------
Date:      Fri, 14 May 1993 16:58:01 GMT
From:      vjs@rhyolite.wpd.sgi.com (Vernon Schryver)
To:        comp.protocols.tcp-ip
Subject:   Re: Specs on rlogin? now where are dey?

In article <1svsdhINN1hq@flash.pax.tpa.com.au>, hart@flash.pax.tpa.com.au (Leigh M Hart) writes:
> Now, either I didn't look hard enough or I'm blind, but for the life of
> me I can't find the specifications for the rlogin protocol.  The RFC's
> don't seem to cover it (unless I missed it) - any ideas?

Like RIP, the authoritative reference is not an RFC, but the source.

Look on uunet.

Vernon Schryver,  vjs@sgi.com


-----------[000202][next][prev][last][first]----------------------------------------------------
Date:      Fri, 14 May 1993 17:22:20 GMT
From:      davis@unidata.ucar.edu (Glenn P. Davis)
To:        comp.protocols.tcp-ip
Subject:   PIPE_BUF (or equivalent) for a socket file descriptor

Hi.

I have a tcp socket which is set for non-blocking I/O:

int cfd ; /* client side file descriptor, a TCP socket */
int flags = fcntl(cfd, F_GETFL, 0) ;

if(flags == -1)
{
serror("fcntl(..., F_GETFL,)") ;
return 0 ;
}
/* else */

flags |= O_NONBLOCK ;
if(fcntl(cfd, F_SETFL, flags) == -1)
{
serror("fcntl(..., F_SETFL, O_NONBLOCK)") ;
return 0 ;
}

What I need to determine is the maximum number of bytes that can
be written atomically to the descriptor. (If this were a POSIX system
and the descriptor was a pipe, this number would be referred to as
PIPE_BUF.) By "written atomically", I mean that all the bytes will
be transfered by a single call to write(), or none will be transfered
write() returns -1 and errno is set to EWOULDBLOCK (EAGAIN).

I guess the first question is whether I can count on the existance of
such semantics at all? The implementations of interest are all UNIX:
SunOS 4.1.x, SunOS 5.1, Ultrix 4.3, AIX 3.2, IRIX 4.0.5F, OSF-1 ...

The second question is, if the semantics exist, how do I determine the number?
If the POSIX function fpathconf(cfd, _PC_PIPE_BUF) returns an error, can
a make a guess from the return of getsockopt(..., ..., SO_SNDBUF, ...) ?
If both are available, what is or should be the relationship between them?

Here is a code fragment I ran on several systems:

long mtu = 512 ; /* _POSIX_PIPE_BUF, default minimum value? */
int optlen = sizeof(mtu) ;

/* try fpathconf first */
mtu = fpathconf(cfd, _PC_PIPE_BUF) ;
if(mtu == -1L)
{
int errnum = errno ;
fprintf(stderr, "fpathconf: %s\n", strerror(errnum));
}
else
{
fprintf(stdout, "MTU (_PC_PIPE_BUF) %ld\n",
mtu) ;
}
/* compare with getsockopt */
errno = 0 ;
if(getsockopt(cfd, SOL_SOCKET, SO_SNDBUF,
(char *)&mtu, &optlen ) < 0)
{
int errnum = errno ;
fprintf(stderr, "getsockopt: %s\n", strerror(errnum));
}
else
{
fprintf(stdout, "MTU (getsockopt SOL_SOCKET) %ld\n",
mtu) ;
}

And here are the results:

SunOS 4.1.3
fpathconf: Invalid argument
MTU (getsockopt SOL_SOCKET) 4096

SunOS 5.1
MTU (_PC_PIPE_BUF) 5120
getsockopt: No such file or directory

Ultrix 4.3, MIPSEL
MTU (_PC_PIPE_BUF) 4096
MTU (getsockopt SOL_SOCKET) 16384

AIX 3.2
MTU (_PC_PIPE_BUF) 32768
MTU (getsockopt SOL_SOCKET) 16060

IRIX 4.0.5F
MTU (_PC_PIPE_BUF) 10240
MTU (getsockopt SOL_SOCKET) 61320

This shows how far standardization efforts have to go to get
sockets rolled in.

Some hypotheses (Feel free to comment, confirm, or deny.)

SunOS 4.1.3
Doesn't support fpathconf for sockets => sockets and
pipes have different semantics => all bets are off?
Kinda small SO_SNDBUF?

SunOS 5.1
Sockets and pipes share kernel support, but they didn't
get the getsockopt compatibilty call right. Use 5120.

Ultrix 4.3, MIPSEL
I guess use the smaller of the two numbers. Do the semantics
apply?

AIX
How can getsockopt(...SO_SNDBUF) be less than PIPE_BUF?
Weird. Do the semantics apply? With which number?

IRIX
Sockets and pipes share kernel support, use 10240.
(If all the systems had a number this big, I wouldn't
need to do the nonblocking I/O at all!)

In the absence of a reasonable, portable way to determine this
at runtime, is there a number which will "always" work? 512? 1024?
4096?

Any discussion? Especially welcome are remarks by those familiar with
the internals of the various systems.

Glenn P. Davis				davis@unidata.ucar.edu
UCAR / Unidata
PO Box 3000                   3300 Mitchell Lane, Suite 170
Boulder, CO 80307-3000        Boulder, CO  80301

(303) 497 8643


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

In article <1stbbuINNct@spatula.csv.warwick.ac.uk> cudep@csv.warwick.ac.uk (Ian Dickinson) writes:
>The net has come up trumps here - I now have a set of patches which make
>cslip-2.6 a dynamically loadable module, and I'm told that ppp-1.2 can do
>the same, and more importantly, that they happily co-exist.

Enough people have asked me where to get this from (and I don't know the
offical source for these patches) that I've put the stuff up for anon ftp
from ftp.warwick.ac.uk:/pub/inet

Will a modloadable cslip-2.6 co-exist with dp-2.3 ?

Also, Bob Sutterfield mentioned it being quite easy to modify a PPP
implementation to do SLIP.  Has anyone done this to a PD implementation
and managed to keep the PPP support working?  It certainly looks like dp-2.3
with this capablity would be ideal for my situation.  But I'll stick with
what I have for now.

Cheers,
--
vato@csv.warwick.ac.uk  ...!uknet!warwick!vato        those who disapprove but
@c=GB@o=University of Warwick@ou=Computing Services@cn=Ian Dickinson      read


-----------[000204][next][prev][last][first]----------------------------------------------------
Date:      Fri, 14 May 93 20:18:23 GMT
From:      ddml@visual1.jhuapl.edu (Dave Libershal)
To:        comp.protocols.tcp-ip
Subject:   Help! Need feedback on FTP's PC/LPD

Hello,

Does anybody have any experience they can share using FTP's PC/LPD
software??  We want to print from both remote UNIX machines and a local
PC to the printer which is attached to that PC (Parallel connection). PC/LPD
runs in a DOS box under Windows, allowing the remote UNIX printing. Local
printing can be done from the Windows or DOS drivers. So, that should do
the trick. But, how well does it work. The FTP sales person says they run it
on standalone (dedicated print server) PCs for performance reasons.

I'm thinking about getting a copy to try it out with our applications, but I
don't want to use the PC as a dedicated print server; I want the user to be
able to run his normal PC applications while allowing the UNIX printing.

Has anybody done this????

Thanks,

Dave Libershal


-----------[000205][next][prev][last][first]----------------------------------------------------
Date:      Fri, 14 May 93 20:36:41 GMT
From:      ccg@tcdsp1.mmm.com ("Charles Ganzhorn")
To:        comp.protocols.tcp-ip
Subject:   Re: Specs on rlogin? now where are dey?

One thing that seems to be missing in the spec is the connection port
numbers and the starting range of the return port numbers.  Where are
they?

Charles.

--
Charles Ganzhorn			E/Mail:  ccganzhorn@mmm.com
3M IT Network Services			AT&T:	 +1 612 736 7122
St. Paul, MN				FAX:	 +1 612 736 7689


-----------[000206][next][prev][last][first]----------------------------------------------------
Date:      Fri, 14 May 1993 21:36:44 GMT
From:      ekc1@wucs1.wustl.edu (Eng K. Chong)
To:        comp.protocols.tcp-ip
Subject:   Can't obtain broadacast mask from UDP app.

We're using a version of the winsock API and can't obtain the broadcast mask
via the standard ioctl command (in winsock the command is actually ioctlsocket) as it is currently not supported.

My question:

Does anyone know of an alternative means of obtaining the broadcast mask under
the winsock API?   -- OR --

I can obtain my local IP address and determine whether or not it is class
the implications of IP-subnetting.   Can anyone offer some experienced

ekc1@wucs1.wustl.edu


-----------[000207][next][prev][last][first]----------------------------------------------------
Date:      Fri, 14 May 1993 21:53:55 GMT
From:      chris@uis.com (Chris Howard)
To:        comp.protocols.tcp-ip,comp.sys.hp,comp.sys.ibm
Subject:   IBM 3090 connections

We have a need for information on tcp/ip connections from
an IBM 3090 to an existing network (ethernet) of HP Unix
boxes (750s).

We need to move a _lot_ of data in file transfers.

Any suggestions, or contacts to people doing it now would
be appreciated.

--
Chris Howard					          chris@uis.com
Unix Integration Services     	Urbandale, Iowa	          (515) 254-3074
--
Chris Howard					          chris@uis.com
Unix Integration Services     	Urbandale, Iowa	          (515) 254-3074


-----------[000208][next][prev][last][first]----------------------------------------------------
Date:      Fri, 14 May 1993 21:59:15 GMT
From:      vhalkka@klaava.Helsinki.FI (Vesa Halkka)
To:        comp.dcom.lans.ethernet,comp.protocols.tcp-ip
Subject:   Re: DECbridge90 filtering strategy ?

In <1993May7.112947.9474@serra.unipi.it> luigi@pical2.iet.unipi.it (Luigi Rizzo) writes:

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

It is a toy bridge: it has a very limited forwarding table,
and *it is bridging only to one direction.* Every packet
coming from the other direction goes through the bridge.

They were cheap, and we almost bought them. But we did read
the FM.

VesA


-----------[000209][next][prev][last][first]----------------------------------------------------
Date:      Sat, 15 May 1993 02:29:43 GMT
From:      raj@cup.hp.com (Rick Jones)
To:        comp.protocols.tcp-ip,comp.sys.hp,comp.sys.ibm
Subject:   Re: IBM 3090 connections

Well, since you are going to move a lot of data, I assume that you are
interested in performance.

"Raw" TCP as measured by netperf on the 750 will proceed in excess of
1024 KBytes/s (K=1024). With reasonably zippy disks, you should be
able to see that with FTP.

If you would like to get a copy of netperf, try ftp-ing over to
iworks.ecn.uiowa.edu, or ftp.csc.liv.ac.uk.

Having said all that, I assume that you have figured-out that your
*best-case* transfer time is going to be on the order of 50*1024
seconds, or roughly 14 hours, 15 minutes. This assumes that the *only*
nodes generating traffic on the Ethernet are the 3090 and the 750. The
peak transfer rate that I have seen on "timeshare" lans has been
800KB/s, which would up the time to over 18 hours.

This seems like a rather long time. You might want to consider means
of improving your theoretical performance. If there are multiple
files, you could add a second Ethernet between the two hosts. My
stronger suggestions, however, would be to put a faster link between
the two boxes - perhaps FDDI.

If you opt for FDDI, you must choose an EISA FDDI card. "Raw" TCP on
the HP EISA FDDI is not going to exceed 4MB/s. If you are willing to
upgrade the 750 to a 755, you have another choice in FDDI interfaces -
an integrated one which has "raw" TCP of 80+Mb/s. I do not know what
sort of FTP performance you could expect. If you cannot upgrade the
750, there are a couple of third-parties who either have, or are
producing EISA FDDI cards for 700's - I would hope that they could
meet or exceed the performance levels of the HP EISA FDDI card.

Of course, this rambling completely ignores the capabilities and/or
limitations of the 3090...and remember, I have quoted a lot of TCP
performance figures, NOT FTP figures. FTP performance includes a lot
more than just TCP, it includes disk, filesystem, and all sorts of
other things that could bog stuff down. Think of the TCP number in the
same way you would (should?) MFLOPS - something you are guaranteed NOT
to exceed... ;-)

rick jones
I am in a maze of twisty little opinions, all my own...
I am but knowledgable north by northwest, when the bits are from the east...


-----------[000210][next][prev][last][first]----------------------------------------------------
Date:      15 May 93 04:29:45 GMT
From:      sun-jian@cc.sophia.ac.jp (Sun Jian)
To:        comp.protocols.tcp-ip
Subject:   about PWD_2 and simtel20

i send this message befor, but it may be did not delivered because my server
host spool was overflowed. i send it again.
i got a message on the PED_2 and simtel20, but  i do not know them detail.
i need some information on the protocol simulations, but i have not any materials on it, and so i need help now.


-----------[000211][next][prev][last][first]----------------------------------------------------
Date:      15 May 93 04:33:45 GMT
From:      sun-jian@cc.sophia.ac.jp (Sun Jian)
To:        comp.protocols.tcp-ip
Subject:   about PWD_2 and simtel20

i send this message befor, but it may be did not delivered because my server
host spool was overflowed. i send it again.
i got a message on the PED_2 and simtel20, but  i do not know them detail.
i need some information on the protocol simulations, but i have not any materia\
ls on it, and so i need help now.


-----------[000212][next][prev][last][first]----------------------------------------------------
Date:      Sat, 15 May 1993 08:11:42 GMT
From:      sakura@ics.kula.kyoto-u.ac.jp (Takashi SAKURAGAWA)
To:        comp.sys.mac.system,comp.sys.mac.comm,comp.protocols.tcp-ip
Subject:   Question: Broadcast address of MacTCP

Hi! Everybody.

When I open AdminTCP or MacTCP control panel on Macintosh, there is no
to set an arbitrary broatcast address.  I think there is no protocol

I think there are three possibilities.

(1)Macintosh sends no broadcast packet and it does not recognize them.

(2)Macintosh sends no broadcast packet and it recognize more than one

Which is the truth?

sakura@ics.kula.kyoto-u.ac.jp
Takashi SAKURAGAWA
Faculty of Integrated Human Studies
Kyoto University
Japan


-----------[000213][next][prev][last][first]----------------------------------------------------
Date:      14 May 1993 20:01:12 +0930
From:      hart@flash.pax.tpa.com.au (Leigh M Hart)
To:        comp.protocols.tcp-ip
Subject:   Specs on rlogin? now where are dey?

Now, either I didn't look hard enough or I'm blind, but for the life of
me I can't find the specifications for the rlogin protocol.  The RFC's
don't seem to cover it (unless I missed it) - any ideas?

Cheers

Leigh
--
Leigh M Hart (hart@pax.tpa.com.au)


-----------[000214][next][prev][last][first]----------------------------------------------------
Date:      15 May 1993 14:11:55 GMT
From:      trier@odin.ins.cwru.edu (Stephen C. Trier)
To:        comp.sys.mac.system,comp.sys.mac.comm,comp.protocols.tcp-ip
Subject:   Re: Question: Broadcast address of MacTCP

In article <SAKURA.93May15171142@misen.ics.kula.kyoto-u.ac.jp> sakura@ics.kula.kyoto-u.ac.jp (Takashi SAKURAGAWA) writes:

This option is correct.  I don't know if MacTCP can receive broadcasts to

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


-----------[000215][next][prev][last][first]----------------------------------------------------
Date:      Sat, 15 May 1993 16:07:33 GMT
From:      swslr@well.sf.ca.us (Larry Krone)
To:        comp.protocols.tcp-ip
Subject:   SCO TCP

Gentle People:

We are trying to use SCO TCP/IP under SCO 2.3.4...We are using the
progress database pacakge and FTP.  After a certain number of connections
via TCP has been reached, the system hangs....this number seems to be around
30 or 40 but is not consistent....Is there some TCP/IP paramaters
for SCO that I can check, or does anyone have any ideas???

Thanx,

Larry Krone
swslr@well.sf.ca.us


-----------[000216][next][prev][last][first]----------------------------------------------------
Date:      16 May 1993 02:07:10 GMT
From:      shuford@cs.utk.edu (Richard Shuford)
To:        vmsnet.networks.misc,comp.protocols.tcp-ip
Subject:   Re: VMS-TCP/IP

In article <1993May13.182036.14889@picker.com>,
visconti@picker.com (Leonard A. Visconti, +1 216/473-4801) writes:
>
> Does anyone know of any public domain software that would provide FTP
> capablility for a vax? Thanks you.

Presumably you mean a VAX running VMS? (or OpenVMS, in fashionable terms)

And also presumably you are in need not just of an implementation of
the File-Transfer Protocol (FTP) but of the entire TCP/IP protocol
suite to run on this VAX?

If so, the microbudget way to set up TCP/IP on your VAX is to obtain
the package which is now called "CMU-OpenVMS-IP".  (The software once
had a connection to Tektronix, but the current name remembers only the
Carnegie-Mellon heritage.)

Information on the most economical commercial TCP/IP stack for VMS may
be obtained by e-mailing a query about "TCPware" to "sales@process.com".
The other major vendors are TGV, with Multinet, and Wollongong, with
WIN/TCP.  Network Research is said to sell Fusion TCP for VMS.  DEC
sells an implementation called "UCX" or "TCP/IP Services for OpenVMS",
but only halfheartedly, since DEC's corporate sympathy is with OSI.

Most net discussion of CMU-OpenVMS-IP takes place in the newsgroup
"vmsnet.networks.tcp-ip.cmu-tek". (If you can't access this group,
you can join the mailing list by e-mailing a request to
"CMU-OpenVMS-IP-Request@DRYCAS.CLUB.CC.CMU.EDU".)

Here is some recent instruction from Henry Miller, the current heroic
wielder of the BLISS compiler for the CMU-OpenVMS-IP community.

| To get the new version, use ANONYMOUS FTP to either SACUSR or
| SACWMS.MP.USBR.GOV.  In directory [.TEKIP] are the files TEKIP0665A.SAVE and
| TEKIP0665A.SAVE_Z.  The latter is an LZCOMP'ed version of the former.  This
| is not at installation kit, but just a BACKUP saveset and the structure of
| the saveset should make it obvious where the files go under CMUTEK_SYSROOT:.
|
| Due to the new IP driver and PTY drivers, you will have to reboot the system.
| The IPACP and drivers are co-dependent on each other, so you have to load
| them all up and reboot.  Before you reboot, modify your INTERNET.CONFIG
| file to use the 'ETHER' driver instead of 'XEDRV'.  There are still some
| problems with the external driver, but the internal driver works OK.
|
| ----------
| Henry W. Miller
| Assistant Systems and Network Manager
| U.S. Bureau of Reclamation
| Mid Pacific Region
| 2800 Cottage Way MP1100
| Sacramento, CA 95825
| (916) 978-5108
| Internet: "henrym@sacwms.mp.usbr.gov"
| BITNET:    hmiller@scu"                "I've fallen, and I can't get up!"
--
...Richard S. Shuford  | "A prudent man sees danger and takes refuge,
...shuford@cs.utk.edu  |  but the simple keep going and suffer for it."
...Info-Stratus contact|  Proverbs 22:3 NIV


-----------[000217][next][prev][last][first]----------------------------------------------------
Date:      16 May 93 18:27:35 GMT
From:      jonc@status.gen.nz (Jon Clarke)
To:        comp.protocols.tcp-ip
Subject:   ESIX tcp-ip

Hello netters,

Is there any sites out there that use tcp-ip with ESIX Sys V at all?
If so can you please drop me an email.

I want information on sub-addressing ESIX so it can find a PCR.

regards

_         Jon Clarke (jonc@status.gen.nz)       * Public Access Unix *
( )o       The home of Z*NET on the World Nets (Z*NET Free ASCII Zines)
/\  \      HEXAGON: HSBC NZ EBD  GEM: Jon Clarke   PH : (+649) 358-5589


-----------[000218][next][prev][last][first]----------------------------------------------------
Date:      Mon, 17 May 1993 03:32:27 GMT
From:      mdella@dts.harris.com (Marcos Della)
To:        comp.protocols.tcp-ip
Subject:   Info on VistaPoint Wireless

Has anyone had any experiance with the Motorola VISTAPoint wireless
microwave LAN transmitter?  I'm looking at buying one, but would like
to know if anyone has had any experiance with them...

Marcos

--
_______________________________________________________________________________
Marcos R. Della                             | Did you ever wonder if there was
Harris Digital Telephone Systems            | more to the universe than this?
mdella@dts.harris.com                       |


-----------[000219][next][prev][last][first]----------------------------------------------------
Date:      Mon, 17 May 1993 05:40:15 GMT
From:      swslr@well.sf.ca.us (Larry Krone)
To:        comp.protocols.tcp-ip
Subject:   AIX TCP

To those who sent me replies about my SCO problem, thanx...Here we go again:

One of our sites is running a network of 2 AIX boxes on site (550 & 580) and
a 530 remotely over a 56KB line...We just upgraded the operating system
tonite and started to have a weird problem; we can rlogin and telnet to the
remote 530 okay for a while; then it just locks up on us...we cannot
rlogin,telnet or FTP to the 530, but ping returns okay.  ALso, if we
reboot the 550 & 580 all becomes well again for a while...

Thoughts???

swslr@well.sf.ca.us


-----------[000220][next][prev][last][first]----------------------------------------------------
Date:      17 May 93 11:14:43
From:      art@now.midnight.com (Art Mellor)
To:        comp.protocols.tcp-ip
Subject:   Beta testers needed for IP net discovery tool


We have a simple net management tool for doing IP node discovery. We would
like to find some people to help us Beta test it. If you are interested,
please send mail to support@midnight.com and we'll send you details.

Requirements:
------------

o Sparc running SunOS 4.x.x

o Network Interface Tap (NIT) installed

o An UP and RUNNING IP interface with a Class B (or smaller) net mask

o Working hostname resolution (NIS, DNS, and/or host file)

o ~ 2.0M of disk space

o X11R4 or R5 (OpenWindows 3 or 4 should be OK)

--

...............................................................................
Art Mellor       : Midnight Networks Inc. 100 Fifth Avenue Waltham MA 02154
art@midnight.com : Phone 617/890-1001 Fax 890-0028  *The Best in Network SW


-----------[000221][next][prev][last][first]----------------------------------------------------
Date:      Mon, 17 May 1993 07:18:02 GMT
From:      cproto@cs.curtin.edu.au (Computer Protocol)
To:        comp.protocols.tcp-ip
Subject:   Public domain OSPF ?

Is there a public domain version of OSPF ?

Regards - Tibor Sashegyi (cproto@cs.curtin.edu.au)


-----------[000222][next][prev][last][first]----------------------------------------------------
Date:      Mon, 17 May 1993 08:59:37 GMT
From:      websterc@decuk.uvo.dec.com (Colin Webster)
To:        comp.dcom.lans.ethernet,comp.protocols.tcp-ip
Subject:   Re: DECbridge90 filtering strategy ?


In article <1993May14.215915.2460@klaava.Helsinki.FI>, vhalkka@klaava.Helsinki.FI (Vesa Halkka) writes:
|>Xref: uvo.dec.com comp.dcom.lans.ethernet:4419 comp.protocols.tcp-ip:25876
|>Newsgroups: comp.dcom.lans.ethernet,comp.protocols.tcp-ip
|>Path: uvo.dec.com!news.crl.dec.com!pa.dec.com!decwrl!elroy.jpl.nasa.gov!usc!cs.utexas.edu!utnut!torn!nott!bnrgate!bnr.co.uk!uknet!pipex!sunic!news.funet.fi!hydra!klaava!vhalkka
|>From: vhalkka@klaava.Helsinki.FI (Vesa Halkka)
|>Subject: Re: DECbridge90 filtering strategy ?
|>Message-ID: <1993May14.215915.2460@klaava.Helsinki.FI>
|>Organization: University of Helsinki
|>References: <1993May7.112947.9474@serra.unipi.it>
|>Date: Fri, 14 May 93 22:59:15 GMT-1:00
|>Lines: 18
|>
|>In <1993May7.112947.9474@serra.unipi.it> luigi@pical2.iet.unipi.it (Luigi Rizzo) writes:
|>
|>>Of course I may be totally wrong, but after 10 days of tracing
|>>ethernet packets I'm pretty confident there's something non obvious
|>>with the learning strategy of the DECbridge90 (mainly because
|>>once it has been replaced with a PCBRIDGE, all the strange things
|>>have disappeared!).
|>
|>It is a toy bridge: it has a very limited forwarding table,
|>and *it is bridging only to one direction.* Every packet
|>coming from the other direction goes through the bridge.
|>
The DECbridge 90 is a so called "workgroup" bridge. As such, it only
has one address table with a maximum of 200 nodes and this is for the nodes
on the "workgroup" side. If a node is not in this table, then it is assumed
to be on the "backbone" side.
If the 200 node table is exceeded, then the 201st node cannot talk to
the backbone (the only situation where you bridge in one direction is
where the 200 node limit is exceded with a  DB90FL, the bridge goes into
to flood mode and allows all traffic to the backbone untill the "workgroup"
node count is 200 or less).
The forwarding and filter rate is pretty much the same as a DEC lanbridge 200.
You can draw your own conclusions as to whether the "workgroup" concept
for a hub based bridge makes it a toy or not.

/Colin


-----------[000223][next][prev][last][first]----------------------------------------------------
Date:      Mon, 17 May 1993 11:16:26 GMT
From:      evansmp@uhura.aston.ac.uk (Mark Evans)
To:        comp.protocols.tcp-ip
Subject:   Re: Specs on rlogin? now where are dey?

Vernon Schryver (vjs@rhyolite.wpd.sgi.com) wrote:
: In article <1svsdhINN1hq@flash.pax.tpa.com.au>, hart@flash.pax.tpa.com.au (Leigh M Hart) writes:
: > Now, either I didn't look hard enough or I'm blind, but for the life of
: > me I can't find the specifications for the rlogin protocol.  The RFC's
: > don't seem to cover it (unless I missed it) - any ideas?
:
:
: Like RIP, the authoritative reference is not an RFC, but the source.

Odd I have a printout of an RFC claiming to be the BSD rlogin
protocol....

--
-------------------------------------------------------------------------
Mark Evans                                   |evansmp@uhura.aston.ac.uk
+(44) 21 429 9199  (Home)                    |evansmp@cs.aston.ac.uk
+(44) 21 359 6531 x4039 (Office)             |


-----------[000224][next][prev][last][first]----------------------------------------------------
Date:      Mon, 17 May 1993 13:30:11 GMT
From:      edge@unislc.slc.unisys.com (Brian Edginton)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP calculation

cmaeda+@cs.cmu.edu (Christopher Maeda) writes:

>In article <C706F0.31M@noose.ecn.purdue.edu> schlege@lips2.ecn.purdue.edu (Kevin L Schlegelmilch) writes:
>>Question:
>>  If a sender of TCP has a window size limit of 4096 bytes and the
>>receiver has a limit of 8196 bytes, the two are connected via a
>>1544000bps (t-1) link, for what distances are the window sizes a
>>bottleneck, and for what distances is the link a bottleneck?
>>(Express the distance in microseconds.)  If the speed of light
>>is 3 times 10 to the 8th meters/second, how long is the cable at
>>the threshold?

>What is the airspeed velocity of an unladen swallow?

African or European?

>--
>Chris Maeda, Grad Student and RetroGrouch <cmaeda@cs.cmu.edu>
>"A unix signature isn't a return address, it's the ASCII equivalent of
>a black velvet clown painting. It's a rectangle of carets surrounding
>a quote from a literary giant of weeniedom like Heinlein or Dr. Who."
--
Brian Edginton                   | edge@unislc.slc.unisys.com
Unisys - Performance Engineering | unislc!edge@cs.utah.edu
320 North 2200 West  D1V01       | {hpda, sun, uplherc}!unislc!edge
Salt Lake City, Utah 84116       | (801) 594-6009 Human (usually)


-----------[000225][next][prev][last][first]----------------------------------------------------
Date:      Mon, 17 May 1993 13:58:11 GMT
From:      vjs@rhyolite.wpd.sgi.com (Vernon Schryver)
To:        comp.protocols.tcp-ip
Subject:   Re: Specs on rlogin? now where are dey?

In article <1993May17.111626.24534@aston.ac.uk>, evansmp@uhura.aston.ac.uk (Mark Evans) writes:
> Vernon Schryver (vjs@rhyolite.wpd.sgi.com) wrote:
> : In article <1svsdhINN1hq@flash.pax.tpa.com.au>, hart@flash.pax.tpa.com.au (Leigh M Hart) writes:
> : > Now, either I didn't look hard enough or I'm blind, but for the life of
> : > me I can't find the specifications for the rlogin protocol.  The RFC's
> : > don't seem to cover it (unless I missed it) - any ideas?
> :
> : Like RIP, the authoritative reference is not an RFC, but the source.
>
> Odd I have a printout of an RFC claiming to be the BSD rlogin
> protocol....

The rlogin and RIP RFC's were written a decade or more after the code
that implemented and defined the protocols, and not by the authors of
the implementations that defined the protocols.

A quick reading of the RIP RFC finds at least one modest error in how
RIP has worked for many years, and some more significant errors in how
the 4.3BSD code works.  (Sorry, it's been a year or two since I read
the RIP RFC after a bout hacking on the code and I've forgotten details.)

Consider the differences between RFC 1282 and RFC 1258.  You can check
old versions of the source to discover that the protocol did not change.

Did the MIL spec's re-define (and so break) TCP, despite carrying more
de jure weight than the RFCs?

A standard can be good for describing and documenting reality, but a
standard does not redefine reality.  Only reality defines reality.
Like any documentation, a standard is only as good as it is complete
and free of errors.  Like every work of man, every standard has errors
and almost all standards are incomplete.

It's a sympthom of a disease common among Standards Committee Goers to
believe that nothing exists except as written in a Genuine Standard
(tm) by an Accredited Committee (tm).

The RIP RFC and the second rlogin RFC should be viewed as very good
textbooks on their subjects.  Like any textbook about practical
matters, whether about mining, airplanes or computers, they do not
define their subjects.  Who would pick an airplane driven by someone

Of course the RIP-2 RFC is definitive about its protocol, because it
defined the protocol before (or perhaps during, I don't know) the
implementations.

Vernon Schryver,  vjs@sgi.com


-----------[000226][next][prev][last][first]----------------------------------------------------
Date:      Mon, 17 May 1993 14:10:43 GMT
From:      larryp@sco.COM (Larry Philps)
To:        comp.protocols.tcp-ip
Subject:   Re: SCO subnetting problem

In <5@mhinfo.UUCP> carrato@mhinfo.UUCP (Tony Carrato) writes:

> In article <3@mhinfo.UUCP> I wrote:
> >Here's the problem:
> >
> >	Segment 1				Segment 2
> >  ================================   ==========================
> >  "       "          "           "   "           "            "
> > SCO    RS6000     PC 1 w/        Netware     PC 2 w/      PC  3 w/
> >                   LAN WG         w/ Novell   LAN WG       LAN WG
> >		   for DOS        TCP/IP      for DOS      for DOS
> >
> >In this configuration, PC 1 can ping/telnet to the SCO box.  If you
> >move it to segment 2, it can't.  However, on either segment, PC 1
> >(and the other PC's) can easily ping/telnet to the RS6000.
>
> It turns out the problem was the subnetwork addressing on the SCO box.
> as soon as we went to a subnet mask of 255.255.255.0 things started working
> fine.  It could well be that on the SCO TCP/IP implementation that
> partial byte subnetting simply doesn't work.  (The RS6000 worked just
> fine in either configuration.)

I really have no idea what is/was causing your problem, but partial
byte subnetting works fine under SCO (at least with TCP/IP 1.2.0 and
1.2.1.  I have a working subnet (for testing) that uses a netwask of
255.255.225.224 off a Class C address.  There are 5 configured subnets
under this.  The test net is gatewayed to the rest of SCO's corporate
net via an ODT 2.0 machine acting as a 4 way router.  The results of
ifconfig'ing the interfaces on this machine are shown below.  (I have
changed the actual class C network numbers for reasons that can only be
attributed to paranoia to ClassC.Net.1, ClassC.Net.2, and ClassC.Net.3)

Script started on Mon May 17 10:03:16 1993
$ifconig wdn0 wdn0: flags=23<UP,BROADCAST,NOTRAILERS> inet ClassC.Net.1.124 netmask ffffff00 broadcast ClassC.Net.1.255$ ifconfig wdn1
$ifconfig wdn2 wdn2: flags=23<UP,BROADCAST,NOTRAILERS> inet ClassC.Net.2.1 netmask ffffffc0 broadcast ClassC.Net.2.63$ ifconfig wdn3
$script done on Mon May 17 10:04:33 1993 The only time I have seen such a configuration fail to work, is when all the systems involved are not configured with the same broadcast addresses. ie. they all must use all 1's for the broadcast part, and those addresses must match the host part of the address _after_ the netmask is applied. See the above for examples - the .31, .63, and .127 are important. --- #include <std/disclaimer> Larry Philps, SCO Canada, Inc. Postman: 130 Bloor St. West, 10th floor, Toronto, Ontario. M5S 1N5 InterNet: larryp@sco.COM UUCP: uunet!sco!larryp Phone: (416) 922-1937  -----------[000227][next][prev][last][first]---------------------------------------------------- Date: 17 May 93 17:47:13 GMT From: ajm@wilson.fibercom.com (AJ Madison) To: comp.protocols.tcp-ip,comp.protocols.ppp Subject: Re: Fast modems and dialup SLIP/PPP  In article <BOB.93May13153250@volitans.MorningStar.Com>, bob@MorningStar.Com (Bob Sutterfield) writes: > > Many of the questions in comp.protocols.ppp are from people using code > that is largely unchanged from Drew Perkins' original proof-of-concept > implementation, written four years ago while RFC 1134 was being ironed > out by Drew and the other programmers/protocol designers (notably Russ > Hobby), who were also working on their own independent > proof-of-concept implementations. > > I haven't looked at dp-2.3, but I suspect the guts of its PPP protocol > engine haven't changed much since it was called "patchlevel 5", by > which time its guts hadn't changed much since Drew's original 4.2BSD > code. Yes, more recent maintainers have done a lot of porting work > and bug fixes, and they've apparently added modern VJ negotiations, > but the guts are showing their age. The IETF PPP Working Group > (defines the protocol) and the PPP Consortium (industry group that > conducts formal interoperability tests) have learned a *lot* since RFC > 1134 was published, and RFC 1331 shows it. Every finite-state-machine > change, no matter how subtle, reflects that increase in the collective > wisdom. > Bob had gotten me to think that dp-2.3 may not be as up to date as I thought. I dug in and gave the source and the RFCs a good once over. Here is the list of (non-)compliances that I came up with. I make no claim that this list is exhaustive (nor a comment on the quality of the maintainers). I say dp-2.3, but I'm really talking about the CMU PPP "core." RFC1331 Compliance: (As Bob points out above) VJ Negotiation terminology has been upgraded in dp-2.3. Best I can tell, the functionality remains the same, but the names have been changed. RFC1332 Compliance: dp-2.3 has made the IPCP Ip-Addresses option backwardly compatible and now includes the Ip-Address option. The former was deprecated in RFC1332 and the latter an addition. RFC1331 NON Compliance: dp-2.3 includes passive and active Open States in the FSM. Fortunately, they're implemented as sub-states, and consolidation to RFC 1331's Open state is almost trivial, albeit tedious. (Bob Sutterfield pointed out this problem some months ago). dp-2.3's LCP does not successfully negotiate the usage of the Authentication protocols. This is actually an implementation defect rather that lack of compliance. I may have suggested earlier there are flaws in the RFCs when I really was trying to vent my frustration with the share-ware implementations. The RFCs are fine. dp-2.3's LCP includes and expects a callback field in the Authenticate Option when requesting CHAP. This field is not present in RFC1331/RFC1334. Anyone desiring to "tolerate" older versions of PPP should be prepared to ignore this field. LCP code has been set-up to allow for options to be longer than they should be, which is a plus, so defect removal should be easy. dp-2.3's PPP does not protocol reject unrecognized protocols/channel id's (for example LQM). If it did this, the remote node (eg. MST PPP) could adjust, adapt, and overcome (to paraphrase Clint Eastwood). (Again a nod to Bob). RFC1334 NON Compliance: dp-2.3's CHAP expects a value-length field in incoming Success and Failure Packets. This field is not in evidence in RFC1334. Interestingly enough, dp-2.3 does not format these packets with these fields, which makes this feature not only non-compliant, but a defect as well. dp-2.3's CHAP through no fault of its own, can be configured to be unable to reach the Opened state upon reception of a good Response Packet. Not really a non-compliance issue; included for completeness. dp-2.3 PPP makes no attempt to "prefer" CHAP over UPAP as has been strongly recommended in RFC1334. Further, dp-2.3 can be configured to use both protocols simultaneously, which is also strongly discouraged in the RFC. -- A.J. Madison PHONE: (703) 342-6700 X383 FiberCom, Inc. FAX: (703) 342-5961 P.O. Box 11966 INTERNET: ajm@fibercom.com Roanoke, VA 24022-1966 UUCP: ...!uunet!fibercom!ajm  -----------[000228][next][prev][last][first]---------------------------------------------------- Date: Mon, 17 May 1993 17:57:55 GMT From: wmasson@cbnewsj.cb.att.com (bill.masson) To: comp.protocols.tcp-ip Subject: shared sockets  The book "Internetworking with TCP/IP Volume III" by Douglas Comer & David Stevens describes a concept of shared sockets, whereby a master server creates a socket and then spawns several slave process's which each inherit this socket and hang an accept off of it waiting for connections. They go on to say that the UNIX implementation provides mutual exclusion for multiple processs that all atempt to accept connections from the same socket. My question is, does this hold true for multiprocessor systems. Are semafors needed to guarantee the mutal exclusion? Does this paradigm make sense in a multiprocessor environment?  -----------[000229][next][prev][last][first]---------------------------------------------------- Date: Mon, 17 May 1993 18:09:42 GMT From: wmasson@cbnewsj.cb.att.com (bill.masson) To: comp.protocols.tcp-ip Subject: max tcp connections  What is the maximum number of concurrent TCP connections on a Sparc 10 running Solaris 2.x and is there a kernel tunable that must be set to realize this max? Ive found documentation for AT&T's SVR4/386 stating that the kernel variable NDEV_TCP can be set to a minimum of 10 and a max of 1024, but can not find anything in the Solaris Documentation. Also what kind of memory do I need to support the maximum configuration? Thanks.  -----------[000230][next][prev][last][first]---------------------------------------------------- Date: Mon, 17 May 1993 19:23:00 GMT From: tim@spctrm.UUCP (Tim Fry) To: comp.protocols.tcp-ip,comp.unix.misc,comp.unix.programmer Subject: TLI/TCP data transfer question  Does anyone know how to determine if a *non-blocking* TCP based TLI connection between two processes is able to handle a known number of bytes *before* a t_snd() call is issued? Unfortunately the t_snd() call does not return the number of bytes written if the send was flow-controlled - it simply fails and returns -1, setting t_errno to TFLOW. I assumed(wrongly) that if I tried to send 5000 bytes from A to B and B was in some wait state, then the above TLI generated flow-control condition implied that the t_snd() did not send *any* of the 5000 bytes. It seems however, that partial data is sent even though the call fails. This tends to screw-up my protocol somewhat as I am left with fragmented messages queued up for the receiving process. This is on Interactive 3.2 2 and sending between two processes on the same machine. Thanks Tim  -----------[000231][next][prev][last][first]---------------------------------------------------- Date: Tue, 18 May 1993 00:03:06 GMT From: royc@rbdc.wsnc.org (Roy Crabtree) To: comp.unix.questions,comp.protocols.tcpip Subject: WANTED: SVR4/SVR3 RFS on TCP/IP (NCR to ESIX)  ESIX 5.3.2D (Everex UNIX) to/from AT&T/NCR 4.0 3.0: What are the appropriate addreses to get RFS running? ESIX uses rss.serve/rss in its rfmaster files NCR uses \x00020aceTCPIPHEX for its. I can get remsh, rcp, and telnet to function, BUT rlogin fails ('rcmd failed') and RFS does not see each other. Do I need to reenable the listener at \00020401 on 4.0 side? Email me solutions and I will post the result. Thanx! roy andrew crabtree  -----------[000232][next][prev][last][first]---------------------------------------------------- Date: 18 May 1993 14:29:41 -0400 From: bb31351@bingsunb.cc.binghamton.edu (Rakesh Shetty) To: comp.protocols.tcp-ip Subject: PING source code !!!!!!!!  Hello, I am looking for the source code of ping (packet internet groper - BSD). Any info on where I could ftp it from would be a great help. Thanx, Rakesh  -----------[000233][next][prev][last][first]---------------------------------------------------- Date: 18 May 93 12:01:03 GMT From: J.Crowcroft@cs.ucl.ac.uk (Jon Crowcroft) To: comp.protocols.tcp-ip Subject: Re: TCP calculation  >>receiver has a limit of 8196 bytes, the two are connected via a >>1544000bps (t-1) link, for what distances are the window sizes a >>bottleneck, and for what distances is the link a bottleneck? below threshold, link speed throttles, above it, window does. >>(Express the distance in microseconds.) If the speed of light >>is 3 times 10 to the 8th meters/second, how long is the cable at >>the threshold? Threshold bps = limiting-W/threshold-rtt = 1544000 for T1 Assumptions 1. ignoring processing: 2. assume T1 is copper/coax therefore 2/3 c signal propogation speed) rtt = cablelength/2*10**8 (dimensionally trivial - i.e. threshold-rtt = limiting-W/1544000 = cablelength/2*10**8 i.e. for rx window 8k bytes, you have trtt=414 msecs or 1 way 200 msecs approx cablelength is around (200 * 10**-3 * 2 * 10**8) meters, or 40000 kilometers (like near geostationary satellite) i could be out by a factor of x, where x is left as an e?ercise for the reader... >What is the airspeed velocity of an unladen swallow? 720 cleese's per nano-palin but what's your name? jon  -----------[000234][next][prev][last][first]---------------------------------------------------- Date: 18 May 93 15:18:36 GMT From: rturner@imagen.com (Randy Turner) To: comp.protocols.tcp-ip Subject: PD TCP/IP (~NCSA)  Is there a public domain TCP/IP package that is relatively stable that was designed for a multitasking OS. I have looked at the NCSA code and found it to be too monolithic, since I plan on running the system in a multitasking environment. I have heard about the CMU package. Is it geared towards a multi-task model? Or is there some other TCP/IP stack implementation out there that is? Thanx in advance! Randy -- ----------------------------------------------------------------------------- Randy Turner QMS, Inc. rturner@aqm.com  -----------[000235][next][prev][last][first]---------------------------------------------------- Date: Tue, 18 May 1993 16:47:18 GMT From: Benoit Grange <Benoit_Grange@gateway.qm.apple.com> To: comp.unix.wizards,comp.protocols.tcp-ip Subject: HELP: Need to implement rarp on SysV.4  How can I implement a rarp daemon that would answer to rarp queries ? Where can I read rarp paquets arriving to my machine ? And send responses ? My system is a Consensys (or Unixware) SysV.4. ---- Benoit Grange  -----------[000236][next][prev][last][first]---------------------------------------------------- Date: 18 May 93 17:03:45 GMT From: garry@ceco.ceco.com (Garry J. Garrett) To: comp.protocols.tcp-ip Subject: Help me fix my EBCDIC-ASCII translate table for FTP  I have found that when I ftp something from our mainframe to my sun and then ftp it back to the mainframe, I don't get the same file (dataset) back on the mainframe. What I have found is that our translate for EBCDIC & ASCII tables don't have a 1:1 mapping. Originally the ASCII-to-EBCDIC table was ignoring the parity bit but the EBCDIC-to-ASCII table was translating some of it's characters into 8 bit IBM PC ascii. I have fixed most of the table by altering the ASCII-to-EBCDIC chart so that if EBCDIC character Y is translated into ASCII character Y, then character Y on the ASCII-to-EBCDIC chart translates Y back into X. Now I am down to a handful of EBCDIC control characters that have no equivalent in ASCII. Presently, they all map to 1A in ASCII. Only 3F EBCDIC should map to 1A ASCII. Also EBCIDIC 15, 1C, and 1E all map to ASCII characters that don't map back into that same character in the ASCII-to-EBCDIC chart. My background is in Suns & PCs. I am not familiar enough with these control characters to make a maping that makes sense. (I am down to eenie-meenie-minie-moe.) All I want is a 1:1 maping so that if I send a file back & forth nothing gets lost in the translation. I would like to have a little more confidence in my conversion charts than I do with the eenie-meenie-minie-moe method. What would I like from you? Do you have a chart that you are willing to share with me (that has a 1:1 corresponance, i.e. each character on the chart maps to one and only one character on the other chart, and that character maps back to the one you started with.)? Or do you have any suggestions as to how I should modify my chart to get a 1:1 maping? I would perfer e-mail as I don't frequent this newsgroup. Garry Garrett garry@ceco.ceco.com My chart after I fixed the 8 bit ascii thing: ---------------------------------------------- ; ; ASCII-to-EBCDIC table ; x0 x1 x2 x3 x4 x5 x6 x7 x8 x9 xA xB xC xD xE xF ; 00 01 02 03 37 2D 2E 2F 16 05 25 0B 0C 0D 0E 0F ; 0x ; 10 11 12 13 3C 3D 32 26 18 19 3F 27 22 1D 35 1F ; 1x ; 40 5A 7F 7B 5B 6C 50 7D 4D 5D 5C 4E 6B 60 4B 61 ; 2x ; F0 F1 F2 F3 F4 F5 F6 F7 F8 F9 7A 5E 4C 7E 6E 6F ; 3x ; 7C C1 C2 C3 C4 C5 C6 C7 C8 C9 D1 D2 D3 D4 D5 D6 ; 4x ; D7 D8 D9 E2 E3 E4 E5 E6 E7 E8 E9 AD E0 BD 5F 6D ; 5x ; 79 81 82 83 84 85 86 87 88 89 91 92 93 94 95 96 ; 6x ; 97 98 99 A2 A3 A4 A5 A6 A7 A8 A9 C0 4F D0 A1 07 ; 7x ; 43 01 02 03 37 EB 2E 9B 71 05 25 49 90 BA EC DF ; 8x ; 45 11 12 9D 72 3D 8A 9A 67 56 64 4A 53 68 59 46 ; 9x ; EA DA 7F DE 8B 55 41 FE 58 51 52 48 69 DB 8E 8D ; Ax ; 73 74 75 FA F4 B0 B1 B3 B4 B5 6A B7 B8 B9 CC BC ; Bx ; AB C1 C2 C3 BF 8F C6 C7 A0 C9 CB CA D3 D4 9C D6 ; Cx ; D7 EF D9 E2 E3 E4 77 70 BE BB AC 54 63 65 66 62 ; Dx ; 79 42 47 57 EE 85 B6 E1 CD ED 91 44 CE CF 95 AA ; Ex ; FC 9E AE 8C DD DC A5 FB 80 AF FD 78 76 B2 9F FF ; Fx ; ; ; EBCDIC-to-ASCII table ; x0 x1 x2 x3 x4 x5 x6 x7 x8 x9 xA xB xC xD xE xF ; 00 01 02 03 1A 09 1A 7F 1A 1A 1A 0B 0C 0D 0E 0F ; 0x ; 10 11 12 13 1A 0A 08 1A 18 19 1A 1A 1C 1D 1E 1F ; 1x ; 1A 1A 1C 1A 1A 0A 17 1B 1A 1A 1A 1A 1A 05 06 07 ; 2x ; 1A 1A 16 1A 1A 1E 1A 04 1A 1A 1A 1A 14 15 1A 1A ; 3x ; 20 A6 E1 80 EB 90 9F E2 AB 8B 9B 2E 3C 28 2B 7C ; 4x ; 26 A9 AA 9C DB A5 99 E3 A8 9E 21 24 2A 29 3B 5E ; 5x ; 2D 2F DF DC 9A DD DE 98 9D AC BA 2C 25 5F 3E 3F ; 6x ; D7 88 94 B0 B1 B2 FC D6 FB 60 3A 23 40 27 3D 22 ; 7x ; F8 61 62 63 64 65 66 67 68 69 96 A4 F3 AF AE C5 ; 8x ; 8C 6A 6B 6C 6D 6E 6F 70 71 72 97 87 CE 93 F1 FE ; 9x ; C8 7E 73 74 75 76 77 78 79 7A EF C0 DA 5B F2 F9 ; Ax ; B5 B6 FD B7 B8 B9 E6 BB BC BD 8D D9 BF 5D D8 C4 ; Bx ; 7B 41 42 43 44 45 46 47 48 49 CB CA BE E8 EC ED ; Cx ; 7D 4A 4B 4C 4D 4E 4F 50 51 52 A1 AD F5 F4 A3 8F ; Dx ; 5C E7 53 54 55 56 57 58 59 5A A0 85 8E E9 E4 D1 ; Ex ; 30 31 32 33 34 35 36 37 38 39 B3 F7 F0 FA A7 FF ; Fx ; My chart before I fixed the 8 bit ASCII thing: (note how the 2nd 1/2 of the ascii chart looks amazingly like the first 1/2) ----------------------------------------------- ; ; ASCII-to-EBCDIC table ; x0 x1 x2 x3 x4 x5 x6 x7 x8 x9 xA xB xC xD xE xF ; 00 01 02 03 37 2D 2E 2F 16 05 25 0B 0C 0D 0E 0F ; 0x ; 10 11 12 13 3C 3D 32 26 18 19 3F 27 22 1D 35 1F ; 1x ; 40 5A 7F 7B 5B 6C 50 7D 4D 5D 5C 4E 6B 60 4B 61 ; 2x ; F0 F1 F2 F3 F4 F5 F6 F7 F8 F9 7A 5E 4C 7E 6E 6F ; 3x ; 7C C1 C2 C3 C4 C5 C6 C7 C8 C9 D1 D2 D3 D4 D5 D6 ; 4x ; D7 D8 D9 E2 E3 E4 E5 E6 E7 E8 E9 AD E0 BD 5F 6D ; 5x ; 79 81 82 83 84 85 86 87 88 89 91 92 93 94 95 96 ; 6x ; 97 98 99 A2 A3 A4 A5 A6 A7 A8 A9 C0 4F D0 A1 07 ; 7x ; 00 01 02 03 37 2D 2E 2F 16 05 25 0B 0C 0D 0E 0F ; 8x ; 10 11 12 13 3C 3D 32 26 18 19 3F 27 22 1D 35 1F ; 9x ; 40 5A 7F 7B 5B 6C 50 7D 4D 5D 5C 4E 6B 60 4B 61 ; Ax ; F0 F1 F2 F3 F4 F5 F6 F7 F8 F9 7A 5E 4C 7E 6E 6F ; Bx ; 7C C1 C2 C3 C4 C5 C6 C7 C8 C9 D1 D2 D3 D4 D5 D6 ; Cx ; D7 D8 D9 E2 E3 E4 E5 E6 E7 E8 E9 AD E0 BD 5F 6D ; Dx ; 79 81 82 83 84 85 86 87 88 89 91 92 93 94 95 96 ; Ex ; 97 98 99 A2 A3 A4 A5 A6 A7 A8 A9 C0 4F D0 A1 07 ; Fx ; ; ; EBCDIC-to-ASCII table ; x0 x1 x2 x3 x4 x5 x6 x7 x8 x9 xA xB xC xD xE xF ; 00 01 02 03 1A 09 1A 7F 1A 1A 1A 0B 0C 0D 0E 0F ; 0x ; 10 11 12 13 1A 0A 08 1A 18 19 1A 1A 1C 1D 1E 1F ; 1x ; 1A 1A 1C 1A 1A 0A 17 1B 1A 1A 1A 1A 1A 05 06 07 ; 2x ; 1A 1A 16 1A 1A 1E 1A 04 1A 1A 1A 1A 14 15 1A 1A ; 3x ; 20 A6 E1 80 EB 90 9F E2 AB 8B 9B 2E 3C 28 2B 7C ; 4x ; 26 A9 AA 9C DB A5 99 E3 A8 9E 21 24 2A 29 3B 5E ; 5x ; 2D 2F DF DC 9A DD DE 98 9D AC BA 2C 25 5F 3E 3F ; 6x ; D7 88 94 B0 B1 B2 FC D6 FB 60 3A 23 40 27 3D 22 ; 7x ; F8 61 62 63 64 65 66 67 68 69 96 A4 F3 AF AE C5 ; 8x ; 8C 6A 6B 6C 6D 6E 6F 70 71 72 97 87 CE 93 F1 FE ; 9x ; C8 7E 73 74 75 76 77 78 79 7A EF C0 DA 5B F2 F9 ; Ax ; B5 B6 FD B7 B8 B9 E6 BB BC BD 8D D9 BF 5D D8 C4 ; Bx ; 7B 41 42 43 44 45 46 47 48 49 CB CA BE E8 EC ED ; Cx ; 7D 4A 4B 4C 4D 4E 4F 50 51 52 A1 AD F5 F4 A3 8F ; Dx ; 5C E7 53 54 55 56 57 58 59 5A A0 85 8E E9 E4 D1 ; Ex ; 30 31 32 33 34 35 36 37 38 39 B3 F7 F0 FA A7 FF ; Fx ; -- # Garry Garrett, P&EIS # (Me? Speak for CECo? I get into enough # Commonwealth Edison Co. # trouble speaking for myself!) # P.O. Box 767, 1600 Edison # UUCP: ...!uunet!ceco.ceco.com!garry # Chicago, IL 60690-0767 # Internet: garry@ceco.ceco.com  -----------[000237][next][prev][last][first]---------------------------------------------------- Date: 18 May 93 18:07:13 GMT From: lars@spectrum.CMC.COM (Lars Poulsen) To: comp.protocols.tcp-ip Subject: Re: RFC's Etc (was Rlogin specs, now where are dey?)  In article <1tb2roINNgkk@flash.pax.tpa.com.au> hart@flash.pax.tpa.com.au (Leigh M Hart) writes: >Some peole have posted saying the RFCs aren't necessarily a good guideline >for implementing [rlogin etc], if they aren't then what is? should we >have to read original code to implement the protocol in our own applications? > ... >Now I simply ask - is the RFC for the rlogin protocol (RFC1282) correct? or >am I wasting my time implementing the protocol based on the RFC? does the >same go for the telnet protocol specification and telnet option specification >RFCs? The Internet perspective is that there is no point in implementing a protocol if it does not work. Arguing about whether the paper specification is more correct than the many currently running implementations is pointless. This applies in particular, when - as in the case of rlogin - the protocol was not developed through the standards process, but was a useful non-standard hack implemented by someone and then widely distributed. RFC1282 reflects a reverse-engineering effort and it is very nearly correct. TELNET, on the other hand, is a standard protocol, and the specification is authoritative. -- / Lars Poulsen, SMTS Software Engineer Internet E-mail: lars@CMC.COM CMC Network Products / Rockwell Int'l Telephone: +1-805-968-4262 Santa Barbara, CA 93117-3083 TeleFAX: +1-805-968-8256  -----------[000238][next][prev][last][first]---------------------------------------------------- Date: Tue, 18 May 1993 18:51:28 GMT From: imp@boulder.parcplace.com (Warner Losh) To: comp.protocols.tcp-ip Subject: Re: RFC's Etc (was Rlogin specs, now where are dey?)  In article <1tb2roINNgkk@flash.pax.tpa.com.au> hart@flash.pax.tpa.com.au (Leigh M Hart) writes: >Some peole have posted saying the RFCs aren't necessarily a good guideline >for implementing these protocols, if they aren't then what is? should we >have to read original code to implement the protocol in our own applications? rlogin is a fairly new RFC, so it is bound to have some problems. FTP and SMTP RFC's aren't quite right either. They have been updated over time. They are very old RFC's, while rlogin is much newer and the stuff that isn't quite right in these Request For Comments hasn't been commented on. The RFCs are a good place to start, but there are implementations out there that, for whatever reason, don't conform 100% to the RFCs. Your best bet is to do interop testing once you have your base implementation done. Anything less, even in a fully specified protocol, would not be wise. Warner -- Warner Losh imp@boulder.parcplace.COM ParcPlace Boulder I've almost finished my brute force solution to subtlety.  -----------[000239][next][prev][last][first]---------------------------------------------------- Date: Tue, 18 May 1993 19:18:58 GMT From: tomiii@mtu.edu (Thomas Dwyer III) To: comp.protocols.tcp-ip Subject: Re: Specs on rlogin? now where are dey?  Vernon Schryver (vjs@rhyolite.wpd.sgi.com) wrote: >The rlogin and RIP RFC's were written a decade or more after the code >that implemented and defined the protocols, and not by the authors of >the implementations that defined the protocols. Could someone please point out the major differences between the rlogin RFC and the reality of its implementation? Thanks, Tom.III  -----------[000240][next][prev][last][first]---------------------------------------------------- Date: Tue, 18 May 93 23:01:34 GMT From: thsssxs@iitmax.iit.edu (Semir Sirazi) To: comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc Subject: Wanted: TFTP Source for Windows  Hello there, I am looking for source code for the TFTP protocol (client side only). What I am intending on doing is to port the TFTP stack to Windows 3.1 running over the Novell LAN WorkPlace TCP/IP Stack, (Berkley Sockets). If anyone knows of source code that might get me close to what I am trying to do, I would greatly appreciate hearing from you. Please E-mail me directly at keithz@usr.com. Thank you, Keith Zimmerman keithz@usr.com U.S. Robotics  -----------[000241][next][prev][last][first]---------------------------------------------------- Date: Tue, 18 May 1993 23:48:14 GMT From: vjs@rhyolite.wpd.sgi.com (Vernon Schryver) To: comp.protocols.tcp-ip Subject: Re: RFC's Etc (was Rlogin specs, now where are dey?)  In article <1tb2roINNgkk@flash.pax.tpa.com.au>, hart@flash.pax.tpa.com.au (Leigh M Hart) writes: > ... > Some peole have posted saying the RFCs aren't necessarily a good guideline > for implementing these protocols, if they aren't then what is? should we > have to read original code to implement the protocol in our own applications? I don't know of an errors in the rlogin RFC, but I wouldn't consider hiring anyone who wouldn't or couldn't check the rlogin source before implementing it. >Not only does that breach copyright (in terms of continuancy) in some countries > but it's a pain. In what way does the BSD copyright restrict you? You can do anything you please with the BSD source, provided only you don't blame them, and you include the copyright message somewhere. In which countries have any of the many vendors selling BSD derived products, including rlogin, had any problems? For pity's sake, notice who is my employer! Silicon Graphics has had problems with RIP, but only because of U.S. export restrictions, and certainly not because of the BSD copyright. Why unthinkingly invent something different, inevitably with differen bugs and features, when the Real McCoy, Genuine Article is free for the using? > Now I simply ask - is the RFC for the rlogin protocol (RFC1282) correct? or > am I wasting my time implementing the protocol based on the RFC? does the > same go for the telnet protocol specification and telnet option specification > RFCs? The rlogin and RIP protocols existed for many years in freely available code before people decided to write reasonably good but not authoritative RFC's about them. ... oh, whatever... consider my previous diatribe against egregiously slavish Standard Committee-ism repeated. If nothing else, read the first paragraph on both versions of the rlogin RFC to see that the RFC "does not specifiy an Internet standard." Telnet was and is different. The RFC's defining Telnet did not come long after the implementations. There were many different early implementations of telnet, while there has long been only a single implementation of rlogin, albeit that rlogin implementation has appeared in a myriad of guises. > There must be *some* semblence of consistency in these documents! If people > implementing these protocols don't follow the RFCs that have been designated > as the "standard" then where will we end up? about 20 years behind thats > where - as far as I can see, the push towards "open systems" is really > hotting up at the moment, and it can't succeed without people adhering to > standards that are set up - regardless of which "Standards Organisation (tm)" > defines them. That's almost my rant, except you are being picky about the language of the standard and the Royal Patent of the standards writers. Code is a perfectly fine language for standards. After all, the best (well, whatever) products of CCITT or ANSI are filled with "psuedo-code" and "state machine descriptions." The usual way to write from such standards is to mentally compile from their language into your current favorite. The authoritative description of the rlogin standard is the BSD source. If you don't want to compile, use and ship binaries from that standard then don't. That your C compiler won't accept the stuff in an OSI document, or even any of the contents of most (but not all) RFC's does not keep you from paying homage to them. You're not going to be able respond to your push towards "open systems"' unless you're able to be rational about the standards and standards organizations you accept. Vernon Schryver, vjs@sgi.com  -----------[000242][next][prev][last][first]---------------------------------------------------- Date: Tue, 18 May 1993 23:49:28 GMT From: vjs@rhyolite.wpd.sgi.com (Vernon Schryver) To: comp.protocols.tcp-ip Subject: Re: PING source code !!!!!!!!  In article <1tb9ul$23m@bingsunb.cc.binghamton.edu>, bb31351@bingsunb.cc.binghamton.edu (Rakesh Shetty) writes:
>
> I am looking for the source code of ping (packet internet groper - BSD).
> Any info on where I could ftp it from would be a great help.

Check uunet.  someplace like .../usr.etc/ping.c

Check brl.mil.

Vernon Schryver,  vjs@sgi.com


-----------[000243][next][prev][last][first]----------------------------------------------------
Date:      Tue, 18 May 1993 23:57:06 GMT
From:      vjs@rhyolite.wpd.sgi.com (Vernon Schryver)
To:        comp.protocols.tcp-ip
Subject:   Re: Specs on rlogin? now where are dey?

In article <1993May18.191858.14617@mtu.edu>, tomiii@mtu.edu (Thomas Dwyer III) writes:
> Vernon Schryver (vjs@rhyolite.wpd.sgi.com) wrote:
> >The rlogin and RIP RFC's were written a decade or more after the code
> >that implemented and defined the protocols, and not by the authors of
> >the implementations that defined the protocols.
>
> Could someone please point out the major differences between the rlogin
> RFC and the reality of its implementation?

I've recently quickly skimmed the rlogin RFC.  I've seen no difference.

Still, would you hire someone who would not or could not or did not
check the real, authoritative standard, the source at the start and end
of such a project?
When there is no restriction on doing so?
When you can buy the source on CDROM for a few dollars?
When you can have the source delivered by email to you just about as easily
and for little more money than the RFC?  (uunet's email service)

Eventually I suppose the transformation of the Internet standards
and sub-culture into something identical to ANSI/CCITT/OSI/IEEE/whatever
is inevitable, where form matters and politics and content is at often
no more than an inconvenient detail.  I hope I'm gone by then.

Vernon Schryver,  vjs@sgi.com


-----------[000244][next][prev][last][first]----------------------------------------------------
Date:      Wed, 19 May 1993 02:22:17 GMT
From:      ray@exicom.OZ.AU (Ray Soo)
To:        comp.protocols.tcp-ip
Subject:   problem with dialup SLIP interfaces?

we are a leaf site with dialup SLIP access to a university campus network
(we use the slipware.tar.Z package from Toronto University on a Sparc 2 running
SunOS 4.1.2).

The university end of the connection
has more than one slip interface and each slip
interface there is associated with a particlular IP route. I don't
have the complete details but as I
understand the problem from our network contact at the university, the
problem for us is that if more than one slip interface is down
(off-line) at any one time, the slip interfaces have to come
up in a particular order (e.g. if our route were associated
with slip0, then we would have to come back up first, or else
we'll get allocated slip1 which is associated with the wrong route).

So occasionally when the university dials us back and
the slip interface comes back up , we find the routing
to the outside world is incorrect.

I can't see anything in the slipware package that can
hardwire a particular slip interface to a particular IP address.

How do we solve this problem? If you have answers, please EMAIL

ray@exicom.OZ.AU

ray


-----------[000245][next][prev][last][first]----------------------------------------------------
Date:      Wed, 19 May 1993 06:24:27 GMT
To:        comp.protocols.tcp-ip
Subject:   Re: Help me fix my EBCDIC-ASCII translate table for FTP

In article <900@ceco.ceco.com>, garry@ceco.ceco.com (Garry J. Garrett) wrote:
>What would I like from you?  Do you have a chart that you are willing
>to share with me (that has a 1:1 corresponance, i.e. each character
>on the chart maps to one and only one character on the other chart,
>and that character maps back to the one you started with.)?

The following should do it.  It's the "MTS T-Day chart".  Much efforts
and sweat had gone into it.

+display ascebc@type=xl256
+ascebc@type=xl256  X'
+        00010203 372D2E2F 1605250B 0C0D0E0F 10111213 3C3D3226 18193F27
+        1C1D1E1F 405A7F7B 5B6C507D 4D5D5C4E 6B604B61 F0F1F2F3 F4F5F6F7
+        F8F97A5E 4C7E6E6F 7CC1C2C3 C4C5C6C7 C8C9D1D2 D3D4D5D6 D7D8D9E2
+        E3E4E5E6 E7E8E9BA E0BBB06D 79818283 84858687 88899192 93949596
+        979899A2 A3A4A5A6 A7A8A9C0 4FD0A107 20212223 24150617 28292A2B
+        2C090A1B 30311A33 34353608 38393A3B 04143EFF 41AA4AB1 9FB26AB5
+        BDB49A8A 5FCAAFBC 908FEAFA BEA0B6B3 9DDA9B8B B7B8B9AB 64656266
+        63679E68 74717273 78757677 AC69EDEE EBEFECBF 80FDFEFB FCADAE59
+        44454246 43479C48 54515253 58555657 8C49CDCE CBCFCCE1 70DDDEDB
+        DC8D8EDF'
+display ebcasc@type=xl256
+ebcasc@type=xl256  X'
+        00010203 9C09867F 978D8E0B 0C0D0E0F 10111213 9D850887 1819928F
+        1C1D1E1F 80818283 840A171B 88898A8B 8C050607 90911693 94959604
+        98999A9B 14159E1A 20A0E2E4 E0E1E3E5 E7F1A22E 3C282B7C 26E9EAEB
+        E8EDEEEF ECDF2124 2A293BAC 2D2FC2C4 C0C1C3C5 C7D1A62C 255F3E3F
+        F8C9CACB C8CDCECF CC603A23 40273D22 D8616263 64656667 6869ABBB
+        F0FDFEB1 B06A6B6C 6D6E6F70 7172AABA E6B8C6A4 B57E7374 75767778
+        797AA1BF D0DDDEAE 5EA3A5B7 A9A7B6BC BDBE5B5D AFA8B4D7 7B414243
+        44454647 4849ADF4 F6F2F3F5 7D4A4B4C 4D4E4F50 5152B9FB FCF9FAFF
+        5CF75354 55565758 595AB2D4 D6D2D3D5 30313233 34353637 3839B3DB
+        DCD9DA9F'

...Sam
--

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


-----------[000246][next][prev][last][first]----------------------------------------------------
Date:      Wed, 19 May 1993 09:47:43 +0000
From:      akcs@semagl.demon.co.uk (Alistair Scott)
To:        comp.protocols.tcp-ip,comp.unix.solaris,comp.unix.sys5.r4,comp.protocols.misc
Subject:   Reliable multi-cast comms - please help

We are interseted in any products which sit on-top of
SVR4 UNIX (e.g. SunOS 5.1) which can provide a reliable
LAN based multi-cast messaging service, with flow-control.

We would like to use this from within a multi-threaded

Does anyone have experience or know of any such products
or packages?

akcs@semagl.co.uk
and   mnb@baesema.demon.co.uk

Many thanks in advance for you help.
--
Alistair Scott, BAeSEMA Ltd.


-----------[000247][next][prev][last][first]----------------------------------------------------
Date:      Wed, 19 May 1993 10:04:26 GMT
To:        comp.protocols.tcp-ip,comp.protocols.snmp
Subject:   Commercial PC-Route with SNMP support ?

We've been using the internet-available version of PC-Route for a while now
and are very happy with it.  What I'm after is a version of PC-Route that has
SNMP support - I suspect that there isn't a free version of such a beast but
does it's commercial incarnation offer such support ?  Who do I contact ?
--
Continuing Education Unit				Fax :	(+61 7) 365 7099
The University of Queensland.  QLD  4072.  AUSTRALIA


-----------[000248][next][prev][last][first]----------------------------------------------------
Date:      Wed, 19 May 1993 12:51:49 GMT
From:      artman@vpnet.chi.il.us (Wilfred A Artman)
Subject:   WAN Vendor Info

We are planning the installation of a wide area network in the near
future (2-3 months) and have contacted various vendors concerning
there respective hardware.

I would like to have any input from admin's who have dealt with, or
have knowledge of the following equipment in a networking environment
that includes the implementation of NIS.

1) 3-Com Boundry Routing
3) ACC Remote Bridge/Router & Central Site Bridge/Router

We are running Solbournes at the remote sites and a mix of Solbournes
and Vaxen at the local (host) site. We would like to manage the admin
files using NIS but have heard through the trade journals that this
operation may not work well across a bridged environment.

Any information, including any "oh hecks..." will be greatly appreciated!

Please respnd via e-mail and I will consolidate and post any results.

Thanks!

===========================================================================
Wil Artman                            Email: artman@vpnet.chi.il.us
Senior System Administrator           Voice: (708) 505-0066
Millward Brown, Inc.                  Fax:   (709) 505-0077
Naperville, IL


-----------[000249][next][prev][last][first]----------------------------------------------------
Date:      Wed, 19 May 1993 16:30:07 GMT
From:      craig@sics.se (Craig Partridge)
To:        comp.protocols.tcp-ip
Subject:   re: Info on high-speed transport protocols requested

>We have looked at using TCP, but its maximum transmission speed using a Sparc
>over Ethernet is not fast enough for us. Also TCP is stream-oriented. TP4 is message-
>oriented, but for the same hardware configuration, it is slower than TCP. We
>cannot use XTP, because we need to have IP compatibility.

Please note that this is a limitation of the Sparc TCP/IP and TP4
implementations you have.

> Are there any transport protocols that have been implemented to take advantage of
> the much higher data rates achievable with FDDI? One that we know of is the
> Versatile Message Transaction Protocol, or VMTP designed at Stanford University,
> but are there any commercial implementations of this?

It is very important to distinguish between what the *protocol* can do and
what the *implementation* one has actually achieves.  There exist research
Sparc TCP/IP implementations that achieve a large fraction of the FDDI
bandwidth.  (I think the latest ones fill the FDDI).  In addition,
some vendors, like Silicon Graphics distribute TCP/IP with their products
that achieves 100 Mb/s.

I suspect the experimental VMTP implementations are slower than the best
TCP/IP implementations.

Craig Partridge
craig@bbn.com


-----------[000250][next][prev][last][first]----------------------------------------------------
Date:      Wed, 19 May 1993 16:48:44 GMT
From:      vjs@rhyolite.wpd.sgi.com (Vernon Schryver)
To:        comp.protocols.tcp-ip
Subject:   Re: Info on high-speed transport protocols requested

In article <2025@alcbel.be>, sp_ppm@space.alcbel.be (Paul Moore) writes:
> ...
> We have looked at using TCP, but its maximum transmission speed using a Sparc
> over Ethernet is not fast enough for us. Also TCP is stream-oriented.
> TP4 is message-
> oriented, but for the same hardware configuration, it is slower than TCP. We
> cannot use XTP, because we need to have IP compatibility.

That limits your choices to among TCP/IP, UDP/IP, and some kind of
raw or non-standard IP.

> So we are looking for other transport protocols that might be available, and
> preferably implemented on dedicated hardware, such as for the VME bus.
>
> Are there any transport protocols that have been implemented to take
> the much higher data rates achievable with FDDI? One that we know of is the
> Versatile Message Transaction Protocol, or VMTP designed at Stanford
> University,
> but are there any commercial implementations of this?
> ...

Hmmmph.

This common question is just another form of the ancient and equally
wrong "what kind of protocol should I use instead of TCP/IP because my
ethernet machines can do only 0.8Mbit/sec".
Remember when a VAX-750 was respectable?
Remember when Van Jacobson astounded the world by running TCP/IP
at Ethernet speed?

Some commercial TCP/IP/FDDI implementations do "take advantage of the
much higher data rates achievable with FDDI":

- A pair of Silicon Graphics R4000 Indigos run at "light speed"
over a single TCP/IP virtual circuit as measured by ttcp.
Light speed for TCP over FDDI with 4K packets and tokens
every 40-100KBytes is about 98Mbit/sec.  We showed that
at Interop92.  "Light speed" means the token rotation time
is as high as you want to push it.

- at Interop92 I saw a pair of boxes in the DEC booth doing 95Mbit
sec through TCP/IP.  I have reason to believe they were Alpha's.

- HP has publically said they can do 80Mbit/sec with some model
of system and a new FDDI card.

This ignores the Gbit/sec rates reported by Cray over HIPPI links.
Just how fast do you want TCP/IP to go?

That some FDDI implementations are slower than others implies nothing
about the TCP/IP protocol itself.  That PC-AT clones do an awesome
300KByte/sec over Ethernet implies nothing of technical interest.  That
some commercial workstations are not impressive on FDDI says some
slightly interesting things about bus, cache and I/O architectures that
would good 10 years ago but wrong today.  Those slow workstations may
and that more people are not necessarily more productive than fewer.
(The "software team" for SGI FDDI development has fewer than 2
full-time-equivalents, and the "hardware team" is only slightly
larger.  "Team"--eeyuck.  Those who talk that way are often the problem.)

Vernon Schryver,  vjs@sgi.com


-----------[000251][next][prev][last][first]----------------------------------------------------
Date:      19 May 1993 01:58:40 +0930
From:      hart@flash.pax.tpa.com.au (Leigh M Hart)
To:        comp.protocols.tcp-ip
Subject:   RFC's Etc (was Rlogin specs, now where are dey?)


Apologies WRT not opening my eyes when looking for the RFC on the rlogin
protocol.  It was there all along!  amazing huh.

Some peole have posted saying the RFCs aren't necessarily a good guideline
for implementing these protocols, if they aren't then what is?  should we
have to read original code to implement the protocol in our own applications?

Not only does that breach copyright (in terms of continuancy) in some countries
but it's a pain.

Now I simply ask - is the RFC for the rlogin protocol (RFC1282) correct?  or
am I wasting my time implementing the protocol based on the RFC?  does the
same go for the telnet protocol specification and telnet option specification
RFCs?

There must be *some* semblence of consistency in these documents!   If people
implementing these protocols don't follow the RFCs that have been designated
as the "standard" then where will we end up?  about 20 years behind thats
where - as far as I can see, the push towards "open systems" is really
hotting up at the moment, and it can't succeed without people adhering to
standards that are set up - regardless of which "Standards Organisation (tm)"
defines them.

Leigh
--
Leigh M Hart (hart@pax.tpa.com.au)


-----------[000252][next][prev][last][first]----------------------------------------------------
Date:      Wed, 19 May 1993 17:38:07 +0000
From:      proyse@peeras.demon.co.uk (Phil Royse)
To:        comp.protocols.tcp-ip
Subject:   Class C Addresses & subnet masks


A client I am working for is planning to install a large IP
router network of about 60 routers, 40/60 premises and 1200 hosts.
We have only been allocated a Clump-o-Cs, and have planned on paper
an address structure which makes heavy use of subnetting:

subnet mask = 255.255.255.192  = two subnets of 62 hosts each
= 255.255.255.224  = six subnets of 30 hosts
= 255.255.255.240  = 14   "      "  14  "

etc. etc., we even have 30 subnets with 6 hosts (for the small
offices)  -  tight, I know, but that's all we got :-)

We are planning to use OSPF within the autonomous system.

Are there any pitfalls related to all this heavy subnetting???

Can most modern routers (e.g. 3Com, Cisco, W'Fleet etc. cope OK?)

--

Phil Royse     Comms Consultant  | member:  The Peer Association
TUDOR HOUSE                      | (networking & OSI specialists)
Surrey  CR8 4LN   (UK)        Tel: (+44) 81 645-9868


-----------[000253][next][prev][last][first]----------------------------------------------------
Date:      Wed, 19 May 1993 19:07:45 GMT
From:      randolph@freighter.mitre.org (Randolph Mitchell)
To:        comp.protocols.tcp-ip
Subject:   Re: Info on high-speed transport protocols requested


Are you sure that even a *zero* processing-overhead transport protocol will give you the performance you desire?  A while back, we took some measurements (on a Sun) that showed that you could realize a 25% improvement in throughput by skipping the transport protocol altogether (i.e., go right to network-layer).  That's an improvement, to be sure, but not exactly breath-taking.  The problems (as the Wise Ones have pointed out over the past few years) often do not lie with the protocols themselves, but with

memory management, the OS, interface mechanisms, etc.  These do not change with the choice of transport protocol.  Perhaps you have already done this, but I'd make doubly sure that the transport protocol is properly configured and that the bottleneck is indeed the transport protocol before hunting for a special-purpose transport protocol.

Regards,
Randy Mitchell


-----------[000254][next][prev][last][first]----------------------------------------------------
Date:      19 May 1993 20:17:06 GMT
From:      mogul@pa.dec.com (Jeffrey Mogul)
To:        comp.unix.questions,comp.protocols.tcp-ip
Subject:   Re: Internetworking book

In article <C7AGJA.79C@mcs.anl.gov> curtis@achilles.ctd.anl.gov (Jeffrey S. Curtis) writes:
>I've searched high and low for a copy of the book _Internetworking:
>Bridges and Routers_ to no avail.  None of the local bookstores have
>it, and I can't even find it in any of the well-known book lists (yabl,
>the book faq, et al.).  Can anyone give me a pointer to a list which
>contains this book, or tell me the ISBN, or at least the publisher, or

AUTHOR:       Perlman
TITLE:        Interconnections: Bridges and Routers in Osi and Tcp / Ip
IMPRINT:      Addison Wesley Pub Co Inc., 1991. (Hardback. ISBN:0-201-56332-0)

You can phone-order books from Addison-Wesley, 1-800-447-2226.

The Stanford bookstore sells this for $45.95, but it might list for more, and you have to pay shipping if you order by telephone. -Jeff  -----------[000255][next][prev][last][first]---------------------------------------------------- Date: 19 May 93 20:18:01 GMT From: art@acc.com (Art Berggreen) To: comp.unix.questions,comp.protocols.tcp-ip Subject: Re: Internetworking book  In article <C7AGJA.79C@mcs.anl.gov> curtis@achilles.ctd.anl.gov (Jeffrey S. Curtis) writes: >I've searched high and low for a copy of the book _Internetworking: ^^^^^^^^^^^^^^^ Interconnections >Bridges and Routers_ to no avail. None of the local bookstores have >it, and I can't even find it in any of the well-known book lists (yabl, >the book faq, et al.). Can anyone give me a pointer to a list which >contains this book, or tell me the ISBN, or at least the publisher, or >anything else about this book? ISBN 0-201-56332-0 Addison-Wesley 1992  -----------[000256][next][prev][last][first]---------------------------------------------------- Date: Wed, 19 May 1993 20:21:17 GMT From: curtis@achilles.ctd.anl.gov (Jeffrey S. Curtis) To: comp.unix.questions,comp.protocols.tcp-ip Subject: Re: Internetworking book (solution)  curtis@achilles.ctd.anl.gov (Jeffrey S. Curtis) writes: }I've searched high and low for a copy of the book _Internetworking: }Bridges and Routers_ to no avail. [...] I've been informed that the correct title is _Interconnections: Bridges and Routers_ by Radia Perlman for Addison-Wesley, ISBN 0-201-56332-0. Thanks to Greg Dobrich for this info. Jeff -- Jeffrey S. Curtis - curtis@anl.gov / Argonne National Laboratory Research Assistant, Network Section / Electronics and Computing Technologies Polk - Phase Linear - Sanyo - Proton / 9700 South Cass Avenue Jensen - Sony - StreetWires - Sennet / Argonne, IL 60439 +1 708/252-4750  -----------[000257][next][prev][last][first]---------------------------------------------------- Date: Wed, 19 May 1993 20:30:56 GMT From: mskucher@math.uwaterloo.ca (Murray S. Kucherawy [MFCF]) To: comp.protocols.tcp-ip Subject: Declaring a weird CNAME to named  We have a host called 1308.watstar, whose relevant nameserver data looks like this: 1308.watstar IN A 129.97.20.3 IN MX 0 starhost.watstar IN MX 10 steam 1308 IN CNAME 1308.watstar The meaning of this last line, the CNAME, has me puzzled. nslookup(1) seems to interpret it to mean "1308 is an alias for 1380.watstar", but host(1) seems to interpret it to mean "1308.watstar is an alias for 1308.watstar with a time-to-live of 1308". Unless I've missed some detail in RFC1035, it could go either way; RFC1123 says having a name fragment which is all digits is legal. So which is correct, and which will the nameserver use? -- Murray S. Kucherawy ----------------------------------------+-------------- Software Systems Co-op, Math Faculty Computing Facility [MFCF] | This is a University of Waterloo, Ontario, Canada | machine that E-mail: mskucherawy@{math,watdragon}.UWaterloo.ca | goes PING! ---------------------------------------------------------------+--------------  -----------[000258][next][prev][last][first]---------------------------------------------------- Date: Wed, 19 May 1993 20:54:21 GMT From: lapp@waterloo.hp.com (David Lapp) To: comp.unix.questions,comp.protocols.tcp-ip Subject: Re: Internetworking book  Jeffrey S. Curtis (curtis@achilles.ctd.anl.gov) wrote: : I've searched high and low for a copy of the book _Internetworking: : Bridges and Routers_ to no avail. None of the local bookstores have : it, and I can't even find it in any of the well-known book lists (yabl, : the book faq, et al.). Can anyone give me a pointer to a list which : contains this book, or tell me the ISBN, or at least the publisher, or : anything else about this book? Assuming that you mean "Interconnections: Bridges and Routers" by Radia Perlman then try ISBN 0-201-56332-0 Published by Addison-Wesley : Thanks, You're welcome. Dave Lapp  -----------[000259][next][prev][last][first]---------------------------------------------------- Date: Wed, 19 May 93 21:56:17 GMT From: jan@ois.com (Jan Morales) To: comp.dcom.lans.misc,comp.protocols.tcp-ip,comp.protocols.ppp,comp.unix.aux,comp.unix.questions,comp.sys.sun.misc,comp.sys.sun.admin Subject: cannot get SLIP to work  I am posting this for a friend so please e-mail replies to him: sturt@filetek.com Thanks. ---------------------- I recently got the sun slip mods for sunos 4.1 off of the uunet archives. I want to set up my sun at work as a slip server that I can use from my Apple AUX system at home. I got the driver genned into the sun kernel without a hitch but I'm having problems setting up the connection from home. I dial into the sun logon and run slip-attach as follows: slip-attach /dev/ttypxxx 9600 sun-addr home-addr netmask I then open up another window on my home system and run slattach and ifconfig to configure the serial line as follows: slattach /dev/tty0 9600 ifconfig sl0 home-addr sun-addr up When I ping the sun host I see the transmit light on the modem working but nothing comes back. I also get a console message on the sun side: vmunix: slipencode: overrun This indicates a packet over the MTU for the connection. Can anybody give me a play by play on how to set up the slip connection and what I might be doing wrong? Do I need special modem strappings? Thanks in advance for any help Dave S. sturt@filetek.com uunet!fltk!sturt -- Jan Morales jan@ois.com Objective Interface Systems, Inc. uunet!ois!jan Reston, Virginia, U.S.A.  -----------[000260][next][prev][last][first]---------------------------------------------------- Date: Thu, 20 May 1993 04:41:29 GMT From: vjs@rhyolite.wpd.sgi.com (Vernon Schryver) To: comp.protocols.tcp-ip Subject: Re: RFC's Etc (was Rlogin specs, now where are dey?)  In article <1993May18.180713.6908@spectrum.CMC.COM>, lars@spectrum.CMC.COM (Lars Poulsen) writes: > In article <1tb2roINNgkk@flash.pax.tpa.com.au> > hart@flash.pax.tpa.com.au (Leigh M Hart) writes: > >Some peole have posted saying the RFCs aren't necessarily a good guideline > >for implementing [rlogin etc], if they aren't then what is? should we > >have to read original code to implement the protocol in our own applications? > > ... > >Now I simply ask - is the RFC for the rlogin protocol (RFC1282) correct? or > >am I wasting my time implementing the protocol based on the RFC? does the > >same go for the telnet protocol specification and telnet option specification > >RFCs? > > The Internet perspective is that there is no point in implementing a > protocol if it does not work. Arguing about whether the paper > specification is more correct than the many currently running > implementations is pointless. > > This applies in particular, when - as in the case of rlogin - the > protocol was not developed through the standards process, but was > a useful non-standard hack implemented by someone and then widely > distributed. RFC1282 reflects a reverse-engineering effort and it is > very nearly correct. > > TELNET, on the other hand, is a standard protocol, and the specification > is authoritative. Well put. Last week someone wrote me suggesting that the diffference between the RIP RFC and the routed implementation should and must be resolved by changing routed implemenation, and never mind that the BSD code is many years older and in the particular technical differences, obviously better. The idea of treating an RFC as newly revealed devine law, innocently proposed although it was, is what really started the smoke pouring out of my ears. The trouble with the final rlogin RFC is that it is too consise. No new implementation of rlogin from the RFC will be usable without years of debugging, because the RFC documents only the trivial part of the protocol that can be seen with your favorite ethernet snoop tool. The hard issues are such as implementing that out-of-band stuff mentioned in passing by the RFC. Consider the reasons for moving the initialization of the SIGURG signal handler between 4.3BSD and more recent versions. Or the reasons for the strange helper signal handlers in the parent of the two rlogin processes. Vernon Schryver, vjs@sgi.com  -----------[000261][next][prev][last][first]---------------------------------------------------- Date: Thu, 20 May 1993 06:47:22 GMT From: isc20078@nusunix1.nus.sg (FOONG CHEE KHIONG) To: comp.protocols.tcp-ip Subject: PCTCP appilcation package  My project group is currently embarking on a project to incorporate 3D sound into our existing system. The sound equipment is PC-based while our system is running on the Silicon Graphics Reality Engine. Hence, we are in the process of scouting for viable software to link both our systems. We sincerely hope that somebody could give us some informations about the source code and library routine documentation that we can made use of. Currently we are working on 'C' programming , therefore we do not need the executable files but rather the 'C' codes of the FTP package. We intend to use 'types.h, socket.h' which are available in Unix 'C' but not to be found on Borland C++ on our PC. ckfoong@iss.nus.sg  -----------[000262][next][prev][last][first]---------------------------------------------------- Date: Thu, 20 May 93 07:05:41 GMT From: R.Thirlby@lut.ac.uk To: comp.protocols.tcp-ip Subject: Re: 3270 Terminal Emulation  We have a similar requirement for 3270 emulation over IP for an HP710 workstation. Any information would be useful rob thirlby, r.thirlby@lut.ac.uk  -----------[000263][next][prev][last][first]---------------------------------------------------- Date: Thu, 20 May 1993 13:25:28 GMT From: stewart@oin.cis.udel.edu (John Stewart) To: comp.unix.questions,comp.protocols.tcp-ip Subject: Re: Internetworking book  In article <C7AGJA.79C@mcs.anl.gov> curtis@achilles.ctd.anl.gov (Jeffrey S. Curtis) writes: >I've searched high and low for a copy of the book _Internetworking: >Bridges and Routers_ to no avail. None of the local bookstores have >it, and I can't even find it in any of the well-known book lists (yabl, >the book faq, et al.). Can anyone give me a pointer to a list which >contains this book, or tell me the ISBN, or at least the publisher, or >anything else about this book? I don't know of a book by that name. Could you mean _Interconnections: Bridges and Routers_ by Radia Perlman? If so, the ISBN is 0-201-56332-0. (There's also the three volume _Internetwokring with TCP/IP_ series by Comer and Stevens, but the "Bridges and Routers" you mention makes me think it's Perlman's book you want.) Good luck. /jws  -----------[000264][next][prev][last][first]---------------------------------------------------- Date: Thu, 20 May 1993 16:38:46 GMT From: skaggs@nsslsun.nssl.uoknor.edu (Gary Skaggs) To: comp.dcom.lans.misc,comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpC Subject: Need Router software that runs on a PC...  I've looked in the FAQs for a few groups and haven't found this anywhere and haven't needed it till now, but I need the PD softwared that runs on a poor old dumb PC that uses two network cards to route (or bonus, and bridge) between two networks. Any help on finding this is appreciated. ______________________________________________________________________________ Gary Skaggs - WB5ULK skaggs@nssl.nssl.uoknor.edu "Neither my employer, The University of Oklahoma, nor The National Severe Storms Laboratory, where I work, know that I even have any opinion, much less this one."  -----------[000265][next][prev][last][first]---------------------------------------------------- Date: Thu, 20 May 1993 18:48:13 GMT From: pug@wixer.bga.com (Pug) To: comp.sys.mac.programmer,comp.sys.mac.apps,comp.sys.mac.comm,comp.protocols.tcp-ip,comp.protocols.tcp-ip.domains Subject: MacTCP 1.1.1 and DNS...  Good Morning, This is been posted over a wide variety of places just because I'm not sure who to ask/discuss this with. We have an ethernet network with a lot of Mac's on it. We have MacTCP 1.1.1 running on them and generally use NCSA Telnet 2.5. This is happening on all of our Macs so I don't think it's System dependant. What the problem is is this - When using MacTCP and having more then one server per domain, which is rather standard to have a primary and secondary server incase the primary is down, if the primary *is* down, it will not use the secondary for the domain. You have to change the default setting and then reboot. Well this is not an acceptable solution. It will go on to any server under another domain name though. The reason that we need a solution is our primary server is moving and we want people to still be able to access other computers when it does. We can't synchronize the changing of every Mac in the building when we do switch, and would prefer to have the time. As well, if the primary at any point is down *and* they have another NS off-site listed, then if our link to the world goes down as well, they can't even get to the UN*X box that might be sitting on the next guys desk. I have tried talking to 1-800-SOS-APPL to no avail, they don't even seem to believe that the problem exists, eventhough it can easily be duplicated. Does anyone know of a solution for this problem? In the domainname field, does it have to be a true domain? For example can I put arluta.utexas.edu, arlutb.utexas.edu, etc and still get back correct addresses given the short name for a host? Thanks to anyone who has any ideas on this. Ciao, -- Richard Bainter Mundanely | System Analyst - OMG/CSD Pug Generally | Applied Research Labs - U.Texas bainter@csdsun1a.arlut.utexas.edu | pug@wixer.bga.com Note: The views may not reflect my employers, or even my own for that matter.  -----------[000266][next][prev][last][first]---------------------------------------------------- Date: Thu, 20 May 1993 20:15:37 GMT From: richb@jti.com (Rich Braun) To: comp.protocols.tcp-ip Subject: Re: Class C Addresses & subnet masks  proyse@peeras.demon.co.uk writes: >A client I am working for is planning to install a large IP >router network of about 60 routers, 40/60 premises and 1200 hosts. >We have only been allocated a Clump-o-Cs, and have planned on paper >an address structure which makes heavy use of subnetting: A little over a year ago I posted to this newsgroup with the same problem: a site about to buy a bunch of routers and link 20 field offices onto the net, which had 10 Class C addresses. The feedback I got here was unanimous: you'll regret subnetting your Class C networks like that. Not all _client_ IP implementations support this. Unless you know for sure they do, then you might run into trouble later. Armed with this advice, I went for a Class B network number. Made things a heck of a lot easier to manage, especially as the field sites grew. Have Class B's already gotten hard to come by? -rich  -----------[000267][next][prev][last][first]---------------------------------------------------- Date: Thu, 20 May 1993 21:26:47 GMT From: cricket@corp.hp.com (Cricket Liu) To: comp.protocols.tcp-ip Subject: Re: Declaring a weird CNAME to named  Murray S. Kucherawy [MFCF] (mskucher@math.uwaterloo.ca) wrote: : We have a host called 1308.watstar, whose relevant nameserver data looks like : this: : 1308.watstar IN A 129.97.20.3 : IN MX 0 starhost.watstar : IN MX 10 steam : 1308 IN CNAME 1308.watstar : The meaning of this last line, the CNAME, has me puzzled. nslookup(1) seems : to interpret it to mean "1308 is an alias for 1380.watstar", but : host(1) seems to interpret it to mean "1308.watstar is an alias for : 1308.watstar with a time-to-live of 1308". Hmm. I've never heard of the field after the record type being interpreted as a time-to-live (of course, I may have missed some subtle nuance of RFC1035). Certainly not with a dot separating it from the first field of record-specific data. BTW, my host command doesn't interpret the '1308' as a TTL. I use the NIKHEF version, ftp'able from ftp.nikhef.nl. -- cricket cricket@hp.com / Hewlett-Packard Professional Services Org. / Englewood, CO  -----------[000268][next][prev][last][first]---------------------------------------------------- Date: Thu, 20 May 1993 23:01:11 GMT From: tannen@mack.geg.mot.com (David Tannen x2325) To: comp.protocols.tcp-ip Subject: Developing with Sockets and recv  Our application uses Sockets (recv and send) to transport data across TCP/IP. My question has to do with recv. 1) I want to send up to 32k buffers across TCP/IP, but my documentation (and socket.h) seem to indicate that sockets can only handle about 8k at a time. Is this true? If we do have to break up the 32k buffer into pieces, do we need to track the order of each piece? (i.e. Is the order that sends occur preserved across TCP/IP?) 2) The buffer contains a header which indicates the size of the entire buffer. The header is the first 20 bytes of the buffer. If I do a recv for the first 20 bytes, without the PEEK flag, will the rest of the buffer be lost? Our prototype seems to indicate that we should break up our buffers into smaller pieces and then send them. It also seems to indicate that recv is destructive, unless the PEEK flag is used.  -----------[000269][next][prev][last][first]---------------------------------------------------- Date: Thu, 20 May 1993 23:13:47 +0000 From: chan@chan1.demon.co.uk (Daniel de Klerk) To: comp.sys.novell,comp.protocols.tcp-ip Subject: LAN WorkPlace, Ethernet and terminal emulator problems...  I believe that this question might be an FAQ, but I do not normally follow these newsgroups (although I have subscribed now). Please give me some pointers if you can: We are running Novell 3.11 (5 user) on Ethernet with 3 PC's and a proprietary box running standard (I think) TCP/IP. Two PC's are running DOS 5, one on DOS 6, and all load the following drivers: LSL although this also works LSL NE2000 NE2000 TCPIP IPXODI TELAPI NETX IPXODI TCPIP NETX NETX TSU (2 sessions) TSU (ditto) We have our own terminal emulator written in Turbo C which talks to the proprietary system, and works quite happily from DOS. Yes, this whole lot eats memory, but hold on, there's more to come... I now want to load 2 session of the emulator under Windows so that we can have multiple sessions to the same host. The emulator talks to INT 14, which is intercepted by TSU and passed on to the Telnet servers on the host. I can get this whole setup running quite well provided I have enough memory before I start Windows. If I have all the above drivers loaded, and Novell's CAPTURE as well, Windows complains that there is not enough memory to start the application, sometimes the application (the term em) is aborted due to illegal instructions, and whatever can get worse. Sometimes Windows complains that there is not enough memory for the application's screen to be displayed, but if you ignore the message it starts up OK. The "funny" (not ha-ha) thing is that the term em uses less than 200K of RAM (tested by doing MEM, then loading and shelling to DOS and doing MEM again; find the difference). I am starting the sessions up via PIF files, and have fiddled with memory settings and windowed vs full-screen, to no avail. I have also tried QEMM 6.0 and DOS 6 to improve memory usage. Both do quite a good job of giving me lots of memory, but the emulator will not work at all if TCPIP and TELAPI are loaded high. So, the question: If I start Windows with the drivers loaded as listed above, I start off with approx 470K RAM (yes, horrible, isn't it!). The terminal emulator sessions crash with varying degrees of severity, or Windows just refuses to load them. Is there anything I am doing wrong? Can I try something like the Clarkson packet drivers with some PD/Shareware TCP/IP instead of LAN WorkPlace? All help MUCH appreciated! -- __________________________________________________________________ Neville Chamberlain chan@chan1.demon.co.uk  -----------[000270][next][prev][last][first]---------------------------------------------------- Date: Thu, 20 May 1993 23:24:39 GMT From: kre@cs.mu.oz.au (Robert Elz) To: comp.protocols.tcp-ip Subject: Re: Declaring a weird CNAME to named  In <C7AJnK.7II@math.uwaterloo.ca> mskucher@math.uwaterloo.ca (Murray S. Kucherawy [MFCF]) writes: | We have a host called 1308.watstar, whose relevant nameserver data looks like | this: | 1308.watstar IN A 129.97.20.3 | IN MX 0 starhost.watstar | IN MX 10 steam | 1308 IN CNAME 1308.watstar | The meaning of this last line, the CNAME, has me puzzled. nslookup(1) seems | to interpret it to mean "1308 is an alias for 1380.watstar", That's correct. | but host(1) seems to interpret it to mean "1308.watstar is an alias for | 1308.watstar with a time-to-live of 1308". Weird. | Unless I've missed some detail in RFC1035, it could go either way; | RFC1123 says having a name fragment which is all digits is legal. | So which is correct, and which will the nameserver use? nslookup uses the nameserver, and in the binary packet formats, the whole thing is unambiguous ("1308" as a string is in the name field, and is clearly a name, 1308 as a binary integer is in the TTL field, and so is a TTL). I thought host did that too, but haven't used it, so I'm not sure. Dig agrees with nslookup. In any case, in zone files, names always begin at the left margin, and whatever is at the left margin is always a name (modulo absurd BIND DNS file parsing implementations, and continuation lines using '(' ')' in conforming zone files). TTL's, if given, must be indented. " 1308 IN CNAME ..." would make 1308.watstar be a cname for 1308.watstar (which is both meaningless and illegal) with a ttl of 1308. As you have it, and without the space, all is fine. What's more, it really does work... dig 1308.uwaterloo.ca ; <<>> DiG 2.0 <<>> 1308.uwaterloo.ca ;; ->>HEADER<<- opcode: QUERY , status: NOERROR, id: 6 ;; flags: qr aa rd ra ; Ques: 1, Ans: 2, Auth: 0, Addit: 0 ;; QUESTIONS: ;; 1308.uwaterloo.ca, type = A, class = IN ;; ANSWERS: 1308.uwaterloo.ca. 86400 CNAME 1308.watstar.uwaterloo.ca. 1308.watstar.uwaterloo.ca. 86400 A 129.97.20.3 ;; Sent 4 pkts, answer found in time: 3767 msec sent 3 too many pkts ;; FROM: mulga.cs.mu.OZ.AU to SERVER: default -- 192.43.207.2 ;; WHEN: Fri May 21 09:24:26 1993 ;; MSG SIZE sent: 35 rcvd: 90 kre  -----------[000271][next][prev][last][first]---------------------------------------------------- Date: 21 May 1993 11:11:23 -0400 From: kent@tfd.com (Kent Hauser) To: comp.protocols.tcp-ip Subject: Can't flush a TCP connection  Environment: All under SunOS 4.1.1 and 4.1e Is there a way a sender can abort and flush a TCP connection? I have a system where a server process provides a stream of data to multiple remote clients. When a client fails to read it's data (for instance it rec'd a SIGSTOP, or is busted), TCP provides buffering on both the local host & remote host. When the buffering capability is exhausted, my server receives EWOULDBLOCK & closes the connection. Unfortunately, all of the buffered data on both the local & remote hosts sits around waiting for the client to one day read it (or exit). This is a problem when there are multiple connections stopped up, as it eats up all of my buffer space. Since the FIN' bit is buffered right along with the data, I think I need to send a RESET' some how. I tried setting the linger' option on the socket to 2 seconds, but it had no effect. Can someone advise me how I can kill the connection & flush the buffers? Thanks. Kent -- Kent Hauser UUCP: {uunet,sundc,uupsi}!tfd!kent Twenty-First Designs INET: kent@tfd.com (301) 572-6370  -----------[000272][next][prev][last][first]---------------------------------------------------- Date: 21 May 1993 05:14:51 GMT From: munna@eng.umd.edu (Ajay Kumar Srivastava) To: comp.protocols.tcp-ip Subject: FAQ  Keywords: I recently joined this news group. Can someone please send me an FAQ for this news group. Thanks, ajay  -----------[000273][next][prev][last][first]---------------------------------------------------- Date: 21 May 1993 10:48:12 GMT From: neideck@nestvx.enet.dec.com (Burkhard Neidecker-Lutz) To: comp.protocols.tcp-ip Subject: Re: Info on high-speed transport protocols requested  In article <i0imr8g@rhyolite.wpd.sgi.com> vjs@rhyolite.wpd.sgi.com (Vernon Schryver) writes: > - at Interop92 I saw a pair of boxes in the DEC booth doing 95Mbit > sec through TCP/IP. I have reason to believe they were Alpha's. Yep, and some CPU cycles left doing that. Complain to SUN (and tell them that both SGI and DEC can do this). Reminds me of the customers we had here that didn't believe you could get 1 MByte/sec task-to-task via Ethernet. Showed them that on 2 DECstations (not even Alpha's). Customers comment: "The best we've ever seen on a SUN is 500 KByte/sec. What kind of ethernet do you have ?" My response: "We have thicker cables..." Burkhard Neidecker-Lutz Distributed Multimedia Group, CEC Karlsruhe Software Motion Pictures & BERKOM II Project Digital Equipment Corporation neidecker@nestvx.enet.dec.com  -----------[000274][next][prev][last][first]---------------------------------------------------- Date: Fri, 21 May 1993 11:42:38 GMT From: luca@dedalo.unipg.it (Luca Priorelli) To: comp.protocols.tcp-ip Subject: Help installing SLIP on Sun!  I want to install SLIP on a SPARCstation running SunOS 4.1.2. I got cslip 2.6. 1 - I don't know if this is the best slip package 2 - I installed it and it runs badly. pinging from the client is very slow. Some ping packets are dropped. Any other tcp/ip command works partially (e.g. they give a 'connect' message but do not go ahead). Can you help me? Luca Priorelli  -----------[000275][next][prev][last][first]---------------------------------------------------- Date: 21 May 1993 12:55:28 GMT From: casper@fwi.uva.nl (Casper H.S. Dik) To: comp.protocols.tcp-ip Subject: Re: Info on high-speed transport protocols requested  neideck@nestvx.enet.dec.com (Burkhard Neidecker-Lutz) writes: >Yep, and some CPU cycles left doing that. Complain to SUN (and tell them >that both SGI and DEC can do this). Reminds me of the customers we had >here that didn't believe you could get 1 MByte/sec task-to-task via >Ethernet. Showed them that on 2 DECstations (not even Alpha's). Customers >comment: > "The best we've ever seen on a SUN is 500 KByte/sec. What > kind of ethernet do you have ?" We never had any problem getting 1000KB/s on Suns. Of course, if the customers had a pretty busy ethernet or pretty obsolete Sun hardware, it would not have been possible. Ans what tests did they use? The default TCP send/recv windows are small compared to other vendors. Also, some Sun hardware is limited to 600KB/s. Anything with the Intel (ie) ethernet interfaces can't possibly get above 600KB/s because it's a broken chip. I'll grant yuo, though, that Sun for a company that has in the past claimed that the network is the computer'' has always been running behind on ethernet performance and even more behind in FDDI performance. Casper  -----------[000276][next][prev][last][first]---------------------------------------------------- Date: Fri, 21 May 1993 14:03:18 GMT From: mskucher@math.uwaterloo.ca (Murray S. Kucherawy [MFCF]) To: comp.protocols.tcp-ip Subject: Semantics of RFC1035$ORIGIN

I'm afraid the wording of RFC1035 isn't quite clear to me with respect
to how to handle $ORIGIN control lines... for example, if my current origin is "uwaterloo.ca" and I specify "$ORIGIN math", is the new
origin for the next record(s) encountered just "math", or is it
prepended to become "math.uwaterloo.ca" since there is no terminating
"." character?

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


-----------[000277][next][prev][last][first]----------------------------------------------------
Date:      Fri, 21 May 1993 15:44:11 GMT
From:      jpb@jpbpc1.uncc.edu (John Bennett)
To:        comp.protocols.tcp-ip
Subject:   Super-TCP

I have just finished Tested the following nine competing products:
PC/TCP from FTP Software
ChameleonNFS from NetManage
Pathway Access from Wollongong
Lan Workspace for DOS from Novell
3Com TCP from 3Com
Sun PC-NFS from SunSoft V5.0
IBM TCP/IP V2.1 from IBM
Beam & Whiteside NFS V3.0a from Beam & Whiteside
Super-TCP From Frontier Technologies V3.0 R1

Our basic requirements for a TCP/IP package are NFS support for both DOS & Windows environments, an
integrated mail product with the ability to support enclosures, ease of installation, minimal use of base
memory, ability to support third party vendor applications such as X-Windows for the PC, a package that
was stable in performance, and support for DNS name servers.. Other considerations were support for
Winsock v1.1, standard Telnet, FTP, SMTP, POPmail, TN3270, and support for SMC/WD ethernet cards.
Super-TCP from Frontier Technologies is the only software that meets all of our basic requirements.
Frontier Technologies Super-TCP Email supports (MIME) extensions through SMTP gateways, Thus
allowing the transmission of data to persons on various platforms for their use.

Package Requirements:

*	Windows Sockets API
*	Winsock V1.1 support
*	100% Windows DLL
*	VxD Virtual Driver
*	Dual Mode Operation (100% DLL or TSR for DOS)
*	VT220 VT320
*	TN3270
*	Telnet Redirector
*	Client-Server FTP, TFTP
*	Electronic Mail (SMTP, POP 2&3) (MIME)
*	Talk
*	NFS Client
*	NFS Server
*	Remote Protocols
*	SNMP Agent
*	Extendible MIB
*	ONC RPC/XDR API
*	NetBIOS API
*	Binary API
*	Berkely Sockets API
*	LPR
*	LPD
*	NDIS & PACKET DRIVERS
*	ODI & ASI DRIVERS
*	SLIP
*	PPP
*	X.25
*	RFC 1006 OSI
*	Modem Server
*	BOOTP
*	Third Party Support


-----------[000278][next][prev][last][first]----------------------------------------------------
Date:      21 May 1993 03:58:33 +0930
From:      hart@flash.pax.tpa.com.au (Leigh M Hart)
To:        comp.protocols.tcp-ip
Subject:   Re: RFC's Etc (was Rlogin specs, now where are dey?)

vjs@rhyolite.wpd.sgi.com (Vernon Schryver) writes:

>I don't know of an errors in the rlogin RFC, but I wouldn't consider
>hiring anyone who wouldn't or couldn't check the rlogin source before
>implementing it.

When it comes to implementing protocols for the TCP/IP suite I'm pretty
much a "newbie" (for want of a better word).  I'm writing an application
that I hope, eventually, will be a viable contender for existing network
hardware.  I basically know (through USENET and other net exposure) that
when implementing existing protocols, following the RFCs is the norm and
is generally accepted as the way to do these things.

Obviously anyone implementing one of the protocols from an RFC that isn't
the authoritive standard would cross reference their code with the freely
available and hopefully authoritive source code (in this case BSD's code
for rlogin) to make damn sure it conformed, as well as the obvious testing
to make sure it worked in the first place.

I wasn't suggesting implementations should be wholy-and-solely based
on the RFCs and never checked against existing source code, but that
implementors shouldn't base their code entirely on original code.

>> There must be *some* semblence of consistency in these documents!   If people
>> implementing these protocols don't follow the RFCs that have been designated
>> as the "standard" then where will we end up?  about 20 years behind thats
>> where - as far as I can see, the push towards "open systems" is really
>> hotting up at the moment, and it can't succeed without people adhering to
>> standards that are set up - regardless of which "Standards Organisation (tm)"
>> defines them.

>That's almost my rant, except you are being picky about the language of
>the standard and the Royal Patent of the standards writers.  Code is a
>perfectly fine language for standards.  After all, the best (well,
>whatever) products of CCITT or ANSI are filled with "psuedo-code" and
>"state machine descriptions."  The usual way to write from such
>standards is to mentally compile from their language into your current
>favorite.

I agree with you on this point - the easiest (and safest) way to implement
any standard is to include example code along with the waffle describing
how it all works.

>The authoritative description of the rlogin standard is the BSD source.
>If you don't want to compile, use and ship binaries from that standard
>then don't.  That your C compiler won't accept the stuff in an OSI
>document, or even any of the contents of most (but not all) RFC's does
>not keep you from paying homage to them.

That's the point!  I _do_ want to compile use and ship binaries from
the _standard_ - what's the point otherwise? (as you pointed out in
your post, why reinvent the wheel, just to find your's is square?)
The task at hand is to decypher the waffle and find out what *is* the
standard (in this case, you have put me on the right track, thanks!)

One example where this unfortunately all falls down, is some companies
when they invent a protocol that becomes a "standard" when applied to their
own products, but do not release code to their protocol nor (as far as I
know) freely release documentation of their protocol for developers,
it makes it kind of hard to implement their protocols.

Leigh
--
Leigh M Hart (hart@pax.tpa.com.au)


-----------[000279][next][prev][last][first]----------------------------------------------------
Date:      Fri, 21 May 93 19:43:43 GMT
From:      news@nlm.nih.gov
To:        comp.protocols.tcp-ip
Subject:   PC-NFS SLIP and Windows 3.1 compatible?

Hi,

I am trying to connect a PC and a Sparc using PC-NFS 4.0 SLIP and Microcom
modems.  The problem is if I tried to enter Windows 3.1 after establishing
SLIP connection, the PC hangs and I have to reboot.  Also I cannot establish
SLIP by typing connect "profilename".  I have to use connect -i to setup the
link.  Did I miss something?  The documentation is not much help.

The many questions are:

Have anyone ever tried to use PC-NFS SLIP and Windows 3.1?

Is SLIP and modems only work in DOS level?

Is PPP support in PC-NFS's future plan?

When I just use a null modem cable to establish a direct connect SLIP,
everything works fine. I can enter Windows with no problem.

Thanks.

Tin Li

Nationale Library of Medicine, NIH

li@nlm.nih.gov


-----------[000280][next][prev][last][first]----------------------------------------------------
Date:      Fri, 21 May 1993 20:03:36 GMT
From:      vjs@rhyolite.wpd.sgi.com (Vernon Schryver)
To:        comp.protocols.tcp-ip
Subject:   Re: Info on high-speed transport protocols requested

In article <1tijg0$dgo@mail.fwi.uva.nl>, casper@fwi.uva.nl (Casper H.S. Dik) writes: > > We never had any problem getting 1000KB/s on Suns. Of course, > if the customers had a pretty busy ethernet or pretty obsolete > Sun hardware, it would not have been possible. > Ans what tests did they use? The default TCP send/recv windows > are small compared to other vendors. > > Also, some Sun hardware is limited to 600KB/s. Anything with > the Intel (ie) ethernet interfaces can't possibly get above > 600KB/s because it's a broken chip. > ... I don't know about Sun ethernet TCP speed in the last few years, but it turns out that a fast pair of machines using by-the-book Ethernet and medium sized (> 20K) TCP windows are limited to about 800KByte/sec, because the Ethernet backoff algorithm gets unfair to losers during saturation. On the other hand, 1100KByte/sec is easy if you either play games with TCP or use "broken", "polite", "slow", "non-standard" or "enhanced" AMD 7990 LANCE's. (Pick the right adjective when talking to AMD, depending on whether you're playing angry customer or happy customer.) This is because the LANCE defers longer than the required 9.6 microseconds, reducing the collision rate, and so the rate at which the TCP receiver gets exponentially backed off into the weeds. Vernon Schryver, vjs@sgi.com  -----------[000281][next][prev][last][first]---------------------------------------------------- Date: Fri, 21 May 1993 22:59:49 GMT From: joey@tessi.com (Joey Pruett) To: comp.protocols.tcp-ip,comp.dcom.lans.ethernet Subject: xyplex xp-cc8-e on tcp?  i've unconvered one of these beasts and have talked with xyplex to learn that they talk some proprietary protocol with a vax. i was wondering if anyone out there had maybe figured out how to use them in a standard tcp/ip environment. i realize this is not a simple task, but maybe someone has done it. any info would be appreciated  -----------[000282][next][prev][last][first]---------------------------------------------------- Date: Sat, 22 May 1993 00:23:17 GMT From: rstevens@noao.edu (W. Richard Stevens) To: comp.protocols.tcp-ip Subject: Re: Can't flush a TCP connection  >Since the FIN' bit is buffered right along with the data, I think I >need to send a RESET' some how. I tried setting the linger' option >on the socket to 2 seconds, but it had no effect. > >Can someone advise me how I can kill the connection & flush the >buffers? You can force a reset by setting the SO_LINGER option with l_onoff set to 1, and l_linger set to 0. The next close() sends the RST. Rich Stevens (rstevens@noao.edu)  -----------[000283][next][prev][last][first]---------------------------------------------------- Date: 22 May 93 02:50:55 GMT From: herlock@lclark.edu (Jon Herlocker) To: comp.protocols.tcp-ip Subject: FAQ?  Could someone send me or direct me to a FAQ for this group? Thanks! Jon -- Jon Herlocker email: herlock@lclark.edu Lewis & Clark College Portland, OR 97219  -----------[000284][next][prev][last][first]---------------------------------------------------- Date: 22 May 93 10:06:14 GMT From: eb@felix.Sublink.Org (Enrico Badella) To: comp.protocols.tcp-ip.ibmpc,comp.protocols.tcp-ip Subject: Packet driver for AT&T LANPACER T7231  Hello I was wondering if anyone has already written a packet driver for the AT&T LANPACER T7231 and related chips and is willing to share it. Thank you. -- Enrico Badella Internet: eb@felix.sublink.org Soft*Star s.r.l. eb@icnucevx.cnuce.cnr.it Via Camburzano 9 Phone: +39-11-746092 10143 Torino, ITALY Fax: +39-11-746487  -----------[000285][next][prev][last][first]---------------------------------------------------- Date: 22 May 1993 16:57:01 GMT From: sinisa@thphys.irb.hr (Sinisa Novosel) To: comp.protocols.tcp-ip Subject: gethostbyaddr_after_gethostbyname  I have a problem (Interactive(SunSoft) 3.0 Unix): gethostbyaddr() doesnt work if previous call was 'gethostbyname()' ?! h_errno == 1. Named is not running, but nameserver is defined in 'resolv.conf'. RTFM procedure doesnt help, i.e. I cant make my little program to work. Same program work OK under Ultrix. Any advise ? Sinisa -- ----------------------------------------------------------------------------- ! Sinisa Novosel, Institut Rugjer Boskovic, dep. FIZIKA; Croatia,Zagreb ! ! sinisa@thphys.irb.hr ! -----------------------------------------------------------------------------  -----------[000286][next][prev][last][first]---------------------------------------------------- Date: Sat, 22 May 1993 23:16:56 CDT From: <U37127@uicvm.uic.edu> To: comp.protocols.tcp-ip Subject: Info on programming SOCK_RAW type sockets  Sorry if this is not the appropriate group, but here goes. I am looking for information or examples on programming SOCK_RAW type sockets. I have checked the Comer books, but they dont seem to have any concrete details, just vague references. I would appreciate any pointers to books or samples that you can give me. Thank you, Satish Movva Samll Systems Group, Univ. Of Illinois at Chicago  -----------[000287][next][prev][last][first]---------------------------------------------------- Date: Sun, 23 May 1993 00:31:21 GMT From: Ronald M. Hoering <rhoering@uchicago.edu> To: comp.protocols.tcp-ip Subject: TN3270 and HyperCard  Hello, I have what maybe a strange question. Does anyone know of a set of X-commands that would allow HyperCard to access Mainframes via the INBM 3270 terminal protocol? I really only need to read a line at a time and send back an appropriate response. My application is to login and parse out certain bits of data from the text screens. Thanks, Ron ----------------------------------------------------------------- Physics Student: "What the hell is all this math stuff anyway?" Math Student: "How the hell do I know what it is!" Art Student: "Math!?! Why ask why, Bud Dry!"  -----------[000288][next][prev][last][first]---------------------------------------------------- Date: 23 May 93 10:34:55 -0600 From: lynn@vax1.mankato.msus.edu To: comp.protocols.tcp-ip Subject: NOVELL SHARING MODEM?  This posting is for my brother. He does not have access to NEWS. If your mail bounces back, please E-mail your comments to me and I will forward them to him. Thank you. My Address is: lynn@vax1.mankato.msus.edu. Subj: Modem Sharing with NWlite v1.1 I have two computers that I want to share a modem between the two. I currently have Netware LITE v1.1 installed on both machines. The communication package that I am using is QMPRO. QMPRO is made to work with a LAN system but unfortunatly the instructions doesn't say a whole lot about it. Does anyone know if this is possible and what I will need. Responses can be sent to: m9aa@sdstate.sdsumus.edu Thank you. Sam  -----------[000289][next][prev][last][first]---------------------------------------------------- Date: 23 May 93 00:39:32 GMT From: trt@duke.cs.duke.edu (Tom Truscott) To: comp.protocols.tcp-ip Subject: Re: Developing with Sockets and recv  You omitted an important detail: are you using SOCK_STREAM or SOCK_DGRAM? For SOCK_STREAM you can send arbitrary lengths, and it generally behaves just like a pipe(). Since it is a stream, if you send(100) and then send(100) and then recv(150), the recv may return any number of bytes between 1 and 150 inclusive. (This is a source of lots of bugs.) A read of a SOCK_STREAM only removes the bytes you requested, subsequent bytes wait patiently for a a later read. For SOCK_DGRAM you can send only up to sender's SO_SNDBUF (a larger send will be rejected) and up to the receiver's SO_RCVBUF (a larger send will be quietly dropped). You can set those with setsockopt(), and you should make SO_RCVBUF at least 16 bytes larger than the sent message (aka. record) because ... of an implementation botch. (Make RCVBUF size larger than that if you need to hold multiple incoming messages, otherwise some will be quietly dropped.) SOCK_DGRAM messages must be read "atomically": if you got a 1000 byte message and read 600 bytes of it, you get the first 600 bytes and the last 400 are quietly dropped. You can indeed do a MSG_PEEK, or you can just allocate a huge buffer and do a huge read to be safe. Since SOCK_DGRAM is record oriented, you will get at most 1 datagram message per read. Using SOCK_DGRAM can get quite complex. It does not guarantee delivery, nor ordering if you send several messages. Most typically people use SOCK_DGRAM either for non-critical stuff such as that used by rwho and ruptime, or in an RPC mode in which each message is numbered and only one message is "in flight" at a time. That way lost messages can be retransmitted and there is no danger of things getting out of order. Hope that helps, Tom Truscott  -----------[000290][next][prev][last][first]---------------------------------------------------- Date: Sun, 23 May 1993 01:07:51 GMT From: rene@einstein.et.tudelft.nl (Rene Bodenstaff) To: comp.protocols.tcp-ip Subject: ATM  Hi to all you network gurus, I wanted to know something about ATM. Any info or pointers are welcomed. Tnx, Rene. -- ---< Sonic says: "more haste is more speed" >---  -----------[000291][next][prev][last][first]---------------------------------------------------- Date: Sun, 23 May 1993 03:40:12 GMT From: gc@isag1.isa.com (George Colt) To: comp.unix.wizards,comp.protocols.tcp-ip Subject: Re: HELP: Need to implement rarp on SysV.4  Benoit_Grange@gateway.qm.apple.com (Benoit Grange) writes: : How can I implement a rarp daemon that would answer to rarp queries ? : Where can I read rarp paquets arriving to my machine ? And send responses : ? : : My system is a Consensys (or Unixware) SysV.4. : ---- : Benoit Grange Unixware comes with a rarp server. Check out the man page for rarpd. The server code is in /usr/sbin/in.rarpd -- | George Colt ISA, Inc. | | Email : colt@isag1.isa.com Chesapeake, VA. |  -----------[000292][next][prev][last][first]---------------------------------------------------- Date: Sun, 23 May 1993 12:03:13 GMT From: rstevens@noao.edu (W. Richard Stevens) To: comp.protocols.tcp-ip Subject: Re: Info on programming SOCK_RAW type sockets  >I am looking for information or examples on programming SOCK_RAW >type sockets. How about a hint as to what you'd like to do with them? If you want to read ICMP data, take a look at the ping sources (widely available). If you want to write your own IP datagrams, take a look at the traceroute sources. Rich Stevens  -----------[000293][next][prev][last][first]---------------------------------------------------- Date: Sun, 23 May 1993 17:28:12 GMT From: fschotte@risc4.physik.fu-berlin.de (Friedrich-Schotte-6119-1.4.42) To: comp.protocols.tcp-ip Subject: TCP/IP programming library for MacOS ? - Please help me  Is there a network programming library for Think C or MPW C which is source code compatible with the UNIX socket and TCP/IP programming Interface? I don't really need the basic system calls, I would be happy if there exists a library for Remote Procedure Calls which is compatible with the SUN RPC Library. Thank you in advance. Friedrich Schotte Free University of Berlin fschotte@dec1.physik.fu-berlin.de  -----------[000294][next][prev][last][first]---------------------------------------------------- Date: Mon, 24 May 1993 03:39:24 GMT From: seifert@netcom.com (Rich Seifert) To: comp.protocols.tcp-ip,comp.unix.solaris,comp.unix.sys5.r4,comp.protocols.misc Subject: Re: Reliable multi-cast comms - please help  Alistair Scott (akcs@semagl.demon.co.uk) wrote: : We are interseted in any products which sit on-top of : SVR4 UNIX (e.g. SunOS 5.1) which can provide a reliable : LAN based multi-cast messaging service, with flow-control. : We would like to use this from within a multi-threaded : language (Ada in particular). : Does anyone have experience or know of any such products : or packages? It is not directly targeted at running over SunOS, but the IEEE 802.1(e) System Load Protocol is a reliable multicast (data link) protocol with full error and flow control. It was originally designed to allow embedded diskless systems (e.g., bridges or intelligent NICs) to be download from a boot server, but it can be used for any variety of multicast image load problems. It is available from IEEE in NY (like all IEEE standards). -- Rich Seifert Networks and Communications Consulting seifert@netcom.com (408) 996-0922 (408) 996-2860 FAX "... specialists in Local Area Networks and Data Communications systems"  -----------[000295][next][prev][last][first]---------------------------------------------------- Date: Mon, 24 May 1993 08:49:15 CDT From: <U37127@uicvm.uic.edu> To: comp.protocols.tcp-ip Subject: Re: Info on programming SOCK_RAW type sockets  In article <1993May23.120313.3330@noao.edu>, rstevens@noao.edu (W. Richard Stevens) says: > >>I am looking for information or examples on programming SOCK_RAW >>type sockets. > >How about a hint as to what you'd like to do with them? If you want >to read ICMP data, take a look at the ping sources (widely available). >If you want to write your own IP datagrams, take a look at the >traceroute sources. Thank you! Yep, I wanted to see how to write my own IP datagrams. The traceroute sources were great, but is there a more definitive treatment of raw sockets available in a book form perhaps? Thanks again, Satish Movva Univ. Of Illinois at Chicago > > Rich Stevens  -----------[000296][next][prev][last][first]---------------------------------------------------- Date: Mon, 24 May 1993 06:19:12 GMT From: wselig@teal.csn.org (William John Selig) To: comp.protocols.tcp-ip Subject: looking for reference for installing SLIP  Can anyone point me to a reference for installing SLIP (preferably on a sun, but at this point I'ld take any info). I'm having trouble installing this on a Sun4m and don't even know enough about how it's supposed to work to check for how close I'm getting. Thanks in advance, --bill wselig@csn.org  -----------[000297][next][prev][last][first]---------------------------------------------------- Date: Mon, 24 May 1993 09:26:48 +0000 From: proyse@peeras.demon.co.uk (Phil Royse) To: comp.protocols.tcp-ip Subject: Re: Class C Addresses & subnet masks  In article <C7CDM2.In3@jti.com> richb@jti.com writes: >>We have only been allocated a Clump-o-Cs, and have planned on paper >>an address structure which makes heavy use of subnetting: > >A little over a year ago I posted to this newsgroup with the same >problem: a site about to buy a bunch of routers and link 20 field >offices onto the net, which had 10 Class C addresses. > >The feedback I got here was unanimous: you'll regret subnetting your >Class C networks like that. Not all _client_ IP implementations support >this. > >Have Class B's already gotten hard to come by? > >-rich Yes, very much so. This solution of subnetting Class Cs has been forced upon us by the Internet. PIPEX, the UK Registration Authority has rejected the client's application for a Class B. The routers we have chosen are Cisco MGS (at the 7 main offices) and many 3000's at the smaller offices. When you mentioned "client IP implementations" above, did you mean the routers? or the UNIX hosts & PCs etc which will be the main user machines? The formal tender documents I wrote and the supplier responded to includes categorical statements that the routers will all subnet down to the last two bits of the fourth octet. Ie. the allowable subnet masks are: 255.255.255.192 ...224 ...240 ...248 and ... 252 Is this sensible? Are there anyt other issues which might give us some problems?? (eg. problems on the host IP capability?) TIA Phil -- Phil Royse Comms Consultant | member: The Peer Association TUDOR HOUSE | (networking & OSI specialists) 12 Woodside Road, Purley Surrey CR8 4LN (UK) Tel: (+44) 81 645-9868  -----------[000298][next][prev][last][first]---------------------------------------------------- Date: Mon, 24 May 93 10:46:44 GMT From: chris@comtech.ct.oz.au (Chris Martin ) To: comp.protocols.tcp-ip Subject: Reserved IP addresses (128.0.X.X) etc  I have just discovered that the address range 128.0.X.X is reserved. I have no idea why this address range is reserved. Can any one enlighten us. Some others that we have come up with are 191.255.X.X and 192.0.0.X Cheers Chris Martin chris@comtech.ct.oz.au  -----------[000299][next][prev][last][first]---------------------------------------------------- Date: Mon, 24 May 93 12:08:13 GMT From: smiles@NMC.ED.RAY.COM (Kevin Ruddy) To: comp.protocols.tcp-ip,comp.dcom.lans.ethernet Subject: Re: xyplex xp-cc8-e on tcp?  In article <1993May21.225949.19760@tessi.com> joey@tessi.com (Joey Pruett) writes: >i've unconvered one of these beasts and have talked with >xyplex to learn that they talk some proprietary protocol >with a vax. i was wondering if anyone out there had maybe >figured out how to use them in a standard tcp/ip environment. >i realize this is not a simple task, but maybe someone has >done it. any info would be appreciated Xyplex CC8Es support IP. However, the CC8Es themselves are no longer supported by Xyplex. The VMS-based code is no supported beyond VMS 5.4 I believe, but I can't recall. You have to load them from a VMS-based host, unless you are intending to reverse engineer the Xyplex proprietary protocol and reimplement it on some other box. Talk to Xyplex for official answers -- (800) HELP-XYP. -- Kevin.Ruddy@NMC.ED.RAY.COM  -----------[000300][next][prev][last][first]---------------------------------------------------- Date: Mon, 24 May 1993 12:21:10 GMT From: joe@cm.nctu.edu.tw () To: comp.protocols.tcp-ip Subject: about pcip  Hi... I have some problems about pcip: 1):: I want to trace the source code,but I find that I have no document files.Where can I get these document files?? 2):: As I use MSC to compile it,I find that it can't succeed.I doubt the makefile or my compiler has problem .(I use MSC 6.0 to compile but use MSC4.0 make program) Thanks !!!!!!!!  -----------[000301][next][prev][last][first]---------------------------------------------------- Date: 24 May 93 19:09:43 MDT From: jrd@cc.usu.edu (Joe Doupnik) To: comp.protocols.tcp-ip Subject: Re: about pcip  In article <C7J6BA.6LM@csie.nctu.edu.tw>, joe@cm.nctu.edu.tw () writes: > Hi... > I have some problems about pcip: > > 1):: I want to trace the source code,but I find that I have no document > files.Where can I get these document files?? > > > 2):: As I use MSC to compile it,I find that it can't succeed.I doubt the > makefile or my compiler has problem .(I use MSC 6.0 to compile but use MSC4.0 > make program) > > Thanks !!!!!!!! -------- "The whole thing", docs and all, are on netlab1.usu.edu cd pub/netwatch and netlab.usu.edu cd [.netwatch]. Read the read.me file for navigation information. Joe D.  -----------[000302][next][prev][last][first]---------------------------------------------------- Date: Mon, 24 May 93 13:32:10 GMT From: philippe@gull.world (Philippe Waroquiers) To: comp.protocols.tcp-ip Subject: non-blocking mode! and then?  Dear netters, If you know TCP-IP and the socket interface, then perhaps you know the answers to the following 2 questions : I am using the socket BSD interface in non blocking mode. This works ok but in some cases, I do not see how I can determine the state of the socket. Question 1 (after a select for "connect"): ------------------------------------------ a socket is created then set it in non blocking mode using fcntl(2) and the flag O_NONBLOCK. I then use the connect(2) system call. The manual of connect(2) indicates then that select(2) can be used to determine if the connect is succesful by selecting for writing. If no process is listening, the select call also terminates and does not indicate an error. Question is : in such a case, how do I see if the socket is connected? Question 2 (after a select for "read"): --------------------------------------- when a socket is selected for read, the select returns when the socket is ready for reading. Then some data can be read. When the remote process closes the socket or dies, the socket is always selectable for read but no data can be received (read returns 0 bytes but does not return an error). Question is : in such a case, how do I determine that the connection is not valid anymore ? (note : I do not want to write on the socket to see it the socket is still valid). Thank you for your help. -- Philippe WAROQUIERS Eurocontrol - Central Flow Management Unit philippe@cfmu.eurocontrol.be Avenue des Arts 19H Tel: +32 2 729 33 67 B-1040 BRUSSELS Fax: +32 2 729 32 16 Belgium  -----------[000303][next][prev][last][first]---------------------------------------------------- Date: Mon, 24 May 1993 17:06:39 +0000 From: steve@svlpw.demon.co.uk (Steven Pearce) To: comp.protocols.tcp-ip Subject: Software production  -- Steven Pearce  -----------[000304][next][prev][last][first]---------------------------------------------------- Date: 24 May 1993 17:48:48 GMT From: whalenm@tsg.com (Matthew Whalen) To: comp.protocols.tcp-ip Subject: TCP/IP tunnel over AppleTalk  I realize that this thought may make some cringe, but I am looking for some software (preferable PD) that will let me tunnel TCP/IP traffic over an AppleTalk WAN. Anyone have some suggestions? thanks -matthew ____ whalenm@tsg.com \ / equal rights, not special rights (NeXTMail OK) \/ (My actions/words in no way reflect those of my employer.)  -----------[000305][next][prev][last][first]---------------------------------------------------- Date: Mon, 24 May 1993 18:13:12 GMT From: grmensz@grmensz.erenj.com (Gary R. Menszyk) To: comp.protocols.tcp-ip Subject: Re: TN3270 and HyperCard  In article <1993May23.003121.28201@midway.uchicago.edu>, Ronald M. Hoering <rhoering@uchicago.edu> wrote: > > Hello, > > I have what maybe a strange question. > > Does anyone know of a set of X-commands that would allow HyperCard to > access Mainframes via the INBM 3270 terminal protocol? > > I really only need to read a line at a time and send back an appropriate > response. My application is to login and parse out certain bits of data > from the text screens. > > Thanks, > > Ron > > ----------------------------------------------------------------- > Physics Student: "What the hell is all this math stuff anyway?" > Math Student: "How the hell do I know what it is!" > Art Student: "Math!?! Why ask why, Bud Dry!" I assume you are aware of the fact that the 2.3d26+ release of tn3270 from Brown University has an API which lets other applications use it to communicate with a mainframe via PPC or their own inter-program communications. Don't know if these are in the form of X-cmds, but this should be fairly easy to do using PPC support in the current release of HyperCard (easy for me to say since I have never built an X-cmd or used the PPC toolbox). Gary R. Menszyk Exxon Research & Engineering Co. grmensz@erenj.com  -----------[000306][next][prev][last][first]---------------------------------------------------- Date: Mon, 24 May 1993 18:27:52 GMT From: "David Herron" <david@twg.com> To: comp.sys.sun.admin,comp.protocols.tcp-ip Subject: Weirdo IP routing problem  Have I got a weird problem! Summary: Have a local ethernet at home with a couple machines. Am setting up SLIP to The Internet. When the SLIP line is up, and a default route is installed, none of the local machines are reachable. My system: (davids.mmdf.com) SPARC II, SunOS 4.1.2 (no kernel level patches), using either CSLIP v2.6 or MorningStar PPP (in SLIP mode) v1.4beta. Remote: (crl.com) Sun 4/4xx, SunOS 4.1.2, probably using CSLIP v2.6. The network looks like: samson.mmdf.com termy.mmdf.com steves.mmdf.com | davids.mmdf.com | ----+---------------+----+---+------------+-- House network (224.42.25.0) | | 192.215.1.18:192.215.1.13 | -------+-------------- CRL 192.215.1.0 Looks real simple, right? When the system boots I configure a network route (224.42.25.0) and default route (pointing to 224.42.25.1 with metric 0). Then when SLIP comes up, a point-point route is set up for the above addresses, and a different default route to 192.215.1.13 with metric 1. In other words: Then after shutting down the SLIP (which undoes the default route): | 36 - davids.mmdf.com:david --> netstat -in Name Mtu Net/Dest Address Ipkts Ierrs Opkts Oerrs Collis Queue le0 1500 224.42.25.0 224.42.25.1 7673 0 6476 0 0 0 lo0 1536 127.0.0.0 127.0.0.1 1163 0 1163 0 0 0 | 37 - davids.mmdf.com:david --> ifconfig le0 le0: flags=63<UP,BROADCAST,NOTRAILERS,RUNNING> inet 224.42.25.1 netmask ffffff00 broadcast 224.42.25.255 | 38 - davids.mmdf.com:david --> ifconfig lo0 lo0: flags=49<UP,LOOPBACK,RUNNING> inet 127.0.0.1 netmask ff000000 | 39 - davids.mmdf.com:david --> ifconfig sl0 sl0: flags=2010<POINTOPOINT,LINK1> inet 192.215.1.18 --> 192.215.1.13 netmask ffffff00 | 40 - davids.mmdf.com:david --> arp -a steves.mmdf.com (224.42.25.2) at 0:0:c0:7a:87:29 permanent published termy.mmdf.com (224.42.25.3) at 0:80:96:0:7:2e | 41 - davids.mmdf.com:david --> davids.mmdf.com# ping -s termy PING termy.mmdf.com: 56 data bytes 64 bytes from termy.mmdf.com (224.42.25.3): icmp_seq=0. time=8. ms 64 bytes from termy.mmdf.com (224.42.25.3): icmp_seq=1. time=2. ms 64 bytes from termy.mmdf.com (224.42.25.3): icmp_seq=2. time=2. ms ^C ----termy.mmdf.com PING Statistics---- 3 packets transmitted, 3 packets received, 0% packet loss round-trip (ms) min/avg/max = 2/4/8 The routing configuration while CSLIP'd to CRL: | 29 - davids.mmdf.com:david --> netstat -rn Routing tables Destination Gateway Flags Refcnt Use Interface 127.0.0.1 127.0.0.1 UH 2 798 lo0 192.215.1.13 192.215.1.18 UH 0 5 sl0 default 192.215.1.13 UG 1 171 sl0 224.42.25.0 224.42.25.1 U 6 4732 le0 | 30 - davids.mmdf.com:david --> netstat -in Name Mtu Net/Dest Address Ipkts Ierrs Opkts Oerrs Collis Queue le0 1500 224.42.25.0 224.42.25.1 5743 0 4542 0 0 0 sl0 552 192.215.1.13 192.215.1.18 50 0 176 0 0 0 lo0 1536 127.0.0.0 127.0.0.1 970 0 970 0 0 0 | 31 - davids.mmdf.com:david --> ifconfig le0 le0: flags=63<UP,BROADCAST,NOTRAILERS,RUNNING> inet 224.42.25.1 netmask ffffff00 broadcast 224.42.25.255 | 32 - davids.mmdf.com:david --> ifconfig lo0 lo0: flags=49<UP,LOOPBACK,RUNNING> inet 127.0.0.1 netmask ff000000 | 33 - davids.mmdf.com:david --> ifconfig sl0 sl0: flags=2051<UP,POINTOPOINT,RUNNING,LINK1> inet 192.215.1.18 --> 192.215.1.13 netmask ffffff00 | 34 - davids.mmdf.com:david --> arp -a steves.mmdf.com (224.42.25.2) at 0:0:c0:7a:87:29 permanent published termy.mmdf.com (224.42.25.3) at 0:80:96:0:7:2e And attempts to reach a local host then: PING steves.mmdf.com: 56 data bytes ^C ----steves.mmdf.com PING Statistics---- 71 packets transmitted, 0 packets received, 100% packet loss davids.mmdf.com# !! ping -s steves PING steves.mmdf.com: 56 data bytes ^C ----steves.mmdf.com PING Statistics---- 476 packets transmitted, 0 packets received, 100% packet loss I've had a couple different people, all experienced with configuring IP routing, double check me here. We all agree it looks right. So ... any ideas? The netmasks are right, and there is a route (metric 0) for the local network. The two machines even have arp entries ... Yet during that ping just above, I could see the send/receive lights flickering at the same rate as a ping. Further, since MorningStar put in such excellent logging, you can see from there that the packets for the local net are going out the SLIP line. Do I need to provide more information? I tried to be complete ... Is there anything I should try? I tried to try everything ... Please... if you respond by mail, send to david@twg.com or david@davids.mmdf.com. Thank you, David Herron  -----------[000307][next][prev][last][first]---------------------------------------------------- Date: Mon, 24 May 1993 19:06:24 +0000 From: steve@svlpw.demon.co.uk (Steven Pearce) To: comp.protocols.tcp-ip Subject: Software production  **********************Analyst/Programmers********************************* *************************for hire***************************************** Do you have any requirements in the following areas? C C++ Unix Motif OSI X400 TCP-IP If not then read no further. If you do then consider the following. We have a SCO Unix based development system, a link to the Internet for E-mail and expertise in all of the above. We can supply quality software at very competitive prices. All software will be supplied on a trial basis and we will provide free quotations. Anything tackled, from bespoke packages to maintenance, from large applications to small programs and scripts. Interested? Contact Steve Pearce or Vivienne Walker in one of the following ways. E-mail steve@svlpw.demon.co.uk Phone UK 0602 463106  -----------[000308][next][prev][last][first]---------------------------------------------------- Date: Mon, 24 May 1993 20:55:40 +0000 From: mark@kram.org (Mark Turner) To: comp.protocols.tcp-ip Subject: Ever increasing RTT!  One of our connected sites is experiencing a wierd problem. He dials into our gateway using Morningstar PPP on a SCO ODT machine. Our gateway runs MST PPP on SCO. Every time he logs in and either of us pings the other we see an ever increasing RTT! I do not believe that MST is causing the problem as I remember seeing a similar problem between 2 machines on our ethernet a while ago. We have dozens of sites dialing into the same machine in the same way with no problems and I can't find any obvious difference with the affected site. Can anyone give me any clues where I should look? Regards, Mark. -- /\/\ark Turner Demon Systems / Demon Internet Home: mt@kram.org (PGP key available) 42 Hendon Lane, London Office: mark@demon.co.uk (+44 81 3490063) N3 1TT, England *** IP level dialup Internet connectivity for a tenner a month! ***  -----------[000309][next][prev][last][first]---------------------------------------------------- Date: 24 May 93 21:03:30 GMT From: wew@nuxi.ucc.nau.edu (Bill Wilson) To: comp.protocols.tcp-ip Subject: Public NFS for Mac?  Is there a public nfs for the Mac that runs with Mactcp? We would also like rmt and tar is there is. -- Let sleeping dragons lie........ | The RoleMancer -------------------------------------------------------------------- William Wilson (wew@naucse.cse.nau.edu | wilson@nauvax) Northern AZ Univ Flagstaff, AZ 86011 -- Let sleeping dragons lie........ | The RoleMancer -------------------------------------------------------------------- William Wilson (wew@naucse.cse.nau.edu | wilson@nauvax) Northern AZ Univ Flagstaff, AZ 86011  -----------[000310][next][prev][last][first]---------------------------------------------------- Date: 24 May 1993 23:13:47 GMT From: tli@cisco.com (Tony Li) To: comp.protocols.tcp-ip Subject: Re: Reserved IP addresses (128.0.X.X) etc  In article <1993May24.104644.21289@comtech.ct.oz.au> chris@comtech.ct.oz.au (Chris Martin ) writes: I have just discovered that the address range 128.0.X.X is reserved. I have no idea why this address range is reserved. Can any one enlighten us. Some others that we have come up with are 191.255.X.X and 192.0.0.X These were reserved because they are the corner cases in the Class system, and would likely lead to confusion. For example, is 191.255.255.255 a broadcast to all Class B networks? ;-) Tony  -----------[000311][next][prev][last][first]---------------------------------------------------- Date: Tue, 25 May 93 01:07:22 GMT From: jbell@pdev.ga.oz.au (John Bell) To: comp.protocols.tcp-ip Subject: Newbie TCP/IP Programming Problem  Hi all, I'm fairly new to TCP/IP programming (I've only read about 1/3 of the Stevens book) and need some help with a project that has landed on my desk. A customer of mine has a Unisys host running Burroughs Poll/Select which is connected to a Sun. The Sun has a Hardware/Software package that allows anyone with a vt220 terminal to engage in an interactive session with Unisys apps. They want to purchase a 486 server running Advanced Pick (a database product) under SCO Unix. This will be connected to the Sun via E-net. The AP application needs to call a C subroutine which will log into the Unisys host, make a query, massage the return screen output and return it to the AP application as a formatted string. It seems to me that I have to open a pty pair on the SCO host, bind it to the Sun IP address and perhaps talk to its' telnet port. Am I going in the right direction or barking up the wrong tree? Can anybody give me some idea of how to code this? *NOTE* My MX record is not yet in place, so if you want to reply by Mail rather than using the newsgroup please send to ronny@mhs.oz.au who will forward your response to me. Thanks in advance John Bell jbell@pdev.ga.oz.au +61-3-522-2211  -----------[000312][next][prev][last][first]---------------------------------------------------- Date: 25 May 93 02:24:25 GMT From: trt@duke.cs.duke.edu (Tom Truscott) To: comp.protocols.tcp-ip Subject: Re: non-blocking mode! and then?  >Question is : in such a case, how do I see if the socket is connected? If getpeername() succeeds, the socket is connected. >When the remote process closes the socket or dies, ... >Question is : in such a case, how do I determine that the connection is >not valid anymore ? (note : I do not want to write on the socket to see >it the socket is still valid). Hmm, "not valid" is a bit fuzzy. A read (of non-zero amount) that returns 0 indicates you will never get any more data from the socket. But you can still write to the socket if getpeername() succeeds and your program has not called shutdown(WRITE) and there is room left in the socket send buffer. Fuzzy enough? (Alas, the socket API is a bit odd.) Tom Truscott  -----------[000313][next][prev][last][first]---------------------------------------------------- Date: Tue, 25 May 1993 03:58:29 GMT From: a866700@hp9000.csc.cuhk.hk (Wong Siu To) To: comp.protocols.tcp-ip Subject: FTP: Use PD version or write one ?  Hi there, I apologize if this's a FAQ, and if this group is not the right place to ask... I'd like to know if there's 'configurable' ftp software available on the net. We're going to set up an anonymous ftp server soon and want to have some features to keep track of the usage, e.g. - number of active ftp connections - file size limit in file upload/download - user information (hostname/IP address, session duration, files accessed, etc.) - customized messages to be displayed - etc. We're also considering to write one to fit our requirement if we've sufficient time ... :-( Would anyone please advise ? Thanks in advance. Regards, -- S.T. Wong | BITNET: A866700@CUCSC.BITNET Computer Services Centre | Internet: st-wong@cuhk.hk The Chinese University of Hong Kong | Tel. No: (852) 609 8825 Shatin, N.T., Hong Kong | FAX No: (852) 603 5001  -----------[000314][next][prev][last][first]---------------------------------------------------- Date: 24 May 1993 16:54:04 +0800 From: dinesh@mail-server.bass.my (Dinesh Arnold Nair) To: comp.protocols.tcp-ip Subject: Re: looking for reference for installing SLIP  In article <wselig.738224352@teal> wselig@teal.csn.org (William John Selig) writes: >Can anyone point me to a reference for installing SLIP (preferably on a sun, >but at this point I'ld take any info). I'm having trouble installing this on >a Sun4m and don't even know enough about how it's supposed to work to check >for how close I'm getting. > >Thanks in advance, >--bill wselig@csn.org > /\_/\ "All dogs go to heaven." (0 0) +==========================----oOO--(_)--OOo----============================+ | Dinesh Nair (dinesh@bass.my) / Surface Address : | | Software Engineer \ 8th Floor, Menara SMI, | | Technical Services Group / 6 Lrg P Ramlee, 50250 Kuala Lumpur | | Bass Consulting \ Malaysia. Tel : 03-2305588 | +===========================================================================+  -----------[000315][next][prev][last][first]---------------------------------------------------- Date: Tue, 25 May 1993 13:26:34 GMT From: ramon@cantabria.cber.nih.gov (Ramon J. Hontanon) To: comp.protocols.tcp-ip.ibmpc,comp.protocols.tcp-ip Subject: DECnet & TCP/IP. Can they co-exist???  Hello all, We have the need to do FTP file transfer from/to a PC that is currently running a DECnet client in an all-DECnet ethernet. My question is: - Will we need to reboot the machine to load the TCP/IP drivers after having run DECnet for awhile? - Will we need to edit any config files before starting the FTP transfer? - How well do TCP/IP and DECnet packets coexist on the same ethernet? (the network admin was hesitant about allowing us to do this) We'd appreciate any comments/experiences, as well as advice as to what TCP/IP package to install. (All we need is FTP, no Telnet, SMTP, etc.) Best regards, Ramon -- ___________________________________________________________________ Ramon J. Hontanon, KE8SF ramon@helix.nih.gov CBER FDA, 8800 Rockville Pk. Bethesda, MD 20892 (301) 496 0718  -----------[000316][next][prev][last][first]---------------------------------------------------- Date: Tue, 25 May 93 15:07:15 GMT From: horn@schaefer.math.wisc.edu (Jeffrey Horn) To: comp.protocols.tcp-ip,comp.protocols.tcp-ip.pc Subject: SLIP Recommendations  I was wondering if anyone could tell me about some good SLIP implementations. I am trying to connect remote PC's to a central Sun 690. The connections will not be up 24 hours/day, but rather about 4-6 hours/day. Could anyone help me as to reasonable modem and phone line specs as well? Is there any software or hardware that can manage several slip connection through a single serial line? Thanks for your help!!! Jeffrey Horn  -----------[000317][next][prev][last][first]---------------------------------------------------- Date: Tue, 25 May 1993 15:49:32 GMT From: drubin@poly.edu (Dave Rubin) To: comp.sys.sun.admin,comp.protocols.tcp-ip Subject: Synchronous serial line IP on a SUN?  Is there a way to use a synchronous serial connection as an IP link (e.g., PPP) between two SUN SPARCstation 2 machines (i.e., without the need for a sync to async converter)? Thanks... please respond via E-mail. -- Dave Rubin Polytechnic University drubin@poly.edu  -----------[000318][next][prev][last][first]---------------------------------------------------- Date: Tue, 25 May 93 16:16:02 GMT From: oberman@ptavv.llnl.gov To: comp.protocols.tcp-ip Subject: RE: MacTCP 1.1.1 and DNS...  In Article <1993May20.184813.2879@wixer.bga.com> pug@wixer.bga.com (Pug) writes: > We have an ethernet network with a lot of Mac's on it. We have MacTCP >1.1.1 running on them and generally use NCSA Telnet 2.5. This is >happening on all of our Macs so I don't think it's System dependant. >What the problem is is this - When using MacTCP and having more then one >server per domain, which is rather standard to have a primary and >secondary server incase the primary is down, if the primary *is* down, >it will not use the secondary for the domain. You have to change the >default setting and then reboot. Well this is not an acceptable >solution. It will go on to any server under another domain name though. >The reason that we need a solution is our primary server is moving and >we want people to still be able to access other computers when it does. No one else has answered, so I'll throw in my un-informed 2 bits. The way to configure DNS is weird and totally undocumented (by Apple). The first entry (or, at least the one marked DEFAULT should be the local domain name and the address of the primary: bga.com 198.3.116.3 * Then configure your secondaries as: 198.3.116.3 137.39.1.3 and so on. Yes, this is weird, but so is MacTCP. (Please note that the primary is listed twice, once for the local domain and once for root. This does not really mean that either the primary or the secondary is a root server. It means that requests for address in any domain under the root should go there. If you really want to keep all of your requests going to on system, list it first after the local domain. If you want to split the load , list them in reverse order. R. Kevin Oberman Lawrence Livermore National Laboratory Internet: koberman@llnl.gov (510) 422-6955 Disclaimer: Being a know-it-all isn't easy. It's especially tough when you don't know that much. But I'll keep trying. (Both)  -----------[000319][next][prev][last][first]---------------------------------------------------- Date: Tue, 25 May 93 16:22:25 GMT From: oberman@ptavv.llnl.gov To: comp.protocols.tcp-ip Subject: RE: DECnet & TCP/IP. Can they co-exist???  In Article <1993May25.092634@cantabria.cber.nih.gov> ramon@cantabria.cber.nih.gov (Ramon J. Hontanon) writes: >Hello all, > >We have the need to do FTP file transfer from/to a PC that is currently > running a DECnet client in an all-DECnet ethernet. My question is: > >- Will we need to reboot the machine to load the TCP/IP drivers after > having run DECnet for awhile? Shouldn't need to. (I can't speak for all packages, but those using NDIS drivers (or any properly written ones) should have no trouble talking both. CAVEAT!!! Because DECnet will rewrite the physical address of the Ethernet, it MUST start before IP. >- Will we need to edit any config files before starting the FTP transfer? Shouldn't need to. The protocols are totally indepentdent and have no reason to know that the other exists. >- How well do TCP/IP and DECnet packets coexist on the same ethernet? > (the network admin was hesitant about allowing us to do this) Just fine. I have about 1000 DECnet and 5000 IP nodes on my Ethernet (routed) and about 50 DECnet and 300 IP on the local net. All of it works just fine. Ethernet was designed to support this operation. R. Kevin Oberman Lawrence Livermore National Laboratory Internet: koberman@llnl.gov (510) 422-6955 Disclaimer: Being a know-it-all isn't easy. It's especially tough when you don't know that much. But I'll keep trying. (Both)  -----------[000320][next][prev][last][first]---------------------------------------------------- Date: 25 May 93 16:35:51 GMT From: jordan@IMSI.COM (Jordan Hayes) To: comp.protocols.tcp-ip Subject: Re: non-blocking mode! and then?  Philippe Waroquiers <philippe@gull.world> writes: [ non-blocking connect(), select for write ... ] in such a case, how do I see if the socket is connected? (this is under UNIX) If connect() returns EINPROGRESS, you can select() for write. When it returns, you need to check out what happened. I just call connect() again. If it worked, connect() will return -1 and set errno to EISCONN; if the connect() failed, the socket will be trashed by now (so connect() will set errno to EINVAL, since the socket is no longer valid), but there's a socket option to retrieve the reason it failed in the first place, so you can retrieve it and slam that reason into errno for reporting to the user ... Here's some code: int fd, i, len; struct sockaddr_in local; extern int errno; /* try to connect again */ bzero((char *)&local, sizeof(local)); len = sizeof(local); if (connect(fd, (struct sockaddr *)&local, len) < 0) switch (errno) { case EISCONN: /* worked! */ break; case EINVAL: len = sizeof(i); if (getsockopt(fd, SOL_SOCKET, SO_ERROR, (char *)&i, &len) < 0) Warn("%t getsockopt(%d, SO_ERROR): %m", fd); else errno = i; /*FALLTHROUGH*/ default: Warn("%t connect(%d): %m", fd); (void)close(fd); /* other cleanup */ return; } /jordan  -----------[000321][next][prev][last][first]---------------------------------------------------- Date: 25 May 1993 17:51:46 GMT From: raghu@ecst.csuchico.edu (Raghu Madhok) To: comp.protocols.tcp-ip Subject: MTU for ethernet  I would like to send UDP datagrams between two machines as quick as possible. To avoid segmentation at any of the protocol layers, I need to know the Maximum Transmission Unit (MTU) for ethernet, and the size of the UDP, IP, and ethernet headers appended to each packet. This will give me the maximum number of bytes of data I can squeeze into each (datagram) packet. If it makes a difference, I am doing this between two Sun SparcStations currently running 4.1.2. Any help on this subject would be appreciated. Please send replies to my e-mail address. ...Raghu raghu@ecst.csuchico.edu  -----------[000322][next][prev][last][first]---------------------------------------------------- Date: 25 May 1993 18:05:20 GMT From: trier@odin.ins.cwru.edu (Stephen C. Trier) To: comp.sys.mac.programmer,comp.sys.mac.apps,comp.sys.mac.comm,comp.protocols.tcp-ip,comp.protocols.tcp-ip.domains Subject: Re: MacTCP 1.1.1 and DNS...  MacTCP's domain name server setup is braindead. The "domain" asssociated with each server restricts the queries that will be sent to that server. To make things worse, the domain associated with the first server in the list is used as the Mac's domain. It seems whoever designed this was rather unfamiliar with how DNS usually works. The workaround is to list the first server twice. Set up your configuration like this: <server 1> .macs.domain.name <server 2> . <server 1> . The "." means "this server can handle queries for all domains". You have to list a real domain the first time in order to let the Mac know its domain, then you need to list both servers with the "." wildcard so that you have fallback from one to another. I've redirected followups to only comp.protocols.tcp-ip. Please don't cross-post as widely as you did. ONE group is sufficient. Pick the best and use it. -- Stephen Trier (trier@ins.cwru.edu - MIME OK) Network Software Engineer IRIS/INS/T Case Western Reserve University  -----------[000323][next][prev][last][first]---------------------------------------------------- Date: Tue, 25 May 1993 18:18:05 GMT From: vjs@rhyolite.wpd.sgi.com (Vernon Schryver) To: comp.protocols.tcp-ip Subject: Re: DECnet & TCP/IP. Can they co-exist???  In article <1tth3o$iak@lll-winken.llnl.gov>, oberman@ptavv.llnl.gov writes:
> >- Will we need to reboot the machine to load the TCP/IP drivers after
> >    having run DECnet for awhile?
>
> Shouldn't need to. (I can't speak for all packages, but those using NDIS
> drivers (or any properly written ones) should have no trouble talking both.
>
> CAVEAT!!! Because DECnet will rewrite the physical address of the Ethernet, it
> MUST start before IP.
> ...

That depends on the system.  A system can (and some do) repeat the ARP
announcement of the IP-Ethernet mapping when DECnet is started and
changes the mapping.  On some such systems it is practically impossible
and fortunately unnecessary to start DECnet before IP.

Vernon Schryver,  vjs@sgi.com


-----------[000324][next][prev][last][first]----------------------------------------------------
Date:      25 May 93 18:47:09 GMT
From:      henry@ice03.uts.amdahl.com (Henry Cho)
To:        comp.protocols.tcp-ip
Subject:   Re: SLIP Recommendations

In article <1993May25.150715.16807@schaefer.math.wisc.edu>, horn@schaefer.math.wisc.edu (Jeffrey Horn) writes:
|> I was wondering if anyone could tell me about some good SLIP
|> implementations.  I am trying to connect remote PC's to a central
|> Sun 690.  The connections will not be up 24 hours/day, but rather
|>
|> Could anyone help me as to reasonable modem and phone line specs
|> as well?  Is there any software or hardware that can manage several
|> slip connection through a single serial line?
|>
|>
|> Jeffrey Horn

I suggest you invest in a Xyplex TCP/IP terminal server.  It is capable of
routing incoming SLIP packet to TCP/IP packet.  So what you need is to
connect a few 9600 baud modems to the terminal connector and connect the
etherport to you Sun 690 and up you running.  By the way SLIP are
point-to-point connection, it run on a single serial and cannot be share by
multiple SLIPs, unlike PPP which allow other application to share the serial
port.  What you need is a few rotary phone line connect the those modem which
in turn connect to the terminal server on the terminal side so that who ever
dial in can be automatically connect to a free terminal port using the same
phone number.


-----------[000325][next][prev][last][first]----------------------------------------------------
Date:      25 May 93 18:48:11 GMT
To:        comp.protocols.tcp-ip,comp.protocols.ppp
Subject:   PPP Patch Level 6 problem

Hi,

I am having a small problem trying to run the public domain PPP by
Karl Fox. Whenever a remote machine call's my machine and I start up PPP
it says "/dev/cua0: Locked". I am running PPP patch level 6 on a
Sun Sparc IPC (SunOS 4.1.3), my modem is a Miracom V.32 bis Fax (handles
up 14,400 baud). I have no problem calling the remote site (using a
variation on Karl's chat script), so I think my PPP is built and configured
into the kernel O.k. I could not find any lock files anywhere in /var/spool
or /tmp, so I am wondering whether my getty when it answers the phone is
locking the modem device.

Does anybody have any idea what I'm doing wrong ? Any help much
appreciated.

Regards,
A. Mahmood
Edinburgh


-----------[000326][next][prev][last][first]----------------------------------------------------
Date:      25 May 93 18:54:53 GMT
From:      don@lclark.edu (Don Weston)
To:        comp.dcom.sys.cisco,comp.protocols.tcp-ip
Subject:   IP Routing Questions on Subnet Masks and Multicasting


Hello,

I have a series of relatively straight forward IP routing questions which
are primarily focused on creative IP mask construction and multicasting

The scenario is this:  we have a class B Internet address, but the component
class C addresses are spread randomly (by department) across the campus.  In
our Library for example we have 16.0, 20.0, 28.0, and 51.0.  These four
share one logical ethernet segment.  This segment is connected via Cisco
IGS+ to the "backbone" ethernet.

In the case of the Library the four subnets do not show up on the backbone,
but any of the 250 others could.  The backbone has the mask of 255.255.0.0.
This makes it difficult to route between the library and the campus since
the router sees on one port the whole class B address and on the other four
component class C nets which because of the masking appear to live on both
sides of the router.

As a short term fix I told the router that both sides were class C
addresses, and then used Cisco's multicast feature to add more class C
subnets.  This strikes me as inefficient, since it appears the router is in
effect rebroadcasting multiple class C packets when what I want is one
packet which gets to the appropriate places.

After doing some reading it looks like routing would be more efficient if I
reassigned the IP net numbers to be adjacent and created an appropriate net
mask.  This way the netmask would do the work and I would not have to rely
on multicasting.  I assume this is how the Internet folks band together Class C
addresses for institutions who joined the game too late to get a Class B.

Two to four class C addresses together seem to be the appropriate size for a
subnet.  (especially if we get a collapsed backbone router with under ten
ports and end up running large portions of campus on one logical ethernet.)

Our new configuration could look something like this:
(This is off the cuff so I may have botched the mask,
but hopefully the idea comes across.)

149.175.1.0
149.175.2.0
149.175.3.0
149.175.4.0

149.175.5.0
149.175.6.0
149.175.7.0
149.175.8.0

Subnet C: etc...
Further subnetting would be simple under this model.

I understand that most people out there stick with class C addresses, but
these are not quite big enough for what we need to do.  Has anyone
experienced pitfalls with going to a nonstandard netmask?  Does this
particular scheme look right?  Is multicasting really better?
Do the nonstandard netmasks confuse some implementations of IP software such
as MacIP, NCSA Telnet, SunOS, etc?

... ... ... ... ....		Don Weston, Jr.		  .... ... ... ... ...
Network Manager
Lewis & Clark College
... ... ... ... ....		don@lclark.edu		  .... ... ... ... ...


-----------[000327][next][prev][last][first]----------------------------------------------------
Date:      25 May 1993 20:08:03 GMT
From:      tli@cisco.com (Tony Li)
To:        comp.protocols.tcp-ip
Subject:   Re: MTU for ethernet

In article <1ttmbiINNfg8@charnel.ecst.csuchico.edu> raghu@ecst.csuchico.edu
I would like to send UDP datagrams between two machines as quick as
possible.  To avoid segmentation at any of the protocol layers, I
need to know the Maximum Transmission Unit (MTU) for ethernet, and
the size of the UDP, IP, and ethernet headers appended to each packet.
This will give me the maximum number of bytes of data I can squeeze
into each (datagram) packet.

Ethernet can support up to 1500 bytes, including the IP and UDP header, but
excluding the MAC layer.

But a better solution is to use ICMP Path MTU Discovery.

Tony


-----------[000328][next][prev][last][first]----------------------------------------------------
Date:      Tue, 25 May 1993 22:33:26 GMT
From:      alun@huey.wst.com (Alun Jones)
To:        comp.protocols.tcp-ip
Subject:   Re: MacTCP 1.1.1 and DNS...

In article <1ttn50$rje@usenet.INS.CWRU.Edu> trier@odin.ins.cwru.edu (Stephen C. Trier) writes: >MacTCP's domain name server setup is braindead. The "domain" As a PC user who has been branded our company's Internet expert, I've been asked by several Mac users how we can connect them to the Internet. Is Mac TCP the only/best way to do this? All our Macs have ethernet boards, and are talking across the same ethernet branches as our PCs that run packet driver software to get to the internet. I would appreciate guidance as to what software I can get that will allow me to give the people on the Macs the same access to Internet as those of us on PCs. Thanks, Alun. ~~~~  -----------[000329][next][prev][last][first]---------------------------------------------------- Date: Wed, 26 May 1993 06:53:18 GMT From: rob@sybase.com (Rob Cook) To: comp.protocols.tcp-ip Subject: Help with 'discovering' a client end connection died...  I've run into a problem in a few customer environments where a client (PC under DOS/Windows in this case), connected to a server via sockets dies, but the server is never (apparently) notified. The server, if it attempts a write on the socket, will of course be notified that the socket is dead on the client side. My problem is that if the client and server are idle, and *then* the client dies, the server is not aware of the condition, and it keeps the context and associated memory&socket descriptor resources, eventually running out of free ones. I've fiddled w/ linger, keepalive, etc., to no avail. I'd like to provide a 'heartbeat' type of functionality between the client and server so that the 'heartbeat' can detect the client is gone, then notify the server (once I can discover a dead/gone client, I can easily notify my server). Ideally, I'd like to be able to do the equivalent of a 'ping' to the specific client-side port to see if it's still there, without interfering with any of the client/server interaction. It is important that this be transparent to the existing client and server processes (other than the fact that this 'heartbeat' process can notify the server when a dead/gone connection is detected). I've though of trying to open the client address&port after a period of inactivity on the connection, though I'm not sure that would work. I'm sure there is a relatively easy way of doing this, yes? *Any* pointers/hints/help/etc. will be *most* appreciated. Premptive apologies if this is a FAQ item, I'm fresh to this group, and just as fresh to low-level tcp/socket programming. Please reply directly to e-mail below, or call if desired. Regards, Rob rob@sybase.com (510)596-3443  -----------[000330][next][prev][last][first]---------------------------------------------------- Date: Wed, 26 May 1993 11:54:16 +0000 From: proyse@peeras.demon.co.uk (Phil Royse) To: comp.protocols.tcp-ip Subject: Re: Super-TCP  In article <C7Dvpn.AyH@unccsun.uncc.edu> jpb@jpbpc1.uncc.edu writes: >I have just finished Tested the following nine competing products: > PC/TCP from FTP Software > ChameleonNFS from NetManage > Pathway Access from Wollongong > Lan Workspace for DOS from Novell > 3Com TCP from 3Com > Sun PC-NFS from SunSoft V5.0 > IBM TCP/IP V2.1 from IBM > Beam & Whiteside NFS V3.0a from Beam & Whiteside > Super-TCP From Frontier Technologies V3.0 R1 >Super-TCP from Frontier Technologies is the only software that meets all of our > basic requirements. This is very interesting. Please could you give more information and feedback from your tests? How can I contact Frontier Technologies? What is their Internet address? TIA Phil R. -- Phil Royse Comms Consultant | member: The Peer Association TUDOR HOUSE | (networking & OSI specialists) 12 Woodside Road, Purley Surrey CR8 4LN (UK) Tel: (+44) 81 645-9868  -----------[000331][next][prev][last][first]---------------------------------------------------- Date: 26 May 93 13:49:59 GMT From: frankc@teleng.eng.telxon.com (Frank Ciotti) To: comp.protocols.tcp-ip Subject: RFC for keepalives  Is there an RFC for TCP keepalive polls? I could not find any reference to them in the RFC index, RFC 793, RFC 896, or the Comer/Stevens books. Thanks for any help. Frank Ciotti frankc@telxon.com Telxon Corp. Akron, OH  -----------[000332][next][prev][last][first]---------------------------------------------------- Date: Wed, 26 May 1993 15:25:22 GMT From: rob@icarus.inmos.co.uk (Robin Pickering) To: comp.sys.sun.admin,comp.protocols.tcp-ip Subject: Re: Weirdo IP routing problem  In article <1993May24.182738.511@twg.com> "David Herron" <david@twg.com> writes: >Have I got a weird problem! ... > >When the system boots I configure a network route (224.42.25.0) >and default route (pointing to 224.42.25.1 with metric 0). This is the problem!. You should not set up a route for the locally connected network as this will have a hard-wired route entry by default. By definition a default route should not have a 0 metric as this is only for routes where the *target* host is on the local net (not the gateway) Your configuration then should be: Gateway (davids.mmdf.com): SLIP down: No routes SLIP up: default route 192.215.1.13 metric >= 1 (i.e. route add default 192.215.1.13 1) Other Nodes: default route 224.42.25.1 metric >= 1 In practice however you may as well set up the default route on the gateway at start-up and leave it irrespective of the status of the SLIP line. When the SLIP interface is down the gateway will toss the packet and send an ICMP unreachable net just the same as if it had no route. The metric 0 case in the route table is only for use in the specific case where a host address which isn't on the local net actually has another interface which is directly connected to the local net. -- Rob Pickering.  -----------[000333][next][prev][last][first]---------------------------------------------------- Date: 26 May 1993 16:06:10 GMT From: pkrishna@cs.tamu.edu (P. Krishna) To: comp.protocols.tcp-ip Subject: FAQ  Could someone send me or direct me to a FAQ for this group? Thanks! Krishna. P. Krishna FTCL, Computer Science Dept. Texas A&M University.  -----------[000334][next][prev][last][first]---------------------------------------------------- Date: 26 May 93 16:17:15 GMT From: wew@nuxi.ucc.nau.edu (Bill Wilson) To: comp.protocols.tcp-ip Subject: Macs on Ethernet & backup.  Is anyone out there backing up Macs to vhs or dat tape drives on Unix servers? Anyone doing it to a file on a Unix system? If so, are you using TCP/IP or some form of localtalk? If localtalk, is it public domain? -- Let sleeping dragons lie........ | The RoleMancer -------------------------------------------------------------------- William Wilson (wew@naucse.cse.nau.edu | wilson@nauvax) Northern AZ Univ Flagstaff, AZ 86011 -- Let sleeping dragons lie........ | The RoleMancer -------------------------------------------------------------------- William Wilson (wew@naucse.cse.nau.edu | wilson@nauvax) Northern AZ Univ Flagstaff, AZ 86011  -----------[000335][next][prev][last][first]---------------------------------------------------- Date: Wed, 26 May 1993 16:27:36 GMT From: lapp@waterloo.hp.com (David Lapp) To: comp.protocols.tcp-ip Subject: Re: RFC for keepalives  Frank Ciotti (frankc@teleng.eng.telxon.com) wrote: : Is there an RFC for TCP keepalive polls? I could not find any reference : to them in the RFC index, RFC 793, RFC 896, or the Comer/Stevens books. One of the Host Requirements RFCs (RFC 1122) does discuss tcp keepalives. I'm not sure of any other RFCs which might. Dave Lapp Standard Disclaimer etc...  -----------[000336][next][prev][last][first]---------------------------------------------------- Date: 26 May 93 17:31:47 GMT From: nellied@dingo.ca.boeing.com (Nellie Diaz) To: comp.protocols.tcp-ip,comp.unix.questions Subject: tftp transfer time out  I had a user complain about a 30MB file size transfer limitation with tftp. Since they have installation files that exceed that size and don't want to have a login for every person that needs the software, this presents a problem. The person that complained to me was transferring between IBM RS6k's, so I did some testing in my lab with tftp transfers between 2 IBM RS6k's (models 520 & 530), between 2 Sun Sparcstations and between 2 HP 9000 (model 7xx). The IBM got a transfer timeout error at 33+ MB (out of a 52MB file). I increased the max timeout to 60 seconds and it still timed out in the exact same spot. Both the Sun's and HP's timed out at 16.6 MB (out of a 63MB and 72MB file respectively). I increased the max timeout to 60 & 120 seconds and they still timed out at 16.6MB transferred. Anyone out there have any ideas as to what is going on? Is this a tftp limitation or a platform dependant limitation? I would appreciate direct email as I don't always have time to read netnews and when I do, I usually only get through comp.unix.aix. Thank you in advance for all responses. -- Nellie Diaz nellied%rstech3@atc.boeing.com ___ ___ ___ ___ ___ UNIX Server Technical Services /__// //__ / /\ // _ +1 206 957-5352 =-=-=-=-=-=-=-=-=-= /__//__//__ _/_ / //__/ All statements are my own, not Boeings. Computer Services  -----------[000337][next][prev][last][first]---------------------------------------------------- Date: 26 May 1993 17:50:09 GMT From: emv@garnet.msen.com (Edward Vielmetti) To: comp.protocols.tcp-ip Subject: Re: RFC for keepalives  Frank Ciotti (frankc@teleng.eng.telxon.com) wrote: : Is there an RFC for TCP keepalive polls? I could not find any reference : to them in the RFC index, RFC 793, RFC 896, or the Comer/Stevens books. A quick WAIS search of "internet-rfcs" for "keepalive" or "keepalives" threw up references to these RFCs - I don't know how much they say about them tho (someoen who could condense these referecnes into something useful would be welcomed). rfc1267.txt rfc1163.txt rfc1105.txt rfc969.txt rfc998.txt rfc1323.txt rfc1265.txt rfc1164.txt : Thanks for any help. : Frank Ciotti : frankc@telxon.com : Telxon Corp. : Akron, OH  -----------[000338][next][prev][last][first]---------------------------------------------------- Date: Wed, 26 May 1993 19:41:08 GMT From: richb@tps.COM (Richard Bourassa) To: comp.protocols.tcp-ip Subject: NNTP News Reader for Macintosh  Hello! Does anyone know of a PD NNTP News Reader for the Macintosh? If so, can I get it from an anonymous FTP site? I am trying to find something along the lines of Trumpet, but for a Macintosh. I would be thrilled to death to find out that there is a version of Trumpet for the Mac! any help is greatly appreciated! Thanks, Rich richb@tps.com (PS please respond via eMail if possible.)  -----------[000339][next][prev][last][first]---------------------------------------------------- Date: Wed, 26 May 1993 19:53:00 GMT From: vjs@rhyolite.wpd.sgi.com (Vernon Schryver) To: comp.protocols.tcp-ip Subject: Re: SLIP Recommendations  In article <1bCs03fAd3YP00@amdahl.uts.amdahl.com>, henry@ice03.uts.amdahl.com (Henry Cho) writes: > > I suggest you invest in a Xyplex TCP/IP terminal server. It is capable of > routing incoming SLIP packet to TCP/IP packet. So what you need is to > connect a few 9600 baud modems to the terminal connector and connect the > etherport to you Sun 690 and up you running. By the way SLIP are > point-to-point connection, it run on a single serial and cannot be share by > multiple SLIPs, unlike PPP which allow other application to share the serial > port. What you need is a few rotary phone line connect the those modem which > in turn connect to the terminal server on the terminal side so that who ever > dial in can be automatically connect to a free terminal port using the same > phone number. What's this about not being able to have several SLIP links share the same modem? Maybe that's true of Xyplex's product, although I have no idea. In fact, the PPP and SLIP protocols are exactly the same as far as how many links can share the same modems or telephone lines. Both are point-to-point links. Some implementations keep a SLIP or PPP link alive when the the modem and phone line is dead or in use by another SLIP, PPP, or other use. This is sometimes called something like "demand-dialing." Vernon Schryver, vjs@sgi.com  -----------[000340][next][prev][last][first]---------------------------------------------------- Date: Wed, 26 May 1993 20:11:55 GMT From: motoole@relay.nswc.navy.mil (Edwina O'Toole - K31) To: comp.protocols.tcp-ip Subject: Strange address  What would this address be - 1.1.1.1 It showed up in the IP accounting table for several days on one of the routers here. Thank you, ------------------------------------------------------------------------ Edwina O'Toole Naval Surface Warfare Center Phone: (703) 663-7529 Code K31 (DSN) 249-7529 Dahlgren, VA 22448 MILNET: motoole@relay.nswc.navy.mil ========================================================================  -----------[000341][next][prev][last][first]---------------------------------------------------- Date: 26 May 93 20:30:05 GMT From: jordan@IMSI.COM (Jordan Hayes) To: comp.protocols.tcp-ip Subject: Re: Help with 'discovering' a client end connection died...  Rob Cook <rob@sybase.com> writes: I've run into a problem in a few customer environments where a client (PC under DOS/Windows in this case), connected to a server via sockets dies, but the server is never (apparently) notified. [ is this for Sybase DataServer? ] Anyway, I think the best way to deal with this is to first set keepalives on the socket, and then put a timer on each connection that's as long as half the amount of time you're willing to wait to timeout a connection. Then, in the timer callback, do a FIONREAD on the socket. If the keepalives have marked the socket as dead, this FIONREAD will generate the error necessary to close down the socket. If this *is* for the Sybase dataserver, please include an sp_clearclients or something that wil explicitly run through all clients and do a FINOREAD *now* to reap any dead clients. /jordan  -----------[000342][next][prev][last][first]---------------------------------------------------- Date: Wed, 26 May 1993 21:01:50 GMT From: michael.ward@nt.com (Michael Ward) To: comp.protocols.tcp-ip Subject: NFS Alternative for Wide Area Networks  Hi, Does anyone know about an alternative to NFS mounts for unix servers. I am looking at several unix machines that use NFS to mount drives across the network and since NFS uses UDP to transmit information is proves to be very un-reliable across mutiple Wide Area serial links. This proves especially so with low speed links like 56K. What I am looking for is the functionality that looks like NFS but uses a more reliable protocol for transport like TCP. I do not want to tune NFS on over 300 unix machines thoughout the network and some of the NFS mounts cross 4 to 5 hops in the network. It is a very large network. Thanks in advance, - Michael ----------------------------------------------------------------------------- Michael Ward || My views are my own and do not Northern Telecom || reflect the opinions of NT/BNR 2221 Lakeside Blvd || Richardson, Tx. 75082 || e-mail : nvjmw01@nt.com || #include <std/disclaimer> ------------------------------------------------------------------------------  -----------[000343][next][prev][last][first]---------------------------------------------------- Date: 26 May 1993 21:43:06 GMT From: kevin@kevins.frontiertech.com To: comp.protocols.tcp-ip Subject: Re: Super-TCP  Frontier Technologies Corp. 10201 N. Port Washington Rd. Mequon, WI 53092 Telephone: 414-241-4555 Fax: 414-241-7084 email: TCP@FrontierTech.COM  -----------[000344][next][prev][last][first]---------------------------------------------------- Date: 26 May 1993 20:14:10 +0200 From: hz907sc@unidui.uni-duisburg.de (Lutz Schneider) To: comp.protocols.tcp-ip Subject: SOS, who can help me and my network ?  I'm working with a pc-network and want to analyze an Ethernet system. Exactly I want to get statistics about Ethernet errors. I'm using standard Ethernet cards like NE2000, WD, Long shine, etc and packet drivers. Now I want to know how to get error-informations with packet drivers. Furthermore I want to know whether it is possible to get statistics with software which based on TCP/IP. What is the meaning of the netmask (for example in a configuration-file for Telnet or FTP) ? I would be grateful to someone who can help me. Lutz Schneider  -----------[000345][next][prev][last][first]---------------------------------------------------- Date: Thu, 27 May 1993 01:52:24 GMT From: scott@nova.tcs.tufts.edu (Scott R. Corzine) To: comp.protocols.tcp-ip Subject: Re: DECnet & TCP/IP. Can they co-exist???  In article <i4iink6@rhyolite.wpd.sgi.com> vjs@rhyolite.wpd.sgi.com (Vernon Schryver) writes: >In article <1tth3o$iak@lll-winken.llnl.gov>, oberman@ptavv.llnl.gov writes:
>> CAVEAT!!! Because DECnet will rewrite the physical address of the Ethernet, it
>> MUST start before IP.
>> ...
>
> That depends on the system.  A system can (and some do) repeat the ARP
> announcement of the IP-Ethernet mapping when DECnet is started and
> changes the mapping.  On some such systems it is practically impossible
> and fortunately unnecessary to start DECnet before IP.

However I know of one major router vendor whose software has real
difficulties with its ARP cache.  We've had some difficulties
consistently convincing the router that the IP-Ethernet mapping
has changed without rebooting the router.  I don't know if any
other implementations have similar problems.

I would recommend caution if attempting to start DECnet after IP.

-Scott R. Corzine-


-----------[000346][next][prev][last][first]----------------------------------------------------
Date:      Thu, 27 May 1993 02:04:03 GMT
From:      scott@nova.tcs.tufts.edu (Scott R. Corzine)
To:        comp.protocols.tcp-ip
Subject:   Re: SLIP Recommendations

In article <i5927bi@rhyolite.wpd.sgi.com> vjs@rhyolite.wpd.sgi.com (Vernon Schryver) writes:
>
> What's this about not being able to have several SLIP links share the
> same modem?  Maybe that's true of Xyplex's product, although I have no
> idea.

If multiple SLIP links sharing the same modem means supporting
different SLIP connections at different times, the Xyplex Doc's
definitely seem to support this through a couple different methods
(although possibly not in the most desirable fashion).

If multiple SLIP links share the same modem means supporting the
connections simultaneously (ie a multi-drop line), then I am
unaware of any SLIP implementation which supports this (is it even
possible)... :-)

Disclaimer: This is from my reading the docs in preparation for
implementing this, I'm still awaiting approval for the phone line
for testing.  I have used Xyplex's SLIP implementation over direct

-Scott R. Corzine-


-----------[000347][next][prev][last][first]----------------------------------------------------
Date:      27 May 1993 03:05:28 GMT
From:      herrera@athena.mit.edu (Ramon F Herrera)
To:        comp.protocols.tcp-ip
Subject:   Are proxy ARP and ICMP redirects compatible??


I have a SLIP link between my home Mac and an Annex at work, but
one day it stopped working for no apparent reason.  Trying to find
the cause of the problem, I captured some packets that tell me that
the Annex is doing both proxy ARP and ICMP redirects.  Is that normal?
Note that on the Annex, the Ethernet port and the serial port have

It seems strange to me that the Annex is sending ICMP redirects.
If the remote Mac is on the same subnet as the Annex, shouldn't
proxy ARP suffice?  Isn't that the case that from the point of
view of all the hosts in the LAN (except for the Annex) there
is NO routing going on?  They should just ARP, the Annex answers
with its own Ethernet address and that should be all.  The only
routing table that needs to know about my Mac is the Annex's.
If I am right those redirects are just bringing confusion, which
should be the reason for the link's failure to work.

My LAN is completelyt flat: one subnet with only one way out to
the Internet.  I don't have 'routed' running on any host.  The
routing tables only contain the minimun number of routes: looopback,
local net, and a default route.  I have not tried to put the Mac
on a different subnet because I don't want to add a new route to
every host's routing table.  Only one of the Annex' ports is
configured for SLIP.

Thanks for any insights,

-Ramon Herrera


-----------[000348][next][prev][last][first]----------------------------------------------------
Date:      Thu, 27 May 93 14:39:48 -0400
To:        comp.protocols.tcp-ip
Subject:   PC-eudora

Also posted to qualcomm.com

I am running PC-NFS v5.0 , MS-DOS 6.0, on a Dell 486-66 ME.

I like PC-Eudora.

Currently using pce11a7.exe

WHen I setup the PC-NFS network.bat file to use direct services:

NET NISDOMAIN gando
NET START RDR gran *
NET PCNFSD gru5

everything works fine.

But when I use NIS like so:

NET NISDOMAIN gando
NET START RDR gran *
NET NISSET *
NET PCNFSD *

Then it don't work:

All other PC-NFS services work fine under both scenarios.

The error is:

Unable to get services pop3 due to unspecified error.
(This may not be exactly what it says)

I have configured and rebuilt my services files in C:\NFS, C:\ETC,
on the NIS Server master file, etc.

They all look like this:

ftp             21/tcp
telnet          23/tcp
smtp            25/tcp          mail            # Simple Mail Transfer Protocol
time            37/udp          timeserver
time            37/tcp          timeserver
name            42/udp          nameserver
finger          79/tcp
ns              105/tcp         ns              # NameServer
pop             110/tcp                         # Post Office Protocol Default
pop2            109/tcp                         # Post Office Protocol V2
pop3            110/tcp                         # Post Office Protocol V3
sunrpc          111/udp
sunrpc          111/tcp
snmp            161/udp                         # Simple Network Mgmt Prot.
snmp-trap       162/udp         snmptrap        # SNMP trap (event) messages
shell           514/tcp         cmd             # no paawords used
printer         515/tcp         spooler         # line printer spooler

etc, etc, etc.

I have installed the new WSHELPER.EXE which was provided by Sun Microsytstems.

Do you have any intuition about where I might be going wrong?


-----------[000349][next][prev][last][first]----------------------------------------------------
Date:      26 May 1993 20:24:19 +0800
To:        comp.sys.mac.programmer,comp.sys.mac.apps,comp.sys.mac.comm,comp.protocols.tcp-ip,comp.protocols.tcp-ip.domains
Subject:   Re: MacTCP 1.1.1 and DNS...

We've got about 30 PCs, 3 Mac Ifxs and 25 Sun SS1s. The Suns are on a
thick ethernet backbone and so is our Sun SparcServer 690MP. The PC's go
thru a Xyplex Termserver and can login to the Suns. The Macs are
standalones. Any comments and software on how I can introduce the Macs to
our net ? I'm a bit new at this so please excuse my ignorance. Thanking

/\_/\   "All dogs go to heaven."
(0 0)
+==========================----oOO--(_)--OOo----============================+
| Dinesh Nair (dinesh@bass.my)     /    Surface Address :                   |
| Software Engineer                \    8th Floor, Menara SMI,              |
| Technical Services Group         /    6 Lrg P Ramlee, 50250 Kuala Lumpur  |
| Bass Consulting                  \    Malaysia.   Tel : 03-2305588        |
+===========================================================================+


-----------[000350][next][prev][last][first]----------------------------------------------------
Date:      Thu, 27 May 1993 17:53:14 -0400
From:      "Eugene F. Hastings" <hastings+@andrew.cmu.edu>
To:        comp.protocols.tcp-ip
Subject:   Re: NNTP News Reader for Macintosh

Check out Nuntius and NewsWatcher, both available in the Info-Mac archives
on sumex-aim.stanford.edu. Nuntius is a little fancier, but requires System
7. NewsWatcher will work with System 6.x

Gene


-----------[000351][next][prev][last][first]----------------------------------------------------
Date:      27 May 93 13:10:32 GMT
From:      mvbr@se.alcbel.be (Marc Verbruggen)
To:        comp.protocols.tcp-ip
Subject:   DECnet vs. TCPIP


--
1) Where do I find a description on the differences between DECnet and TCP/IP.

2) We consider to use TCP/IP as main protocol on the Ethernet to connect VAXes,
PCs, IBMs, Unix systems. Are there (dis)advantages to allow systems of the
same architecure to communicate using their proprietary protocol ? E.g. VAX-VAX
= decnet, IBM-IBM = sna.
-----------------------------------------------------------
Marc Verbruggen                 tel : 03.240.94.19
Alcatel Bell Telephone          fax : 03.240.99.50
F. Wellesplein 1                email : mvbr@se.alcbel.be
B-2018 Antwerp
Belgium

"System Manager's Headaches Are Not Cured With Aspirin,
There Is A Better Way ..."


-----------[000352][next][prev][last][first]----------------------------------------------------
Date:      Thu, 27 May 1993 13:27:06 GMT
From:      keith@comp.lancs.ac.uk (Mr K C Craig)
To:        comp.protocols.tcp-ip
Subject:   Re: MacTCP 1.1.1 and DNS...


In article <1993May25.223326.3132@nntpxfer.psi.com> alun@huey.wst.com (Alun Jones) writes:
>In article <1ttn50$rje@usenet.INS.CWRU.Edu> trier@odin.ins.cwru.edu (Stephen C. Trier) writes: > >As a PC user who has been branded our company's Internet expert, I've been >asked by several Mac users how we can connect them to the Internet. Is >Mac TCP the only/best way to do this? Just as word of a warning (and maybe a question to) when you run MAC TCP/IP, it doesn't seem to bother to check if the IP address that you supply to it is already in use. This makes for great "entertainment" if a user places the IP address of your X-Term server in their configuration by mistake. In PC TCP/IP work I have done the system checks to see if the IP address has already been used. Is there anyway of avoiding this problem? (with the exception of dynamically assigning IP addresses, which I can't do in these cases.) Keith Craig MicroComputer Consultant Lancaster University  -----------[000353][next][prev][last][first]---------------------------------------------------- Date: Thu, 27 May 1993 13:57:00 GMT From: keith@comp.lancs.ac.uk (Mr K C Craig) To: comp.protocols.tcp-ip Subject: MAC TCP/IP DNS  There was a recent posting detailing how to set up secondary DNS servers in MAC TCP/IP written by Steve Trier, I think. I've deleted my copy by accident. Could someone repost it or mail it to me at keith.cent1.lancs.ac.uk. Keith Craig MicroComputer Consultant Lancaster University.  -----------[000354][next][prev][last][first]---------------------------------------------------- Date: 27 May 1993 15:14:22 GMT From: kbw@helios.ath.epa.gov (Kevin B. Weinrich) To: comp.protocols.tcp-ip Subject: How to convert ethernet hard. addr. to IP addr.? ARP?  I know how (via kludge) to get an ethernet hardware address from an IP address: ping host.domain arp -a will first add host.domain to arp's table, then list all the machines currently in the table, including both numeric IP addr and ether hardware addr. There's probably a slicker way to do this; I'd be thankful for hearing of it. But how can I do the reverse: start with an ethernet hardware address, and wind up with the IP address it goes with? -- Kevin Weinrich Computer Sciences Corp. kbw@helios.ath.epa.gov  -----------[000355][next][prev][last][first]---------------------------------------------------- Date: 27 May 1993 15:16:12 GMT From: roy@mchip00.med.nyu.edu (Roy Smith) To: comp.protocols.tcp-ip Subject: Re: MacTCP 1.1.1 and DNS...  keith@comp.lancs.ac.uk (Mr K C Craig) writes: > Just as word of a warning (and maybe a question to) when you run MAC > TCP/IP, it doesn't seem to bother to check if the IP address that you > supply to it is already in use. This makes for great "entertainment" if a > user places the IP address of your X-Term server in their configuration by > mistake. In PC TCP/IP work I have done the system checks to see if the IP > address has already been used. I believe the latest version of MacTCP (2.0, which may or may not be available to the public yet) does complain about duplicate IP addresses. Duplicate IP addresses is not a problem specific to MacTCP. Anytime the user (or the system administrator, for that matter!) can set the IP address, the possibility of duplication occurs. I remember one memorable day when somebody running Sun's PC/NFS set their IP address to the same as one of our major file servers. What fun. -- Roy Smith <roy@nyu.edu> Hippocrates Project, Department of Microbiology, Coles 202 NYU School of Medicine, 550 First Avenue, New York, NY 10016 "This never happened to Bart Simpson."  -----------[000356][next][prev][last][first]---------------------------------------------------- Date: Thu, 27 May 1993 15:40:19 +0000 From: proyse@peeras.demon.co.uk (Phil Royse) To: comp.protocols.tcp-ip Subject: Re: Super-TCP  In article <C7Dvpn.AyH@unccsun.uncc.edu> jpb@jpbpc1.uncc.edu writes: >I have just finished Tested the following nine competing products: John, Have you got more info on TN3270? What does it not have that proper 3270 in a host have? Put another way... if IBM are recommending PC3270 to run a software package over an SNA link, but we want to use TCP/IP over our Ethernet, can we still use TN3270 (in the IBM 9370) and a TN3270 emulator/over telnet/over TCP/IP without losing fuctionality? TIA, Phil R. -- Phil Royse Comms Consultant | member: The Peer Association TUDOR HOUSE | (networking & OSI specialists) 12 Woodside Road, Purley Surrey CR8 4LN (UK) Tel: (+44) 81 645-9868  -----------[000357][next][prev][last][first]---------------------------------------------------- Date: 27 May 93 15:41:31 GMT From: nellied@dingo.ca.boeing.com (Nellie Diaz) To: comp.unix.questions,comp.protocols.tcp-ip Subject: tftp limitation problem  Big thank you to Tony Li for the following reply to the file size transfer problem I was having with tftp: >Yes, that's a limitation of the protocol. TFTP can only handle up to >16 bits of blocks, each block is 512 bytes, thus 65535x512=33553920. >As the RFC never specified how to wrap block numbers (it _could_ be >done), the protocol itself is limited to this size. >The Sun implementation (and probably the HP) is broken because they >use _signed_ numbers, and thus get confused when they've done 15 bits >worth of blocks. >Anonymous ftp would be a much better solution to this problem anyhow... -- Nellie Diaz nellied%rstech3@atc.boeing.com ___ ___ ___ ___ ___ UNIX Server Technical Services /__// //__ / /\ // _ +1 206 957-5352 =-=-=-=-=-=-=-=-=-= /__//__//__ _/_ / //__/ All statements are my own, not Boeings. Computer Services  -----------[000358][next][prev][last][first]---------------------------------------------------- Date: 27 May 93 15:49:04 GMT From: art@acc.com (Art Berggreen) To: comp.protocols.tcp-ip Subject: Re: Strange address  In article <1993May26.201155.4245@relay.nswc.navy.mil> motoole@relay.nswc.navy.mil (Edwina O'Toole - K31) writes: >What would this address be - > 1.1.1.1 > >It showed up in the IP accounting table >for several days on one of the routers here. My first guess would be that it leaked out of a test configuration. Either the packet originated inside your enviroment and had a destination address of 1.1.1.1 and happened to follow a default path, or someone outside sent a packet to one of your addresses with a source address of 1.1.1.1. Art  -----------[000359][next][prev][last][first]---------------------------------------------------- Date: Thu, 27 May 1993 12:37:42 +0200 From: Andre' Pirard <pirard@vm1.ulg.ac.be> To: comp.protocols.tcp-ip Subject: Re: Help me fix my EBCDIC-ASCII translate table for FTP  In article <C79GGu.6qA@wimsey.bc.ca> Samuel Lam, skl@wimsey.bc.ca writes: > In article <900@ceco.ceco.com>, garry@ceco.ceco.com (Garry J. Garrett) wrote: > >What would I like from you? Do you have a chart that you are willing > >to share with me (that has a 1:1 corresponance, i.e. each character > >on the chart maps to one and only one character on the other chart, > >and that character maps back to the one you started with.)? > > The following should do it. It's the "MTS T-Day chart". Much efforts > and sweat had gone into it. > > [table removed] I have no doubt about the sweat :-) As a specialist of the question, I have checked the table and found it to match the IBM official translation between ISO 8859-1 and CECP 037 (it is reversible and one to one indeed). Apparently good, but there's a hitch, read on... ISO 8859-1 is the de-facto-recognized(*) standard for 8-bit communication of Latin-1 languages over networks formerly called ASCII (other language groups would use another -x version of the same standard, while waiting that a multi-byte code allow any language to use the same code. But that would need that the TCP/IP protocols suite define an XDR (external data representation), sort of OSI level 6, on a global scale to be used by any protocol of the suite, a need I won't extend here). (*) 8859 _is_ a standard, even the only real one, but its use is only indicated for some TCP/IP application RFCs (Xwindows, Gopher, ...); the other protocols use it in a de facto way, by similarity and compatibility with the others. No one seems to question 8859. Subject closed one side. CECP 037 is the official IBM EBCDIC code (the 'hex values') to be used in US for exactly that same character set (shapes) as ISO. And here's the hitch: "in US". IBM defined different codes with exactly the same Latin-1 character set to be used in different countries, much like as if same ASCII characters had different values in different states of the US. Moreover, CECP 037 (and none of the others) is _not_ compatible with traditional US EBCDIC for the values of brackets recognized by a host of programs, including IBM's, among which one pinpoints the compilers (C, Pascal) and _all_ the programs that produce EBCDIC to be translated to ASCII (Postscript, HP ...). This is ever so true that 3270 terminal emulators from IBM (e.g. X3270) have a toggle to 'put the brackets correct', as they say. A working group of SHARE (IBM users group) urged IBM to define a USEBCDIC-compatible Latin-1 CECP and recommended that this single one be used world-wide. From this emerged the definition of CECP 1047. In summary, one may run into big troubles if the ISO 8859-1 to CECP 1047 is not used, especially because data is transmitted over EBCDIC networks in US EBCDIC and it would convert to wrong ASCII. It's the eperience of many people. Try requesting a uuencoded or binhex over BITNET and see which translation works to get it back to ASCII. And everything clutches together. Try Kermit etc... The formerly posted table differs at ASCII 5B 5D 5E A8 AC DD (brackets, circumflex and swaps). I would highly recommend the following table instead (in IBM TCP/IP format). IBM TCP/IP default US EBCDIC translation table is indeed just another one only this one is compatible with (and no other will work, eg for SMTP that will no longer recognize brackets). * Translation between ISO8859/1 and EBCDIC CECP 1047 * ASCII-to-EBCDIC table * 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F * 00 01 02 03 37 2D 2E 2F 16 05 25 0B 0C 0D 0E 0F * 00 * 10 11 12 13 3C 3D 32 26 18 19 3F 27 1C 1D 1E 1F * 10 * 40 5A 7F 7B 5B 6C 50 7D 4D 5D 5C 4E 6B 60 4B 61 * 20 * F0 F1 F2 F3 F4 F5 F6 F7 F8 F9 7A 5E 4C 7E 6E 6F * 30 * 7C C1 C2 C3 C4 C5 C6 C7 C8 C9 D1 D2 D3 D4 D5 D6 * 40 * D7 D8 D9 E2 E3 E4 E5 E6 E7 E8 E9 AD E0 BD 5F 6D * 50 * 79 81 82 83 84 85 86 87 88 89 91 92 93 94 95 96 * 60 * 97 98 99 A2 A3 A4 A5 A6 A7 A8 A9 C0 4F D0 A1 07 * 70 * 20 21 22 23 24 15 06 17 28 29 2A 2B 2C 09 0A 1B * 80 * 30 31 1A 33 34 35 36 08 38 39 3A 3B 04 14 3E FF * 90 * 41 AA 4A B1 9F B2 6A B5 BB B4 9A 8A B0 CA AF BC * A0 * 90 8F EA FA BE A0 B6 B3 9D DA 9B 8B B7 B8 B9 AB * B0 * 64 65 62 66 63 67 9E 68 74 71 72 73 78 75 76 77 * C0 * AC 69 ED EE EB EF EC BF 80 FD FE FB FC BA AE 59 * D0 * 44 45 42 46 43 47 9C 48 54 51 52 53 58 55 56 57 * E0 * 8C 49 CD CE CB CF CC E1 70 DD DE DB DC 8D 8E DF * F0 * * * EBCDIC-to-ASCII table * 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F * 00 01 02 03 9C 09 86 7F 97 8D 8E 0B 0C 0D 0E 0F * 00 * 10 11 12 13 9D 85 08 87 18 19 92 8F 1C 1D 1E 1F * 10 * 80 81 82 83 84 0A 17 1B 88 89 8A 8B 8C 05 06 07 * 20 * 90 91 16 93 94 95 96 04 98 99 9A 9B 14 15 9E 1A * 30 * 20 A0 E2 E4 E0 E1 E3 E5 E7 F1 A2 2E 3C 28 2B 7C * 40 * 26 E9 EA EB E8 ED EE EF EC DF 21 24 2A 29 3B 5E * 50 * 2D 2F C2 C4 C0 C1 C3 C5 C7 D1 A6 2C 25 5F 3E 3F * 60 * F8 C9 CA CB C8 CD CE CF CC 60 3A 23 40 27 3D 22 * 70 * D8 61 62 63 64 65 66 67 68 69 AB BB F0 FD FE B1 * 80 * B0 6A 6B 6C 6D 6E 6F 70 71 72 AA BA E6 B8 C6 A4 * 90 * B5 7E 73 74 75 76 77 78 79 7A A1 BF D0 5B DE AE * A0 * AC A3 A5 B7 A9 A7 B6 BC BD BE DD A8 AF 5D B4 D7 * B0 * 7B 41 42 43 44 45 46 47 48 49 AD F4 F6 F2 F3 F5 * C0 * 7D 4A 4B 4C 4D 4E 4F 50 51 52 B9 FB FC F9 FA FF * D0 * 5C F7 53 54 55 56 57 58 59 5A B2 D4 D6 D2 D3 D5 * E0 * 30 31 32 33 34 35 36 37 38 39 B3 DB DC D9 DA 9F * F0 * ------ Andre' Pirard SEGI, Universite' de Liege 139.165 IP coordinator B26 - Sart Tilman B-4000 Liege 1 (Belgium) +32 (41) 564932 pirard@vm1.ulg.ac.be alias PIRARD@BLIULG11.BITNET  -----------[000360][next][prev][last][first]---------------------------------------------------- Date: 27 May 93 16:10:13 GMT From: veizades@apple.com (John Veizades) To: comp.protocols.tcp-ip Subject: Re: MacTCP 1.1.1 and DNS...  In article <1993May27.132706.12720@comp.lancs.ac.uk>, keith@comp.lancs.ac.uk (Mr K C Craig) wrote: > Just as word of a warning (and maybe a question to) when you run MAC TCP/IP, it > doesn't seem to bother to check if the IP address that you supply to it is already in use. MacTCP in all its incarnations uses ARP to check if its IP address is in use by anyother system on the cable. John Veizades... MacTCP Lead Engineer Apple Computer, Inc.  -----------[000361][next][prev][last][first]---------------------------------------------------- Date: Thu, 27 May 1993 16:56:02 GMT From: craig@sics.se (Craig Partridge) To: comp.protocols.tcp-ip Subject: Advance Program for ACM SIGCOMM '93  ADVANCE PROGRAM FOR ACM SIGCOMM '93 September 13-17th, San Francisco, California, USA ************************************************************************** ************************************************************************** CONFERENCE LOCATION The SIGCOMM '93 Conference will be held at the Westin St. Francis Hotel in downtown San Francisco, California. The hotel is within walking distance of San Francisco's Chinatown and an easy cable car ride away from Ghiradelli Square and Fisherman's Wharf. Napa and Sonoma Valleys, the heart of California wine country, are an hour's drive away. Weather: San Francisco in September is typically very pleasant. Sunny and warm (about 70F) during the day, and cool (about 50F) in the evenings. Note that the evening fog often makes it feel a bit colder and we recommend you bring a jacket. Transportation: The hotel is about 20 minutes away from San Francisco International Airport. A taxi ride from the airport typically costs about$25.  Also, the SFO Airporter has direct service to the
hotel at 20-minute intervals.  The fare is $8 one-way and$14
round-trip.

Rental Cars: HERTZ has been appointed as the car rental supplier for
SIGCOMM '93.  Special rates with unlimited mileage have been negotiated
for SIGCOMM attendees and are also available the week prior and the
week after the symposium.  To make reservations call HERTZ Meeting Services
at 1-800-654-2240 (In Canada 1-800-263-0600) and identify yourself as
SIGCOMM attendee (Meeting # 2499).  Cars can be rented at most Bay-area
airports and also at the Westin St. Francis Hotel.

Social Event: An evening dinner-cruise on the San Francisco Bay is planned
for Wednesday, September 15.  The cost of the cruise is included in
the registration fee.  Additional tickets may be purchased at a price
of $53 each. The cruise will be held on the Hornblower Dining Yachts's Empress. Beverages will include premium wine and beer, soft drinks, fruit juices and mineral water. Dinner will be a Greek Salad, Rice Pilaf, a choice of carved turkey or pasta, and dessert. ************************************************************************** ************************************************************************** ADVANCE PROGRAM Monday, September 13th 1:00-5:00 TUTORIALS Tutorial T1A: High-Speed Transport Protocols Krishan Sabnani, AT&T Bell Labs Tutorial T1B: Interconnecting MANs and LANs to ATM Mario Gerla, UCLA ------------------------------------------------------------------------------ Tuesday, September 14th 8:00-12:00 TUTORIALS Tutorial T2A: Wireless Communication Worldwide for Cellular and PCS Donald L. Schilling, InterDigital Communications Corporation Tutorial T2B: Trends and Challenges in Broadband Networking Richard D. Gitlin, AT&T Bell Labs 1:30-5:30 TUTORIALS Tutorial T3A: All-Optical Networking Paul E. Green Jr., IBM T.J. Watson Research Center Tutorial T3B: Metropolitan Area Networks James F. Mollenauer, Technical Strategy Associates 6:00-8:00 Reception at Westin St. Francis Hotel. ------------------------------------------------------------------------------ Wednesday, September 15th 9:00 - 10:30 Keynote Address: SIGCOMM Award Winner 11:00 - 12:30 REAL TIME COMMUNICATIONS On Per-Session End-to-End Delay Distribution and the Call Admission Problem for Real Time Applications with QOS Requirements David Yates, Jim Kurose, Don Towsley (Univ. of Mass) and Mike Hluchyj (Motorola/Codex Corp) Analysis of Burstiness and Jitter in Real Time Communications Zheng Wang and Jon Crowcroft (University College London) An Adaptive Congestion Control Scheme for Real Time Packet Video Transport Hemant Kanakia, Amy Reibman (AT&T Bell Lab) and Partho P Misra (Univ. of Maryland - CP) 2:00 - 3:30 ROUTING The Synchronization of Periodic Routing Messages Sally Floyd and Van Jacobson (Lawrence Berkeley Lab.) Dynamics of Internet Routing Information Bilal Chinoy (San Diego Supercomputer Center) Open Shortest Path First (OSPF) Routing Protocol Simulation Deepinder Sidhu, Tayang Fu, Shukri Abdallah, Raj Nair (Univ. of Maryland - BC) and Rob Coltun (Consultant) 4:00 - 5:00 PROTOCOL IMPLEMENTATION ISSUES Implementation of Network Protocols at the User Level Chandramohan Thekkath, Edward D. Lazowska, Thu. D. Nguyen and Evelyn Moy (University of Washington) Locking Effects in Multiprocessor Implementation of Protocols Mats Bjorkman (Uppsala University) and Per Gunningberg (Swedish Institute of Computer Science) 5:30 Busses Leave for Cruise. 6:30 - 9:00 SOCIAL EVENT Cruise in San Francisco Bay. ------------------------------------------------------------------------------ Thursday, September 16th 9:00 - 10:30 MULTICAST Core Based Trees Tony Ballardie (University College London), Paul Francis (Bellcore) and Jon Crowcroft (University College London) Routing Reserved Bandwidth Multi-Point Connections Dinesh C. Verma, P. M. Gopal (IBM T.J. Watson Research Center) The Design of a Reliable Multicast Algorithm R. Ajello, E. Pagani, G.P. Rossi (Universita' di Milano) 11:00 - 12:30 CONGESTION AND ADMISSION CONTROL, SCHEDULING Optimizing File Transfer Response Time Using the Loss Load Curve Congestion Control Mechanism. Carey Williamson (Univ. of Saskatchewan) An Adaptive Framework for Dynamic Access to Bandwidth at High Speed. Kerry W. Fendick and Manoel A. Rodrigues (AT&T Bell Laboratories) Warp Control: A Dynamically Stable Congestion Protocol and its Analysis. Kihong Park (Boston University) 2:00 - 3:30 PROTOCOL DESCRIPTION Control Handling in Real-Time Communication Protocols. Atsushi Shionozaki and Mario Tokoro (Keio University) Structural Complexity and Execution Efficiency of Distributed Application Protocols. K. Ravindran and X. T. Lin (Kansas State University) A Data Labelling Technique for High-Performance Protocol Processing and its Consequences. David C. Feldmeier (Bellcore) 4:00 - 5:00 TRAFFIC CHARACTERISTICS On the Self-Similar Nature of Ethernet Traffic Will E. Leland (Bellcore), Murad S. Taqqu (Boston University), Walter Willinger and Daniel V. Wilson (Bellcore) Application of Sampling Methodologies to Network Traffic Characterization George Polyzos, K. C. Claffy and H. W. Braun (UC, San Diego) ------------------------------------------------------------------------------ Friday, September 17th 9:00 - 10:30 SCHEDULING AND MANAGEMENT ATM Scheduling with Queueing Delay Predictions Daniel B. Schwartz (GTE Laboratories) HAP: A New Model for Packet Arrivals with Implications for Broadband Network Control. Ying Dar Lin, Tzu Chieh Tsai and Mario Gerla (UCLA) Management of Virtual Private Networks for Integrated Broadband Communication Juergen M. Schneider (IBM European Networking Center), Thomas Preuss (Technische Universitaet Cottbus) and Peter S. Nielsen (L. M. Ericsson A/S) 11:00 - 12:30 NETWORKING ISSUES A Case for Caching File Objects Inside Internetworks Peter B. Danzig (University of Southern California), Richard S. Hall and Michael F. Schwartz (University of Colorado, Boulder) Linear Recursive Networks and Their Applications in Topological Design and Data Routing. Wea Jing Hsu (Nanyang Technological Univ.) The Importance of Non-Data Touching Processing Overheads in TCP/IP. Jonathon Kay and Joseph Pasquale (UC, San Diego) 2:00 - 3:30 PRACTICAL PROTOCOLS A Distributed Queueing Random Access Protocol for a Broadcast Channel. Graham Campbell and Wenxin Xu (Illinois Institute of Technology) Fault Detection in an Ethernet Network Using Anomaly Signature Matching Frank Feather (Hewlett-Packard Company), Dan Siewiorek and Roy Maxion (Carnegie Mellon University) End-to-End Packet Delay and Loss Behavior in the Internet Jean - Chrysostome Bolot (INRIA) ************************************************************************** ************************************************************************** TUTORIAL DESCRIPTIONS Tutorial T1A: High-Speed Transport Protocols. Instructor: Krishan Sabnani, AT&T Bell Laboratories (Monday, Sept. 13th, 1:00-5:00) Advances in data transmission and switching over the last decade promise deployment of communication systems with raw bandwidth and switching speeds that are orders of magnitude higher than the current systems. Optical fibers, for example, allow transmission of tens of gigabits/sec over several kilometers without repeaters and switch fabrics that can switch bit-streams of more than hundreds of megabits/sec have already been prototyped. To realize the fruits of these advances, transport protocols capable of delivering high end-to-end bandwidth to their users are needed. Various approaches for doing this have been proposed: (1) design of lightweight transport protocols such as NETBLT, SNR, and VMTP; (2) VLSI implementations of transport protocols such as PROVE and the Protocol Engine. Some high-speed versions of standard protocols such as TCP have also been developed. Many important advances in this area will be discussed. A special effort will be made to describe the underlying principles behind these approaches. In addition, the adaptation layer protocols being proposed for the ATM/BISDN networks will also be presented. Biography: Krishan Sabnani is a researcher in the Distributed Systems Research Department of AT&T Bell Laboratories. His major area of interest is communication protocols. Krishan received the Leonard G. Abraham Award from the IEEE Communications Society in 1991. He was awarded the Bell Laboratories Distinguished Technical Staff Award in 1990. He is also a fellow of the IEEE, and an editor for the IEEE/ACM Transactions on Networking. He has been an editor of the IEEE Transactions on Communications and of the IEEE Transactions on Computers. He has served as a guest editor for the IEEE Journal on Selected Areas in Communications (JSAC) and the Computer Networks Journal. He also serves on the editorial boards of Journal of Systems Integration and Journal of High Speed Networks. --------------------------------------------------------------- Tutorial T1B: Interconnecting MANs and LANs to ATM. Instructor: Mario Gerla, Computer Science Department, UCLA. (Monday, Sept. 13, 1:00-5:00). The need for higher data rates in local and metropolitan areas has recently led to the development of several network products in the 100 MBPS speed range ( eg FDDI, DQDB etc). Following the introduction of a nationwide ATM network, it will be natural to interconnect these LANs and MANs to ATM, thus extending their services to large geographical areas. One of the main challenges of the LAN/MAN/ATM interconnect is the connectionless traffic support in ATM. In fact, LANs and MANs are virtually all connectionless, while ATM is connection oriented and requires bandwidth allocation prior to connection setup. In this seminar, we will examine and compare various alternatives for ATM connectionless service support, including: dedicated VPs (Virtual Paths); on-the-fly burst transmissions; fast reservations; and connectionless servers. We will also discuss the problem of extending LAN and MAN multicast services within ATM. Finally, we will consider the ATM LAN solution for local and campus area coverage, and examine the problem of interconnecting the ATM LAN to the ATM WAN. Biography: Dr. Gerla was born in Milan, Italy. He received a graduate degree in engineering from the Politecnico di Milano, in 1966, and the M.S. and Ph.D. degrees in engineering from UCLA in 1970 and 1973, respectively. He joined the faculty of the UCLA Computer Science Department in 1977. His research interests cover the performance evaluation, design and control of distributed computer communication systems and high speed computer networks (ATM and Optical Networks). --------------------------------------------------------------- Tutorial T2A: Wireless Communication Worldwide for Cellular and PCS. Instructor: Donald L. Schilling, InterDigital Communication Corporation (Tuesday, Sept. 14th, 8:00-12:00) This is the decade of wireless telecommunications. During the 1990s people will demand, in increasing numbers, the ability to communicate with a high degree of mobility, high quality voice, data at ISDN rates and multimedia information such as video. Indeed, consumers demand wired line quality with wireless convenience. The user of a cellular or PCS system wants to use one phone for all of these intended needs. Thus, a single portable phone should be able to operate in a residence as a cordless phone, in a vehicle using a cellular system and in an office using a WPBX. This tutorial discusses the two primary technologies for wireless communications: TDMA and CDMA. Topics include: principles of operation of TDMA and CDMA; channel characterization-multipath fading, theory and experimental results; as well as applications and comparison of TDMA and CDMA for cellular and PCS. Biography: Donald L. Schilling is Executive President of InterDigital Communications Corporation where he directs programs leading to the production and sale of Wireless TDMA and B-CDMA Communication's products. Dr. Schilling retired in May 1992 as the Herbert G. Kayser, Distinguished Professor of Electrical Engineering at the City College of the City University of New York where he had been a Professor since 1969. Dr. Schilling is an internationally-known expert in the field of Communications Systems. He has made many notable contributions in Meteor-Burst Communications Systems, Spread Spectrum Communication Systems, FM and Phase Locked Systems and HF systems. His design of a voice digitizer, called an adaptive delta modulator, is used on the Space Shuttle. Dr. Schilling was President of IEEE Communications Society from 1980-1981, and a member of the Board of Directors of the IEEE from 1982-1983. He was Editor of the IEEE Transactions on Communications for 1968-1978. He is a Fellow of the IEEE and a member of Sigma Xi. He has co-authored eight textbooks and more than 140 papers in Telecommunications and Electronics. --------------------------------------------------------------- Tutorial T2B: Trends and Challenges in Broadband Networking. Instructor: Richard Gitlin, AT&T Bell Labs (Tuesday, Sept. 14th, 8:00-12:00) This tutorial will present an overview of research in Broadband Networking (B-ISDN) based on the Asynchronous Transfer Mode (ATM). ATM is the leading candidate to provide a technological discontinuity that enables integrated broadband telecommunication services (e.g., multimedia), high-speed computer networking and scalable local, metropolitan, and wide area networks. Specific topics that will be addressed are: o The technological discontinuities between narrowband and broadband networking; o Challenges and barriers to a broadband network; o Selected research topics (including the LuckyNet broadband testbed). Biography: Richard D. Gitlin received the B.E.E. degree (cum laude) from the City College of New York, N.Y., in 1964 and the M.S. and D.Eng.Sc. degrees from Columbia University, New York, N.Y., in 1965 and 1969, respectively. Since 1969, he has been with AT&T Bell Laboratories, Holmdel, N.J. In November, 1992 he was appointed Director of the Communications Systems Research Laboratory. He is now responsible for research in broadband networking, wireless networks, and access technologies. Dr. Gitlin is the author of more than 50 technical papers, numerous conference papers, and he holds 25 patents in the areas of data communications, digital signal processing, and broadband networking. He is a co-author of the text, Data Communication Principles (Plenum Press, 1992). He is a member of Sigma Xi, and in 1985 he was elected a Fellow of the IEEE for his contributions to data communications technology. In 1987 he was named an AT&T Bell Laboratories Fellow. --------------------------------------------------------------- Tutorial T3A: All-Optical Networking. Instructor: P. E. Green, Jr., IBM TJ Watson Research Center. (Tuesday, Sept. 14th, 1:30-5:30). This short course will focus on recent developments in networks that exploit the multiprotocol and high bandwidth possibilities of clear end-to-end optical fiber paths by sending different sessions or connections at different wavelengths of light. In the first hour, the motivation and overall principles of such networks are reviewed. In the next, the appropriate fiber optic technology is covered, focussing on those components that are special to networking. In the third hour, various architectural topics are covered, (including link budgets, topologies and protocols), and in the final hour the status and prospects for real operational all-optical networks of various types are presented. Biography: Paul E. Green, Jr. is Manager of Advanced Optical Networking Member at IBM Research in Hawthorne, NY. After some years at M.I.T. Lincoln Laboratory, where he made pioneering contributions to spread spectrum, adaptive receivers, radar astronomy and seismic data processing, he joined IBM, where he has held a variety of research and Corporate Technical Staff positions. His technical interests have centered on computer network architecture, and he has received several IBM Outstanding Innovation Awards for his role in formulating and promoting Advanced Peer-to-Peer Networking, now the basis for further evolution of IBM's System Network Architecture. He is a member of the National Academy of Engineering, in 1983 was named Distinguished Engineering Alumnus by North Carolina State University, and received the IEEE's Simon Ramo Medal in 1991. He is the author of many technical papers, has edited several books on computer communications, and is the author of the textbook: Fiber Optic Networks, (Prentice Hall, 1993), on which this course is based. Currently he is President of the IEEE Communication Society. --------------------------------------------------------------- Tutorial T3B: Metropolitan Area Networks. Instructor: James F. Mollenauer, Technical Strategy Associates. (Tuesday, Sept. 14th, 1:30-5:30). This tutorial will cover the applications, standards aspects, and technology of metropolitan area networks and their relationship to ATM technology. The need for segmented transmission to support data, voice, and video services led early on to the adoption of an ATM or cell-based transmission strategy. This provides a close relationship to ATM as it has emerged as a technology of choice for premises networks, replacing the shared medium LAN. The tutorial will cover private multiservice networks and public facilities and their support of voice and video in addition to data. Implementation issues will be addressed, both for the IEEE 802.6 MAN standard and for the public SMDS service based on it. Biography: James F. Mollenauer is currently President, Technical Strategy Associates, of Newton, Massachusetts, providing consultation in metropolitan and other high-speed networks from both a technical and product strategy point of view. Since 1982 he has chaired the standardization group for metropolitan area networks, IEEE Project 802.6. Prior to his present position Dr. Mollenauer was Vice President, Advanced Technology at Artel Communications Corporation, architecting a new line of very-high-performance LAN bridging and routing products. Previously he spent 17 years at Bell Laboratories, starting out in nuclear physics research and moving on to work in real-time computing, time sharing, and computer-aided design. He has also served at Prime Computer and its Computervision division in data communication architectures and planning, and at Codex Corporation, where he undertook strategic studies in LAN's and metropolitan area networks, and developed a wireless radio-based LAN. Dr. Mollenauer is the author of many articles and conference papers on metropolitan and high speed networks and is currently Chair of the IEEE Local Computer Networks Conference. He received his bachelor's degree at Amherst College and his PhD from the University of California at Berkeley. ************************************************************************** ************************************************************************** REGISTRATION INFORMATION Advance registration is available using the form below through September 7th. (E-mail registration available only through August 10th, and must use a credit card number). On site registration at the Westin St. Francis Hotel will be available starting Sunday, September 12th from 1PM-5PM, and every day of the conference starting at 7:30 AM. Student Registration includes conference proceedings and presentations but does not include the conference social event. --------------------------------------------------------------------------- SIGCOMM '93 Registration Form Please send this form and a check, credit card information, or money order (no purchase orders) to SIGCOMM '93. Registrations accepted via postal mail, FAX, or email only. SIGCOMM '93 Registrar Hewlett-Packard Laboratories, MS 1U-17 P.O. Box 10490 Palo Alto, CA 94303-0969 FAX: +1 415 813-3706 EMAIL: sigcomm93-registration@hp.com (**note) Inquiries only: +1 415 857-3295 (voice) ----------------------------------------------------------- If you are not an ACM or a SIGCOMM member at this time, you may join now to take full advantage of ACM/SIG Member or Student(*) rates for SIGCOMM '93: ACM Associate Member Dues __$79 US
Add SIGCOMM to ACM Membership                   __ $22 US ACM Student Dues __$24 US
Add SIGCOMM to ACM Student Membership           __ $15 US SIGCOMM Membership only (non-ACM) __$50 US

Total New Membership Fees                       $_____ US ----------------------------------------------------------- Tutorials (check the box for each tutorial attending) Note: You may select at most one tutorial from each session time (MAX 3). ___ High-Speed Transport Protocols ....................../__/ T1A (Monday, 1-5) ___ Interconnecting MANs and LANS to ATM . ............../__/ T1B (Monday, 1-5) ___ Wireless Communication Worldwide ..................../__/ T2A for Cellular and PCS (Tuesday, 8-12AM) ___ Trends and Challenges in ............................/__/ T2B Broadband Networking (Tuesday, 8-12AM) ___ All-Optical Networking ............................../__/ T3A (Tuesday, 1:30-5:30) ___ Metropolitan Area Networks ........................../__/ T3B (Tuesday, 1:30-5:30) Enter total number of tutorials at the appropriate rate: For registrations received (postmarked) by after August 10 1993 August 10 1993 #$'s Each     #    $'s Each --------------- --------------- ACM/SIG Member ___ @$ 99 US     ___ @ $125 US Non-Member ___ @$119 US     ___ @ $145 US Student* ___ @$ 50 US     ___ @ $50 US Total Tutorial Fee:$_____ US
-----------------------------------------------------------
Conference (select one):

by             after
August 10 1993   August 10 1993

ACM/SIG Member  ___ $290 US ___$340 US
Non-Member      ___ $355 US ___$395 US
Student*        ___ $100 US ___$100 US

Conference Fee:                                 $_____ US ----------------------------------------------------------- Extra Dinner/Cruise Tickets ___ @$53 US
(September 15)
Total for extra tickets:                        $_____ US ----------------------------------------------------------- Total Amount enclosed:$_____ US
-----------------------------------------------------------
Vegetarian Meals:   ___ YES  /  ___ NO
-----------------------------------------------------------

Name: ____________________________________

Affiliation: _____________________________

Phone: ___________________________________

FAX: _____________________________________

ACM Member #: ____________________________
(write "new" if joining at this time)

SIGCOMM Member?  ____ YES   /   ___ NO

Credit Card Payment

__ Visa    __ Mastercard

Card Holder Name: ________________________

Card Number: _____________________________

Expiration Date: _________________________

Signature: _______________________________

*  See the Advance Program section on student fees.
** Email registration is only available through August 10th and must
use credit card payment.

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

HOTEL REGISTRATION

The Westin St. Francis
Union Square
335 Powell Street
San Francisco, CA 94102  USA

A special conference rate has been arranged for attendees of
SIGCOMM '93.  These rates are applicable from September 10-17, 1993.
When making reservations by telephone, identify yourself as an
attendee of SIGCOMM '93.  Hotel reservation deadline: August 10,
1993. Reservations received after August 10, 1993 are subject to
availability and prevailing rates.

The Westin San Francisco will not hold your reservation after 6:00 PM
on the day of arrival without guaranteeing the reservation with a
check or money order in U.S. dollars covering the first night's stay
(including 11% occupancy tax) or a major credit card with expiration
date and authorized signature.

Deposits will be refunded only if cancellation notification is
received at least 24 hours prior to arrival.  Check in time is 3:00 PM.

Type of Room       Main Building       Towers
Single Double      Single Double
Standard           $120$120         -      -
Medium             $135$135        $155$155
Deluxe             $150$150        $170$170

Arrival Date: __________________________________

Departure Date: ________________________________

Name: __________________________________________

Share With: ____________________________________

_______________________________________

Daytime Telephone: ___________________

Check or Money Order Enclosed in amount:

_ Mastercard   _ American Express  _ Carte Blanche
_ Visa         _ Discover          _ Diners Club

Credit Card Holder's Name: _________________

Credit Card No: ____________________________

Expiration Date: ___________________________

Signature: _________________________________

Reservation by fax, dial: +1 774-0292/774-0124

Reservation by phone, dial: +1 415 397-7000

Identify SIGCOMM '93 for conference rates.

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

CONFERENCE COMMITTEE

General Chair: Imrich Chlamtac, Univ. Massachusetts
Program Chair: Deepinder Sidhu, Univ. Maryland - BC
Tutorial Chair: Ian F. Akyildiz, Georgia Tech
Local Arrangements Chair: Anujan Varma, Univ. California - Santa Cruz
Treasurer: Lixia Zhang, XEROX PARC
Publicity Chair: Craig Partridge, BBN
Fund Raising Chair: Biswanath Mukherjee, Univ. California - Davis
Registration Chair: Mark Laubach, Hewlett-Packard

INDUSTRIAL SUPPORTERS OF SIGCOMM '93

SIGCOMM '93 would like to thank Digital Equipment Corporation, Hewlett
Packard, International Business Machines Corporation, and XEROX Palo
Alto Research Center for their support of SIGCOMM '93.


-----------[000362][next][prev][last][first]----------------------------------------------------
Date:      Thu, 27 May 1993 13:44:45 +0200
From:      Andre' Pirard <pirard@vm1.ulg.ac.be>
To:        comp.protocols.tcp-ip
Subject:   Re: Class C Addresses & subnet masks

In article <738235608snz@peeras.demon.co.uk> Phil Royse,
proyse@peeras.demon.co.uk writes:
> In article <C7CDM2.In3@jti.com> richb@jti.com writes:
>
> >A little over a year ago I posted to this newsgroup with the same
> >
> >The feedback I got here was unanimous:  you'll regret subnetting your
> >Class C networks like that.  Not all _client_ IP implementations
support
> >this.
> >
> The formal tender documents I wrote and the supplier responded
> to includes categorical statements that the routers will all
> subnet down to the last two bits of the fourth octet.  Ie. the
>
> 255.255.255.192    ...224     ...240    ...248   and  ... 252
>
> Is this sensible?   Are there anyt other issues which might
> give us some problems??  (eg. problems on the host IP capability?)

No, this is not sensible. Given the new referred to Internet philosophy,
any router or host must also be able to subnet _up_ to some bits too,
which means consolidating a "power-of-two" range of class C networks into
a single view.
Software writers beware, the RFC has no restriction about the mask and
what has been good intention check one day may become bad service
to-morrow.
As a one off example, I would choose MacTCP whose subnetting slidebar
bangs on the left side.

Related considerations.
A multiple-class-C network can alternatively be setup so that the home
router relays data onto the same network. Ugly, but works as long as the
router can be configured with multiple interface addresses, like cisco
(hey, Tony, I guess you (and others) don't send ICMP redirect in _that_
"same interface" case).
But what if one would wish to save some traffic by configuring part of
the hosts with the "consolidated mask"?
ARPs sent by the latter ones could be with all ones, but will or how will
the former reply? Any other problem? I guess! Seems like opening a can of
worms!
However, the problem is not quite new with those hosts unable to subnet.

------
Andre' Pirard         SEGI, Universite' de Liege  139.165 IP coordinator
B26 - Sart Tilman     B-4000 Liege 1 (Belgium)           +32 (41) 564932
pirard@vm1.ulg.ac.be  alias PIRARD@BLIULG11.BITNET


-----------[000363][next][prev][last][first]----------------------------------------------------
Date:      27 May 93 17:06:04 GMT
From:      daveb@jaws (David Breneman)
Subject:   SLIP for 3B2

Greg's 3B2 FAQ contains a cryptic message :-) about SLIP for the 3B2:

---CUT---
------------------------------------------------------------------------
Subject: 14 Is there an implementation of SLIP for the 3B2?
------------------------------------------------------------------------

Rumor has it that there was one written by Wollongong, but AT&T
purchased exclusive marketing rights to WIN TCP/IP for the 3B2, but
chose NOT to include SLIP.  There is the NOS (KA9Q) package that
supposedly provides SLIP capabilities, but I have not tried it and
don't know if it'll run on a 3B2.

---CUT---

What is the NOS package?  *Has* anybody ported SLIP to the 3B2?
"Enquiring minds which can't afford an ethernet card want to know."
Thanks to any and all respondants.

--
David Breneman                          Email: daveb@jaws.engineering.dgtl.com
Software Engineering Services
Digital Systems International, Inc.     Voice: 206 881-7544  Fax: 206 556-8033


-----------[000364][next][prev][last][first]----------------------------------------------------
Date:      Thu, 27 May 1993 14:14:56 +0200
From:      Andre' Pirard <pirard@vm1.ulg.ac.be>
To:        comp.protocols.tcp-ip
Subject:   Re: Subnetting question...

In article <1993May26.222718.2142@tolten.puc.cl> Jorge Cisternas M.,
jcistern@lascar.puc.cl writes:
> Hi:
> 	We have a class B network, but I need smallest's subnetworks (much
> less than 253 hosts per net), so I think on change some subnetmasks.
>
> 	What I think on is:
>
> 146.155.1.0	255.255.255.0	(the backbone)
> 146.155.31.0	255.255.255.224	(one subnet of 30 hosts)
> and so on.
>
> And between the backbone and the subnets, a public domain pcroute
> (V. Morrison's), with one interface 146.155.1.57, subnetmask
> 255.255.255.0, and the other interface 146.155.31.1, subnetmask
> 255.255.255.224.
>
> 	My question: SHUOLD THIS WORK, OR I NEED TO CHANGE ALL MY
> NETWORK'S SUBNETMASK TO DO THIS?

Vance states explicitly that interfaces of PCROUTE can have different
subnetting.
From what I know of PCROUTE (much, but not tried this), I think it should
work if all the networks beyond one PCROUTE are deeper-subnetted the same
way in a single cluster and rely on RIP default route (and none appears
elsewhere than in this cluster, of course). What I would try first is how
RIP behaves on the normal subnet side (if it consolidates the subnets).

------
Andre' Pirard         SEGI, Universite' de Liege  139.165 IP coordinator
B26 - Sart Tilman     B-4000 Liege 1 (Belgium)           +32 (41) 564932
pirard@vm1.ulg.ac.be  alias PIRARD@BLIULG11.BITNET


-----------[000365][next][prev][last][first]----------------------------------------------------
Date:      Thu, 27 May 1993 18:29:33 +0000
From:      proyse@peeras.demon.co.uk (Phil Royse)
To:        comp.protocols.tcp-ip
Subject:   Re: IP Routing Questions on Subnet Masks and Multicasting

In article <1993May25.185453.19457@lclark.edu> don@lclark.edu writes:
>
>Hello,
>
>I have a series of relatively straight forward IP routing questions which
>are primarily focused on creative IP mask construction and multicasting
>
>149.175.1.0
>149.175.2.0
>149.175.3.0
>149.175.4.0

>  Does this particular scheme look right?
>
>
>.... ... ... ... ....           Don Weston, Jr.           .... ... ... ... ...

Don,

The plan you suggest does seem to be a good idea.
If I have understood your plan correctly, you will get ONE subnet
with 510 hosts, for each Clump o' Cs, so long as the clumps are
contiguous.

I have just drawn up an IP address plan for a large UK org.
which was given a clump o' 16 Cs for 60 or so offices, despite
our application for a Class B.  It was quite a headache jumbling
the number range and the masks.

None of our subnets needed more than 255 hosts, so we
subnetted "down" not "up" as you are doing.

One problem with subnetting down is that one cannot have a subnet
mask of 255.255.255.128  as that forces the network number
to be an illegal one or zero, thereby losing address space.  We
would have liked to have had two subnets of 126 hosts from
out of one Class C, but can't, the nearest is two subnets
of 62 hosts with a subnet mask of 255.255.255.192

Regards,

Phil R.

--

Phil Royse     Comms Consultant  | member:  The Peer Association
TUDOR HOUSE                      | (networking & OSI specialists)
Surrey  CR8 4LN   (UK)        Tel: (+44) 81 645-9868


-----------[000366][next][prev][last][first]----------------------------------------------------
Date:      27 May 1993 19:28:56 GMT
From:      mengel@dcdmwm.fnal.gov (Marc Mengel)
To:        comp.protocols.tcp-ip
Subject:   Re: SLIP Recommendations

In article <SCOTT.93May26210403@nova.tcs.tufts.edu>, scott@nova.tcs.tufts.edu
|>     If multiple SLIP links share the same modem means supporting the
|>     connections simultaneously (ie a multi-drop line), then I am
|>     unaware of any SLIP implementation which supports this (is it even
|>     possible)... :-)

I guess I'm having trouble seeing why this would be so difficult, if you
had some sort of box to hand around ClearToSend leads to each connection
on the multi-drop (which multi-drop lines usually do...)  Of course you
would "hear" lots of frames that weren't yours, which would be bad if you
tried to route them...

-------
Marc Mengel
mengel@fnal.fnal.gov


-----------[000367][next][prev][last][first]----------------------------------------------------
Date:      Thu, 27 May 1993 21:46:13 GMT
To:        comp.protocols.tcp-ip
Subject:   Re: MacTCP 1.1.1 and DNS...

In article <1993May27.132706.12720@comp.lancs.ac.uk> keith@comp.lancs.ac.uk (Mr K C Craig)  writes:
>
>
>Just as word of a warning (and maybe a question to) when you run MAC TCP/IP, it
>doesn't seem to bother to check if the IP address that you supply to it is already in use.
>This makes for great "entertainment" if a user places the IP address of your X-Term server
>in their configuration by mistake.  In PC TCP/IP work I have done the system checks to
>
>Is there anyway of avoiding this problem? (with the exception of dynamically assigning
>IP addresses, which I can't do in these cases.)

Actually, MacTCP will not let you do this.

If MacTCP has not yet been initialized and a program calls TCPOpen() (or
whatever the call really is), it will arp for its address and fail to
open if present.

It will not report any problems if its address appears between runs of a
program that uses MacTCP (then it's the other machine's fault).

>Keith Craig
--
MicroConsultant                       		  Rice University
(What is that? A small consultant?)	              Houston, TX
Any resemblance between real opinions and my post is coincidental


-----------[000368][next][prev][last][first]----------------------------------------------------
Date:      Thu, 27 May 1993 20:29:12 +0200
From:      Andre' Pirard <pirard@vm1.ulg.ac.be>
To:        comp.protocols.tcp-ip
Subject:   Time synchronization

and I finally decided to take some time for a text in hope it reaches the
persons in a position to solve an irritating problem.
So, please forward if you know where to someone interested.

Computers normally get UTC time from their clock.
A local algorithm converts UTC to local for user display.
The algorithm adds a fixed value (time zone) and often a varying one
(daylight savings). (And doing it the other way round makes the following
problem even worse). Daylight savings is a rule RFCs cannot counteract.
UTC is the only time machines can exchange in the _general case_, because
they may be in different time zones.

Bigger systems' administrators know more of it, to varying degrees, but
especially that daylight savings rules are far from set in stone
(sometimes depending more on farmers' complaints that on computer
sanity). People's bored care is generally a rough setting of their local
clock so that the various _local_ dates in their system do not look
completely idiot in the _middle_ of summer.

Being on a network both strengthens the need for correct clock
synchronisation and offers means to achieve it.
The NTP protocol is the most refined way to distribute UTC to larger
machines with precision by far better than one second.
SNTP can be used to redistribute it to smaller ones, as a successor to
the TIME protocol (used by the setclock command).

A network administrator regrets that it is not possible, in the
_particular case_ of his machines with same time zone and daylight
savings rule, to concentrate a subject to change time offset information
on his few time servers and redistribute it automatically in addition to
UTC without a per TCP/IP implementation hack, because no time protocol
conveys the local offset (and DAYTIME is unspecified format and still a
hack to use).

Had the TIME protocol conveyed a few more bytes with this information, a
setclock writer for the PC would probably have used what he found in it
to be able to set the PC's (local time) clock without requiring a TZ
maintained by the user or set the TZ itself altogether so that the PC can
finally use UTC.
More generally speaking, an option of the setclock command could then
indicate if the server is known to use the same time offset as the client
and the time offset set in addition to UTC (the particular case).

The question are: could the TIME protocol be augmented with time offset?
If not, should the SNTP tackle the problem?
Else, is yet another time protocol needed so that the operation will be
possible in a few years?
Or is a world-wide strike to stop daylight savings the only solution?

------
Andre' Pirard         SEGI, Universite' de Liege  139.165 IP coordinator
B26 - Sart Tilman     B-4000 Liege 1 (Belgium)           +32 (41) 564932
pirard@vm1.ulg.ac.be  alias PIRARD@BLIULG11.BITNET


-----------[000369][next][prev][last][first]----------------------------------------------------
Date:      28 May 1993 00:15:23 GMT
From:      trier@odin.ins.cwru.edu (Stephen C. Trier)
To:        comp.protocols.tcp-ip
Subject:   Re: Time synchronization

BOOTP can convey time-zone information in the RFC 1084 vendor extension
field.

Some operating systems support automatic daylight savings time adaptation.
For those, being in the right time zone is not a major problem.

--
Stephen Trier (trier@ins.cwru.edu - MIME OK)
Network Software Engineer
IRIS/INS/T
Case Western Reserve University


-----------[000370][next][prev][last][first]----------------------------------------------------
Date:      Fri, 28 May 1993 09:59:14 GMT
From:      masmm@gdr.bath.ac.uk (M McGettrick)
To:        comp.protocols.tcp-ip
Subject:   RPC problems with clnt_create() and pmap_getmaps()


I have a problem with making an rpc call to certain hosts (as far as I can
figure out, only to RS6000s (AIX)). Basically the clnt_create() routine fails
with the message "port mapper failure" followed by RPC: Timed Out. This
happens after say (roughly) 20 seconds. The thing is if I don't get a client
handle from clnt_create(), I can go no further.

Does anyone know how to set the TIMEOUT for the clnt_create() call itself, or
is this possible (I understand there's a default timeout of 25 seconds on RPC
stuff - I want clnt_create() to keep trying for longer than that!)?

(
To be more specific here, and example of a call I try which fails is
cl = clnt_create("130.233.224.22", 100000, 2, "tcp");
)

Another (perhaps related) problem is this: the pmap_getmaps() routine also
fails for certain hosts. This is puzzling, as the rpcinfo command succeeds
for these same hosts, and as I understand it rpcinfo uses pmap_getmaps().
Any hints here (or is it possible to get a look at the source code for
rpcinfo)?

Thanks!

Michael Mc Gettrick,
University of Bath.
(masmm%gdr.bath.ac.uk@cunyvm.cuny.edu)


-----------[000371][next][prev][last][first]----------------------------------------------------
Date:      28 May 93 10:23:24 GMT
From:      bqt@Minsk.docs.uu.se (Johnny Billquist)
To:        comp.protocols.tcp-ip
Subject:   Re: How to convert ethernet hard. addr. to IP addr.? ARP?

In <1u2lse$dle@hermes.ath.epa.gov> kbw@helios.ath.epa.gov (Kevin B. Weinrich) writes: >I know how (via kludge) to get an ethernet hardware address from an IP >address: > ping host.domain > arp -a >will first add host.domain to arp's table, then list all the machines >currently in the table, including both numeric IP addr and ether hardware >addr. There's probably a slicker way to do this; I'd be thankful for hearing >of it. >But how can I do the reverse: start with an ethernet hardware address, and >wind up with the IP address it goes with? Was some time since I looked through this, but i think that's what RARP are for. However, if I understand correctly, you are interested in finding out for yourself, and not if the system can solve this for its own uses. I don't know if and how you can talk directly to ARP and RARP, but it should be possible in some way. I have only implemented ARP under another OS, haven't played with it that much under unix. -- Johnny Billquist || "I'm on a bus CS student at Uppsala University || on a psychedelic trip email: bqt@minsk.docs.uu.se || Reading murder books pdp is alive! || tryin' to stay hip" - B. Idol  -----------[000372][next][prev][last][first]---------------------------------------------------- Date: 28 May 1993 10:25:37 GMT From: ruspc40@rus.uni-stuttgart.de (Peter Kolb) To: comp.protocols.tcp-ip Subject: Paket Driver for SMC 8013EPU wanted  Hello I am not sure if this is the right groupe to post, but I try first here. I am looking for a paket driver for the SMC Ether Card PLUS. The full name is 8013EPC, and I know that SMC did WD stuff. I have already looked in ARCHIE , and didnt find one. I need it for runnig telnet on a MS-DOS PC. May someone of you know where I can find one , or where I can get an telnet that supports this ethernetcard. Pleas send E-Mail: torfnase@berapc.rus.uni-stuttgart.de or just post in here Thanx Peter Kolb  -----------[000373][next][prev][last][first]---------------------------------------------------- Date: Fri, 28 May 1993 10:27:50 GMT From: hmchen@fcom.ee.ntu.edu.tw (Hung-ming Chen) To: comp.protocols.tcp-ip Subject: Select function call question?  Dear Netter, I wrote a program using select function under Socket. When I tested the program, sometimes the select function acted something wrong. Its return value was greater than zero. But when I tried to check the readmask(declare as fd_set), there was nothing setting on. And my program did a endless loop that caused all system CPU time were eaten by it. What's happenned? Can I avoid this condition, or when it occured how to detect it and recover? P.S. It almost occured when something did a wrong action. Fred Chen  -----------[000374][next][prev][last][first]---------------------------------------------------- Date: Fri, 28 May 1993 10:56:49 GMT From: norbert@dfv.rwth-aachen.de (Norbert Vohn) To: comp.protocols.tcp-ip Subject: sliding window protocols  Hello there! I'm a student of electrical engineering and just doing my masterthesis. In the scope of this I need to implement a sliding window protocol (with selective repeat) for usage in an simulation tool. (see Andrew S. Tanenbaum, Computer Networks) Maybe there exist some implementations in C++ or C? Is there anyone who knows something about it, or even knows how to implement the protocol quickly by myself? So, I would wonder if someone of you could help me! _______________________________________________________________________________ Norbert Vohn | C O M Communication Networks, Technical University of Aachen | --v-^-v-^-v-^-v-- Phone: +49-241-807925 Fax: +49-241-84964 | N E T S Email: norbert@dfv.rwth-aachen.de | RWTH Aachen, Germany -- Norbert Vohn | C O M Communication Networks, Technical University of Aachen | --v-^-v-^-v-^-v-- Phone: +49-241-807925 Fax: +49-241-84964 | N E T S Email: norbert@dfv.rwth-aachen.de | RWTH Aachen, Germany  -----------[000375][next][prev][last][first]---------------------------------------------------- Date: 28 May 93 11:10:09 GMT From: gerry@spider.co.uk (Gerry Meyer) To: comp.protocols.tcp-ip Subject: Re: RFC for keepalives  emv@garnet.msen.com (Edward Vielmetti) wrote: >Frank Ciotti (frankc@teleng.eng.telxon.com) wrote: >: Is there an RFC for TCP keepalive polls? I could not find any reference >: to them in the RFC index, RFC 793, RFC 896, or the Comer/Stevens books. >A quick WAIS search of "internet-rfcs" for "keepalive" or "keepalives" >threw up references to these RFCs - I don't know how much they say about >them tho (someoen who could condense these referecnes into something >useful would be welcomed). >rfc1267.txt rfc1163.txt rfc1105.txt rfc969.txt rfc998.txt rfc1323.txt >rfc1265.txt rfc1164.txt I hope all references to TCP keepalives in these will be unfavourable. They are a practice to be severly frowned upon. As an example if you make a telnet connection via a wide area network dialup/demand connection and leave yourself logged in over the week end YOU will foot the telephone bill because these useless keepalives have forced your router to keep the call open UNNECESSARILY.  -----------[000376][next][prev][last][first]---------------------------------------------------- Date: 28 May 93 16:36:24 From: drw@zermelo.mit.edu (Dale R. Worley) To: comp.protocols.tcp-ip Subject: Return-receipt-to and Errors-to headers  There are a small number of headers that sendmail implements but are not described in RFC 822. Most useful among these are Return-receipt-to: and Errors-to:. Has there been a more recent RFC that has standardized these, or are they still strictly non-standard? Would it be a useful thing to produce an RFC that standardized them? Thanks, Dale  -----------[000377][next][prev][last][first]---------------------------------------------------- Date: Fri, 28 May 1993 09:54:03 +0200 From: Andre' Pirard <pirard@vm1.ulg.ac.be> To: comp.protocols.tcp-ip Subject: Re: SLIP Recommendations  In article <1u34pp$n7u@fnnews.fnal.gov> Marc Mengel,
mengel@dcdmwm.fnal.gov writes:
> In article <SCOTT.93May26210403@nova.tcs.tufts.edu>,
scott@nova.tcs.tufts.edu
> |>     If multiple SLIP links share the same modem means supporting the
> |>     connections simultaneously (ie a multi-drop line), then I am
> |>     unaware of any SLIP implementation which supports this (is it
even
> |>     possible)... :-)
>
> I guess I'm having trouble seeing why this would be so difficult, if you
> had some sort of box to hand around ClearToSend leads to each connection
> on the multi-drop (which multi-drop lines usually do...)  Of course you
> would "hear" lots of frames that weren't yours, which would be bad if
you
> tried to route them...

The first aspect is that the SLIP encapsulation just doesn't provide the
information to sort out multiplexed level 2 connections on a single line.
One could use  another protocol to tunnel SLIP indeed, but that wouldn't
be SLIP we would be talking of any longer.

The second aspect is that PPP is able to multiplex different protocols,
because its encapsulation contains a protocol type (while SLIP implies
IP).

Did I understand correctly so far?

The third aspect I am raising is that, when properly configured, a Cisco
Terminal Server is able to "multiplex SLIP at level 3" or, in simpler
parlance, to connect a remote IP network (not a single IP address) over a
dialup or fixed asynchronous line (and in fact do everything the full
blown routers do on synchronous line, but limited to IP, for example load
balancinng on parallel lines, X.25 over IP, ..., isn't that lovely). SLIP
or CSLIP on demand.
For that matter, they have been quite appropriately renamed
"Communication Server", specifically models CS 508 and CS 516 (8/16
ports).
Does any other make do similar things?

------
Andre' Pirard         SEGI, Universite' de Liege  139.165 IP coordinator
B26 - Sart Tilman     B-4000 Liege 1 (Belgium)           +32 (41) 564932
pirard@vm1.ulg.ac.be  alias PIRARD@BLIULG11.BITNET


-----------[000378][next][prev][last][first]----------------------------------------------------
Date:      Fri, 28 May 1993 10:47:24 +0200
From:      Andre' Pirard <pirard@vm1.ulg.ac.be>
To:        comp.protocols.tcp-ip
Subject:   Re: Time synchronization

In article <1u3lir$g90@usenet.INS.CWRU.Edu> Stephen C. Trier, trier@odin.ins.cwru.edu writes: > BOOTP can convey time-zone information in the RFC 1084 vendor extension > field. I am not sure that a bootp server would (presently) be the best means to answer such requests coming from all over the campus. A fact is that the idea did not materialize in PC setclock implementation. Something more obvious would be needed. You're sure right in migrating the idea that the info could come from sort of a 'campus info' protocol, together with other data. An extendable protocol. This would further simplify TCP/IP installation indeed. In fact, there are too many protocols providing what a single one could give (TIME, DAYTIME, BOOTP, ICMP router discovery, RARP ...). Some info being LAN specific and the other general, are two protocols needed or can a single one be designed so that a local server fills in general info from a global one. Is it the role of the local router (replaced by a local host if there is no router) to answer the (broadcast) request (instead of requiring a full blown server on each and every tiny network). Or are request to be forwarded to the global one that would recognize the originating network? Maybe an extended BOOTP after all? Dunno. Of course, it wouldn't simplify setup until the protocol became a requirement... ------ Andre' Pirard SEGI, Universite' de Liege 139.165 IP coordinator B26 - Sart Tilman B-4000 Liege 1 (Belgium) +32 (41) 564932 pirard@vm1.ulg.ac.be alias PIRARD@BLIULG11.BITNET  -----------[000379][next][prev][last][first]---------------------------------------------------- Date: Fri, 28 May 1993 14:20:50 GMT From: cam@mbunix.mitre.org (McLaughlin) To: comp.protocols.tcp-ip Subject: Routing Protocol Overhead - Class C vs. Class B  Has anyone got information on differences in routing protocol overhead expected when a set of Class C networks ( > 256 nets) is implemented vs. several Class B networks? The Class Cs will be set up to take advantage of supernetting, when supernetting becomes available. Until then, what should we expect? We're looking at using BGP3, currently are using EGP, OSPF. Colleen McLaughlin cam@mbunix.mitre.org C2 Communications The MITRE Corp.  -----------[000380][next][prev][last][first]---------------------------------------------------- Date: Fri, 28 May 1993 14:31:33 GMT From: vjs@rhyolite.wpd.sgi.com (Vernon Schryver) To: comp.protocols.tcp-ip Subject: Re: RFC for keepalives  In article <1993May28.111009.15926@spider.co.uk>, gerry@spider.co.uk (Gerry Meyer) writes: > > I hope all references to TCP keepalives in these will be unfavourable. > They are a practice to be severly frowned upon. > > As an example if you make a telnet connection via a wide area network > dialup/demand connection and leave yourself logged in over the week end YOU > will foot the telephone bill because these useless keepalives have > forced your router to keep the call open UNNECESSARILY. That's such an overstatement that it is simply wrong. First, if the router keeps the call alive continually, then the router is broken. A packet every few hours should not require the router to keep the line open continually. It should simply than restore the line for a few minutes every few hours to pass the keepalive. (Assuming the now typical hours between keepalives.) Second, people really need keepalives in many circumstances. If they didn't they wouldn't continually ask about them in this newsgroup. That they usually don't use the right jargon, and instead ask about determining if a link has died is not their fault. That keepalives are not always useful or that they are not free does not imply that they should be outlawed. Vernon Schryver, vjs@sgi.com  -----------[000381][next][prev][last][first]---------------------------------------------------- Date: 28 May 93 15:48:25 GMT From: lvandyke@balboa.eng.uci.edu (Lee Van Dyke) To: comp.protocols.tcp-ip Subject: When does recv exit if its buffer is not full?  Hi, in general, does anyone know when recv exits if its buffer is not full? I am losing data when sent from a sun to a pc running dvx, using the dvx recv. TIA Lee -- Lee Van Dyke lvandyke@balboa.eng.uci.edu, UUCP: infotec!Infotec.COM!lee@sunkist.West.Sun.COM  -----------[000382][next][prev][last][first]---------------------------------------------------- Date: 28 May 93 16:42:11 GMT From: ercm20@festival (Sam Wilson) To: comp.protocols.tcp-ip Subject: Re: MacTCP 1.1.1 and DNS...  Mr K C Craig (keith@comp.lancs.ac.uk) wrote: : Just as word of a warning (and maybe a question to) when you run MAC TCP/IP, it : doesn't seem to bother to check if the IP address that you supply to it is already in use. : This makes for great "entertainment" if a user places the IP address of your X-Term server : in their configuration by mistake. In PC TCP/IP work I have done the system checks to : see if the IP address has already been used. Err... I had a user phone me the other day to say that she couldn't get Telnet started on her Mac because MacTCP was complaining that someone else was using its IP number (indeed it was!). There may be a version difference here, but whatever we are using (could be 1.1.1) obviously does check, presumably by doing an ARP for its own address. Sam Wilson Network Services Division Computing Services, The University of Edinburgh Edinburgh, Scotland, UK  -----------[000383][next][prev][last][first]---------------------------------------------------- Date: Fri, 28 May 1993 17:00:52 GMT From: richb@jti.com (Rich Braun) To: comp.mail.sendmail,comp.unix.admin,comp.protocols.tcp-ip Subject: SysVr4 + IDA sendmail: FQDN anomaly  Sending mail from my site to users on the following sites doesn't work: Generic name FQDN of primary MX forwarder u.washington.edu bashful.u.washington.edu apollo.hp.com daphne.ch.apollo.hp.com attmail.com att.att.com What these sites have in common is this: sending mail to "user@FQDN" will bounce or fail to get through a gateway sitting behind a firewall; this is how those sites are configured. For most sites, sending mail to "user@generic" works fine; from here, it doesn't. I'm running IDA sendmail v5.65c, and Microport SysVr4.1 (also Unix 3.2 as shipped by Intel about 3 years ago). What I'm looking for is other people who are running the same combination of software to test mail directed toward these sites. Any SysV implementation may or may not exhibit this behavior, and I'm curious as to just how many people might run into this problem. To test this, run 'sendmail -bt' and enter the command '3,0 foo@generic.site.domain' and see if it translates the name to a FQDN or leaves it well enough alone. What's happening is the DNS resolver is substituting the MX gateway's FQDN for the generic name in rule set 8 within IDA's Sendmail.mc rule. According to Neil Rickert, this should not be happening, and it signifies a bug in the vendor's resolver library. This problem has caused some embarrasing moments for me as I've reported "bugs" to the postmasters at these sites, and although they've got their sites configured in somewhat unusual ways, there's nothing about them which violates any of the SMTP standards. -rich  -----------[000384][next][prev][last][first]---------------------------------------------------- Date: 28 May 1993 17:55:29 GMT From: carl@busop.cit.wayne.edu (carl@busop.cit.wayne.edu) To: comp.protocols.tcp-ip Subject: working COOKIE servers ... need IP addresses ?  I doubt this is the best place to post such a request, but I couldn't find anywhere else that seemed appropriate. Does anyone have any COOKIE server addresses, perferably in the U.S., as many as you can list? Thank you.  -----------[000385][next][prev][last][first]---------------------------------------------------- Date: 28 May 93 18:55:21 GMT From: guy@Auspex.COM (Guy Harris) To: comp.protocols.tcp-ip Subject: Re: sockoptions in TLI  >>I have a system which is built around TLI (SunOS). Since the transport >>provider I'm using (tcp) is configured with the Nagle-algoritm option disabled >>(The TCP_NODELAY for sockets) and my system sends out a lot of small packets >>I'd like to set the TCP_NODELAY option thus enabling the Nagle algoritm > >//[turning O_NDELAY on] works on a SunOS 4.1.x Sorry, wrong answer. TCP_NODELAY has nothing to do with O_NDELAY; TCP_NODELAY disables the Nagle algorithm, while O_NDELAY puts the file descriptor into "no delay" mode. From a look at the SunOS 4.1[.x] code, it appears that the "/dev/tcp" code will turn the Nagle algorithm off whenever it accepts a connection, or whenever, when making a connection, the other side accepts the connection.  -----------[000386][next][prev][last][first]---------------------------------------------------- Date: Fri, 28 May 1993 19:03:18 GMT From: yefim@magna.com (Yefim V. Natis) To: comp.protocols.tcp-ip,comp.protocols.misc,comp.protocols.ibm Subject: CPI-C over TCP/IP  I am looking for communications software with CPI-C (or near) API to use on a TCP/IP-connected network. The hardware involved is the major flavors of UNIX servers, the IBM mainframes, and Bull (Honeywell) mainframes. Please help, if you can. Find me at ynatis@magna.com on uunet. Thanks Yefim Natis Software Architect Magna Software Corporation  -----------[000387][next][prev][last][first]---------------------------------------------------- Date: Fri, 28 May 93 19:13:00 GMT From: hgv@herring.network.com (Harry G. Varnis) To: comp.protocols.tcp-ip Subject: Rare (but nasty) BSD TCP problem  I recently stumbled across an admittedly weird case of socket misuse that locks up SunOS 4.1 tighter than a drum. It happens when an application connects through a local interface to the same port to which it is bound. From experimentation on another platform it appears that the TCP is mangling the tcb state in such a way as to induce a hard loop doing tcp_output-s. If someone knows of a fix to this problem I would appreciate hearing of it. Here is the program. Execute at your own risk. #include <sys/types.h> #include <sys/socket.h> #include <netinet/in.h> main() { struct sockaddr_in server; int s, length; s = socket(AF_INET, SOCK_STREAM, 0); if (s < 0) { perror("socket"); exit(1); } bzero(&server, sizeof(server)); server.sin_family = AF_INET; server.sin_addr.s_addr = INADDR_ANY; server.sin_port = htons(0); if (bind(s, &server, sizeof(server)) < 0) { perror("bind"); exit(1); } length = sizeof(server); if (getsockname(s, &server, &length) < 0) { perror("getsockname"); exit(1); } printf("local: addr %s port %d\n", inet_ntoa(server.sin_addr), ntohs(server.sin_port)); server.sin_addr.s_addr = inet_addr("127.0.0.1"); printf("connecting: addr %s port %d\n", inet_ntoa(&server.sin_addr), ntohs(server.sin_port)); if (connect(s, &server, sizeof(server)) < 0) { perror("connect"); } exit(0); } -- Harry Varnis <hgv@anubis.network.com> +1 612 493 1042  -----------[000388][next][prev][last][first]---------------------------------------------------- Date: Fri, 28 May 1993 19:17:06 +0000 From: pbs@lmrln.demon.co.uk (Philip Shearer) To: comp.protocols.tcp-ip Subject: SLIP Recommendations  |> I was wondering if anyone could tell me about some good SLIP |> implementations. I am trying to connect remote PC's to a central |> Sun 690. The connections will not be up 24 hours/day, but rather |> about 4-6 hours/day. |> |> Could anyone help me as to reasonable modem and phone line specs |> as well? Is there any software or hardware that can manage several |> slip connection through a single serial line? |> |> Thanks for your help!!! |> |> Jeffrey Horn I have a setup somthing like the set up you wish to have. I have a couple of sites where I run Sun machines with a PD version of slip: slip-4.1-beta from Mark.Andrews@syd.dms.csiro.au I picked it up with ftp from src.doc.ic.ac.uk This version works with SunOS 4.1.x The suns are connected via tcp/ip to terminal servers manufactured by Chase Resurch here in the UK. I have seen adverts for them in US mags but if you want info mail hda@chaser.co.uk {Terminal servers alow you to place the serial connectons near the phone lines and only have one eiternet cable to the place where the modems and phone lines are.} Attached to the terminal servers are a number of modems. We use telibits 2500s but they are expensive and not neccerily what you need. Any good V42 bis modem will do. Here in the UK I connect to Internet via a dialup connection using slip to a company called DEMON LTD. Since they started last year they built up their client list to 1000+, most clients are using dialup slip/ppp connections to their machines. I connect using UNIX, but many of their clients use PD PC slip/ppp software. I am not to hot on PD PC software but I believe that they recomend ka9q but I might be wrong. I would suggest that you contact them at email address: internet@demon.co.uk. I am shure that any consultancy fees that they charged you would be well worth while.  -----------[000389][next][prev][last][first]---------------------------------------------------- Date: 28 May 93 19:27:48 GMT From: paul@alantec.com (G. Paul Ziemba) To: comp.protocols.tcp-ip,comp.sys.sun.admin,comp.security.misc,comp.unix.admin Subject: Announcing tcpr: proxy ftp/telnet through firewall  Tcpr was announced on the firewalls mailing list at the beginning of the year; after a few tweaks, it seems as if it's ready for a wider distribution. The currrent release is 1.1.5. [From the README file] Tcpr is a set of perl scripts that enable you to run ftp and telnet commands across a firewall. Forwarding takes place at the application level, so it's easy to control. Tcpr consists of an inetd-type server that interprets commands, a relay program, and a client that talks to the server. The client asks the server for a relay connection to some specified remote host at a specified TCP port number; the server invokes the relay program and returns a proxy port number to the client. The client then invokes telnet or ftp, telling them to connect to the relay host at the proxy port number. The relay program then transfers data between the client host and the remote host. Special handling is implemented for the FTP data connection, so everything works properly. Where to get it Tcpr is available from the following servers via anonymous ftp: ftp.alantec.com pub/tcpr ftp.cs.umb.edu pub/security ftp.psg.com pub/unix/netware grasp1.univ-lyon1.fr pub/unix/network/tcpip/security ftp.denet.dk pub/misc/tcpr Platforms Tcpr is known to work on SunOS 4.1. I haven't tested it on other platforms, so I can't say if it'll work right out of the box for them. It's all perl, but the output format of the netstat and ifconfig commands might vary, and there isn't much flexibility in the parser for that yet. Acknowledgements The tcpr package is based on a relay program written by Kazumasa Utashiro, <utashiro@sra.co.jp>. The relay program originally was to be invoked manually on the relay host, giving a port number which the user then used as an argument to the ftp or telnet program. I modified the relay program to select an outgoing interface based on some simple routing computations, and wrote a client and server to automate the process. Many thanks to the maintainers of the ftp sites mentioned above, listed in reverse alphabetical order (-: Christophe.Wolfhugel John P. Rouillard Kim H|glund Randy Bush -- Paul Ziemba, software archaeologist: paul@alantec.com alantec!paul "The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore, all progress depends on the unreasonable man." - George Bernard Shaw  -----------[000390][next][prev][last][first]---------------------------------------------------- Date: Fri, 28 May 1993 21:30:37 GMT From: mahmood@lambda.msfc.nasa.gov (Rafique Mahmood) To: comp.protocols.tcp-ip,comp.sys.sun.admin Subject: Need help on running 'tcpview'  Problem/question 1: I have installed the tcpview in sun sparcstation 2. I have problem to link with the option '-Bstatic' which is in the makefile. It tells: Undefined -dlsym -dlopen -dlclose Then I took '-Bstatic' out and it compiled fine. What is this Bstatic does? Is is ok to link without it? Problem/question 2: When I try to run tcpview it says: tcpdump: open: /dev/nit: permision denied. I looked at /dev/nit. it had only root read write permision: crw-r--r-- 1 root 37, 40 Jan 10 1991 nit I then changed the permision to: crw-rw-rw- 1 root 37, 40 Jan 10 1991 nit That solved the permision problem but after window comes up everything get hung. What is the problem? I was running as a user. Is is that only root can run it? I could not run as a root because it gave lots of warning: Warning: translation table syntax error: Unknown keysym name: osfDown Warning: ... found while parsing 's c <Key>osfDown:forward-paragraph(extend)' Warning: translation table syntax error: Unknown keysym name: osfDown Warning: ... found while parsing 'c <Key>osfDown:forward-paragraph()' Warning: translation table syntax error: Unknown keysym name: osfDown Warning: ... found while parsing 's <Key>osfDown:process-shift-down()' Warning: translation table syntax error: Unknown keysym name: osfDown Warning: ... found while parsing '<Key>osfDown:process-down()' Warning: translation table syntax error: Unknown keysym name: osfHelp Warning: ... found while parsing '<Key>osfHelp:ManagerGadgetHelp()' Warning: translation table syntax error: Unknown keysym name: osfActivate Please let me know what are these error ( seems motif error)? what can I do for this? It seems still it runs ok (I don't know what to expect). My last question is how can I save the captured packets in a file? Thanks and I appreciate verymuch any help. please email me the response. Rafique email: mahmood@lambda.msfc.nasa.gov  -----------[000391][next][prev][last][first]---------------------------------------------------- Date: 29 May 1993 00:43:52 GMT From: barr@pop.psu.edu (Dave Barr) To: comp.protocols.tcp-ip Subject: Re: Rare (but nasty) BSD TCP problem  In article <1993May28.191300.21994@ns.network.com> hgv@herring.network.com (Harry G. Varnis) writes: >I recently stumbled across an admittedly weird case of socket misuse >that locks up SunOS 4.1 tighter than a drum. Sure does. I ran it on a 4.1.1B (plus lots of patches) machine and it locked up real tight. But, I ran it on a 4.1.3 machine and it was fine. --Dave -- System Administrator, Penn State Population Research Institute End of article 2565 (of 2565)--what next? [npq]  -----------[000392][next][prev][last][first]---------------------------------------------------- Date: 29 May 1993 02:32:10 GMT From: barmar@think.com (Barry Margolin) To: comp.protocols.tcp-ip Subject: Re: How to convert ethernet hard. addr. to IP addr.? ARP?  In article <1u2lse$dle@hermes.ath.epa.gov> kbw@helios.ath.epa.gov (Kevin B. Weinrich) writes:
>wind up with the IP address it goes with?

I don't think all hosts support it (or whether they're even *supposed* to),
but many systems (Suns, cisco routers, and Tektronix X terminals, but not
NCD X terminals) will respond to a ping to the broadcast address.  So if
ethernet address of many of the systems on the subnet.

telecaster-24% arp -a | wc -l
11
telecaster-25% ping 131.239.53.255
131.239.53.255 is alive
telecaster-26% arp -a | wc -l
14
--
Barry Margolin
System Manager, Thinking Machines Corp.

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


-----------[000393][next][prev][last][first]----------------------------------------------------
Date:      Sat, 29 May 1993 02:33:38 GMT
From:      tjohnson@cobber.cord.edu (Protius)
Subject:   Re: SLIP for 3B2

In article <2120@dsinet> daveb@jaws (David Breneman) writes:
>Greg's 3B2 FAQ contains a cryptic message :-) about SLIP for the 3B2:
>
>---CUT---
>------------------------------------------------------------------------
>Subject: 14 Is there an implementation of SLIP for the 3B2?
>------------------------------------------------------------------------
>
>Rumor has it that there was one written by Wollongong, but AT&T
>purchased exclusive marketing rights to WIN TCP/IP for the 3B2, but
>chose NOT to include SLIP.  There is the NOS (KA9Q) package that

The rumors are true, there is a real implementation of SLIP for 3B2s.
It calls itself NTI, networking TTY interface, or something like that.
It apparently works only with WIN/3b version 3.2.  I told Greg about
it a while ago, but we both got distracted.  It is a commercial product
so all the legalise applies.

>
>What is the NOS package?  *Has* anybody ported SLIP to the 3B2?
>"Enquiring minds which can't afford an ethernet card want to know."
>Thanks to any and all respondants.

About a year ago, I tried a system V port of KA9Q that I found on
wuarchive on a 3b2/300.  It worked... sort of.  I could telnet to
another machine, and login, but if I got lots of characters at once,
like a longish ls, the 3b2 couldn't keep up and KA0Q would lock up.

>
>
>--
>David Breneman                          Email: daveb@jaws.engineering.dgtl.com
>Software Engineering Services
>Digital Systems International, Inc.     Voice: 206 881-7544  Fax: 206 556-8033

-Tommy Johnson                        #include<std.disclaimer.h>
tjohnson@cobber.cord.edu
I probably don't know what I'm talking about.


-----------[000394][next][prev][last][first]----------------------------------------------------
Date:      29 May 93 06:57:34 GMT
From:      vmendoza@Auspex.COM (Vince Mendoza)
To:        comp.protocols.tcp-ip
Subject:   Re: non-blocking mode! and then?

In article <PHILIPPE.93May24153245@gull.world> philippe@gull.world (Philippe Waroquiers) writes:
>
>Dear netters,
>
>If you know TCP-IP and the socket interface, then perhaps you know the
>answers to the following 2 questions :
>
>
>I am using the socket BSD interface in non blocking mode. This works ok but
>in some cases, I do not see how I can determine the state of the socket.
>
>Question 1 (after a select for "connect"):
>------------------------------------------
>  a socket is created
>  then set it in non blocking mode using  fcntl(2) and the flag O_NONBLOCK.
>  I then use the connect(2) system call.
>     The manual of connect(2) indicates then that select(2) can be used to
>     determine if the connect is succesful by selecting for writing.
>
>If no process is listening, the select call also terminates and does not
>indicate an error.
>
>Question is : in such a case, how do I see if the socket is
connected?

I am assuming that you are talking TCP.  If so, the "netstat -a"
command shows TCP states of the socket.  If the socket is
connected, the state field for that particular connection will be
CONNECTED.
>

>
>Question 2 (after a select for "read"):
>---------------------------------------
>when a socket is selected for read, the select returns when the socket is
>
>When the remote process closes the socket or dies, the socket is always
>does not return an error).
>
>Question is : in such a case, how do I determine that the connection is
>not valid anymore ? (note : I do not want to write on the socket to see
>it the socket is still valid).

In the a shell, the netstat -a command will serve the same
purpose.  In some cases, you may see the state of a connection
like this hang in something like a FIN-WAIT or CLOSE-WAIT state
(not exactly positive).  But in summary, the netstat command can

---

Vince Mendoza 	{Technical Marketing Engineer}
Auspex Systems
Santa Clara, CA. 95054
Internet:	vmendoza@auspex.com
Phone:		(408) 986-2397
Fax:		(408) 986-2020

--

Vince Mendoza 	{Technical Marketing Engineer}
Auspex Systems


-----------[000395][next][prev][last][first]----------------------------------------------------
Date:      Sat, 29 May 1993 16:27:27 GMT
From:      dls@mentor.cc.purdue.edu (David L Stevens)
To:        comp.protocols.tcp-ip
Subject:   Re: Rare (but nasty) BSD TCP problem

The problem is that there is only one copy of the TCB, so both
sides of the connection are trying to change its state in incompatible
ways. Here's my version of a fix done by another department here at Purdue.
This is code for our version of Sequent's DYNIX, but with the 4.3 Tahoe
code in it. I think all of this section is straight Tahoe code, but line
numbers will certainly be different; the relevant function is in_pcbsetaddr()
in our code. I think this was in in_pcbconnect() directly in 4.2-based code.
You could do this in TCP's connect() code, too, but the problem
will apply generally to connection-oriented protocols. So we did it here.

*** OLD in_pcb.c
--- NEW in_pcb.c	Mon Oct 26 14:32:06 1992
***************
*** 190,195 ****
--- 190,196 ----
{
+ 	struct protosw *pr;

if (sin->sin_family != AF_INET)
return (EAFNOSUPPORT);
***************
*** 274,289 ****
#endif	notdef

+ 	pr = inp->inp_socket->so_proto;
+ 	/* try and prevent kernel from looping when a TCP socket is
+ 		connected to itself */
+ 	if ((pr->pr_flags & PR_CONNREQUIRED) && sin->sin_port == inp->inp_lport
+ 		return(ECONNREFUSED);
+ 	}

if (inp->inp_lport == 0) {

--
+-DLS  (dls@mentor.cc.purdue.edu)


-----------[000396][next][prev][last][first]----------------------------------------------------
Date:      Sat, 29 May 1993 19:21:45 GMT
From:      donp@novell.com (don provan)
To:        comp.protocols.tcp-ip
Subject:   Re: RFC for keepalives

In article <i6ehhmu@rhyolite.wpd.sgi.com> vjs@rhyolite.wpd.sgi.com (Vernon Schryver) writes:
>First, if the router keeps the call alive continually, then the router
>is broken.  A packet every few hours should not require the router to
>keep the line open continually.  It should simply than restore the line
>for a few minutes every few hours to pass the keepalive.  (Assuming the
>now typical hours between keepalives.)

I'd love to hear more about "hours between keepalives" being "typical".
I'm hearing that BSD is brisk enough with its keepalives to detect a
failed node within minutes.  And i assume BSD behavior is still
generally considered typical.
don provan
donp@novell.com


-----------[000397][next][prev][last][first]----------------------------------------------------
Date:      Sat, 29 May 1993 19:30:18 GMT
From:      donp@novell.com (don provan)
To:        comp.protocols.tcp-ip
Subject:   Re: Rare (but nasty) BSD TCP problem

In article <1993May28.191300.21994@ns.network.com> hgv@herring.network.com (Harry G. Varnis) writes:
>I recently stumbled across an admittedly weird case of socket misuse
>that locks up SunOS 4.1 tighter than a drum.  It happens when an application
>connects through a local interface to the same port to which it is bound.

Just for the record, although i concur that this is a rare and
probably useless operation, it is not a "misuse".  There's nothing
resulting TCP connection should be entirely legal and usable.

On the other hand, this result is entirely unexpected, which explains why
it's so often botched.  In fact, now that i think of it, i'm not sure
i've ever seen a TCP implementation that got this right the first time.

don provan
donp@novell.com


-----------[000398][next][prev][last][first]----------------------------------------------------
Date:      29 May 1993 20:51:09 +0200
From:      hn277pk@unidui.uni-duisburg.de (Peter Koch)
To:        comp.protocols.tcp-ip
Subject:   MacTCP and DNS and Bootp


I have asked this question some time ago but got no answer.
The recent discussion in this newsgroup about MacTCP and DNS
especially the following three lines

> Apple Computer, Inc.

Our department has its own subnet. We must have more than one
gateway and more the one nameserver. We must move the namewervers
between machines once in a while and in the past it happened
twice that I spend a whole day changing the nameserver-IP-address
on all our macs. At the moment our computing center is even thinking

Now all this would be no problem if I only could configure MacTCP
to behave in the following way:

On startup it broadcasts a bootp-request. Then the bootp-server
supplies the following information:

complete host name (ie foo.bar.sub.top), ip number of host, subnetmask
list of gateways and list of nameservers.

MacTCP should now use the supplied information and set its default
domain to the domain of its name (ie .bar.sub.top)

With MacTCP 1.1.1 part of this works but it is my impression
that in order to make MacTCP use the nameservers from the
bootp-reply one must not specify any nameservers in the control
panell. But then MacTCP only uses the first nameserver from the supplied
list and no default domain.

At the moment I am running a programm on our bootp server that
permanently checks if the first nameserver in the list of nameservers
is still running. If not the programms changes the bootptab file
and replaces the nameserver by one that is running. And all our users
have to fully specify all hostnames in TCP-application due to the
lack of a default domain.

There should be a better way to do this!

Peter Koch   koch@math.uni-duisburg.de


-----------[000399][next][prev][last][first]----------------------------------------------------
Date:      Sun, 30 May 1993 01:21:14 GMT
From:      vjs@rhyolite.wpd.sgi.com (Vernon Schryver)
To:        comp.protocols.tcp-ip
Subject:   Re: RFC for keepalives

In article <1993May29.192145.2576@novell.com>, donp@novell.com (don provan) writes:
> In article <i6ehhmu@rhyolite.wpd.sgi.com> vjs@rhyolite.wpd.sgi.com (Vernon Schryver) writes:
> >First, if the router keeps the call alive continually, then the router
> >is broken.  A packet every few hours should not require the router to
> >keep the line open continually.  It should simply than restore the line
> >for a few minutes every few hours to pass the keepalive.  (Assuming the
> >now typical hours between keepalives.)
>
> I'd love to hear more about "hours between keepalives" being "typical".
> I'm hearing that BSD is brisk enough with its keepalives to detect a
> failed node within minutes.  And i assume BSD behavior is still
> generally considered typical.
> 						don provan
> 						donp@novell.com

Instead of just loving to hear nonsense and then repeating it, why
don't you check the source?  It's been more than half a dozen years
since 4.3BSD came out with slow keep alives.  Consider the implications
of this line:

#define  TCPTV_KEEP_IDLE (120*60*PR_SLOWHZ)   /* dflt time before probing */

Fetch and read netinet/tcp_timer.c and netinet/tcp_input.c from uunet.
For extra credit, look at netinet/tcp_usrreq.c and netinet/tcp_output.c.

You won't go far wrong simply by looking at the SVR3 or SVR4 source
from your new, east coast colleagues.

You should also pay attention the reams of complaints in this newsgroup
(and maybe still a mailing list) from people who find that 4.3BSD TCP
is <<not>> "brisk enough with its keepalives to detect a failed node
within minutes".  Whatever "failed node" might be.

A dead connection that is active is generally detected within minutes,
but only because of reasonable transmission timers, which have absolutely
nothing to do with keepalives.

Vernon Schryver,  vjs@sgi.com


-----------[000400][next][prev][last][first]----------------------------------------------------
Date:      Sun, 30 May 1993 07:18:40 GMT
From:      donp@novell.com (don provan)
To:        comp.protocols.tcp-ip
Subject:   Re: RFC for keepalives

In article <i7d52o8@rhyolite.wpd.sgi.com> vjs@rhyolite.wpd.sgi.com (Vernon Schryver) writes:
>Instead of just loving to hear nonsense and then repeating it, why
>don't you check the source?  It's been more than half a dozen years
>since 4.3BSD came out with slow keep alives.  Consider the implications
>of this line:

I'm not sure what i ever did to you to illicit this tone, but you
know, in that half a dozen years, i've never had the slightest
interest in finding or retrieving the BSD sources, let alone studying
them well enough to find the one line you tell me i'd be looking for:

>#define  TCPTV_KEEP_IDLE (120*60*PR_SLOWHZ)   /* dflt time before probing */

I take it this makes the default time two hours?  How is the default
time overridden, and how many installations or applications override it?

>You should also pay attention the reams of complaints in this newsgroup
>(and maybe still a mailing list) from people who find that 4.3BSD TCP
>is <<not>> "brisk enough with its keepalives to detect a failed node
>within minutes".  Whatever "failed node" might be.

The typical "failed node" is an idle FTP client (i.e., in a state
where the server isn't transmitting anything, so there's nothing in
any retransmission queue) which crashes and reboots without
remembering the previous FTP session.  How long will it take a typical
4.3BSD FTP server to notice that this client has forgotten about the
connection, and are keepalives the mechanism used to make that
discovery?  Is this the case people complain about?  (Funny i don't
recall any of these discussions.  I must have dozed off.)

>A dead connection that is active is generally detected within minutes,
>but only because of reasonable transmission timers, which have absolutely
>nothing to do with keepalives.

Duh.
don provan
donp@novell.com


-----------[000401][next][prev][last][first]----------------------------------------------------
Date:      Sun, 30 May 93 15:17:53 EDT
From:      MACE@HDQCMS2H.UTSD.ATT.COM
To:        comp.protocols.tcp-ip,comp.protocols.misc,comp.protocols.ibm
Subject:   Re: CPI-C over TCP/IP

In article <C7r3LJ.E9M@magna.com>
yefim@magna.com (Yefim V. Natis) writes:

>I am looking for communications software with CPI-C (or near) API to use on
>a TCP/IP-connected network.  The hardware involved is the major flavors of
>UNIX servers, the IBM mainframes, and Bull (Honeywell) mainframes.
>
>
>Thanks
>
>Yefim Natis
>Software Architect
>Magna Software Corporation
>
>

I would also be interested in the response to this question.  Please post
the information!  Thanks!
------------------------------------------------------------------------------
Mace Moneta, AT&T VM Product Engineering, Piscataway, NJ - mmoneta@attmail.com
------------------------------------------------------------------------------


-----------[000402][next][prev][last][first]----------------------------------------------------
Date:      30 May 93 11:18:30 GMT
From:      jonc@status.gen.nz (Jon Clarke)
To:        comp.protocols.tcp-ip
Subject:   Esix tcp-ip SVR3

Does anyone out there in netland have a Esix svr3 box working 100%
on internet using pc-routers or the likes? If so please drop me mail
as I wish to configure up my box for this purpose next week.

From all accounts it is not possible to find the routers sub address
when using tcp/ip.  I have Svr4 but have not installed yet, if svr3
does not do it does svr4 of Esix work 100%.

I wish to run nntp (have elm working over tcp ip now) server here and
also connect to several other boxes via leased lines.

If you can help me please email me today.

_         Jon Clarke (jonc@status.gen.nz)       * Public Access Unix *
( )o       The home of Z*NET on the World Nets (Z*NET Free ASCII Zines)
/\  \      HEXAGON: HSBC NZ EBD  GEM: Jon Clarke   PH : (+649) 358-5589


-----------[000403][next][prev][last][first]----------------------------------------------------
Date:      Sun, 30 May 1993 13:55:51 GMT
From:      dedgar@mta.ca
To:        comp.protocols.tcp-ip
Subject:   Slip and Xon/Xoff

Hi

Since the RFC (1055) makes no mention it, can I assume that NO slip
implementation ever uses XON\XOFF flow control?

Alternately if there is a standard for this, but not yet RFC'ed could
someone please tell me the ESC codes one would substitute for xon\xoff
chars occuring in the data being transmitted.

Thanks

Dale Edgar
Cybernetic Control Inc.
DEDGAR@MTA.CA


-----------[000404][next][prev][last][first]----------------------------------------------------
Date:      Sun, 30 May 1993 16:25:47 GMT
From:      vjs@rhyolite.wpd.sgi.com (Vernon Schryver)
To:        comp.protocols.tcp-ip
Subject:   Re: RFC for keepalives

In article <1993May30.071840.14806@novell.com>, donp@novell.com (don provan) writes:
> In article <i7d52o8@rhyolite.wpd.sgi.com> vjs@rhyolite.wpd.sgi.com (Vernon Schryver) writes:
> >Instead of just loving to hear nonsense and then repeating it, why
> >don't you check the source?  It's been more than half a dozen years
> >since 4.3BSD came out with slow keep alives.  Consider the implications
> >of this line:
>
> I'm not sure what i ever did to you to illicit this tone

What did you do? You played the same old game that regularly and
justifiably makes you Novell guys so hot.  That is to make
authoritative, prejorative, and wrong statements about protocols or
implementations you evidently know little about.  I would have not
snarled so if this lapse had been your only first, second or even tenth.

>       in that half a dozen years, i've never had the slightest
> interest in finding or retrieving the BSD sources, let alone studying
> them well enough to find the one line you tell me i'd be looking for:

Then how do you presume to make statments about how 4.3BSD TCP works or
what it does?  I try not to talk about how IPX works, because my
knowledge of Novell's code is probably little better than your
knowledge of 4.3BSD TCP.

The "studying well enough" consists of starting with
grep -i 'keep.*alive' *.[ch], skimming the code and comments
that unearths, and repeating the process about 4 times.
Given on-line source, this effort requires less than 10 minutes.
How do I know it takes less than 10 minutes?  Guess how.

If you can't be bothered with an online copy of the free BSD source,
and still can make such pronouncements as you did, then then how can
you Novell guys presume to criticise people for making dumb statements
about your code?  Esp. when it is a lot harder and vastly more
expensive to get into a position where validation of intuition or
prejudice is possible?

Don't you have a copy of SVR4 around?  Where exactly the same line
appears in tcp_timer.h?

> >#define  TCPTV_KEEP_IDLE (120*60*PR_SLOWHZ)   /* dflt time before probing */
>
> I take it this makes the default time two hours?  How is the default
> time overridden, and how many installations or applications override it?

That depends on details of the 4.3BSD port.  Generally, you must change
that line and recompile parts of the UNIX kernel and relink the whole
thing.  Depending on the system, you might be able to use adb, sdb
or even dbx to patch either the running system kernel or the image
that will be load when the system is next rebooted.

one changes or overrides the default, 2 hour 4.3BSD keepalive.

It would be good to have per-connection control on the keepalive
parameters.  (There are more than just this main one.)  I seem to
recall that the HR RFC's urge such control.  It may be that one of the
major UNIX TCP vendors has provided such knobs.

> >You should also pay attention the reams of complaints in this newsgroup
> >(and maybe still a mailing list) from people who find that 4.3BSD TCP
> >is <<not>> "brisk enough with its keepalives to detect a failed node
> >within minutes".  Whatever "failed node" might be.
>
> The typical "failed node" is an idle FTP client (i.e., in a state
> where the server isn't transmitting anything, so there's nothing in
> any retransmission queue) which crashes and reboots without
> remembering the previous FTP session.  How long will it take a typical
> 4.3BSD FTP server to notice that this client has forgotten about the
> connection, and are keepalives the mechanism used to make that
> discovery?  Is this the case people complain about?  (Funny i don't
> recall any of these discussions.  I must have dozed off.)

I don't recall any discussion of failed FTP clients, but people
frequently ask here how their applications of TCP/IP can be
automatically notified when the wires break or the other end of the
connection crashes.  It seems someone asks that question once a week,
but I suppose it's no more than a couple of times per month.  Such
applications and questions have nothing to do with FTP and are obvious
applications of keepalives.

Typical (e.g. 4.3BSD-NET2) FTP implementations have site specific
idle timers that throw off sleepers.  These have nothing to do with
keepalives, but are implemented in the applications.  They do not
detect crashed servers or clients, but only apparently idle servers or
clients.  (Look for "idle" in the 4.3BSD-NET2 client source, then the
server source, then look for "timeout" and "alarm" in the server source.)

Keepalives must be turned on explictly in 4.*BSD.  Consider
grep -i keep * applied to the 4.3BSD source.

The usual argument for keepalives is not FTP, if only because of those
idle timers.  Instead it is telnet, rsh, or rlogin, which generally do not
have idle timers.  The 4.3BSD practice is to:
1. detect crashed telnet, rsh or rlogin clients after a matter of
hours using keepalives, in order to recover server resources.
2. not even try to detect crashed servers, until the client
tries to talk to the server, and ...

> >A dead connection that is active is generally detected within minutes,
> >but only because of reasonable transmission timers, which have absolutely
> >nothing to do with keepalives.
>
> Duh.
> 						don provan
> 						donp@novell.com

I do not understand your "duh".  It could be because you understand the
point, but I am honestly not sure.

The original complainer about keepalives should consider the utility of
the "-n" switch on rlogind or telnetd.  (That may not be a universal
feature.)

Vernon Schryver,  vjs@sgi.com


-----------[000405][next][prev][last][first]----------------------------------------------------
Date:      30 May 1993 16:26:25 GMT
From:      trier@odin.ins.cwru.edu (Stephen C. Trier)
To:        comp.protocols.tcp-ip
Subject:   Re: Slip and Xon/Xoff

In article <1993May30.135551.6453@jupiter.sun.csd.unb.ca> dedgar@mta.ca writes:
>Since the RFC (1055) makes no mention it, can I assume that NO slip
>implementation ever uses XON\XOFF flow control?

No, you can't use XON/XOFF in SLIP.

If you must use XON/XOFF, you can use PPP.  However, even with PPP, the
consensus seems to be to use hardware flow-control if at all possible.

--
Stephen Trier (trier@ins.cwru.edu - MIME OK)
Network Software Engineer
IRIS/INS/T
Case Western Reserve University


-----------[000406][next][prev][last][first]----------------------------------------------------
Date:      Sun, 30 May 1993 20:59:42 GMT
From:      dberry@csa.cs.technion.ac.il (Dan Berry)
To:        comp.protocols.tcp-ip,comp.protocols.snmp
Subject:   Seeking advise on EPILOGUE's software

(Orna Berry-Keren using Dan Berry's account).
I would like to ask whether people have experience in integrating
Epilogue's software (UDP/IP/TCP/telnet/SNMP...).
Can any one compare it (in quality and ease of integration) with other
available packages?

Thanks, Orna

--
Prof. Daniel M. Berry, Computer Science Department, Technion, Haifa 32000 ISRAEL
Tel:+972-4-294325, Bitnet:DBERRY@TECHSEL
Csnet & Internet:dberry@sel.technion.ac.il


-----------[000407][next][prev][last][first]----------------------------------------------------
Date:      30 May 1993 22:27:31 GMT
From:      tomv@cssc-syd.tansu.com.au (Tom Vasak)
To:        comp.protocols.tcp-ip
Subject:   Expedited data over TCP through TLI

Has anyone tried to send expedited data over a TLI connection through a
TCP transport provider on SunOS 4.1.2?

I have been having problems. Any tips?

---
Tom Vasak
Telecom Australia
tomv@cssc-syd.tansu.com.au


-----------[000408][next][prev][last][first]----------------------------------------------------
Date:      Mon, 31 May 93 03:57:26 GMT
To:        comp.protocols.tcp-ip
Subject:   Harvard Router/Bridge tests - time again

Well its that time of year again, I'm starting up the next round of
router & bridge performance tests.  The window is from now until early
August.  The results will be announced during the "fall" Interop at the
end of August & put up for anonymous ftp soon after.

The tests include the Packet Loss Rate, Throughput and Latency
tests as defined in RFC 1242.

This is an open invitation for any vendors of routers or bridges to
take part.  There is no fee for these tests. (Since I expect that a
representative of the vendor will be present during the tests to configure
& observe, it ain't free to the vendor - but the hotels & airlines get
the money not Harvard or me)

If you produce such a device and want to take part please give
me a call for more details and to schedule a testing time.

Harvard University
10 Ware St
Cambridge MA 02138
617-495-3864
---------------------------------------------

There are two basic test setups:

setup 1
---------------
|             |
------------|   tester    |-----------
|           |             |          |
|           ---------------          |
|                                    |
net A    |                                    |   net B
|                                    |
|           ---------------          |
|           |   device    |          |
------------|    under    |-----------
|     test    |
---------------

setup 2
---------------
|             |
---------------|   tester    |--------------
|              |             |             |
|              ---------------             |
|                                          |
net A    |                                          |   net B
|                                          |
|   ------------            ------------   |
|   |  device  |            |  device  |   |
----|   under  |------------|   under  |----
|    test  |   net C    |    test  |
------------            ------------

In the simple case for setup 1 traffic flows from the tester through
net A, through the device under test to net B and then back to the tester.

In the simple case for setup 2 traffic flows from the tester through
net A, through the device under test to net C, through a second identical
device under test to net B and then back to the tester.

Bi-directional traffic is also tested.

Net A & net B are of the same type and can be Ethernets, token
ring, or FDDI. Testing will include devices with up to 48 Ethernet ports,
and 2 ( & I hope 4) token ring or FDDI ports.

Net C is a 9600 baud, 56Kb, T1 & T3 WAN, a 56Kb & T1 frame relay,
an Ethernet, and an FDDI ring

Protocols include TCP/IP, DECnet Phase IV, AppleTalk Phase II,
Novell IPX, OSI CLNP, Banyon Vines IP, bridge mode & mixtures of the same.


-----------[000409][next][prev][last][first]----------------------------------------------------
Date:      31 May 93 22:13:38 -0400
From:      mchenry@guvax.acc.georgetown.edu
To:        comp.protocols.iso.x400,comp.protocols.tcp-ip
Subject:   telecom conference in russia

Announcement:

3rd International Russian Forum on
ELECTRONIC COMMUNICATION TECHNOLOGY - ECT'93

ECT'93 is a conference that examines the state of the art in
Russian and CIS telecommunications through 1) a conference with speakers
who represent major Russian/CIS communications initiatives, 2) an exhibit
by service providers in this field, and 3) tutorial sessions about specific
topics. The organizers of the conference provide conference proceedings and
also publish a large series of tutorial materials on all aspects of Russian
telecommunications. One of the organizers is the International Center for
Scientific Technical Information. ICSTI used to spend most of its time on
databases of scientific and industrial abstracts, and worked closely with
sister institutes throughout the former Eastern bloc. Now it spends most of
its time on conferences, tutorial materials, and incubating joint ventures
or other ventures on its premises. This is a short provisional program for
you are interested in attending.

PROVISIONAL PROGRAMME
of 3rd International Russian Forum on
ELECTRONIC COMMUNICATION TECHNOLOGY - ECT'93
June 28 to July 3, 1993
Academy of National Economy, Moscow, Russia

Russian Ministry of Communication    Academy of National Economy
Concern Telecom of Russia            Russian-American JV "Eco-Trends"
International Centre for Scientific and
Technical Information
June 28,        10:00   Opening Ceremony
June 28-29              Conference on Future Electronic Communications
June 28 to July 3       Exhibition "Telecommunication Systems and Services"
June 29,        18:00   Press-conference
19:30   Welcome reception and cocktail party

June 30 to July 1       Tutorials and Professional Learning Courses
Tut_A   International computer networks: Internet, NASA science
network, and others
Tut_B   Personal computers, modems and communication technology
Tut_C   NetWare local area networks and internetwork technology
Tut_D   Security and data protection in computer networks
Tut_E   Oracle-based information networks
Tut_F   Banking networking and S.W.I.F.T. network

July 1          Business-visits and talks with Russian communication VIPs
BV_1    Russian Ministry of Communication
BV_2    INFOTEL network communication control center
BV_3    Russian satellite communication control center
BV_4    Institute of Automated Systems, IASNET computer network
July 2          Commercial product reviews and company presentation
PR_1    Russian Telecommunication Market
PR_2    Mobile communication networks
PR_3    Open for proposals till May 25, 1993
PR_4    ...
July 3          Business seminar "Privatization and investments in Russian
communication industry"
July 3, 16:00   Closing Ceremony
Lune 29 - July 3  Intensive cultural programme for foreigners and
accompanying persons (Bus tours, theatre, museums, balett etc.)
Juri Gornostaev/Juri Andrianov
ECT'93 Program Committee
125252, Moscow, Russia, Kuusinen Str., 21-B, ICSTI
fax: 7(095)943-0089   Tel: 7(095)198-7041   e-mail: enir@ccic.icsti.msk.su
---
ICSTI Computer Department      E-Mail : enir@ccic.icsti.msk.su
21b Kuusinena st., Moscow      Voice  : (7-095) 198-76-91
125252, RUSSIA                 Fax    : (7-095) 943-00-89


-----------[000410][next][prev][last][first]----------------------------------------------------
Date:      31 May 1993 16:33:36 GMT
From:      ming@engin.umich.edu (horng ming tai)
To:        comp.dcom.sys.cisco,comp.protocols.tcp-ip
Subject:   Re: IP Routing Questions on Subnet Masks and Multicasting

hi! I have a question of interrupt calls on IBM machine for TCP/IP.
I would like to program for my two computers which are connected with RG-58
cable with TCP/IP drivers. But I do not have any document for that. I only have
experiences for ipx on Novell netware. Are there any one have experiences
of programming TCP/IP on IBM machine. Please tell me where I can get the
document and some examples source code.
TKS.


-----------[000411][next][prev][last][first]----------------------------------------------------
Date:      Mon, 31 May 1993 16:54:50 GMT
From:      bacon@mtu.edu (Jeff Bacon)
To:        comp.protocols.tcp-ip
Subject:   multiple ether interfaces on the same subnet, revisited

Let's suppose the following setup:
a sun with two ethernet interfaces, le0 and le1, numbered 128.100.100.1
and 128.100.100.2. we'll assume a subnet mask of 0xffffff00, so both
interfaces are on the same subnet. both interfaces are hooked to
separate ports of a multiport packet switch, which is bridging between
all of its ports. The rest of the ports are connected to various other
ethernets, all on the same subnet (obviously). Of course, the two sun
interfaces will have different MAC addrs (no spanning-tree).

As you might guess, the idea is to get maximum thruput into that
packet switch. Please don't mention FDDI, we can't afford that. (Yes
the sbus cards are kinda cheap, but the card for the packet switch
isn't. either way, I don't have the money.) Nor do I want ten zillion
servers all serving the same thing if I don't have to.

I'm aware of that numbering trick you can do, it's not an option - we
cannot split the clients up in any way such that one half talk to one
interface and the other half talk to the other. (Or at least I don't want
to do it that way - seems kludgy.)

It occured to me that:
a. This machine will be primarily an NFS read-only file server. But, while
there will be more packets going out than in, there will still be a
significant number of inbound packets, in the form of requests and acks.
b. The main reason ethernet doesn't ever go at full wire speed is because
of collisions - Jacobsen showed that a sun could drive an le interface
at near wire speed, if the traffic was unidirectional and there were only
two stations on the wire.
c. I can make it such that there are only two devices on the wire for
both interfaces, the packet switch and the sun, thereby removing any
external source of collisions.
d. If I were to do things such that some clients talked to one interface and
the others to the other, there would still be collisions on both wires
because of the bidirectional traffic, resulting in lower thruput.

So...it seems to me that the thing to do here is this: tell all the clients
that the sun is at 128.100.100.2 (le1). Let the sun go ahead and set
its default route for net 128.100.100.0 to le0. By doing this, what I've
done is essentially make both interfaces single-directional; e.g. all
inbound traffic comes in le1, all outbound traffic goes out le0.

By doing so, we are saying that the sun can't send data out any
faster than le0 can send it. But...since there's no one EVER telling
le0 it CAN'T send, I would think it should be able to send at near-wire
speed, which I would believe to be faster than it could ever send out
both interfaces in the face of collisions. By the same token, the sun
should also be able to receive at near-wire speed on le1.

Of course this would cause some interesting problems with things like
.rhosts, netgroups, etc. But for an NFS fileserver, who cares? Besides, I
can just define both interfaces as trusted anyway.

Am I correct? What am I missing here? Are there any gotchas inside the
kernel code that would keep things from working like I propose? Is my

I'd just try this myself and save the discussion, but I don't happen
to have either the second interface or the packet switch yet.

-bacon
--
= Jeffery Bacon       General Systems Hack, Michigan Technological University =
= bacon@mtu.edu       ph-(906)487-2197 fax-(906)487-2822    Printing is Evil. =


-----------[000412][next][prev][last][first]----------------------------------------------------
Date:      Mon, 31 May 1993 17:18:08 GMT
From:      erick@sunee.uwaterloo.ca (Erick Engelke)
To:        comp.protocols.tcp-ip
Subject:   Re: RFC for keepalives


vjs@rhyolite.wpd.sgi.com (Vernon Schryver) writes:
> donp@novell.com (don provan) writes:
>> vjs@rhyolite.wpd.sgi.com (Vernon Schryver) writes:
>>
>> I'm not sure what i ever did to you to illicit this tone
>
>What did you do? You played the same old game that regularly and
>justifiably makes you Novell guys so hot.  That is to make
>authoritative, prejorative, and wrong statements about protocols or
>implementations you evidently know little about.  I would have not
>snarled so if this lapse had been your only first, second or even tenth.

Ignoring all that, Don may have inadvertently reminded us that many
people such as he and I and many other TCP implementors may have never
inspected BSD code for inspiration, just the RFCs, relevant papers and
packet dumps.  So sometimes it's not as political as one may think, just
a different reference point.  In those cases non-BSDers are not prejudiced
by the same references as you.  In some cases, like the discussion on
'Urgent' vs. OOB, the Noveller's alternative viewpoint turned out to be
inline with the original definition of the protocol.

But thanks for the authoritative answer.

Erick
--
----------------------------------------------------------------------------
Erick Engelke				 	            WATTCP Architect
erick@development.uwaterloo.ca     TCP/IP was easy but i still can't work VI


-----------[000413][next][prev][last][first]----------------------------------------------------
Date:      Mon, 31 May 1993 19:37:49 +0000
From:      proyse@peeras.demon.co.uk (Phil Royse)
To:        comp.protocols.tcp-ip
Subject:   Re: How to convert ethernet hard. addr. to IP addr.? ARP?

In article <bqt.738584604@Minsk> bqt@Minsk.docs.uu.se writes:
>
>>wind up with the IP address it goes with?
>
>Was some time since I looked through this, but i think that's what RARP
>are for.

My understanding is that RARP is for an ethernet device, which doesn't
know its OWN IP address (i.e. one hasn't been configured in it),
but it assumes that an IP address has been somehow "reserved" for it.

The device, in effect says "Hey, somebody on this ethernet, as you
can see from this frame, my MAC address is AA BB CC DD EE FF, who can
tell me what my IP address is supposed to be?  answer my by an

I don't think this RARP mechanism can be used for a general
OTHER than the one which is the subject of the query...
(I think the RARP request will only put {my-address} in the
MAC address field, also, I think, the RARP server will only

Hope this helps,

Phil R
--

Phil Royse     Comms Consultant  | member:  The Peer Association
TUDOR HOUSE                      | (networking & OSI specialists)
Surrey  CR8 4LN   (UK)        Tel: (+44) 81 645-9868


-----------[000414][next][prev][last][first]----------------------------------------------------
Date:      Mon, 31 May 1993 19:42:27 +0000
From:      proyse@peeras.demon.co.uk (Phil Royse)
To:        comp.protocols.tcp-ip
Subject:   Tunnelling or encapsulation?


Can anybody give a simple mind a simple explanantion of the
difference between tunnelling and encapsulation?

This is with regard to sending IP packets over an X.25 subnet?

Don't normal routers (Cisco et al.) wrap the fragments of an
IP packet in standard X.25 packets, once a virtual circuit
has been set up?  Is this encapsulation or tunelling?

TIA

--

Phil Royse     Comms Consultant  | member:  The Peer Association
TUDOR HOUSE                      | (networking & OSI specialists)
Surrey  CR8 4LN   (UK)        Tel: (+44) 81 645-9868


-----------[000415][next][prev][last][first]----------------------------------------------------
Date:      Mon, 31 May 1993 19:49:58 +0000
From:      proyse@peeras.demon.co.uk (Phil Royse)
To:        comp.protocols.tcp-ip
Subject:   TN3270 HLLAPI or TelAPI?


We are looking into Windows based 3270 emulation packages to run over
TCP/IP, into an IBM 9370.  The application needs a HLLAPI interface.

Browns University TN3270 supports TelAPI?  Does any body know
the difference between HLLAPI & TelAPI?  Is it significant?

Will the IBM 9370 support a HLLAPI interface over its TN3270 server?

TIA

--

Phil Royse     Comms Consultant  | member:  The Peer Association
TUDOR HOUSE                      | (networking & OSI specialists)
`