🚀 go-pugleaf

From: jpd@pc.usl.edu (Dugal James P.)
Date: 7 Jul 91 15:45:39 GMT
Subject: Re: Another mbox funny?


Barry VE3JF writes:
>I installed the vanilla 0614 code on our local switch.  When I
>telnet in and go into remote sysop mode, the session consistently hangs
>when I do a 'route' command - it shows part of the routing table and then
>goes into the weeds.  Anyone else seen this one?

I have an intermittent problem with Phil's 06xx NOS versions, where it
gets out of sync updating the current screen window.  It behaves as if
a buffer flush is delayed until an output screen buffer fills up.  I
haven't been able to reliably reproduce this.  I run under Desqview and
msdos 4.01, and compile with Turbo C 1.01.

Could this be what you are seeing, Barry?  And, does anyone have any ideas?

73,
-- 
-- James Dugal,	N5KNX		Internet: jpd@usl.edu
Associate Director		Ham packet: n5knx@k5arh
Computing Center		US Mail: PO Box 42770  Lafayette, LA  70504
University of Southwestern LA.	Tel. 318-231-6417	U.S.A.


----
From: Bdale Garbee <bdale@col.hp.com>
Date: Sun, 07 Jul 91 10:51:07 MDT
Subject: Re: Flat ampr.org

> If the cellular model is adopted, then our IP addresses would need
> to be unique to the computer instead of the amateur

But of course... all of my machines have their own addresses:

$ORIGIN n3eua.ampr.org.
vectra          IN      A       44.32.0.5
clone           IN      A       44.32.0.2
winfree         IN      A       44.32.0.4
laptop          IN      A       44.32.0.3
switch          IN      A       44.32.0.1

Is there a problem?

Bdale


----
From: pabc@n5jxs.jsc.nasa.gov
Date: Sun, 07 Jul 91 19:03:42 cst
Subject: Re: Flat ampr.org

>Is there a problem?
No there is not a problem, BUT the scope of the discussion hasn not
considered o"our" mobile operations. It has now considered the
the fact that ampr


----
From: pabc@n5jxs.jsc.nasa.gov
Date: Sun, 07 Jul 91 19:03:42 cst
Subject: Re: Flat ampr.org

>Is there a problem?
No there is not a problem, BUT the scope of the discussion hasn not
considered o"our" mobile operations. It has now considered the
the fact that ampr


----
From: pabc@n5jxs.jsc.nasa.gov
Date: Sun, 07 Jul 91 19:20:33 cst
Subject: Re: Flat ampr.org

Please excuse duplicate msg, the SLIP line I use on weekends hung!
 
> Ist there a problem?
No problem, except that the "flat ampr.org" discussion, at least
up until recently, seemed to be ignoring the mobile nature of
our fraternaty. We do have mobile operations, we do relocate
on a temporary basis, and we should at least consider a paradym that
can accomodate that one individual may have 3 or 5 addresses, yet
may want the routing mechanism to know where he is, just as a cellular
phone system with call forwarding can. I was merely trying to broaden
the scope of the discussion.
 
*73* - Paul


----
From: skcm@echo.canberra.edu.au (Carl Makin)
Date: Mon, 8 Jul 91 1:37:37 EST
Subject: Re: problem with wormhole

Hi Marco,

> I installed encap and axip at hb9zz; apart from crashes, I have a problem
> with the axip configuration:

and it got a *lot* of use.  Thankyou.
 
> What can I do to use port 0 (ax0) for axip ? Would it be enough to define
> a different link address (->SSID) for port 1 ?

Yes.  This is what you have to do.
The machine (an XT poor thing :-) at this end (VK1KCM) has 3 serial ports
and an ethernet card.  Two of the serial ports go to radios and the third
is an AX25 link to a Xenix box. (horrible I know but it works)

To allow people to use each port you have to define a different link address
so I ended up using VK1KCM-0 for ax0, VK1KCM-1 for ax1 and VK1KCM-2 for ax2.

ax1 is my 144.800 Mhz 4800 baud port.  For someone in Switzerland coming in
via (say) HB9EAS on your ax0 and wishing to go out my ax1 port the connect
would be;

c vk1xyz v hb9zz-3, vk1xwt-4, vk1kcm-1<ret>

(VK1XWT-4 is the axip address pointing to my box of the machine actually
on the Internet)

Carl
vk1kcm@vk1kcm.act.aus.oc
skcm@ise.canberra.edu.au


