🚀 go-pugleaf

From: nn2z@nn2z.uucp
Date: Fri, 12 Jul 91 6:37:23 EDT
Subject: trace via bpq packet driver


I have been experimenting with the bpq packet driver and NOS 910614,
and noticed that transmitted data traces are not decoded by NOS
at the ip and ax25 level when send to the bpq packet driver.
Received data is decoded. Has anyone looked at this problem before ?


73 Dave


----
From: pabc@n5jxs.jsc.nasa.gov
Date: Fri, 12 Jul 91 15:31:17 cst
Subject: Re: WD8003EP on Zenith 159

Thanks Sam. The driver does say that it is using 53248 however.
Your explanation is why I tried this combination AND IT  DOES
WORK.  I  am just concerned that given other program conditions, it
will not work. ARE YOU VERY SURE of your answer?

Thanks again for your  reply, it has been the only one and I have
not had any personal msgs either.
 
*73* -  Paul


----
From: crompton@NADC.NADC.NAVY.MIL (D. Crompton)
Date: Fri, 12 Jul 91 20:22:42 EDT
Subject: Closing TMP files


I have been looking over the modules that use tmpname/tmpfile in
NOS. It is sure obvious that they were written by different authors.
FTPCLI does a specific fclose AND unlink of the file, as does the
DIRUTIL. POP and MAILBOX do not use unlink for the temporary file.

I think some standard should be adhered to for temporary files in NOS.
It seems that BC 2.0 does not specifically delete the file at FCLOSE.
This is mentioned in a warning in the manual under tmpname, I believe.

Either we have to unlink the file or not - if so then there are some 
modules that need changing. It is easy enough to search through and
add an unlink after fclose of the temp files. It would be in probably
no more than 20 places. I am not sure if this is the right thing to
do. Maybe I will try it.

Waiting for some input on this.

Doug


----
From: crompton@NADC.NADC.NAVY.MIL (D. Crompton)
Date: Sat, 13 Jul 91 01:40:48 EDT
Subject: TMP files in NOS


Here are the two methods used in NOS to open temprary files.

Method 1 - Call tmpfile - a nos function which calls tmpnam and mkanme
                          and fopens the temporary file returning the 
                          file pointer.

static int
initnotes(m)
struct mbx *m;
{
	FILE    *tmpfile();
	FILE    *ifile;
	register struct let *cmsg;
	char buf[256];
	int     i, ret;

