🚀 go-pugleaf

From: SPITZNAGEL@uthscsa.edu
Date:  Wed, 10 Jul 1991 9:43:43 CDT
Subject: Stabilizing NOS!

I would also like to second the motion made by John Ackerman!

1) Many local (44.76.2.x) users have expressed interest in NOS but 
have major reservations because of the continuous moving target
syndrome AND lack of DOCS.

2) Mike (n1bee) has already produced several attenuated/short versions
of gerhard's code. Could we prevail upon him to create a small to medium
size version that supports most of the drivers but limits to:
	FTP
	TELNET
	SMTP
	TTYLINK
	POP
	RIP/RSPF
and any other functions that are essential to clean one station operation
with the mailbox?

3) Would love to entertain some informal RFC process to establish spec's
for 2).

4) Will be willing to help assemble DOCS in plain-text for basic/entry level
users for the final product.

Question: Is any one attempting a GUI (windows/os2/xwindow) version of
any of the functions in NOS?  Would be nice to have a NOS .dll and mail
ftp smtp etc.... windows that could use it....   (tuesday pipe-dream...)

reply to: spitznagel@thorin.uthscsa.edu
	  kd4iz@n5hyh.ampr.org
	  CIS 76044,476
tnx  jack......>>
 


----
From: Derrick C. Cole <cole@concert.net>
Date: Wed, 10 Jul 91 09:53:56 -0400
Subject: like to subscribe

SUBSCRIBE


----
From: "Michael Graff" <explorer@iastate.edu>
Date: Wed, 10 Jul 91 13:27:19 CDT
Subject: Archives for this group


Where can I obtain FTP'able digests for this group?

Also, I'm not `into' packet radio; I use ka9q as a ethernet/ppp/slip router.
Is there a `better' group to be in for this purpose, or is this the only
ka9q list?

Thanks,
--Michael

-------------------------------------------------------------------------------
Michael Graff explorer@iastate.edu ga.mlg@isumvs.bitnet gamlg@ccvax.iastate.edu
-------------------------------------------------------------------------------


----
From: Richard Elling <elling@eng.auburn.edu>
Date: Wed, 10 Jul 91 11:51:10 CDT
Subject: problems with Ander's UNIX port

I'm having problems getting the client programs for Ander's NOS-UNIX
port working.  They seem to hang trying to decrement the semaphore
the first time around.  Seems as though the semaphore ops might not
be properly implemented.

Does anyone have this running?  Has anyone seen these problems?

System: SPARCStation, SunOS 4.1.1b.  Code dated January 8, 1991 ftp'ed
from ucsd.edu.

Note: it would be very easy to write XView wrappers around these
clients and have a really nifty user interface... :-)

 Richard Elling                         Manager of Network Support
 Auburn University                      Engineering Administration
 relling@eng.auburn.edu     KB4HB [44.100.0.72]      (205)844-2280
    "I am not an animal!  I am a human bean!"  -- Peanutman


----
From: uunet!samsung!swlvx2.msd.ray.com!anomaly.sbs.com!idsvax!mikebw mikebw@idsvax.ids.com <uunet!samsung!swlvx2.msd.ray.com
Date: Wed, 10 Jul 91 16:36:51 EST
Subject: RE: tmpfile() again ...

Having published the fix for this under Borland C++ 2.0, I am inclined to
point out AGAIN:

1.  The new (2.0) library function fclose() calls library function __MKNAME()
    directly.  It will continue to do so, even if a new function nmkname() or
    whatever is declared.

2.  Because of the above problem, replacing tmpnam() (which also calls
    __MKNAME() from the library) will make the file constructor and the
    file destructor call different functions.  This is no help.  Going
    one more level and replacing tmpfile() is also no help.

3.  Replacing __MKNAME() has to be done within the _TEXT code segment.
    This was no a requirement under TC++ 1.01, because fclose() called
    tmpnam().

4.  The linker is not kidding when it gives you a fixup overflow.  It
    means that you are making a call into never-never land.  You can do
    things which trick the linker into thinking you're not, even if you
    are, but no one in their right mind would do this.

5.  If the new __MKNAME() function is forced into the _TEXT segment with
    the "-zC_TEXT" compiler switch, fclose() can call it and the linker
    will be happy.

-- Mike Bilow, mikebw@idsvax.ids.com


----
From: wkt@csadfa.cs.adfa.oz.au (Warren Toomey)
Date: Wed, 10 Jul 91 10:33:31 EST
Subject: Re: Flat ampr.org

> 	I know that a lot of you are going to disagree but...

Sometimes I wish I hadn't posted certain mail items :-S.....

> 	Currently my tcp/ip address for ampr is gm7jgr@gm7jgr.ampr.org. Now
> hands up all the people who can mail me based on that host.domainname alone.

Not me! A cruel & heartless solution would be to pass all mail to you onto
the nos box owned by a person who believes in callsign.ampr.org. :-)
Ok, I'm not that cruel...

I do believe that most packet stations are geographically fixed for a
reasonable length of time (on the order of months/years). I also think
providing dynamic IP addresses to mobile/portable operators is a GOOD IDEA.
But I think mail forwarding to mobile/portable stations is a BAD IDEA.
In fact, I think mail forwarding to ordinary users is a SOSO idea.

Thus the problem. We want to be able to roam the world and still maintain
our connectivity.

A solution:

	+ Allow people to roam the world.
	+ Give them dynamic IP address allocation, so they can
	  TCP/IP wherever they go.
	+ Have well-known, fixed and reliable mail-machines/BBSs,
	  and give each person an account on one mail-machine,
	  preferably near his usual QTH. Ok, maybe 2 or 3.
	+ Bring the global packet radio `network' to a point that
	  a user can reliably get to her mailbox wherever she is,
	  using telnet/netrom/ax25 etc.
	+ Optional: Allow a user to have mail forwarded on to a
	  remote mail-machine if he so desires, with the understanding
	  that enabling/disabling the forward cannot be done on a
	  day to day basis.