----
From: skcm@echo.canberra.edu.au (Carl Makin)
Date: Mon, 8 Jul 91 4:48:16 EST
Subject: Some questions from the weekends romp thru Switzerland, Hawaii, etc.

I have some general questions arising out of the linking going on last
weekend.

- RSPF vs RIP.  Can I run both RSPF and RIP on the same NOS box?
The situation is that I have 2 radio ports and an ethernet connection.
Would it be correct (and possible) to run RIP on the ethernet and RSPF
on the radio and axip ports?

I have read the rspf.doc document on ucsd.edu and have a small understanding
of it however I don't know much about RIP so here I'm guessing.  The reason
for running RIP is that eventually we intend to have a SCO Unix box onthe
ethernet and it only talks RIP.

- NET/ROM over axip links.  Well I have confirmed it works.  I played around
with defining an axip session over the house ethernet and the node broadcasts
were updating the tables at both ends as per normal.  The links seem to be
ok and I was able to generate NET/ROM sessions both ways.  

Anybody else want to try it as well?  minnie.vk1xwt and bbs.vk1xwt will 
both be running netrom on all axip interfaces during the next link (probably
next weekend) so plug in your routes and give it a try! :-)

- FlexNet.  What is it?  Who wrote it?  How does it work?  (and so on)
While I was rampaging thru Switzerland, France, Germany and Austria on
the weekend via the axip link (hb9zz) I used the Flexnet network.  
Can anybody give me a rundown on it?

- PA0GRI NOS0618 BBS functions.
Another thing I noticed was that normal AX25 users logged into the
MBOX seemed to get the privleges assigned to "anonymous" in the /ftpusers
file.  Also it seemed that as a normal user you could change your "area"
to anyone elses.  ie log in as vk1zdj and change your area with "a vk1kcm"
and read messages for vk1kcm.