	sprintf(buf,"%s/%s.txt",Mailspool,m->area);
	if ((ifile = fopen(buf,READ_TEXT)) == NULLFILE)
		return 0;
	fseek(ifile,0L,2);       /* go to end of file */
	m->mboxsize = ftell(ifile);
	rewind(ifile);
	if(!stricmp(m->area,m->name)) /* our private mail area */
		m->mysize = m->mboxsize;
	if ((m->mfile = tmpfile()) == NULLFILE) {  /* Only have Pointer!  */ 
		(void) fclose(ifile);                     
		return -1;                          
	}                                           
	fclose(m-<mfile);              /* Does NOT Delete it! */
				       /* No way to unlink it */
				       /* Do not have name!   */


Method 2 - Call tmpnam - a nos function which returns a full drive/path
                         and temporary file name.

/* List directory to console */
int
dodir(argc,argv,p)
int argc;
char *argv[];
void *p;
{
     char *path;
     FILE *fp;
     char tmpname[80];
     char **margv;
       if(argc >= 2)
	       path = argv[1];
       else
	       path = "*.*";

       margv = (char **)callocw(2,sizeof(char *));
       
       tmpnam(tmpname);                /* RETURN Temp name - NOS FUNCTION */
       fp = fopen(tmpname,WRITE_TEXT); /* Open it here */
       getdir(path,1,fp);
       fclose(fp);                     /* Close it here - Does NOT delete it! */
       margv[1] = strdup(tmpname);
       domore(2,margv,p);
       free(margv[1]);
       free(margv);
       unlink(tmpname);                /* Delete it by full path name */
       return 0;
}

With Method 1 (the most used in NOS) there is alittle less overhead in
your module but you can never close the file. The name is not known to
the function to use unlink and it does not close on fclose because the
tmpfile function is internal to nos - an fopen is used in tmpfile function.
If the Borland tmpfile were used it would close the file at fclose (note
this may fail also if directories were changed) The main reason to not use
the borland tmpfile function is that you do not have any control over the
name or more importantly where it goes.

In method 2 - used in a few places in NOS (think it is Phil's code)
the tmpname (NOS function) is called to get a fully qualified name
based on TMP enviroment variable. The file is then opened within
your function. Now both the file pointer AND the file name are known.
Thus you can unlink the file  when you are done.

If Borland were to change the TMPFILE function - so it would obey an
enviroment variable - then using the borland tmpfile would solve the
problem. Not counting on that happenning soon it seems that method 2
would work well. Indeed it does now. This is why I was fooled by the
test I did with the NOS dir command. This is not true of POPSERV,
BMUTIL, MAILBOX and SMTPSERV. The main modules where this problem
exists.

What is not clear to me is why this is showing up now - it appears 
that this problem existed all along, but I did not see the problem
until I compiled with BC 2.0. I also only recently started looking
at the code more closely. 

Doug


----
From: uunet!samsung!swlvx2.msd.ray.com!anomaly.sbs.com!idsvax!mikebw mikebw@idsvax.ids.com <uunet!samsung!swlvx2.msd.ray.com
Date: Fri, 12 Jul 91 03:46:35 EST
Subject: Re: Stabilizing NOS!

Jay, K5ZC, asks about making a DesqView specific version of NOS.  I have
thought about this same idea, and it is a good one -- that would require
an enormous amount of work.  I have a friend, Walt, KZ1F, who has been
working on a port of NOS to OS/2 for about a year.  Better him than me.

A simpler alternative might be to make use of the overlay capability in
Borland C.  NOS, as presently written, cannot use overlays because of the
way that the multitasking kernel uses the stack.  Further, there are large
sections of code that absolutely cannot be overlaid, such as interrupt
service routines.  Still, I think a lot could be found that could be
safely overlaid if the kernel were made overlay-compatible.

This would, all together, be much less involved than porting to the
DesqView API or to some other DOS extender.  Minor sectioning of some
modules might be all that is necessary.  For example, do we really need
all of the server code in memory for each server function, whether active
or inactive?  Most of what the telnet, smtp, or ftp server does is sit
around waiting for an incoming connection.  If we maintained just a stub
listener resident, and called the main server code into memory when that
listener received a connection request, what would the problem be?

And what about such things as hopcheck?  It never does anything until
the user invokes it.  Many users will never invoke it.  Does it have to
sit in memory and take up space?  It is a nice feature, and I like to
have it, but it could be implemented with great efficiency as an overlay.

I hope I start something...

-- Mike Bilow, N1BEE @ KA1RCI.RI.USA.NA  (AX.25)
               mikebw@idsvax.ids.com  (Internet)


----
From: uunet!samsung!swlvx2.msd.ray.com!anomaly.sbs.com!idsvax!mikebw mikebw@idsvax.ids.com <uunet!samsung!swlvx2.msd.ray.com
Date: Fri, 12 Jul 91 04:41:35 EST
Subject: RE: Stabilizing NOS!

John, AG9V, proposes that NOS be stabilized at some level for user
distribution, with revisions not more than twice a year.  These versions,
he points out, need to be stable and have all the bugs worked out.

That's a nice idea, but how?  The vast majority of code revisions ARE
bug fixes.  PA0GRI messed up the "param" command in 910531; this was
fixed in 910604.  The ttylink server, when accessed from the mailbox,
is non-functional in 910605; this was fixed in 910618.  And those are
just the examples that come to mind immediately.

Everyone is free to pick a NOS version and run it forever if they want.
I ran KA9Q NOS 900117 until November 1990, because I just could not get
a NOS version to run the way I thought it should.  Then I ran G1EMM
until June 1991, which had a lot of important improvements, especially
the "tcp timertype linear" command.  But I could never get G1EMM NOS
to properly compile under the newer compilers, and I often had seriously
erratic behavior if not outright crashes, so much so that I thought about
going back to KA9Q 900117.

I consider the current release of PA0GRI to be really well done, but not
bug free.  If we wait until NOS is "bug free" before distributing it, we
would still be sending TCP/IP packets with a straight key.  The average
user does not need a C compiler.  I make my executables available, and
anyone who wants to try one is welcome to it.  Several New England stations
have been using my compiled versions of PA0GRI NOS, including our NET/ROM
gateway and the unattended Rhode Island switch.  After the initial flurry
of activity surrounding the 910531 release of PA0GRI NOS, things have
settled down considerably.

It is also a misconception, in my opinion, to say that we know what the
average user wants and needs.  Hardly anyone in New England is running POP,
and a lot of our traffic is SYN frames for hosts not on the air but who
have mail pending.  I would like to make sure that all end users have the
capability to act as POP clients.  That's just an example.

-- Mike Bilow, N1BEE @ KA1RCI.RI.USA.NA  (AX.25)
               mikebw@idsvax.ids.com  (Internet)


----
From: uunet!samsung!swlvx2.msd.ray.com!anomaly.sbs.com!idsvax!mikebw mikebw@idsvax.ids.com <uunet!samsung!swlvx2.msd.ray.com
Date: Fri, 12 Jul 91 04:53:17 EST
Subject: Re: New(er) NOS 0618

Doug comments that he is confused about my corrections to corrections.  He
is certainly justified, and I apologize.  The module I sent out with the
big comment at the beginning dated July 9, 1991 is the correct version.
The wrong version is dated the prior day.

I should also note that is possible but not efficient to make no change to
the code, yet fix the TMP file problem by modifying onlt the MAKEFILE, at
least in the earlier version of PA0GRI 910618.  This would be done by
making a special compilation rule to force all of the PC.C module into
the _TEXT segment.  This may not work for the new version of 910618.

For the benefit of Doug and all others, here is the final version of
the fix.  I have had this in use for several days, and it works.

-- Mike

***** start module MKNAME.C *****

/* New module MKNAME.C
   for PA0GRI NOS 910618v1.7a (910625)

   This module MUST be compiled in such a way that it is forced into
   the _TEXT segment.  This can be accomplished by using the "-zC_TEXT"
   compiler switch with the Borland C++ 2.0 compiler.  I have put this
   switch in a special compilation rule in MAKEFILE for reasons explained
   below.  It is possible to make all of PC.C go into the _TEXT segment,
   but that might put too much in there and cause trouble for the compiler.
   The best way is to put in only what we need, and that is why this must
   be a new and separate module.

   To compile this module right, there must be a special compilation rule
   included in MAKEFILE:

!if (($(CC) == bcc) || ($(CC) == bccx) || ($(CC) == BCC) || ($(CC) == BCCX)) 
mkname.obj: mkname.c
	$(CC) -c $(MODEL) $(CFLAGS) -zC_TEXT $*.c
!endif

   The MAKEFILE must be modified to add MKNAME.OBJ to the list of PCOBJS.
   The file PC.TL must be modified to include MKNAME.OBJ in the list of
   files that are bound into PC.LIB by the librarian.

   The tmpnam() and __MKNAME() functions in the run-time library are in
   the same object module, so both have to replaced together.  Those below
   must be used instead of the ones in PC.C; therefore, both tmpnam() and
   __MKNAME() in PC.C should be removed, as should the declaration of the
   variable _tmpnum.  Since these functions are never called from within
   NOS, this module will be preprocessed to have no compilable code in it
   if the compiler is not the right one.

   The pascal calling convention specifies that symbols are converted to
   upper case and an underscore character is not automatically prepended.
   It is intended that the __MKNAME() DIRECTLY replace the function of the
   same name in the run-time library.  This __MKNAME() function is called
   from run-time library modules tmpnam(), which is being replaced, and
   from fclose(), which is not.  The whole point of this awful kludge is
   to avoid rewriting fclose(), which would be a lot worse than this.

   -- Mike Bilow, 9 July 1991
      N1BEE @ KA1RCI.RI.USA.NA  (AX.25)
      mikebw@idsvax.ids.com  (Internet)

*/

#ifdef __BORLANDC__
			/* This may also work using __TURBOC__, which is
			   always defined anyway if __BORLANDC__ is defined,
			   but I will leave it to someone else who actually
			   has the compiler to verify this.  -- N1BEE
			*/

#include <stdio.h>		/* for sprintf() */
#include <string.h>		/* for strlen() */

				/* These are the ANSI prototpyes, folks */
char far * near pascal __MKNAME(char far *, unsigned int);
char *tmpnam(char *);
char *getnenv(char *);

unsigned int _tmpnum = 0;


char far * near pascal __MKNAME(char far * tmpname,unsigned int tmpnum)
				/* Converted to modern C style  -- N1BEE */
{

	char *tmpdir,*p;
	static char staticname[80];

	if (tmpname == NULL)
		tmpname = staticname;

	p = tmpdir = getnenv("TMP");		/* get tempdir name */

	if (p[0] != '\0')
		p += strlen(p) - 1;		/* point to last character */

	sprintf(tmpname,"%s%sTMP%u.$$$",tmpdir,
			((*p != '/' && *p != '\\')? "/":""),tmpnum);

					/* Note that the default is to use root
					   if TMP= is not specified */

	return tmpname;
}

char *tmpnam (char *name)		/* Converted to modern C style */

{
	do
	{
		if (_tmpnum == 0xffff)
	 _tmpnum = 2;
		else
	 ++_tmpnum;

		name = __MKNAME(name,_tmpnum);
	}
	while (access(name,0) != -1);

	return name;
}

#endif

***** end module MKNAME.C *****


----
From: "John R. Ackermann" <jra@lawday.daytonoh.ncr.com>
Date: Sat, 13 Jul 91 9:41:35 EDT
Subject: RE: Stabilizing NOS?

> 
> In New England, there are my compiled executables of PA0GRI NOS.  They work.
> They're not bug free, but they work.  I run them myself.  That's what they're
> for.  Users can choose to do what they want.  -- Mike
> 
Hi Mike -- 

I hope this gets through to you; my system doesn't like to reply to your
address for some reason.

I think we may be talking at cross-purposes.  It's a good thing that you
have a NOS executable available in New England.  My point it that we
need to have one <world-wide> that's a baseline.  It's only if there's a
standard user-oriented version that we're going to get real docs written
(and I've already volunteered to work on that) and some tcp activity
beyond the hard core.

John


----
From: "John R. Ackermann" <jra@lawday.daytonoh.ncr.com>
Date: Sat, 13 Jul 91 9:55:21 EDT
Subject: RE: Stabilizing NOS!

Mike writes:

[ stuff deleted ]

> I consider the current release of PA0GRI to be really well done, but not
> bug free.  If we wait until NOS is "bug free" before distributing it, we
> would still be sending TCP/IP packets with a straight key.  The average
> user does not need a C compiler.  I make my executables available, and
> anyone who wants to try one is welcome to it.  Several New England stations
> have been using my compiled versions of PA0GRI NOS, including our NET/ROM
> gateway and the unattended Rhode Island switch.  After the initial flurry
> of activity surrounding the 910531 release of PA0GRI NOS, things have
> settled down considerably.

If your version runs reliably with the standard functions, maybe it
should be the base.  That would be fine with me.  My only point is to
get <something> out there as a distribution version that doesn't change
weekly.

> It is also a misconception, in my opinion, to say that we know what the
> average user wants and needs.  Hardly anyone in New England is running POP,
> and a lot of our traffic is SYN frames for hosts not on the air but who
> have mail pending.  I would like to make sure that all end users have the
> capability to act as POP clients.  That's just an example.
> 

I think you've just made my point.  I'll bet that people aren't running
POP for one of two reasons:  First, they may be running a version of NOS
or NET that doesn't support it.  And the main reason for that is probably
that they don't know about the new work, or (in my view more likely) that
they view NOS as being experimental and don't want anything to do with it
until it stabilizes.

Second, they may have a newer version and have no bloody idea how to use
the new features because of the rudimentary documentation.

In either case, a version of NOS that's sanctioned as "the current
release" and well documented would go a long way toward solving the
problem.

John   AG9V


----
From: Bdale Garbee <bdale@col.hp.com>
Date: Sat, 13 Jul 91 08:54:21 MDT
Subject: Re: Stabilizing NOS!

> That's a nice idea, but how?  The vast majority of code revisions ARE
> bug fixes. 

Dunno if you were on the list in the pre-NOS days, but... 

This is *exactly* what I used to do with the pre-NOS code.  K3MC and N3CVL
get the credit for talking me into doing this in the early days, and K3MC gets
the blame for keeping me doing it until NOS shipped...  :-)  The 890421.1
release was the last of my efforts, and despite some defects stood the test
of time quite nicely while NOS remained in its infancy.

The task consisted of:

	- poll the community to get the best base hunk of code to work from,
	  and the best set of potential feature additions from other efforts.

	- collect all existing documentation and integrate the pieces, filling
	  in the gaps as well as is possible.

	- build executables for every machine I own (lots...), and beat on the
	  code *hard*, exercising everything I could think of (call it software
	  QA?) looking for defects.  When a defect is located, fix it and 
	  iterate on this step.

	- find a friend or two with different usage patterns and talk them into
	  trying the new cut.  If problems are found, iterate back to the
	  previous step.

	- package the release with as much user-friendly installation help as
	  possible (which in those days meant boiler-plate config files and a
	  README which told you how to edit and what to edit), full docs, full
	  source as an option, and a reasonable set of executables.

	- distribute the package through "all the usual channels".  I ran a 
	  telephone BBS ("The Hip Shack" that I still get about 3 calls a day
	  on the now-defunct phone line that's on winfree!) that got an
	  amazing amount of use including internationally, I laboriously FTP'ed
	  the code to a number of sites, and equally laboriously UUCP'ed the
	  code to a number of sites.  I never did do floppy distributions, but
	  when TAPR got into doing them, they also got a copy each time.

	- "blitz the media", posting announcements on this mailing list and the
	  rec.ham-radio.packet news group, now known as 
	  rec.radio.amateur.packet.  The announcements included feature lists
	  for the new rev, where to get it, who contributed changes, etc... for
	  a while, they were about once a month, then about twice a year, then
	  a year went by before 890421.1, then no more.

There are some problems with doing this to NOS:

	- there are more base variants now than there were.  Ask PE1CHL about
	  the frustrations involved in having really neat features in a 
	  different base that "the integrator" hasn't got time or energy to
	  re-implement in the chosen base and therefore get left out...  It's
	  one of the reasons I quit...

	- The functionality is much greater, making the Q/A process much more
	  arduous.  When it was Telnet/SMTP/FTP/Finger and a rudimentary
	  receive-only mailbox, doing a nearly complete regression test suite
	  by hand was quite feasible... not sure it is today.

	- I don't know anyone on the list personally who is a) unmarried, has
	  b) lots of time to kill, and c) has enough software and documentation
	  skill to pull this off single-handedly.  I can't now, which is the 
	  other reason I quit.  Nowdays, I meat at most one of these criteria!

	- Successful group projects in amateur radio are few and far between.

I've bothered to type all this out to show those new to the list that this is
indeed a good idea, and has been successfully done in the past, but that it is
not going to be as easy to do today.

> If we wait until NOS is "bug free" before distributing it, we
> would still be sending TCP/IP packets with a straight key. 

Agreed, but you'd be surprised how much mileage you can get with good docs and
a clean installation mechanism.  There've been efforts along these lines
recently, personally, I'd probably focus on making the docs and the install
process better, and worry less about making a consistent version, at least 
until those objectives are met... then revisit a standardized version.

> It is also a misconception, in my opinion, to say that we know what the
> average user wants and needs.

Yes, this is a problem, but only because of the way NOS is built.  Russ Nelson
and others have argued long and hard over time about the value of dynamically
loadable device drivers, and potentially dynamically loaded functionality
modules.  But, as Phil points out, if you want a *real* networking system, just
run Unix with a packet gateway and you're set.  Where's the line?  Dunno.  If
a good overlay scheme comes together (Don has been working hard on this for
Gracilis NOS, I know), then you can indeed ship everyone everything, have it
fit in memory, and not care what slice folks actually use...

Back to working on my soon-to-be tower...

Bdale


----