From wang!elf.wang.com!ucsd.edu!tcp-digest-relay Fri Feb 1 15:29:33 1991 remote from tosspot Received: by tosspot (1.63/waf) via UUCP; Sat, 02 Feb 91 12:01:02 EST for lee Received: from somewhere by elf.wang.com id aa08187; Fri, 1 Feb 91 15:29:32 GMT Received: from ucsd.edu by uunet.uu.net (5.61/1.14) with SMTP id AA11577; Fri, 1 Feb 91 09:56:06 -0500 Received: by ucsd.edu; id AA05108 sendmail 5.64/UCSD-2.1-sun Fri, 1 Feb 91 04:30:37 -0800 for jbloom Received: by ucsd.edu; id AA05097 sendmail 5.64/UCSD-2.1-sun Fri, 1 Feb 91 04:30:31 -0800 for /usr/lib/sendmail -oc -odb -oQ/var/spool/lqueue -oi -ftcp-digest-relay tcp-digest-list Message-Id: <9102011230.AA05097@ucsd.edu> Date: Fri, 1 Feb 91 04:30:27 PST From: Advanced Amateur Radio Networking Group Reply-To: TCP-Group@ucsd.edu Subject: TCP-Group Digest V91 #30 To: tcp-group-digest@ucsd.edu TCP-Group Digest Fri, 1 Feb 91 Volume 91 : Issue 30 Today's Topics: Anybody speak Italian/English? Ax autoroutes DOS 5.0 (2 msgs) FCC Citation Help needed on NOS 113014 How to reach G8BPQ.. multiple routes (2 msgs) net rom timers in new NOS!? updated nos on thumper uptime Wierdo department II XENIX NOS 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, 31 Jan 91 22:45 GMT From: Gareth Howell Subject: Anybody speak Italian/English? To: tcp-group@ucsd.edu Hi all, I received this message over the bbs network. Anybody any idea what this guy might be on about? 73 Gareth --- cut here --- >From g6edd@g6edd.ampr.org Wed Jan 30 00:29:19 1991 >Received: from g6edd by g6kvk with SMTP id AA6145 ; Tue, 29 Jan 91 23:02:07 UTC >From ik1hgi%gb7khw.bbs@g6edd Mon Jan 28 15:36:38 1991 >Received: from g6edd by g6edd with SMTP id AA1321 ; Mon, 28 Jan 91 15:36:36 UTC >Received: from gb7khw.bbs by g6edd (901130 (G1EMM v1.4)) id AA1318 ; Mon, 28 Jan 91 15:35:01 UTC >Date: Mon, 28 Jan 91 15:35:01 UTC >Message-Id: <1319@g6edd> >From: ik1hgi%gb7khw.bbs@g6edd >To: tcpip@tcpip >Subject: numerazion tcpip hosts >X-BBS-Msg-Type: B R:910128/1453z @:GB7KHW._2111.GBR.EU Dunton, Biggleswade. #:16502 Z:IO92VC R:910128/1432z 51450@GB7ZPU.GBR.EU Sutton, Beds R:910128/1357z 59484@:GB7HHH._331.GBR.EU [Hemel Hempstead, Herts - IO91RR] R:910128/1354z 29652@GB7HSN._3212.GBR.EU [Mottingham,London] NNA V1.09 R:910128/1347z 4583@:GB7SEK._341.GBR.EU [Ashford, Kent] R:910128/1336z 4030@GB7ZAA._3411.GBR.EU [Canterbury, Kent. ] NNA V1.09 R:910128/0123Z @ON4HU.BFHT.BEL.EU #58213 [Mouscron-FBB6.11a+BPQ4.01] SB>TCP/IP, Heerlen 44.137.4.10 JO30AV Op:PE1AYX] R:910112/1933z @DB0IZ [Solingen, JO31NE, Op: DG2EAT] R:910112/1926z @DK0MWX [Langenfeld JO31LC, DL-VHF>TCP/IP Mittelrhein, JO30QJ, Op:DL5DI] R:910112/1531z @DB0GV [RMPRG Maintal-Frankfurt JO40KD OP: DF5FF (438.025 MHz)] R:910112/1512z @DB0SAO [Boeblingen JN48MQ DK5SG-BBS 2.19 OP:DL1SBL] R:910112/1414z @DB0CZ [Deisslingen JN48HD TheBox 1.6b OP:DK5TB] R:910112/0117Z @DB0KCP [Langerringen FI64c Sysop DL4MEA & DL9MCK] R:910110/0550z @DB0PV [DB0PV-1, Muenchen, JN58SC] R:910110/0458z @OE3XBS [* Austria BBS OE3 * JN77XT * DieBox 1.6d *] R:910110/0504 @:OE1XIB.AUT.EU Wien Austria #:11113 Z:A1010 R:910110/0448l @OE6XYG [Austria-Net BBS, JN77RA, TheBox 1.6b OP: OE6UBG] R:910110/0042Z @HA1VH.HUN.EU #20128 [Koszeg - FBB5.11a+BPQ HF> R:910103/0120l @IV3PFF R:910102/1725z @:I3YPJ.VE.ITA.EU R:910102/1157z @:IW3EXH.ITA.EU Vicenza, ITA #:18735 O:IK1HGI R:901231/2145z @:I4FP.#FE.ITA.EU ( Ferrara - JN54TU ) #:3791 Z:44100 R:901231/0700z @:IK4IRO._41_1.ITA.EU #:21801 R:901231/0213z @:IK4MGV._43_1.ITA.EU PARMA SEZ.ARI #:1662 R:901231/0316 @:IW4BLO._43_2.ITA.EU Salsomaggiore Terme, PR #:12363 Z:43039 R:901231/0048z @:IW2DNI.#CREMA.CR.ITA.EU #:31707 R:901230/2253 @:I2AYL.MI.ITA.EU #:36329 Z:20129 R:901230/2121z @IK2ANP.#MI.ITA.EU Milano #:9246 O:IK1HGI $:9246_IK2ANP Nembering worldwide I sistam the hosts.net for change all the number of the chanel tcp/ip i or jain all the nubers tcp/ip i hope that someone can bring it ahead all the work of the mondial numbers untill someone can arrive at the collezion that will never finsh with our passion i hope that we can arrive with a lot of numbers i insert a publisher for evetual modification for the insert of the numbers the program HTOD.EXE permt us to modification of the HOSTS.NET and DOMAIN.TXT for eventual modifications i hope tha i was pleasure. ANTONIO IK1HGI NOVARA TCPIP 44.134.128.86 ------------------------------ Date: Thu, 31 Jan 91 17:45:18 GMT From: tcpgroup@kelvin.uk22.bull.com Subject: Ax autoroutes To: brian@ucsd.Edu Brian et al, I agree totally with the dynamic handling of netrom routings. This functionality has been in the G1EMM version of the netrom code for about a year now. Basically, what happens is this:- If a neighbour is tried via ax25 and fails to establish a link, it and all its dependencies have thier quality value reduced to 2/3 of the original. This rapidly knocks totally non-viable paths out of the NR tables. If however, the link was not made due to short lived noise etc the path is still available for later use, albeit at a lower quality. Admittedly, I only attempt the ax25 connect at the time that we want to carry 'real' traffic. Anyone interested in the details, look at nr_derate() in the netrom source code in kh113016.zip on thumper. I would suggest that the same sort of 'quality' idea is used for ax25 routing for the same reasons. This could then allow multiple dynamic routes in a way that is not possible at the moment. How you determine the route qualities is another matter all together! :-) ------------------------------ Date: Thu, 31 Jan 91 10:48:07 GMT From: kelvin@kelvin.uk22.bull.com Subject: DOS 5.0 To: crompton@NADC.NADC.NAVY.MIL Doug, are you running the 'stat' command on startup within NOS. If so, thats whats causing the message. DOS5.0 is a non-starter for the 'stat' commands file info. This is because the code hacks around the undocumented bits of ms-dos to acquire the info it displays. I didn't write the code, I just ported it over from another program. :-) -- 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: Thu, 31 Jan 91 10:45:19 EST From: crompton@NADC.NADC.NAVY.MIL (D. Crompton) Subject: DOS 5.0 To: tcp-group@ucsd.edu Yes - the stat command is displaying the message and NOS itself seems to run fine under it. I will ignore the message as the rest of the status appears to be correct. Doug ------------------------------ Date: Thu, 31 Jan 91 10:42:46 EST From: crompton@NADC.NADC.NAVY.MIL (D. Crompton) Subject: FCC Citation To: tcp-group@ucsd.edu I guess it is about time that the @USA messages get canned. In general I believe that if the message content was Ham related the FCC would look the other way when an occasional commercial phone number etc. went thru. Especially in the pursuit of equipment repair etc, but this message is obviously a flagrant violation. I understand the bind this puts the bbs operator in but ALL of these messages originate at a single station. Why not go on notice that if ANY station originates a message that causes this kind of problem, that THEY will be censured. BUDLIST'ed out at the BBS(s). If the BBS operator takes a strong stance then this alone would show the FCC that an effort is taking place to eliminate the problem. A BBS operator could even file a report (voluntarily) when a violation occurs along with the corrective action taken. Some sort of AI could be instituted (like fixmail censor) to look for offending words and phone numbers, but it seems like alot to go through when we are a closed group and do our own policing. I wonder how the no code change is going to effect this?? Listening to some of the crap on 75 meter phone would sometimes lead you to believe that the airwaves are totally free, but the FCC has strong rules and guidelines that even the broadcasters must follow. I just heard on the news that somewhere a radio show announced a nuclear attack (as a joke) and the station was fined. Things are much more touchy in times of war. I am certain that this violation was reported to the FCC by a Ham who had different political views. At any other time it may have gone unnoticed. The same thing could have been discussed in a 75 meter QSO and nothing would have happenned. The audience is obviously different. Doug ------------------------------ Date: Thu, 31 Jan 91 12:54:00 PST From: kdavis%w6rfn.ampr.org@kg6kf.AMPR.ORG Subject: Help needed on NOS 113014 To: tcp-group%ucsd.edu@kg6kf.toad.com I am converting to 113014 from 901119 because of creeping memory problems but I have two problems: all mail gets addressed to ampr.org This doesn't occur in the other nos. the x.25 mailbox Chat mode doesn't work. Won't open a socket even if attended is on. Thanks.... Ken -- Ken Davis - W6RFN San Francisco, CA UUCP: {apple,pacbell,hplabs,ucbvax}!well!rainbow!kdavis Internet: kdavis@well.sf.ca.us or kdavis%w6rfn@kg6kf.ampr.org AMNET: ken@w6rfn.ampr.org AMBBS: W6RFN @ K3MC.CA ------------------------------ Date: Thu, 31 Jan 91 17:12:40 EST From: rutgers!wb3ffv.ampr.org!howardl Subject: How to reach G8BPQ.. To: tcp-group Hello All, I am not sure if this is the right place to ask, but I figured it was probably a good start. I am using the G8BPQ PC-Node software with NET/NOS code and some new BBS software at WB3FFV. What I have run into is that G8BPQ has released some new PC-Node software (4.xx) that is supposed to use some TSR programs to provide KISS, PK232, & TNC2 emulation. As of now I have found the latest BPQ code, but in the archives I don't see any of the TSR's that are mentioned. If anyboy knows how I might reach G8BPQ via PACKET/Internet or UUCP it would be most appreicated. Also if anybody has a copy of his latest code that also contains the various emulation modules, and would be willing to let me have a copy it would be most appreicated. I can call in and download the code, or of possible I have FTP and UUCP capabilities. Well that is all I have, and I hope somebody can help me with this one... ------------------------------------------------------------------------------- Internet : howardl@wb3ffv.ampr.org | Howard D. Leadmon UUCP : wb3ffv!howardl | Advanced Business Solutions TELEX : 152252474 | 210 E. Lombard St - Suite 410 FAX : (301)-244-8790 | Baltimore, MD 21202 PACKET : WB3FFV @ WB3FFV.MD.USA.NA | Phone: (301)-576-8635 ------------------------------ Date: Thu, 31 Jan 91 21:24 GMT From: Subject: multiple routes To: tcp-group@ucsd.edu This issue of multiple ax.25 paths is, I hate to remind people, [no, no, tell the truth -- I don't hate it at all] is one part of the problem that I tried to raise, and address, several months ago, which was, shouldn't we be able to handle multiple physical paths to a single IP address and choose the best one at any given time (or, really, for a time interval delta-t). One obvious aspect of that problem is the possibility of having multiple AX.25 routes, which, as I understand it, is precisely the issue that has now been raised by others. I was attempting to address a slightly wider issue, namely the IP routes which, typically, may have both AX.25 and NETROM routes built into them. A pure AX.25->AX.25 connection where the remote host was not an IP host was not addressed, I won't bore you with my proposed solution, which was posted here. I looked at the code myself with a stupid notion that I might be able to build a mechanism for keeping a linked list of routes for each IP host. But I quickly discovered that I couldn't live without all my wonderful C++-isms and it was beyond my primitive C ability, (which I have no wish to improve!) to hack NOS to see if my proposed algorithm would really work. I would be very glad to see someone implement any reasonable automatic solution to the problem of multiple paths, because I think that its something that those of us out here in the boonies can use. [BTW, is there anyone else out there who regards his VHF IP coverage to extend over 100,000 square miles? -- paths are LONG out here] Doc ------------------------------ Date: Thu, 31 Jan 91 16:42:42 MST From: Bdale Garbee Subject: multiple routes To: tcp-group@ucsd.edu > This issue of multiple ax.25 paths is, I hate to remind people, > [no, no, tell the truth -- I don't hate it at all] is one > part of the problem that I tried to raise, and address, several > months ago, which was, shouldn't we be able to handle multiple > physical paths to a single IP address and choose the best one > at any given time (or, really, for a time interval delta-t). Doc, I think many of us agreed with this part of your assertion, but not to the extent that anyone was willing to write the code to do anything about it. What I, at least, found unpleasant in your original proposal was the mechanisms discussed to discover the routes. Brian's suggestion of just caching the last couple of learned routes would have substantially less impact on network performance than the flooding algorithms you were proposing, and so might be worth investigating. Personally, I think that just allowing the program to replace an existing AX.25 route with a new one when heard would solve in excess of 90% of the perceived problem. And this should not be hard code to write. But I'm not going to write it, at least not today. :-) Bdale ------------------------------ Date: Thu, 31 Jan 91 16:24:10 EST From: Subject: net rom timers in new NOS!? To: "TCP/IP User Group" The latest version of nos causes nos to ID alot! The timer must be in interger because I can not set a value more than 32k. Since that equates to 32 seconds max, NET ROM is IDing alot! The new timer routines are probally causing this. Any fixes? = =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Mark Bramwell, VE3PZR Located in sunny London, Ontario Internet: mark@hamster.business.uwo.ca IP Address: 129.100.22.100 Packet: VE3PZR @ VE3GYQ UWO Phone: (519) 661-3714 ------------------------------ Date: Thu, 31 Jan 91 23:51:36 EST From: karn@thumper.bellcore.com (Phil R. Karn) Subject: updated nos on thumper To: tcp-group@ucsd.edu I've put a new version of NOS on thumper under /pub/ka9q/nos. This version fixes the problem with the time of day clock sometimes not increasing monotonically. It turns out that the command to sample the 8254 timer chip's count and output state isn't reliable; if you happen to hit the chip just after the count hits zero, you might catch it before the output has toggled. I fixed this by simply checking for a zero count and re-reading the count and output state when this happens. I also incorporated full assembler implementations of the long division and multiplication routines used for converting ticks into milliseconds; they are quite a bit faster than the C routines I had written initially. There's a "test" command in this version that calls the msclock() function 40,000 times and makes sure that the output always increases. I'd appreciate it if people would try this out on their machines and let me know of any failures. If the code functions properly, you should see no output, just a pause of a few seconds. Be sure you have said "isat on" before running this test. This version also includes an optimization in the interrupt buffer pool code. If an interrupt handler frees a buffer that seems to have come from the interrupt pool and the interrupt pool isn't full, it goes right back on the pool. Phil ------------------------------ Date: Fri, 1 Feb 91 00:08:12 EST From: karn@thumper.bellcore.com (Phil R. Karn) Subject: uptime To: tcp-group@ucsd.edu Oh yes, the new version also shows the system uptime on the first line of a "ps" display. Phil ------------------------------ Date: Fri, 1 Feb 91 10:32:58 MET From: Arne Luehrs Subject: Wierdo department II To: tcp-group@ucsd.edu Kelvin, Anders Looking at the last discussions I have the feeling that I will expose myself to flames here but.... We have this wonderfull mailbox code in Nos... People here like it (once translated in french (anyone care for a copy??)) and have started to use it actively. One of its features is the Send Reply command that will kindly send a copy of the message sent to it's originator. Yet when a reply is replied to you get into the funny situation that the receiver will get the message twice... once from the TO: line and once from the CC: line. Did I overlook something here??? Wierdo 2: Any user can post a message in an area. In the case of third-party-mail ON he can send to others too. He can erase his own messages but he can NOT erase messages HE has posted in an area . Looking at the bmutil.c code (called to kill messages) suggests that a user would need FTP overwrite rights to be able to do this (My C is about as fluent as my martian...NOT..) Without wanting to suggest to recreate Msys here or things of that kind, should this not be changed?? Any suggestions Anders??? 73's F/pa0kkv Arne -- %*%*%*%*%*%*%*%*%*%*%*%*%*%*%*%*%*%*%*%*%*%*%*%*%*%*%*%*%*%*%*%*%*%*%*%*%*%*%*%* Arne Luehrs | mail arne@hppcgelo.grenoble.hp.com Grenoble Personal Computer Group | uucp ...!hplabs!hppcgelo!arne Hewlett Packard, FRANCE | desk arne_luehrs@hp6300.desk.hp.com | ampr arne@pa0kkv [44.151.38.1] %*%*%*%*%*%*%*%*%*%*%*%*%*%*%*%*%*%*%*%*%*%*%*%*%*%*%*%*%*%*%*%*%*%*%*%*%*%*%*%* #include disclaimer.std ...-.- ------------------------------ Date: Thu, 31 Jan 91 10:52:08 EST From: crompton@NADC.NADC.NAVY.MIL (D. Crompton) Subject: XENIX NOS To: tcp-group@ucsd.edu Joe W2NV is still not able to get his NOS working properly. Even after raising the number of processes to a very large value and recompiling the kernel he gets 'no more processes' messages and the process hangs. Any further help would be appreciated. Is anyone running this under Xenix successfully? Reply to group. Doug ------------------------------ End of TCP-Group Digest ******************************