When does the "read Y/N" part of a message get updated?  I noticed that
there is no record of users reading a message.  When they log out and then
log back in, all the message they had previously read were marked "unread"
again. :-(  Is there a way around this?  It would be nice as I'm looking
at using NOS to replace MSYS as my BBS software.

Carl,
vk1kcm@vk1kcm.act.aus.oc
skcm@ise.canberra.edu.au



----
From: mea@Mea.cc.utu.fi (Matti Aarnio)
Date: Mon, 8 Jul 91 12:15:11 EET
Subject: Managing ampr.net domain namespace

Hello,

Question of flatness of NAME space (I will not make comment on address
issues, that is a different beast) is filled with plenty on controversy.

As for MANAGEMENT, splicing AMPR.ORG into subdomains according to first
two or three first letters of callsign would most propably be GOOD IDEA.

It would keep individual region database files in reasonable size, and
same with searches.  (All right, good hashing DB behind DNS will do search
in O(1) in any case.)
For automatic maintance of this database you would need canonical Regular
Expressions to convert any arbitary call sign to DNS subdomain, and something
magical for those call signs which start with number -- DNS doesn't allow
any such:
	4A5BC.4A.ampr.org -> d4A5BC.d4X.ampr.org
where "d" is magic cookie. (Letter)

Also, subdomaining would let master/secondary servers be in places, where
they are practical.  One example is OH-country...  (Let OH.AMPR.ORG have
secondaries in USA also, but let primary be here...)

Still, it would require that all sites/systems needing access to DNS database
for country/region XYZZY would either need copy of its database, or Fully
Connected Network.
With present monolithic approach, everybody either gets the monolith, or they
don't.  Very simple.


Problems arise while using spliced domains, example below is quite good:
(If splicing is made wrong.)

> It would seem to me that the only useful feature of subdomaining ampr.org
> would be for mail routing.  Getting mail directly to ka9q.ampr.org directly
> seems less likely than getting mail to ka9q.nj.us.ampr.org, where a local
> mail host would at least know where to send nj mail.  (Sorry to pick on
> you, Phil, but you were the first case to come to mind where your call
> doesn't indicate what area of the country you are in.)

  Thinking that KA9Q is forever in NJ is an error - Phil noted us, he moves...
Furthermore, to be automatically maintained (would anybody propose anything
else with serious face ?)  this method expects that everybody have geographical
call signs.  (Or dbase creators have more data/exception lists available.)

  I would at most splice DNS to:  KA9Q.KA.AMPR.NET.
And then have MX records pointing to somewhere, who has closer knowledge,
if direct connection isn't possible.

> Besides, why couldn't you have both a "top level" and a subdomain name
> for the same address (e.g., nt1l.ampr.org and nt1l.ma.us.ampr.org are
> the same ip address), the latter mostly for mail routing?  Mail routers
> would only need to have MX records for local sites, connecting regions
> and *.ampr.org (which would go to the next node "up").  If you move,
> the mail host for that area could forward your mail to your new address.

  There is such DNS information unit, as CNAME for aliasing one entity to
another.  Yes, it can be done.   Anybody who does it must do it carefully,
because DNS entity having CNAME must NOT have anything else.
TROUBLE is in defining these (preferrably top-level) CNAMEs pointing to
real data entries.  If regional maintance updates only their zones (sub-
domains), who updates top-level ?  (Must be automatic!)

> The next best (or actually better) thing would be a set of mail hosts
> with reasonable connections to some decent DNS servers (could be the
> same machine for any given region).  If your machine doesn't know the
> destination site's IP address, it sends it to the local mail host and
> lets it figure it out.  (I haven't seen any instances of mail hosts
> in this area.  Are there any areas using one?)

  Yep.  I call local mail hosts with term  "Intelligent Mailer".
They have full knowledge of the network at their disposal, or very least
they know that pseudo-domains .UUCP, and .BITNET are handled better elsewere.
(But for Internet at large they are SMART beasts.)

> For all other services, I'd definitely prefer the "flat" address space.
> If I can't get the address from the DNS zone server for that machine, I
> probably won't be able to get to the machine anyway.

  Your point could be valid for direct connectivity, but MXes are different
subject - and how to handle things like feed from USA to OH-land ?
Defining tertiary MX into US, trinary into Sweden, secondary and primary into
Finland ?  Sounds simple, but isn't that usually.
(It isn't easy to define 4 MXes for every of hundreds of hosts...)

Unfortunately MXing isn't real solution, when there is no full connectivity
for getting the data.  OH.AMPR.ORG for mail could be half the task, but
would not solve non-local cases like KA.AMPR.ORG...

Yes, mail routing can be a heck of a problem.

> Don
> aardvark@nt1l.uucp
> aardvark%nt1l.uucp@primerd.prime.com

	/Matti Aarnio <mea@utu.fi>  oh1mqk
	   Postmaster on a high-trafic system


----
From: Marco Zollinger <hb9zz@bernina.ethz.ch>
Date: Mon, 8 Jul 91 11:44:24 MET DST
Subject: Re: Some questions from the weekends romp thru Switzerland, Hawaii, etc.

Carl,

> Would it be correct (and possible) to run RIP on the ethernet and RSPF
> on the radio and axip ports?

We've been doing it for a while, seemed to be working fine, apart from
increased memory usage.

abt NET/ROM:
> Anybody else want to try it as well?  minnie.vk1xwt and bbs.vk1xwt will 
> both be running netrom on all axip interfaces during the next link (probably
> next weekend) so plug in your routes and give it a try! :-)

will probably be there on Sunday, I'll start defining routes during
this week.
 
> - FlexNet.  What is it?  Who wrote it?  How does it work?  (and so on)

There's an article on it in the 9th ARRL CNC, page 127; contact
Flexnet-group, Bunsenstr. 2a, D-6100 Darmstadt, FAX 49 6151 895718
 
Marco
HB9CAT


----
From: uunet!samsung!swlvx2.msd.ray.com!anomaly.sbs.com!idsvax!mikebw mikebw@idsvax.ids.com <uunet!samsung!swlvx2.msd.ray.com
Date: Fri, 5 Jul 91 09:17:23 EST
Subject: One more shot at __MKNAME()

Rob is right: DON'T remove the declaration of __MKNAME() as pascal or
things will fail.  However, it is possible to do things like that to trick
the linker into letting you make a far call to a near function.  That's
legal in C for a cedecl function, since the caller can clean up the stack
as long as it knows that the function is going to do a near return.  But
that is not legal for a pascal function.  What has to be done is to put
in an override in the MAKEFILE that lets __MKNAME() be in the _TEXT
segment instead of the PC_TEXT segment; then the library's tmpnam() and
fclose() can call it properly.  I will geto this in the next day or so.
In the meantime, just comment out __MKNAME() and tmpnam() in PC.C --
it is not that big a thing, folks.
-- Mike Bilow, N1BEE @ KA1RCI.RI.USA.NA  (AX.25)
               mikebw@idsvax.ids.com  (Internet)


----