From wang!elf.wang.com!ucsd.edu!tcp-digest-relay Sun Feb 3 18:01:34 1991 remote from tosspot Received: by tosspot (1.63/waf) via UUCP; Sun, 03 Feb 91 19:32:02 EST for lee Received: from somewhere by elf.wang.com id aa15349; Sun, 3 Feb 91 18:01:34 GMT Received: from ucsd.edu by uunet.uu.net (5.61/1.14) with SMTP id AA24460; Sun, 3 Feb 91 09:19:21 -0500 Received: by ucsd.edu; id AA04622 sendmail 5.64/UCSD-2.1-sun Sun, 3 Feb 91 04:30:32 -0800 for jbloom Received: by ucsd.edu; id AA04615 sendmail 5.64/UCSD-2.1-sun Sun, 3 Feb 91 04:30:28 -0800 for /usr/lib/sendmail -oc -odb -oQ/var/spool/lqueue -oi -ftcp-digest-relay tcp-digest-list Message-Id: <9102031230.AA04615@ucsd.edu> Date: Sun, 3 Feb 91 04:30:24 PST From: Advanced Amateur Radio Networking Group Reply-To: TCP-Group@ucsd.edu Subject: TCP-Group Digest V91 #32 To: tcp-group-digest@ucsd.edu TCP-Group Digest Sun, 3 Feb 91 Volume 91 : Issue 32 Today's Topics: FCC Citation MORE Internet connection of ham radio networks multiple routes net rom timers in new NOS!? Packet Driver and Novell 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, 2 Feb 91 22:03:27 UTC From: karn@ka9q.bellcore.com (Phil Karn) Subject: FCC Citation MORE To: crompton@nadc.nadc.navy.mil, tcp-group@ucsd.edu I think I've just thought of the first good reason to get rid of the Received header lines in mail... if the FCC is going to use them to cite intermediate stations for carrying verboten traffic, then why should we make their jobs easier for them? :-) A bit more seriously, I am concerned that the FCC would use evidence as indirect as a Received line to cite a station for a rules violation. They assume that because a station appears in the list, it must have transmitted it at one time over amateur frequencies. But I know of at least some links within the BBS "network" that are phone lines, not amateur channels. Phil ------------------------------ Date: Sat, 02 Feb 91 18:15:54 +0900 From: kenji@ybbs.c.u-tokyo.ac.jp (Kenji Rikitake) Subject: Internet connection of ham radio networks To: tcp-group@ucsd.edu A late follow-up to the old topic, but anyway... Note that my comments here are only for technical aspects. No legal issues. In >Date: Thu, 17 Jan 91 13:48:05 EST >From: bill gunshannon <702WFG%SCRVMSYS.BITNET@CORNELLC.cit.cornell.edu> >Subject: AMPR.ORG and the INTERNET >Is there any way that AMPR.ORG could be connected to the INTERNET, given >it's disconnected nature and the fact that I highly doubt that there will >ever be a time when we have all of NET 44 connected together. Even if we >were able to connect the whole US (possible, but not likely) that would >still leave the rest of the world unconnected. This is one of the reasons that PRUG (Packet Radio User's Group) decided to introduce their own domain address, and IP network (Class B 133.168). PRUG has no objections using ampr.org address, but using 44.* will never let us connected into the Internet, unless PRUG can afford paying huge amount of money for their own trans-Pacific link. >Is it totally impossible given the state of TCPIP? You can connect an IP network to another through only one gateway, if you respect domain routing scheme. >If there is no suitable answer to the questions above, should we be >continuing down the path we currently are travelling, or should we perhaps >be looking at turning in th Class A address space in favor of either a >bunch of Class B's or a whole lot of Class C address spaces?? I think you don't have to stick to ampr.org since it is not an actual organization, rather existing virtually for ham radio enthusiasts who want to experiment TCP/IP without violating requirements from SRI-NIC. In this sense, if you have already got an authorized IP network address, you can use it on the radio too. >Am I the only one who sees AMPR.ORG ever connecting to the INTERNET? >Does everyone else see this potential (future) connection as a bad thing >and therefore something we should not be working towards? This is quite a social/political issue, so I don't want to make comments on this in detail, but I think ham radio network or ANY other networks should be able to exchange messages with the Internet community ASAP. And PRUG has been moving towards it. -- Kenji Rikitake, JJ1BDX PRUGNET Domain Administrator/Zone Contact aka jj1bdx@jh1ynw.prug.or.jp (for mail outside Japan please contact to kenji@ybbs.c.u-tokyo.ac.jp) -- Anyone reading this page has an amazing skill called literacy. -- Alvin Toffler, "Powershift", 1990 ------------------------------ Date: Fri, 1 Feb 91 13:37:11 CST From: val!ben@cs.utexas.edu (Ben Thornton) Subject: multiple routes To: tcp-group@ucsd.edu Doc writes: > The problem with only caching the incoming information is, I think, > that it relies on the OTHER guy to tell you about what path to use. > If NOS doesn't ever iniate such checking itself of which is the best > route, then NOS, all by its lonesome, will never update any routes. It > will, rather, rely on real-live people trying the alternatives first. > > In order for NOS to be "intelligent" itself then I think that it must > do a certain amount of "sniffing" for itself. "Flooding" sounds a bit > strong a term for it, because I suspect that most of us most of > the time would only have at most two reasonably plausible routes to > any given host. A couple of pings along two paths once an hour or > so shouldn't be a problem as far as channel usage is concerned, I > wouldn't have thought. > > But I'm glad that the issue has re-arisen, because I'd really like somebody > to try something...anything... (and not necessarily today :-) :-) :-) ) > > 73 -- Doc I recently had an idea along these lines. Would it be possible to extend RSPF to be able to recognize the "#" nodes in Netrom routing table update broadcasts? The RSPF code would then scan the currently loaded netrom table and add routes based on whether a station is preceded by the "#" in it's alias and whether the node is in the manually preloaded arp table. Is this rational? It would add no more network overhead, I wouldn't think, than that already added by RSPF. Ben -- Ben Thornton packet: WD5HLS @ KB5PM Video Associates Internet: ben@val.com Austin, TX uucp: ...!cs.utexas.edu!val!ben Did Schrodinger exist? ...or was that in another universe? ------------------------------ Date: Sun, 3 Feb 91 03:46:06 UTC From: karn@ka9q.bellcore.com (Phil Karn) Subject: net rom timers in new NOS!? To: Mark@hamster.business.uwo.ca, tcp-group@ucsd.edu Dave, NN2Z, also pointed this out. I'll fix it. Phil ------------------------------ Date: Fri, 01 Feb 91 17:54:05 CST From: g4jec@g4jec.ampr.org Subject: Packet Driver and Novell To: marcel@hb9rwm.ampr.org Thanks for the reply Marcel. The reason I wrote the message to the group is that the new Western Digital written (not the standard Clarkson distributed) packet driver is supposed to support both protocols directly. i.e. You can run the 8003PKDR.EXE driver standalone, or, alternatively, you can first load IPX (linked for the WD8003* using V3.09 of the WDPLUS.OBJ) and then load 8003PKDR. If 8003PKDR finds that IPX has already been loaded, it calls routines in IPX.COM, rather than manipulating the ethernet card directly itself. As I said, it is only failing when IPX has been loaded. Actually, it can send packets just fine, the problem is that no received packets get passed to the application (in my case NOS) via the packet interface. Again, thank you for replying. 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 ------------------------------ End of TCP-Group Digest ****************************** From wang!elf.wang.com!ucsd.edu!tcp-digest-relay Sun Feb 3 18:01:40 1991 remote from tosspot Received: by tosspot (1.63/waf) via UUCP; Sun, 03 Feb 91 19:32:06 EST for lee Received: from somewhere by elf.wang.com id aa15392; Sun, 3 Feb 91 18:01:39 GMT Received: from ucsd.edu by uunet.UU.NET (5.61/1.14) with SMTP id AA05954; Sun, 3 Feb 91 12:34:10 -0500 Received: by ucsd.edu; id AA04622 sendmail 5.64/UCSD-2.1-sun Sun, 3 Feb 91 04:30:32 -0800 for jbloom Received: by ucsd.edu; id AA04615 sendmail 5.64/UCSD-2.1-sun Sun, 3 Feb 91 04:30:28 -0800 for /usr/lib/sendmail -oc -odb -oQ/var/spool/lqueue -oi -ftcp-digest-relay tcp-digest-list Message-Id: <9102031230.AA04615@ucsd.edu> Date: Sun, 3 Feb 91 04:30:24 PST From: Advanced Amateur Radio Networking Group Reply-To: TCP-Group@ucsd.edu Subject: TCP-Group Digest V91 #32 To: tcp-group-digest@ucsd.edu TCP-Group Digest Sun, 3 Feb 91 Volume 91 : Issue 32 Today's Topics: FCC Citation MORE Internet connection of ham radio networks multiple routes net rom timers in new NOS!? Packet Driver and Novell 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, 2 Feb 91 22:03:27 UTC From: karn@ka9q.bellcore.com (Phil Karn) Subject: FCC Citation MORE To: crompton@nadc.nadc.navy.mil, tcp-group@ucsd.edu I think I've just thought of the first good reason to get rid of the Received header lines in mail... if the FCC is going to use them to cite intermediate stations for carrying verboten traffic, then why should we make their jobs easier for them? :-) A bit more seriously, I am concerned that the FCC would use evidence as indirect as a Received line to cite a station for a rules violation. They assume that because a station appears in the list, it must have transmitted it at one time over amateur frequencies. But I know of at least some links within the BBS "network" that are phone lines, not amateur channels. Phil ------------------------------ Date: Sat, 02 Feb 91 18:15:54 +0900 From: kenji@ybbs.c.u-tokyo.ac.jp (Kenji Rikitake) Subject: Internet connection of ham radio networks To: tcp-group@ucsd.edu A late follow-up to the old topic, but anyway... Note that my comments here are only for technical aspects. No legal issues. In >Date: Thu, 17 Jan 91 13:48:05 EST >From: bill gunshannon <702WFG%SCRVMSYS.BITNET@CORNELLC.cit.cornell.edu> >Subject: AMPR.ORG and the INTERNET >Is there any way that AMPR.ORG could be connected to the INTERNET, given >it's disconnected nature and the fact that I highly doubt that there will >ever be a time when we have all of NET 44 connected together. Even if we >were able to connect the whole US (possible, but not likely) that would >still leave the rest of the world unconnected. This is one of the reasons that PRUG (Packet Radio User's Group) decided to introduce their own domain address, and IP network (Class B 133.168). PRUG has no objections using ampr.org address, but using 44.* will never let us connected into the Internet, unless PRUG can afford paying huge amount of money for their own trans-Pacific link. >Is it totally impossible given the state of TCPIP? You can connect an IP network to another through only one gateway, if you respect domain routing scheme. >If there is no suitable answer to the questions above, should we be >continuing down the path we currently are travelling, or should we perhaps >be looking at turning in th Class A address space in favor of either a >bunch of Class B's or a whole lot of Class C address spaces?? I think you don't have to stick to ampr.org since it is not an actual organization, rather existing virtually for ham radio enthusiasts who want to experiment TCP/IP without violating requirements from SRI-NIC. In this sense, if you have already got an authorized IP network address, you can use it on the radio too. >Am I the only one who sees AMPR.ORG ever connecting to the INTERNET? >Does everyone else see this potential (future) connection as a bad thing >and therefore something we should not be working towards? This is quite a social/political issue, so I don't want to make comments on this in detail, but I think ham radio network or ANY other networks should be able to exchange messages with the Internet community ASAP. And PRUG has been moving towards it. -- Kenji Rikitake, JJ1BDX PRUGNET Domain Administrator/Zone Contact aka jj1bdx@jh1ynw.prug.or.jp (for mail outside Japan please contact to kenji@ybbs.c.u-tokyo.ac.jp) -- Anyone reading this page has an amazing skill called literacy. -- Alvin Toffler, "Powershift", 1990 ------------------------------ Date: Fri, 1 Feb 91 13:37:11 CST From: val!ben@cs.utexas.edu (Ben Thornton) Subject: multiple routes To: tcp-group@ucsd.edu Doc writes: > The problem with only caching the incoming information is, I think, > that it relies on the OTHER guy to tell you about what path to use. > If NOS doesn't ever iniate such checking itself of which is the best > route, then NOS, all by its lonesome, will never update any routes. It > will, rather, rely on real-live people trying the alternatives first. > > In order for NOS to be "intelligent" itself then I think that it must > do a certain amount of "sniffing" for itself. "Flooding" sounds a bit > strong a term for it, because I suspect that most of us most of > the time would only have at most two reasonably plausible routes to > any given host. A couple of pings along two paths once an hour or > so shouldn't be a problem as far as channel usage is concerned, I > wouldn't have thought. > > But I'm glad that the issue has re-arisen, because I'd really like somebody > to try something...anything... (and not necessarily today :-) :-) :-) ) > > 73 -- Doc I recently had an idea along these lines. Would it be possible to extend RSPF to be able to recognize the "#" nodes in Netrom routing table update broadcasts? The RSPF code would then scan the currently loaded netrom table and add routes based on whether a station is preceded by the "#" in it's alias and whether the node is in the manually preloaded arp table. Is this rational? It would add no more network overhead, I wouldn't think, than that already added by RSPF. Ben -- Ben Thornton packet: WD5HLS @ KB5PM Video Associates Internet: ben@val.com Austin, TX uucp: ...!cs.utexas.edu!val!ben Did Schrodinger exist? ...or was that in another universe? ------------------------------ Date: Sun, 3 Feb 91 03:46:06 UTC From: karn@ka9q.bellcore.com (Phil Karn) Subject: net rom timers in new NOS!? To: Mark@hamster.business.uwo.ca, tcp-group@ucsd.edu Dave, NN2Z, also pointed this out. I'll fix it. Phil ------------------------------ Date: Fri, 01 Feb 91 17:54:05 CST From: g4jec@g4jec.ampr.org Subject: Packet Driver and Novell To: marcel@hb9rwm.ampr.org Thanks for the reply Marcel. The reason I wrote the message to the group is that the new Western Digital written (not the standard Clarkson distributed) packet driver is supposed to support both protocols directly. i.e. You can run the 8003PKDR.EXE driver standalone, or, alternatively, you can first load IPX (linked for the WD8003* using V3.09 of the WDPLUS.OBJ) and then load 8003PKDR. If 8003PKDR finds that IPX has already been loaded, it calls routines in IPX.COM, rather than manipulating the ethernet card directly itself. As I said, it is only failing when IPX has been loaded. Actually, it can send packets just fine, the problem is that no received packets get passed to the application (in my case NOS) via the packet interface. Again, thank you for replying. 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 ------------------------------ End of TCP-Group Digest ******************************