Now, once mail is going to fixed, stable, reliable mail-machines, I don't
care what names they are given, as long inter-mail-machine routes are
also fixed, stable, & reliable.

> 	If we are ever going to set up a global tcp/ip ampr network, perhaps
> with real Internet links, in which mail can be sent from anyone to anyone we
> are going to have to lose the flat domain. There will be those who lose out,
> eg. anyone who operates mobile.

See above. It's going to be impossible to send mail from anyone to anyone.

> P.S. I object to the statement that the FCC are responsible for the ampr
>      domain level 'cos across here they aren't!!!

Nor here in Australia.

Cheers all,

	Warren vk1xwt.


----
From: gvdg@tophat.cdh.cdc.com
Date: Thu, 11 Jul 91 9:31:46 MDT
Subject: Re: New(er) NOS 0618

Hello Tony and others
> 
> Just installed it here.
> 
> I ended up changing my global/default IP address to 128.171.41.31 and
> did an 'ifconfig ax0 ipaddress 44.14.1.2' for the radio port and
> things work.  I also don't have to do an 'ifconfig' for each axip
> interface this way.
> 
> Tony
>  
I found out: the default used for ip/ip is de first found interface exclu-
ding localhost and encap. This means that the last defined interface its
IP address is used as the originating ip address (100 % chance of being wrong)
But as with previous discussions with Phil: Pick the worst guess , that is the 
best one to take, more wrong is inpossible!!! That is logic....


-- 
Internet: gvdg@tophat.cdh.cdc.com       |     Gerard J van der Grinten
UUCP:     gvdgpc!gvdg                   |     Control Data Bv.
Telephone: 0(+31)-70-3119703            |     Van Markenlaan 5
                                        |     2805 VL RIJSWIJK    Netherlands


----
From: wkt@csadfa.cs.adfa.oz.au (Warren Toomey)
Date: Thu, 11 Jul 91 15:56:32 EST
Subject: Re: Flat ampr.org

