From tcpxxx Thu Jan 3 22:26:20 1991 Date: Thu, 3 Jan 91 22:26:05 GMT Message-Id: <4106@G1YYH> From: g1yyh@G1YYH (John Heaton) Reply-To: g1yyh@g1yyh (g1yyh@gb7nwp) To: tcpxxx@G1YYH Subject: TCP-Group Digest #001 Date: Tue, 1 Jan 91 04:30:08 PST From: Advanced Amateur Radio Networking Group Reply-To: TCP-Group@UCSD.Edu Subject: TCP-Group Digest V91 #1 To: tcp-group-digest TCP-Group Digest Tue, 1 Jan 91 Volume 91 : Issue 1 Today's Topics: Administrivia - Happy New Year Send Replies or notes for publication to: . Subscription requests to . Problems you can't solve otherwise to brian@ucsd.edu. Archives of past issues of the TCP-Group Digest are available (by FTP only) from UCSD.Edu in directory "mailarchives". We trust that readers are intelligent enough to realize that all text herein consists of personal comments and does not represent the official policies or positions of any party. Your mileage may vary. So there. ---------------------------------------------------------------------- Date: Mon, 31 Dec 90 16:25:46 -0800 From: brian (Brian Kantor) Subject: Administrivia - Happy New Year To: dsp, info-hams, packet-radio, tcp-group May you have peace, happiness, and prosperity in the new year. - Brian ------------------------------ End of TCP-Group Digest ****************************** From tcpxxx Thu Jan 3 22:26:38 1991 Date: Thu, 3 Jan 91 22:26:27 GMT Message-Id: <4108@G1YYH> From: g1yyh@G1YYH (John Heaton) Reply-To: g1yyh@g1yyh (g1yyh@gb7nwp) To: tcpxxx@G1YYH Subject: TCP-Group Digest #002 Date: Wed, 2 Jan 91 04:30:08 PST From: Advanced Amateur Radio Networking Group Reply-To: TCP-Group@UCSD.Edu Subject: TCP-Group Digest V91 #2 To: tcp-group-digest TCP-Group Digest Wed, 2 Jan 91 Volume 91 : Issue 2 Today's Topics: Casting Pearls among Swine NOS AX.25 Weirdo's N Y State IP Addr coord change Send Replies or notes for publication to: . Subscription requests to . Problems you can't solve otherwise to brian@ucsd.edu. Archives of past issues of the TCP-Group Digest are available (by FTP only) from UCSD.Edu in directory "mailarchives". We trust that readers are intelligent enough to realize that all text herein consists of personal comments and does not represent the official policies or positions of any party. Your mileage may vary. So there. ---------------------------------------------------------------------- Date: Tue, 1 Jan 91 21:51:16 -0800 From: brian (Brian Kantor) Subject: Casting Pearls among Swine To: tcp-group You know, it's messages like the following (found on our local BBS) that cause me to despair that when we get the network built, will the people even notice? - Brian ------fwd: Date: 22 Dec 90 02:44 Message-ID: <999@KC7CG> From: N7OO@KC7CG To: ALL@ALLUS Subject: The Truth about TCP/IP Path: KB6GFT!N6KZB!KB6GVT!KB6JES!KB6RAA!KB6RAA!N8GTC!W7JHX ... R:901221/1908mst 18554@NJ7P [Sierra Vista, AZ] Now that the southwestern desert TCP wars are dying down (again), perhaps it is time to examine why the use of TCP causes so much dissention within the packet community. Those using TCP are attracted to it because it offers a variety of "applications", or perhaps because it seems to be the "in" thing to do. Indeed, the thought of handling large files through the network is appealing. Overlooked in the zeal of getting operational on TCP is the simple fact that TCP was designed to operate on LAND LINE circuits of 9600 baud or greater! Even at 9600 baud, some of the applications available within TCP just limp along. There is general agreement that on 1.2 megabit streams is where TCP really reveals it's potential. Contrast the desired TCP operational sceneario with the real world of our typical 1200 baud multi-user radio packet links. These links are comprised of RF paths ranging from poor to good, of node radio TXD's ranging from .3 to .5 seconds, and of user populations varying from light keyboard activity to heavy BBS usage. Thruput studies (the actual rate at which data arrives at a destination) indicates the typical VHF packet link has a thruput which at best is agonyzingly slow and which typically is near zero! Even when the network is not loaded, thruput is inefficent when compared to a full duplex land line link at the same baud rate. Adding an IP node into this environment DOES NOT ENHANCE network operation! IP nodes generally only serve the end user and even when idle, adds to the network congestion. This is because IP nodes want to be "known" by the network so destination IP nodes can automatically route traffic to them. Thus their sterile voices are appended to the overhead burden of node house- keeping. Added overhead which has no utility to the general user population of the network. Added overhead which competes with other user packets. By far the heaviest network users are BBSes conducting traffic forwarding. These are normally set up to do forwarding at certain times and in a connected mode. If the connection is broken, their transmissions cease until the next scheduled time period. During this quiet period, keyboarders have a high probability of success of venturing out into the node network and actually making an end connect to a destination. IP nodes on the other hand, operate in the "unconnected" mode which usually has no specific schedule. The TCP operator can ready a large file (sometimes exceeding several hundred K bytes), and go off to work knowing that his system will attempt relentlessly to pass the file to it's destination in his absence. Depending on network congestion, a large file may take a week or longer to be passed. While this is going on any downstream user, keyboarder or BBS, may be subject to abrupt disconnection, depending upon the "health" of the network. In summary, TCP/IP when operating in it's intended environment has many worthwhile features. On our typically flaky RF node network links, TCP/IP is NOT EFFICIENT and is DISRUPTIVE to the general packet community. "If you run a diesel locomotive down a cow path, don't be suprised if the cows get mad at you!" Everyone would be a winner if the energy expended on TCP/IP were instead expended on improving our RF systems. Flames to N7OO@NJ7P.AZ.USA.NA Date: 31 Dec 90 23:36 Message-ID: <6406@KB6GFT> From: WA4EGT@KB6GFT To: ALL@ALLUS Subject: TCP/IP vs. AX.25 Path: KB6GFT I hope everyone gets a chance to review N7OO's "The Truth about TCP/IP." It should also be noted that binary file transfers, one of the claimed advantages of TCP/IP, is not exclusive to TCP/IP. AX.25 can transport binary data (which means ANY data), I've been doing it for over 2 years, as well as doing multiple connects, and QSOing while a binary transfer is in progress. The BBS systems can forward binary files as well. The end-user simply needs the right software. In reading the N7OO review, what came to mind was the following analogy: A military contractor contemplates using assembly language to create ROM code for some weapon, but a government official notes that all software should now be written in ADA. Yes, ADA does lots of stuff, but completely unsuited to ROM code development. In this case, as in TCP/IP vs. AX.25, there are times when less is more. I transfer binary files using Packet-GOLD on my AEA TNC and have observed effective baud rates of up to 900+ baud on a 1200 baud channel using AX.25. Perhaps we can have some statistics on TCP/IP "efficiency" or some other measures to better quantify this, and other "advantages" of TCP/IP that are presumably unavailable without TCP/IP. Then developers and others can begin to add those features that are so important to the TCP/IP community, but retaining the "lean and mean" nature of smaller frames and existing networks, and TNC firmware. There are a number of improvements that can be made in radio network design and implementation (dual port NET/ROM nodes vs. single port to name one) a "selective reject" feature in AX.25, dynamic parameter adjustments, etc. etc. 73 and have a great year. Jeff ------------------------------ Date: Tue, 01 Jan 91 10:55:38 CST From: g4jec@g4jec.ampr.org (Chris Cox W0/G4JEC) Subject: NOS AX.25 Weirdo's To: tcp-group@ucsd.edu Happy New Year everyone... Here's a couple of weird ones, which I'd like to know if anyone else has been experiencing. Myself, and another local, Andy G1XRL, have been experiencing problems with attached ax.25 tnc's. There are two problems in particular. 1: I happened to notice in the source that there is a new (I think) optional parameter to the attach asy function to enable cts flow control. However, it only appears to work for the second (or perhaps the last) attached asy device. If the option is enabled for certainly the first (and perhaps any attach asy which isn't the last one) nothing seems to get sent to the tnc. If the 'c' parameter isn't used on the first attach, then that device communicates just fine. I can't verify if this only affects the first tnc, as I only have two to play with. 2: After some indeterminate uptime, possibly related to amount of activity on the serial port channel, the port seems to lose the ability to send anything on the channel. Using a tnc2 clone (a G0BSX tnc2), the txdata LED comes on and stays on indefinitely. Checking the asystat, the number of bytes in the sndq increments appropriately, but nothing gets sent to the tnc. In my case, this happens on the port which does not have cts flow control enabled. In Andy's case, he does not use cts flow control on either port, so that doesn't seem to be relevant. The LED stays on even after rebooting the pc, and doesn't reset itself until the pc is rebooted, AND NOS is restarted, and the attach asy line in autoexec.net is executed. The version of NOS we are now using is 901107a. I have noticed that from the asystat command, there has usually been a number of overuns on the port (about 10 or so). Both ports are running at 9600 baud, currently both radios are communicating at 1200 baud, although one should be soon running at 9600 baud, although that is on the tnc which hasn't so far locked up. Ideas anyone? 73's and Happy New Year... ttfn Chris W0/G4JEC chrisc@moron.vware.mn.org g4jec@g4jec.ampr.org g4jec@g4jec.vware.mn.org 11th Hour Contest Group (North American Chapter) Minneapolis, MN EN34ju ------------------------------ Date: Tue, 1 Jan 91 22:42:37 EST From: robert l. foxworth Subject: N Y State IP Addr coord change To: tcp-group@ucsd.edu News about New York State IP Address Coordination. I was at a local club meeting a couple of weeks ago. I had a copy of amprhosts I downloaded from ucsd.edu and we were discussing the fact that a number of recent assignments in our area had not been included in the master list. One thing led to another and a local IP'er sent mail to Norm, W2JUP, the local who has been NY State Coordinator for the past 3 years. Norm has been busy with a number of things, is not active on IP locally, and so on. As a result we decided between us that since I am active on IP and have access to updating the master list, downloading it, etc. that I would take over Norm's role as NY State Coordinator. We have agreed that this is effective as of today, 01 January 1991. Norm has given me the lists in his possession as of this date. This step is viewed by all of us as a way to make the process run better. There are no "hard feelings" involved in this step. I emphasize that so as to forestall any possible misunderstanding, recalling some of the events of last August. The list of state coordinators that has been circulating on Usenet has been inaccurate, as it pertains to NY state, for some time. The fact of the matter is that NYC-LI addresses (44.68.1.x, 44.68.8.x, 44.68.16.x, 44.68.32,x etc.) are being assigned by Jim nq2d, who lives in Sound Beach, LI NY. Jim has been doing this for something over a year now. Jim does *not* have Internet/Usenet access. He is a fulltime IP'er. I believe that n2igu is assigning addresses in the Albany/ENY area and that wa2wpi in Western upstate NY, and I also believe both of them read Usenet and have access to internet. The system, in Norm's view, was that each of the three would for- ward their info to him and he in turn to ucsd. Somewhere in the chain, the process seemed to either be breaking down or was being bypassed. It doesn't really matter where, at this point. Also in this area are the events leading to the creation of 44.69.x.x addressing. This was never resolved fully as far as I know. With two addresses listed in the database from ucsd in the 44.69 area, it seems there is little interest up there in using this domain. As of today - and I am trying like hell to AVOID making this sound imperious, talking-downish, above-thou-ish or anything like that - it does stand that, whatever "authority" or "juris- diction" Norm had in this area is now been given to me by him. So I think we first of all need to clarify where each of us stands in this area, who is responsible for what, and what I need to do to make sure that whomever wants an address is promptly given one, and that the data is promptly forwarded to ucsd. Some upstate ops have complained that the system has been very slow to respond. This has been true. I hope that from now on that will no longer be true, and I'll do what I can to make that so. I'd like to hear from anyone reading this group who has an interest in N Y State IP address assignment matters - I think this would include n2igu, wa2wpi, wz2b and ka2nrc as well as wb6cyt, and I am pretty sure they are all reading this group. Please correct me if I am wrong. Jim, nq2d doesn't but he is local and I talk with him directly. I don't know how to reach you all, and I may have overlooked others, so I a bit reluctantly feel this is the best way to reach everyone. Apologies for any wasted bandwidth. Tnx and 73, Bob k2euh mail "foxworth@bnlux0.bnl.gov" or packet k2euh@kc2fd.ny.usa ------------------------------ End of TCP-Group Digest ****************************** From tcpxxx Thu Jan 3 22:26:51 1991 Date: Thu, 3 Jan 91 22:26:42 GMT Message-Id: <4110@G1YYH> From: g1yyh@G1YYH (John Heaton) Reply-To: g1yyh@g1yyh (g1yyh@gb7nwp) To: tcpxxx@G1YYH Subject: TCP-Group Digest #003 Date: Thu, 3 Jan 91 04:30:11 PST From: Advanced Amateur Radio Networking Group Reply-To: TCP-Group@UCSD.Edu Subject: TCP-Group Digest V91 #3 To: tcp-group-digest TCP-Group Digest Thu, 3 Jan 91 Volume 91 : Issue 3 Today's Topics: AX.25 Network Simulation (2 msgs) HF (SLOW) TCP/IP Experiment on 18.107 Mhz. SS and AR Status of Mac KA9Q Bits TNC 1 Question Send Replies or notes for publication to: . Subscription requests to . Problems you can't solve otherwise to brian@ucsd.edu. Archives of past issues of the TCP-Group Digest are available (by FTP only) from UCSD.Edu in directory "mailarchives". We trust that readers are intelligent enough to realize that all text herein consists of personal comments and does not represent the official policies or positions of any party. Your mileage may vary. So there. ---------------------------------------------------------------------- Date: Wed, 2 Jan 91 10:14:06 -0800 From: brian (Brian Kantor) Subject: AX.25 Network Simulation To: packet-radio, tcp-group Has anyone done any network simulation on a prototypical AX.25 network using software tools like CACI's NETWORK or other network simulators? - Brian ------------------------------ Date: Wed, 2 Jan 91 16:42:58 EST From: mjj@stda.jhuapl.edu (Marshall Jose) Subject: AX.25 Network Simulation To: tcp-group@ucsd.edu > Has anyone done any network simulation on a prototypical AX.25 network using > software tools like CACI's NETWORK or other network simulators? Brian, I attempted to use NOS as the engine for an AX.25 (& higher) network simulation earlier last year as a school project. While not able to employ the wonderful network simulation analyzers out there, I was able to successfully hack the pktdrvr.c code to simulate the effects of distance, collisions, capture, and link margin. The project was a flop since NOS appears to be bad at pretending to be several independent TNCs. I wasn't able to find a way to cut the "corpus callosum", as it were, in NOS such that it wouldn't know about its other nodes. If somebody out there knows how that might be done, I'd happy to pass on to you the work I did. Marshall Jose WA3VPZ mjj%stda@aplcen.apl.jhu.edu || ...mimsy!aplcen!aplvax!mjj ------------------------------ Date: Wed, 2 Jan 91 23:14:06 MST From: John Hays SEC --- SLC Subject: HF (SLOW) TCP/IP Experiment on 18.107 Mhz. To: tcp-group@ucsd.edu Hi All, I mentioned before the holidays a desire to experiment with NOS over HF Packet. I recieved a piece of mail from a chap in Alberta who is interested in 30 Meters. I have a terrible TVI problem on 30 but am willing to run short tests. However, over the holiday vacation (about 11 days, thanks HP), I started playing with 17 Meters. I found to my joy and suprize another NOS (G1EMM) user on 18.105 Mhz. in W7GHM [44.24.0.29] located in Oak Harbor?, WA --- Despite repeated power outages in the Seattle area due to bad weather we successfully operated IP (SMTP/TELNET/FTP/RIP/RSPF) between our stations and provided gateway service to our respective LANs, I even recieved some SMTP mail from old friends from my NAPRA days. On our last day of operation we agreed to use 18.107 (LSB) as our frequency, as there is a pretty active AX.25 net on 18.105 --- I would like to invite any others who would like to experiment to join us on 18.107 (My station will be up days that I am home, sometimes I work at home during the week so give a try.) or you can try 10.123 Mhz. at night with W7GHM and possibly myself (try 10.145/7 as alternate) --- 300 baud standard. My IP address is [44.40.1.3] on HF and the local lan / I also run [44.40.15.1] on UHF backbone here. HF Netrom is UTAH:KD7UW --- On rare occasions the Unix box is on the home ethernet to the XT doing the radios. Telnet to 'ender' from the MBOX ... [44.40.1.12] --- I will send password info to those who don't guess :) RIP and RSPF are active. John KD7UW hays@hpuslua.nsr.hp.com ------------------------------ Date: 02 Jan 91 18:43:23 EST From: Dewayne Hendricks WA8DZP <75210.10@CompuServe.COM> Subject: SS and AR To: Kevin, N6RCE writes: >> Maybe I should post the whole story of what we're about here soon to >>clear up things a bit.... > >Do as you see the need Dewayne. There are several efforts here in the SF Bay Area which are trying to develop some sort of high-speed packet network. The one I'm associated with is the local Apple Macintosh crowd. We are looking for some sort of hardware which will give us at least a LocalTalk speed network (230.4 kbps) which we will us with the System 7 based tcp/ip for the Macintosh we have in development. To that end, we have been looking at various commerical products to see if they meet our requirements and if not determine if they could be modified to do so. Wireless networking is a hot topic with a number of commercial firms these days. A number of companies have units which operate under the FCC Part 15 rules which don't require a license. To make a long story short, after looking at several of these products we selected a company called Proxim in Mt. View, CA to examine further. Proxim has several spread spectrum (SS) products which operate in the 902-928 MHz band with output power of either 100 mw or 1 watt. By "products" I mean they sell units on an OEM basis for companies to integrate into their own products (note: they just announced an end-user product of their own, a 241 kbps rf modem). We obtained an evaulation kit from them and have packaged them and developed support for them in the Macintosh version of the KA9Q bits. We have been running various tests to see how well they function and the maximum range we can get with the 1 watt units. To date we have been able to get a range of 2.3 mi by using yagi antennas. The units we have been using have a top speed of 121 kbps. We have been doing all of our testing at 19.2 kbps. Our intent right now is to mod the units in various ways in order to get the maximum range possible out of them. These mods will move them out of the Part 15 arena and into the world of Part 97. We have been working closely with Proxim and our hope is that after all of this testing and evaulation effort, we will be able to get them to produce some units which will meet our final set of requirements. > >>LANs aren't WANs or even MANs. >> >>N6RCE >> >>>>Now I've got to make up some yagi antennas and see if I can make it >> >>At least people are hearing the message that omni-to-omni is wasteful. >> >> You seem to be replying to both Russ Nelson's and my postings here. >> >I did cut a line from Russ's posting, but you also indicated you were planning >on using directional antenna's. > >The comment about LANS, etc and Yagi's aren't directly related. One of the >things Glenn has been trying to point out for (ever) is how wasteful >omni-to-omni is on spectrum usage within digital packet radio for AR. > >It seems like you and Russ are discovering experimentally what Glenn has been >trying to explain therotically for some time. Which I'm glad is happenning. I agree with Glenn's position in general. However, I feel that there are certain "mission" specific requirements where omni-to-omni is the best choice. For those of you who are not familiar with Glenn N6GN's et al thoughts, I suggest that you read their excellant paper in the proceedings of the 9th ARRL Computer Networking Conference which is available from ARRL HQ. >It's hard to explain the last years of tinkering and thinking, but some of the >things worth noting include: > >1) Radio receivers intended to work in LAN environment ( 50-200 ft) > don't have to be as sensitive as receivers for MANs or even WANS. > Those PROXIMs work to about -40dBm. The units Glenn put together > so far work down to about -75dBm. That HT on your belt goes down > to -110 dBm ( ignoring or lumping a few Ktb's in). Thanks for pointing this out. You are correct that the Proxim units were designed for the LAN environment. The units which I am now playing with work at -90 dBm. Proxim now realizes that they made a mistake in their product design. It seems that the prospective OEM's they encounter these days want more range out of the product then they have been able to obtain. OEM's seem to be wanting a WAN product from Proxim and not a LAN. This was one of the first things their VP of Sales brought up when we started talking to them. BTW, Proxim's stuff is now being used by Nynex and NCR. >2) Ethernet ( CSMA/CD ) has a built-in slot time. The major contributor > to the upper bound on slot-time is propogation delay. What happens > with the proxim units when you get a large number of users going? That is another good issue. That was the second problem out of the mouth of the VP. They haven't figured out a solution for that one either. For now, we will be ingnoring that issue. It will have to be readdressed again later. >3) Frequency re-use and coordination. Right now, 902 Mhz is pretty > much unused, so there is plenty of room for us all to experiment. > However, since SS isn't channelized, your either going to have to > develop a protocol to handle 500+ hams all on the same chipping > sequence, or issue spreading sequences per group. Again, > coordination and cooperation is going to be the real problems, > rather than get the technology to work. I can't agree with you more. We are really going to need better coordination and cooperation in amateur packet radio then there has been (at least in Northern CA) to get this type of technology into service in the amateur community. Proxim has addressed the channel problem somewhat by implementing switchable channels as part of their design. It won't however be able to handle the case where there are 500+ hams using these units. >Dewayne, these comments aren't mean't at flames at all. I'm am very glad >you and Russ are experimenting in this direction. AR doesn't need just >one solution or everyone going in the same direction. I didn't take this to be a 'flame' on your part. You raised a number of very good points. I hope that what we are doing will complement the efforts of you and Glenn, et al. Right now, I am looking our for the needs of my Macintosh tcp/ip community. With the code that we will be shipping this year, we will need all of the speed we can get in order to run Macintosh applications across the network. Two of the things that AR has been good at over the years is 1) finding and applying commercial products to the ham radio environment and 2) cost reducing those products in unique ways to suit the needs of the ham pocketbook. As I said earlier, there is a lot of new hardware out there these days to do high-speed networking. The commercial amateur packet firms are just now starting to come out with products which will move us from 1200 bps to 19.2 kpbs. If we can adapt/utilitize this other hardware which has been already been designed for low-cost mass production to amateur packet radio, then it will be a big "win" for everyone! >With the advent of no-code, we will find the issues you present of >higher power SS units an increasing reality. If we aren't to become >a complete computer-CB band then we must think about the issues of >building a MAN or WAN ( depending if you live in the Bay Area or >Wichita, Kansas). Right on!!! It will be a real challenge and I feel that amateur radio can make some real contributions here. >However, I'm not sure technology designed for the LAN world can be >adapted to the MAN world and not create a mess. You may be right of course. We shall see. In any event, could it be any worse then the "mess" that exists now? :-) >GL and I'm looking forward to hearing the results of your work. Likewise!! I will be posting updates to the group as things develop. 73's -- Dewayne WA8DZP Internet: 75210.10@@compuserve.com ------------------------------ Date: 02 Jan 91 17:31:08 EST From: Dewayne Hendricks WA8DZP <75210.10@CompuServe.COM> Subject: Status of Mac KA9Q Bits To: I thought that it was time to update all interested parties in the status of the Apple Macintosh version of the KA9Q Internet Protocol Package and upcoming developments which relate to it. The current release, version 2.0 was released last year at the Dayton Hamvention. It has been widely distributed and is available from many sources. This version is based upon the last public release of NET although it does have some NOS features. The function and features of this release are documented in an article which appeared in the October, 1989 issue of "73 Magazine" and the proceedings of the 8th ARRL Computer Networking Conference (CNC). This version is available for ftp from apple.com in the pub/ham-radio directory. The file names you should pick up are: BM-Mac2.sit.hqx - Object of the BM Mailer BM-Mac2.src.sit.hqx - THINK C source code for BM Net-Mac2.sit.hqx - Object of NET Net-Mac2.src.sit.hqx - THINK C source code for NET The files are binhex'ed and packed with StuffIt Deluxe. If you don't have that commercial product, be sure to pick up the public domain UnStuffIt Deluxe in the same folder, under the name UnstufitDlx.hqx. Are current plans are to due one more release of the NET based version. This release will fix all bugs that we are aware of and had a number of features which have been requested by our users. An article which describes this release appears in the proceedings of the 9th ARRL CNC. The current plan is to have this version ready to go in time for the next Dayton Hamvention in '91. However, in order to get as much feedback on this release as possible from our users, we have posted and will continue to post on apple.com the latest development versions so that anyone interested can give them a try and inform us of any problems. The current development versions are named as follows: BM-Mac2.1D1.sit.hqx - Object of development version of BM Mailer Net-Mac2.1D1.sit.hqx - Object of development version of NET/Mac We do not plan to post the source code until the time of final release. However, if anyone really wants it, all they have to do is ask. As we post new versions, I will post a note announcing this to the tcp-group. If you encounter any problems with a development release, please contact me at the email addresses below or use my smail address. The files described above are also available from the Digikron landline BBS at (408) 253-1309 for those of you without Internet ftp capability. As I said above, this will be the last release for the Macintosh done by us based upon NET. Further, we do not plan to offer a port NOS to the Macintosh. Instead, we are in the process of developing a new ground up package that will conform to the requirement of the upcoming System 7 operating system and the Communications ToolBox (CTB). This new support will consist of a CTB tool that will implement the function required to extend AppleTalk over a packet radio network and allow Macintosh applications to function as they would over an AppleTalk network (ie LocalTalk, EtherTalk, etc.). This new tool in addition will be able to interoperate with any NOS implementation. This code is now under development and test here in Northern California. We plan to make it available whenever Apple decides to ship System 7 to the world at large. The last we heard was that this is expected to happen "sometime in the first half of '91". We will be reporting more on this work as it becomes available. We will be writing a paper on the work for the 10th ARRL CNC this fall. If anyone out there is interested in developing a version of NOS for the Macintosh, I would be happy to help out in any way I can. I did a port last year for my own purposes, so I am quite familiar with the issues and problems involved in such an effort. My thanks to all of you out there who have supported this effort over the last several years. Your encourgment and feedback have been most appreciated. 73's -- Dewayne Hendricks WA8DZP Internet: 75210.10@@compuserve.com AppleLink: D6547 Smail: 43730 Vista Del Mar Fremont, CA 94539-6250 ------------------------------ Date: Wed, 2 Jan 91 20:17:37 EST From: Scott R. Weis KB2EAR Subject: TNC 1 Question To: tcp-group@ucsd.edu I have an AEA PKT-1 that I would like to put on TCP/IP. Is there any way I can put kiss roms in it? Tnx, -- Scott R. Weis KB2EAR A.R.E.S. Coordinator South Brunswick NJ Internet: kb2ear@kb2ear.UUCP Packet: KB2EAR @ NN2Z.NJ.USA.NA Snail Mail: 10 Palmer Rd., Kendall Park NJ, 08824-1228 Phone: +1 908 297 0469 Pager: +1 908 954 0215 UUCP: kb2ear Any ACU 9600 1-908-297-8713 in:-BREAK-in:-BREAK-in: nuucp Radio: 440.800 +5 MHz, 141.3 Hz PL ------------------------------ End of TCP-Group Digest ****************************** From tcpxxx Tue Jan 8 23:03:18 1991 Date: Tue, 8 Jan 91 23:02:40 GMT Message-Id: <4214@G1YYH> From: g1yyh@G1YYH (John Heaton) Reply-To: g1yyh@g1yyh (g1yyh@gb7nwp) To: tcpxxx@G1YYH Subject: TCP-Group Digest #004 Date: Fri, 4 Jan 91 04:30:11 PST From: Advanced Amateur Radio Networking Group Reply-To: TCP-Group@UCSD.Edu Subject: TCP-Group Digest V91 #4 To: tcp-group-digest TCP-Group Digest Fri, 4 Jan 91 Volume 91 : Issue 4 Today's Topics: Arlan 450 antenna troubles ax.25 packet driver Lex data terminals connect TCP/IP networks with radio mail address for k8ka/nk6k NOS and SYS V nos and the toshiba T1000SE SS and AR SS and AR -> proxim units (2 msgs) Send Replies or notes for publication to: . Subscription requests to . Problems you can't solve otherwise to brian@ucsd.edu. Archives of past issues of the TCP-Group Digest are available (by FTP only) from UCSD.Edu in directory "mailarchives". We trust that readers are intelligent enough to realize that all text herein consists of personal comments and does not represent the official policies or positions of any party. Your mileage may vary. So there. ---------------------------------------------------------------------- Date: Thu Jan 3 13:54:02 1991 From: nelson@grape.ecs.clarkson.edu Subject: Arlan 450 antenna troubles To: tcp-group@ucsd.edu Hi. A few people were interested in hearing how I'm getting along with pushing the limits of an Arlan 450. Well, my boss got back from vacation, and choked when he saw my yagis. Seems that you can't build them on a PC board (even unclad) without changing the tuning. Sigh. So we're going to try again, this time reading (and following) the ARRL Antenna handbook. -russ ------------------------------ Date: Thu, 03 Jan 91 14:08:48 CST From: g4jec@g4jec.ampr.org (Chris Cox W0/G4JEC) Subject: ax.25 packet driver To: tcp-group@ucsd.edu Further to my message I sent to the group on Tuesday regarding the asy device send lockups, I decided to try using the slip8250 packet driver today, rather than the internal attach asy method. I tried both "KISS" and "AX.25" for the device mode, but I couldn't get either to work with NOS. Incidentally, execut- ing the slip8250.com file for my tnc's causes the same symptoms as when the attached asy device eventually locks-up - i.e. the pc->tnc tx data LED comes on and then stays on, as soon as the slip8250 command is executed. Unplugging the rs232 cable from the tnc does not cause the LED to go out, however, a hard-resetof the tnc does. Apart from that particular problem, any packets that the tnc receives when it is being driven by the packet driver appear as garbage to NOS. Turning trace on for the port shows up the data as either having an ax25 "bad header", or some illegal kiss code (152 seemed frequent). Has anyone at all experienced the problem I described in the preceding message, and/or successfully used the Clarkson slip8250 packet driver with a kiss tnc2? In case anyone missed my previous posting, I am most willing to either send the message to anyone who would like it, or alternatively I will repost it to the group if it never made it! It's i.d. was <4271@g4jec.ampr.org>. Thanks in advance for any comments/assistance... 73's ttfn Chris W0/G4JEC chrisc@moron.vware.mn.org g4jec@g4jec.ampr.org g4jec@g4jec.vware.mn.org 11th Hour Contest Group (North American Chapter) Minneapolis, MN EN34ju ------------------------------ Date: Wed, 2 Jan 91 16:10:38 EST From: Russ Nelson Subject: Lex data terminals connect TCP/IP networks with radio To: tcp-group@ucsd.edu The Sun-Observer-Europe has a new product announcement: Data terminals that link by radio frequency directly with mainframe TCP/IP networks have been launched by industrial communications company Lex Concessionaires. Lex supplies wireless LXE radio data terminals to allow shopfloor operators to communicate with a host computer with little or no software changes in installation, according to David Howe, company spokesperson. The LXE network controller board provides an interface compatible with Sun. The radio terminals have an average system capable of over 10,000 computer updates an hour, according to Howe. Communicatio0n between LXE wireless terminals and other networks can be carried out by industry-standard TCP/IP Telnet protocol. Sheesh! They certainly managed to avoid giving out any pertinent details in *that* press release... -russ ------------------------------ Date: Fri, 4 Jan 91 9:44:08 MET From: Rob Janssen (PE1CHL) Subject: mail address for k8ka/nk6k To: hp4nl!tcp-group@relay.EU.net (TCP/IP interest group) Hello, Does anybody have a valid and working mail address for G0/K8KA and/or NK6K? I have sent some messages to their compuserve address (71635.1174@compuserve.com) but never received a reply. Rob PE1CHL ------------------------------ Date: Thu, 03 Jan 91 16:55:49 PST From: beacker@mips.com (Bradley Eacker) Subject: NOS and SYS V To: tcp-group@ucsd.edu Doug has inspired me. I have gone and gotten a copy of the 11/28 version of nosnix from sics.se. I have it up and functioning in a reasonable fashion on 2 different SYS V machines (Altos 5.2 and Mips 5.3). It doesn't have all the bells and whistles, but it does ftp and ping. I have not tried the telnet yet, and have not had anyone ping into the machine (yet). It does seem relatively stable. I will be trying to add some of the things that Anders has mentioned in his work (fingerd, telnetd, ftpd, etc.). My main goal will be to have this be a setup and forget kind of operation, with multiple mailbox connections on the same channel (no problem with multiple processes for the mailbox). I have to send Anders a set of patches for the sys5 stuff that I had to add. If there is interest in this I will go ahead and make it available on thumper. As you can see from the couple of machines that I have been using it on, it does not rely on anything out of the ordinary. Brad Eacker (beacker@mips.com KB6FED) ------------------------------ Date: Thu, 03 Jan 91 18:29:48 EST From: Edward Vielmetti Subject: nos and the toshiba T1000SE To: tcp-group@ucsd.edu Hi. I've seen problems here using the 901130 version of NOS with the Toshiba T1000SE. The short description of the problem is: - starts up OK - prints a prompt, gives help - 20 or 30 seconds later (or immediately after a ps), machine hangs. When you reboot, the Toshiba "HardRam" ram disk is corrupted, and it needs to be reformatted :-(. Anyone who is successfully running with a T1000SE laptop, let me in on your secrets. --Ed emv@ox.com ------------------------------ Date: 03 Jan 91 13:35:22 EST From: Dewayne Hendricks WA8DZP <75210.10@CompuServe.COM> Subject: SS and AR To: Below is an excerpt of a posting I made to the group yesterday: >>It's hard to explain the last years of tinkering and thinking, but some of >>the things worth noting include: >> >>1) Radio receivers intended to work in LAN environment ( 50-200 ft) >> don't have to be as sensitive as receivers for MANs or even WANS. >> Those PROXIMs work to about -40dBm. The units Glenn put together >> so far work down to about -75dBm. That HT on your belt goes down >> to -110 dBm ( ignoring or lumping a few Ktb's in). > > Thanks for pointing this out. You are correct that the Proxim units were >designed for the LAN environment. The units which I am now playing with work >at -90 dBm. Upon reviewing this posting, Mike Chepponis K3MC, who is a part of this effort, made the following comments to me which I thought were important to post: Only _minor, minor_ thing is -90dBm figure; basically that is the value that the detector begins to work (I believe). I would think that this figures are comparing apples & oranges. In particular, if Glenn's radios do -75 dBm, then the Proxim radios *certainly* do no better than -60 dBm or so (***if that***). This is because I have a diagram of Glenn's radio, and it is a very carefully engineered radio & front end, etc. That is, -75 dBm is damn near state-of-the art for a 250 kbit/sec data rate. So the problem with Proxim's numbers vs Glenn's numbers is that they must be comparing different things; they way the numbers are now suggest that Glenn's radios are deaf, when, in fact, we know that the Proxim boxes could use a system noise figure reduction. I hope that clarifies the earlier posting a bit for those who are interested. -- Dewayne WA8DZP Internet: 75210.10@@compuserve.com ------------------------------ Date: Thu, 3 Jan 91 10:35:09 PST From: Kevin J. Rowett Subject: SS and AR -> proxim units To: tcp-group@ucsd.edu >Date: 02 Jan 91 18:43:23 EST >From: Dewayne Hendricks WA8DZP <75210.10@CompuServe.COM> >Subject: SS and AR >To: > [...] >been running various tests to see how well they function and the maximum range >we can get with the 1 watt units. To date we have been able to get a range of >2.3 mi by using yagi antennas. >> >> don't have to be as sensitive as receivers for MANs or even WANS. >> Those PROXIMs work to about -40dBm. [...] > > Thanks for pointing this out. You are correct that the Proxim units were >designed for the LAN environment. The units which I am now playing with work >at -90 dBm. > Proxim now realizes that they made a mistake in their product design. It [...] >73's >-- Dewayne WA8DZP >Internet: 75210.10@@compuserve.com Humm.. Someone's calculator is broken. Over your 2.3 mile test path, PL could be estimated at 104dB. ( 37 + 20 log distance + 20 log frequency ). I understood the Yagi you used to have 18 dBi on one end and 12 dBi on the other end. Add to this your stated power output of 1 watt (30dBm) I get a total of 60 dBm ERP. This leads to a input power of -44 dBm, which must be the sensitivity of the units. You've used the free air as a graduated (very fine ) step attenuator. N6RCE ------------------------------ Date: Thu, 03 Jan 91 14:59:10 cst From: gerry@n5jxs.jsc.nasa.gov Subject: SS and AR -> proxim units To: kevinr@suntan.tandem.com ..Strange, I get -107 dB path loss...What's 3dB among friends, anyway? ------------------------------ End of TCP-Group Digest ****************************** From tcpxxx Tue Jan 8 23:03:34 1991 Date: Tue, 8 Jan 91 23:03:24 GMT Message-Id: <4216@G1YYH> From: g1yyh@G1YYH (John Heaton) Reply-To: g1yyh@g1yyh (g1yyh@gb7nwp) To: tcpxxx@G1YYH Subject: TCP-Group Digest #005 Date: Sat, 5 Jan 91 04:30:09 PST From: Advanced Amateur Radio Networking Group Reply-To: TCP-Group@UCSD.Edu Subject: TCP-Group Digest V91 #5 To: tcp-group-digest TCP-Group Digest Sat, 5 Jan 91 Volume 91 : Issue 5 Today's Topics: isat ??? KA9Q Net/NOS Availability NOS and SYS V (2 msgs) NOS memory leak identified TCP-Group Digest V91 #2 Send Replies or notes for publication to: . Subscription requests to . Problems you can't solve otherwise to brian@ucsd.edu. Archives of past issues of the TCP-Group Digest are available (by FTP only) from UCSD.Edu in directory "mailarchives". We trust that readers are intelligent enough to realize that all text herein consists of personal comments and does not represent the official policies or positions of any party. Your mileage may vary. So there. ---------------------------------------------------------------------- Date: Fri, 4 Jan 91 7:00:49 EST From: Scott R. Weis KB2EAR Subject: isat ??? To: tcp-group@ucsd.edu Can someone please tell me what the isat command is? Can I use it on a 286? Tnx, -- Scott R. Weis KB2EAR A.R.E.S. Coordinator South Brunswick NJ Internet: kb2ear@kb2ear.UUCP Packet: KB2EAR @ NN2Z.NJ.USA.NA Snail Mail: 10 Palmer Rd., Kendall Park NJ, 08824-1228 Phone: +1 908 297 0469 Pager: +1 908 954 0215 UUCP: kb2ear Any ACU 9600 1-908-297-8713 in:-BREAK-in:-BREAK-in: nuucp Radio: 440.800 +5 MHz, 141.3 Hz PL ------------------------------ Date: 4 Jan 91 16:15:00 CST From: "Suresh Kagoo" Subject: KA9Q Net/NOS Availability To: "tcp-group" I am quite new to Packet Radio. I have been reading about KA9Q's TCP/IP for IBM Compatibles. I would like to find out where I can FTP a Beginers Package of the NET/NOS. Also need to get an IP address (AMPR) coordinated for Memphis, Tennessee. Thanks In advance. Suresh *********************************************************************** Suresh Kagoo Internet: Skagoo@memstvx1.memst.edu Academic Computer Services Suresh.Kagoo@f16.n123.z1.Fidonet.Org Memphis State University Bitnet : SKAGOO@MEMSTVX1 Memphis, Tennessee Amateur Radio : N9GSA/ 4S7??? FIDONET : 1:123/16 "Sri Lanka a taste of Paradise" *********************************************************************** ------------------------------ Date: Fri, 4 Jan 91 09:03 CST From: quack@pueblo.att.com Subject: NOS and SYS V To: pueblo!att!nn2z!tcp-group-relay@ucsd.edu (Bradley Eacker), Brad, Sounds real nice. Sure I would be interested..... Thanks, Jim ====================================================== ------------------------------ Date: Thu, 03 Jan 91 16:55:49 PST From: beacker@mips.com (Bradley Eacker) Subject: NOS and SYS V To: tcp-group@ucsd.edu Doug has inspired me. I have gone and gotten a copy of the 11/28 version of nosnix from sics.se. I have it up and functioning in a reasonable fashion on 2 different SYS V machines (Altos 5.2 and Mips 5.3). It doesn't have all the bells and whistles, but it does ftp and ping. I have not tried the telnet yet, and have not had anyone ping into the machine (yet). It does seem relatively stable. I will be trying to add some of the things that Anders has mentioned in his work (fingerd, telnetd, ftpd, etc.). My main goal will be to have this be a setup and forget kind of operation, with multiple mailbox connections on the same channel (no problem with multiple processes for the mailbox). I have to send Anders a set of patches for the sys5 stuff that I had to add. If there is interest in this I will go ahead and make it available on thumper. As you can see from the couple of machines that I have been using it on, it does not rely on anything out of the ordinary. Brad Eacker (beacker@mips.com KB6FED) ------------------------------ Date: Thu, 3 Jan 91 23:57:28 EST From: mitel!Software!perryd@uunet.UU.NET (Dave Perry) Subject: NOS memory leak identified To: tcp-group@ucsd.edu Hi folks, Somewhere between the 900828 version and the 901128 version there was a bug introduced in dirutil.c. In the function dodir(), the argv parameter for the call to domore() is dynamically allocated. In the old version, this was freed by calling freeargs, and in the new version the call is missing. The result is that you get 2 more mallocs than frees every time you get a directory listing. I suspect that this is related to the fact that newproc() now has a flag as one of its parameters to specify whether arguments should be freed on termination of the process. The problem is, in this case the command is not associated with new process, only a new session. We're not talking about much memory here, but every little bit helps :-) Dave ------------------------------ Date: Fri, 4 Jan 91 16:34:53 PST From: microme!mikeh@ism.isc.com (Michael L. Hasenfratz) Subject: TCP-Group Digest V91 #2 To: TCP-Group@UCSD.Edu Date: Tue, 1 Jan 91 21:51:16 -0800 From: brian (Brian Kantor) Subject: Casting Pearls among Swine To: tcp-group You know, it's messages like the following (found on our local BBS) that cause me to despair that when we get the network built, will the people even notice? - Brian --- Much 'GARBAGE' deleted --- Brian, Take heart! Some of us can't wait to get the TCP/IP network running. Besides, He probably was'nt able to get NET running on his C64 anyway. ;-) Michael Hasenfratz - WA6FXT ------------------------------ End of TCP-Group Digest ****************************** From tcpxxx Tue Jan 8 23:03:44 1991 Date: Tue, 8 Jan 91 23:03:37 GMT Message-Id: <4218@G1YYH> From: g1yyh@G1YYH (John Heaton) Reply-To: g1yyh@g1yyh (g1yyh@gb7nwp) To: tcpxxx@G1YYH Subject: TCP-Group Digest #006 Date: Sun, 6 Jan 91 04:30:13 PST From: Advanced Amateur Radio Networking Group Reply-To: TCP-Group@UCSD.Edu Subject: TCP-Group Digest V91 #6 To: tcp-group-digest TCP-Group Digest Sun, 6 Jan 91 Volume 91 : Issue 6 Today's Topics: Memory problems NOS and SYS V Send Replies or notes for publication to: . Subscription requests to . Problems you can't solve otherwise to brian@ucsd.edu. Archives of past issues of the TCP-Group Digest are available (by FTP only) from UCSD.Edu in directory "mailarchives". We trust that readers are intelligent enough to realize that all text herein consists of personal comments and does not represent the official policies or positions of any party. Your mileage may vary. So there. ---------------------------------------------------------------------- Date: Sat, 5 Jan 91 9:00:49 PST From: Pete Carah Subject: Memory problems To: tcp-group@ucsd.edu I see memory problems both in an old KA9Q version (900810) that I'm actually using right now, and kh113014 (worse). The setup is that I'm using both of these as ethernet terminals to talk to a unix box, with no radios attached (though radio is configured in both packages). Primary symptom is that on a telnet session, if the unix box outputs a lot without any input from the user, the ka9q package locks up and needs to be rebooted (sometimes it will restart from "exit" then "net", but I don't trust it). Since this leaves a session hanging on the unix box it isn't too great. This occurs on both versions. The g1emm version also has a bug in ftp that isn't in the older ka9q version, the older one gets about 20k bytes/sec in image mode (slow but tolerable), while the g1emm gets 4K bytes/sec at best. The old one stays that way forever, but the g1emm one transfers about 400-500K then drops to about 1.5k bytes/sec. If one does a mem st at this point, one finds yellow garbage collects and lots of Ibuf fails. Hardware and driver setup is Clarkson driver (v7 I think) with wd8003e board. -- Pete (K6JRR) pete@puffin.uucp (grian!puffin!pete@elroy.jpl.nasa.gov for those without uucp routers) ------------------------------ Date: Sat, 5 Jan 91 12:38:54 -0800 From: teeter!bobt@ism.isc.com (Bob Teeter) Subject: NOS and SYS V To: ism!beaker@mips.com, ism!microme!mikeh, ism!quack@pueblo.att.com I have had the code base from anders for a while and have found that it works fine. It just has one fault, no smtp and no console functionality. I have cut in the console functions but haven't finished the smtp yet. I have been working with about 8 hams at my work(Interactive Systems, the 386 UNIX people) and several others to get the code base finished for NOS working correctly under UNIX(multi-process). If you are interested the code base I posted on thumper.bellcore.com for the NET version is there and I would be happy to put my NOS version there also. As I said all it is missing is the smtp code to have all the functionality of NET. Bob Teeter - N6XJJ ------------------------------ End of TCP-Group Digest ****************************** From tcpxxx Tue Jan 8 23:03:54 1991 Date: Tue, 8 Jan 91 23:03:47 GMT Message-Id: <4220@G1YYH> From: g1yyh@G1YYH (John Heaton) Reply-To: g1yyh@g1yyh (g1yyh@gb7nwp) To: tcpxxx@G1YYH Subject: TCP-Group Digest #007 Date: Mon, 7 Jan 91 04:30:09 PST From: Advanced Amateur Radio Networking Group Reply-To: TCP-Group@UCSD.Edu Subject: TCP-Group Digest V91 #7 To: tcp-group-digest TCP-Group Digest Mon, 7 Jan 91 Volume 91 : Issue 7 Today's Topics: isat ??? NOS and SYS V PC-elm source. TNC-1 in 300 bps KISS mode Send Replies or notes for publication to: . Subscription requests to . Problems you can't solve otherwise to brian@ucsd.edu. Archives of past issues of the TCP-Group Digest are available (by FTP only) from UCSD.Edu in directory "mailarchives". We trust that readers are intelligent enough to realize that all text herein consists of personal comments and does not represent the official policies or positions of any party. Your mileage may vary. So there. ---------------------------------------------------------------------- Date: Sun, 6 Jan 91 20:45:08 UTC From: karn@ka9q.bellcore.com (Phil Karn) Subject: isat ??? To: kb2ear!kb2ear@rutgers.edu, tcp-group@ucsd.edu The "isat" command specifies whether the system has the Intel 8254 timer chip used in the AT and later model PCs and PC clones. This is distinguished from the 8253 chip used on the original PC and the XT. I recently enhanced the timer routines to get resolution better than one tick, but I could only make it work on the 8254 chip. Unfortunately there seemed to be no easy way to tell the difference between the two chips in software, so I punted the issue and left it a configuration option. Phil ------------------------------ Date: Mon, 07 Jan 91 09:25 From: "Olaf Erb" Subject: NOS and SYS V To: tcp-group@UCSD.EDU It works. I found NOS 900117b.u from Gary L. Grebus, k8lt, who build it for the Unix-PC. I added Anders' mbox code and kd8wk's telunix and xsocket features. There's still some problem with the telunix, but i think it's easy to fix (maybe an EOL problem). A few ------------------------------ Date: Mon, 07 Jan 91 11:59:04 GMT From: kelvin@kelvin.uk22.bull.com Subject: PC-elm source. To: tcp-group@ucsd.edu I've just put the source file for PC-elm v 2.1 on thumper under /pub/ka9q/incoming/G1EMM. It's *NOT* bug free, but it does mostly work and it can also read the nntp mailfiles built by my version. Enjoy! -- All the best, Kelvin. +-------------------------------------------------+ | Kelvin J.Hill - BULL HN Ltd, Hounslow, England. | | Internet - kelvin.uk22.bull.com [128.35.110.6] | | Amprnet - g1emm.ampr.org [44.131.7.6] | +-------------------------------------------------+ ------------------------------ Date: Mon, 7 Jan 91 08:26:56 +0100 From: adam%TNOAL1.TNO.NL@CUNYVM.CUNY.EDU Subject: TNC-1 in 300 bps KISS mode To: Packet-radio@UCSD.Edu, tcp-group@ucsd.edu Hello all, Thanks to all who responded to my 300 bps KISS problem. I got the clue from toth!dave@ria.ccs.uwo.ca (who seems te be unrechable for me, at least I got my message to him back 'undeliverable'), who advised me to set the TXTAIL to about 200 milliSeconds. I am using the PA0GRI version of KISS for the TNC-1, and it seems, that the transmitter it not held in transmit state long enough to send out the complete packet-frame. Holding the transmitter ON for an extra 200 mS cured the problem. 73 de __ / / / /-/ __/ __/ ____ / / (_/ (_/ / / / +------------------------------------------------------------------+ |Please send your reply to: |Where |Mac |Software | |-----------------------------------------+-------+-----+----------| |TNO ZP-LAN:adam@tnoal1 (134.221.128.128)|office |SE |NCSATelnet| | internet:adam@tnoal1.tno.nl | same |same | same | | or:pa2aga@tnoal1.tno.nl | same |same | same | | bitnet:gaalen@hdetno51.bitnet | same |same |DynaComm | | Ham-radio:pa2aga@pa2aga (44.137.32.9) |at home|IIx |NET/Mac | | or:pa2aga@pa2aga-1 (44.137.32.61)|at home|Plus |NET/Mac | | or:pa2aga@pa2aga-2 (44.137.32.19)|at home|512Ke|NET/Mac | | or:pa2aga@pi8mac (44.137.32.22)|at home|SE/30|NET/Mac | +------------------------------------------------------------------+ ------------------------------ End of TCP-Group Digest ****************************** From tcpxxx Tue Jan 8 23:04:06 1991 Date: Tue, 8 Jan 91 23:03:58 GMT Message-Id: <4222@G1YYH> From: g1yyh@G1YYH (John Heaton) Reply-To: g1yyh@g1yyh (g1yyh@gb7nwp) To: tcpxxx@G1YYH Subject: TCP-Group Digest #008 Date: Mon, 7 Jan 91 11:38:23 PST From: Advanced Amateur Radio Networking Group Reply-To: TCP-Group@UCSD.Edu Subject: TCP-Group Digest V91 #8 To: tcp-group-digest TCP-Group Digest Mon, 7 Jan 91 Volume 91 : Issue 8 Today's Topics: hpuslua mail bounces Send Replies or notes for publication to: . Subscription requests to . Problems you can't solve otherwise to brian@ucsd.edu. Archives of past issues of the TCP-Group Digest are available (by FTP only) from UCSD.Edu in directory "mailarchives". We trust that readers are intelligent enough to realize that all text herein consists of personal comments and does not represent the official policies or positions of any party. Your mileage may vary. So there. ---------------------------------------------------------------------- Date: Mon, 7 Jan 91 10:06:53 mst From: John Hays SEC --- SLC Subject: hpuslua mail bounces To: tcp-group@ucsd.edu For those of you who have recieved mail bounces from hpuslua, I have been working the problem(s) and things should be better now. John KD7UW ------------------------------ End of TCP-Group Digest ******************************