> Unfortunately, it looks like you are going to handle routing in exactly
> the same way.  The internet proper knows about a few gateways to the
> .ampr.org net, and routing then proceeds via some peculiar-to-ham-radio
> method other than IP routing.  If you accept that will happen, who is for
> discussing that method?  If not, would you please help me out of this
> conceptual hole I seem to have dug?

Maybe I didn't make myself clear enough?!

To begin with, assume that each class-B or class-C ampr network has one or
more gateways that knows how to route to all other class-B or class-C
networks. I don't care how, if they use the Internet as the data-link
layer it matters not. They could all be connected by Ethernet or 2400bps
telephone lines :-)

Assume that these gateways provide:

	+ telnet sessions to read/send mail
	+ SMTP mail gatewaying
	+ dynamic address allocation.

Ok, I live in 44.136.0/24. My gateway is 44.136.0.16. Great. Mail isn't
forwarded to my home nos box, but is kept on the gateway.

Right, I get into my Sopwith Camel & rip over to mainland USA. Assume the
US has given me a US license for the duration of my trip. I land in the
New Jersey region.

Hmm, I need a local address. I ask the 44.64/16 gateway for an address, and
get one. Now the gateway knows how to route to me & my home gateway, so
I log in and read my mail. It's a bit slower than normal, but that's the
price I pay.

I move on to Virginia & negotiate a 44.62/16 address, after relinquishing
the 44.64/16 address of course. I'm going to be here for 3 weeks, so I send
mail to my home gateway sysop, asking him to forward mail to the Virginia
gateway. This speeds up mail reading a bit!

Notes:

	+ The IP routes never change. Nobody has to muck around
	  with individual addresses.
	+ Mail routing doesn't change, unless the mobile asks the
	  home sysop to do forwarding. And in this case, only
	  the home sysop has to do anything.
	+ The media linking gateways is irrelevant, as it is now.
	  Who cares how the stuff is passed, as long as it is!
	+ All mail is SMTP passed over TCP/IP.

Next round of comments :-)

	Warren.


----
From: Mark H. Levine <yba@space.mit.edu>
Date: Thu, 11 Jul 91 01:38:21 PDT
Subject: Re: Flat ampr.org

Your mail problem is fairly easy to solve with Post-Office-Protocol;
your mobile station can pick up his mail from a known, static, stable
server where his mail usually gets sent.  The name server(s) for
*.ampr.org will then have to have an MX entry for every single call sign,
or we set up special machines with forwarding tables and the name server
has entries for those machines (theoretically the same solution, but
practically easier).

Unfortunately, it looks like you are going to handle routing in exactly
the same way.  The internet proper knows about a few gateways to the
.ampr.org net, and routing then proceeds via some peculiar-to-ham-radio
method other than IP routing.  If you accept that will happen, who is for
discussing that method?  If not, would you please help me out of this
conceptual hole I seem to have dug?


----
From: Don Koch <aardvark@nt1l.uucp>
Date: Wed, 10 Jul 91 23:08:30 EDT
Subject: Re: Managing ampr.net domain namespace


>Well, here we go again.  Confusing NAME with ADDRESS.  I don't know about

I wouldn't say that.

>anyone else, but I have no intention of changing "bill gunshannon" to
>"bill gunshannon wilkes-barre pa usa".  Names and addresses are two totally

And how does the US Postal System get mail to you? :-)

>different animals.  Just because the BBS system uses the two inter-changably
>doesn't make it right.  No FQDN on the INTERNET necessarily reflects the
>correct location or proper routing information for a message addressed to it

Tell this to any site not in the us (about location, not routing).

>and this has worked fine up til now.  When (IF?) AMPR.ORG is ever fully
>connected, then the system will work the way it was designed.  Trying to

When and if are the key questions.

>hack he system to do things it was never intended to do isn't the answer.
>Trying to fix the real problem (inter-connectivity) is the answer.

>bill    KB3YV

Agreed (well, to a point).  If we were to get REAL interconnectivity (i.e.,
not only can I get from here to there, but REAL fast), this would not be the
issue.  As I have seen, even real Internet sites have to be told how to route
mail (not all sites are running DNS and sometimes even their routers have
problems - try ftping to some of the overseas sites).  If nothing else, mail
to other networks (i.e., non-amprnet - and this includes other Internet
sites) may still have to be routed locally.  We actually have routing between
amprnet and the radio BBS world here.

The nice thing is, we could actually wean ourselves off of the system I
proposed as the interconnectivity issue gets solved.  We still need the
MX records to handle mail routing.

Don Koch
aardvark@nt1l.uucp
aardvark%nt1l.uucp@primerd.prime.com
nt1l@nt1l.ampr.org


----
From: jonas@LYSATOR.LiU.SE (Jonas Melin)
Date: Thu, 11 Jul 91 11:54:26 +0200
Subject: Mailing list

Please put me on the mailing list.

73's de Jonas/SM5LZM


----
From: uunet!samsung!swlvx2.msd.ray.com!anomaly.sbs.com!idsvax!mikebw mikebw@idsvax.ids.com <uunet!samsung!swlvx2.msd.ray.com
Date: Thu, 11 Jul 91 02:42:27 EST
Subject: RE: Stabilizing NOS!

Since I was specifically mentioned on this one, I think I should say
something.  I cannot agree that it is proper to "stabilize" NOS at the
source level by stripping things out of it.  I am currently maintaining
two versions which are in distribution in New England, and these are
made from the same source except for the CONFIG.H file.  If you want a
version on NOS with a, b, and c, but not with x, y, and z, then the
CONFIG.H file lets you do this with compile-time defines and undefines.

Both of my executables are downloadable from the ChowdaNet BBS dial-up,
(401)331-0334 (300-9600V.32/V.42) and (401)331-0907 (300-19200PEP/MNP).
The large version of the executable is GRINOS.ZIP, and the small version
is GRINOS-S.ZIP.  The source is available as GRIBEE04.ZIP, which contains
two files, CONFIG.BIG and CONFIG.SML, which can be copied to CONFIG.H to
do the appropriate versions.

The small version is in use at a couple of active sites, including our
ka1mf.ampr.org, which is the gateway between the main New England network
and the NET/ROM system that connects us to the Maine TCP/IPers.  This has
been running in a 540K DesqView window and coreleft has not dropped below
60K.  Other than some pathological example, such as DesqView running on an
XT, I can't imagine too many cases where this amount of memory would not
be available.  We have the large version running on the main Rhode Island
switch (we cover the whole state with one switch), switch.w1cg-9.ampr.org.

As to documentation, I would agree that it is inadequate for new users.
I have been collecting various new user documentation files, written both
locally and elsewhere, and have been maintaing these on ChowdaNet BBS.
The ZIPfiles that I use to distribute my GRINOS executables have a few
textfiles bound into them which are usually short narratives summarizing
bug reports, new features, and anything that may have been brought to my
attention since the prior release.  These comprise a sort of de facto
documentation, but I don't really have the time to do it right.
 
Finally, a comment about whether NOS should be ported to a GUI.  Maybe,
and I hope you find the masochist to do it.  My suggestion is to worry
about NOS memory consumption first, perhaps by using some kind of DOS
extender.  NOS does a lot of things that do not go over very well in
protected mode, but there are a lot of different approaches.  For example,
maybe we would find that it is easier to put the code into extended
memory, rather than the data in the traditional method.  But the big
problem facing NOS right now is memory, not screen appearance and user
interfacing.

-- Mike Bilow, N1BEE @ KA1RCI.RI.USA.NA
               mikebw@idsvax.ids.com


----
From: jonas@LYSATOR.LiU.SE (Jonas Melin)
Date: Thu, 11 Jul 91 11:54:26 +0200
Subject: Mailing list

Please put me on the mailing list.

73's de Jonas/SM5LZM


----