🚀 go-pugleaf

From: wkt@csadfa.cs.adfa.oz.au (Warren Toomey)
Date: Thu, 4 Jul 91 10:39:02 EST
Subject: Is there a gateways list around?

It's pretty difficult to set up Internet gateways when you don't know who
to contact to set up a route to you. I have knocked up a `gateways' list,
with the information I currently have. It's incomplete, so please help
fill in the gaps. Information on other gateways would be nice.

More information, routing requests etc. can be mailed to me! I'll leave the
most up-to-date list on minnie.cs.adfa.oz.au for anon ftp.

	Warren vk1xwt


Gateway to: 44.136.0/24  Canberra, Australia (vk1)
Internet address: minnie.cs.adfa.oz.au		131.236.20.90
Packet address: minnie.vk1xwt.act.au.ampr.org	44.136.0.31
AX25 mycall: vk1xwt-1
Run by: Warren Toomey vk1xwt
Internet email address: wkt@csadfa.cs.adfa.oz.au
Servers: ftp telnet smtp finger
Axip: Yes
Other useful IP addresses: 44.136.0.14 is local BBS, nearly always up
Notes:	minnie is up from 0700Z to 2300Z weekdays, and all weekend.
	Connection to vk1 stations is via dialin slip line, only
	available on weekends. minnie has a list of vk1 hosts and other
	information, such as this gateways list.


Gateway to: 44.64/16  New Jersey, USA
Internet address: switch.ka9q.ampr.com		128.96.160.2
Packet address: switch.wb0mpq.ampr.org		44.64.0.121
AX25 mycall: ???
Run by: Phil Karn ka9q & Al Shjarback wb0mpq
Internet email address: karn@thumper.bellcore.com
Servers: none
Axip: No
Other useful IP addresses: 44.64.0.122, 44.64.0.123


Gateway to: 44.62/16  Central Virginia, USA
Internet address: emperor.handheld.com		192.100.76.2
Packet address: wa4ong.ampr.org			44.62.0.1
AX25 mycall: ???
Run by: ??? wa4ong
Internet email address: ???
Servers: telnet ftp
Axip: ???
Other useful IP addresses:


Gateway to: 44.14/16  Hawaii, USA
Internet address: ampr.wslab.hawaii.edu         128.171.41.250
Packet address: uhm.ampr.org                    44.14.1.2
AX25 mycall: ah6bw-1
Run by: Tony Querubin ah6bw
Internet email address: tony@mpg.phys.hawaii.edu
Servers: telnet ftp smtp finger
Axip: Yes
Other useful IP addresses: 44.14.1.17

Gateway to: 44.130/16  Germany
Internet address: hb9zz.ethz.ch			129.132.20.19
Packet address: ???				???
AX25 mycall: ???
Run by: ??? hb9zz
Internet email address: ???
Servers: telnet ftp
Axip: ???
Other useful IP addresses:

Gateway to: 44.142/16  Switzerland
Internet address: hb9zz.ethz.ch			129.132.20.19
Packet address: ???				???
AX25 mycall: ???
Run by: ??? hb9zz
Internet email address: ???
Servers: telnet ftp
Axip: ???
Other useful IP addresses:

Gateway to: 44.131/16  England
Internet address: switch.ka9q.ampr.com          128.96.160.2
Packet address: ???
AX25 mycall: ???
Run by: Phil Karn ka9q & Al Shjarback wb0mpq
Internet email address: karn@thumper.bellcore.com
Servers: none
Axip: No
Other useful IP addresses: 


----
From: wkt@csadfa.cs.adfa.oz.au (Warren Toomey)
Date: Thu, 4 Jul 91 10:56:20 EST
Subject: Why is the ampr.org namespace flat?

Ok, my final question for today? Inquisitive little so & so, aren't I :-)

Can someone explain why the ampr.org namespace is flat? IMHO it's a stupid
idea! Trying to route mail to callsign.ampr.org must be hell.

My suggestion: the first subdomain below ampr.org SHOULD be the two-letter
country prefix. After that, each country should decide its own subdomains.

For example, Australia's country code is `au'. And our network here in the
Australian Capital Territory is small enough to fit into its own subdomain,
so I would use

	henry.vk1xwt.act.au.ampr.org
	minnie.vk1xwt.act.au.ampr.org

as the names of my packet boxes.

My only other suggestion: the full domain name of each machine SHOULD
have the callsign in it somewhere.

Cheers,
	Warren vk1xwt


----
From: Marc T. Kaufman <kaufman@Neon.Stanford.EDU>
Date: Wed, 3 Jul 91 23:41:14 -0700
Subject: Re: Why is the ampr.org namespace flat?

I read this group a lot, but don't often post.  However, I think the use
of a flat namespace is important enough to comment.

Radios move.  People with radios move.  People with radios take vacations,
to other cities and sometimes to other countries. One of MY personal goals
is to see protocols developed that can support a mobile population of
itinerant users, without requiring the users to do special things, and
without requiring their correspondents to know where they are.  I want to
be wb6ece.ampr.org [44.4.0.33] whereever I may go.

If you want geographic hierarchical addressing, use the AX-25 BBS system.
I aspire to better things, and don't want to see us bog down in "practical
systems" to the point that the goal becomes unattainable.

Marc Kaufman, WB6ECE
kaufman@Neon.stanford.edu


----
From: adam@IGG.TNO.NL
Date: Wed, 3 Jul 91 16:05:36 +0200
Subject: NET/Mac(52).sit.hqx

 
Hello all,

NET/Mac 2.0 version pa2aga(52) has been uploaded to ucsd.edu.

The filename is:    hamradio/ka9q/incoming/NETMac52.sit.hqx

73 de Adam PA2AGA (pa2aga@igg.tno.nl)


----
From: wkt@csadfa.cs.adfa.oz.au (Warren Toomey)
Date: Thu, 4 Jul 91 10:45:10 EST
Subject: Is axip symmetric?

A quick question on axip? Is it symmetric, in that both ends of an axip link
have to set up an axip iface to each other?

>From empirical evidence this appears to be true. I've set up an axip link
with Tony ah6bw; my axip iface callsign is vk1xwt-2, and his axip iface to
me has callsign ah6bw-3.

Now I can digi through ah6bw-1 to get to the Hawaii packet network, but
I _must_ use ah6bw-3 if I want to connect to his gateway, even though his
ax25 mycall isn't ah6bw-3.

Could somebody in the know clarify this?!

Thanx,
	Warren vk1xwt.


----
From: wkt@csadfa.cs.adfa.oz.au (Warren Toomey)
Date: Thu, 4 Jul 91 10:47:42 EST
Subject: What about using rip over the 44/8 virtual network?

Tony ah6bw suggested yesterday that an omniscient 44/8 gateway who knew
the routes to everybody else would be a good idea.

I'd like to ask if running rip between all these gateways might also be
a good idea. As far as I can see, the only problem is to filter out from
each gateway the real Internet routes that it would obtain from the
local LAN.

Comments, criticisms???

	Warren vk1xwt.


----
From: adam@IGG.TNO.NL
Date: Wed, 3 Jul 91 16:05:36 +0200
Subject: NET/Mac(52).sit.hqx

 
Hello all,

NET/Mac 2.0 version pa2aga(52) has been uploaded to ucsd.edu.

The filename is:    hamradio/ka9q/incoming/NETMac52.sit.hqx

73 de Adam PA2AGA (pa2aga@igg.tno.nl)


----
From: crompton@NADC.NADC.NAVY.MIL (D. Crompton)
Date: Wed, 3 Jul 91 16:13:49 EDT
Subject: NOS_0618 BCC compile


   I have successfully compiled PA0GRI 0618 in BCC. Here are the changes
I made:

1.   In makefile  CC=TCC to CC=BCC

2.   Extern Version2 from INSIDE main in main.c to below 'extern Version' in
     global.h

3.   Inserted prototype statement for 'doarea' in mailbox.c

4.   Made Kelvin's suggested changes for __MKNAME in pc.c

 NOTE that the last change may NOT be correct - see Mike W's earlier
 message. In any event it does compile this way and seems to run. I
 have the enviroment variable TMP= defined though.

 Maybe Gerard could make the 2nd and third changes in the distribution
 source.

 It appears that code which compiles correctly under the (less forgiving)
 BCC 2.0 would be OK on earlier TC compilers?? I am not sure if this is
 a correct assumption.

Doug


----
From: crompton@NADC.NADC.NAVY.MIL (D. Crompton)
Date: Wed, 3 Jul 91 15:56:15 EDT
Subject: BCC compile

	>I went around on Doug's problem with the linker fixup error in __MKNAME
	from FCLOSE when compiling PA0GRI NOS under Borland C++ 2.0; I resolved
	the problem with an extensive trace through the code at the assembly
	language level.
	
	This error has nothing to do with where Version2[] is defined or declared.
	It is a stack framing error.  There is no easy way to fix this problem,
	which actually results from a change in the run-time library between
	Turbo C++ 1.01 and Borland C++ 2.0, and it must be taken seriously.
	
	MOST IMPORTANTLY, THE FAILURE OF THE LINKER TO CATCH THE ERROR DOES NOT
	MEAN THAT THE ERROR IS NOT STILL PRESENT.  THE ERROR IS ALWAYS PRESENT.
	
	The work-around that I have been using is to comment out the replacement
	__MKNAME() and tmpnam() functions in PC.C, letting the compiler use the
	ones in the run-time library instead.  I have explained this in several
	messages previously, and I will not repeat all of that here.
	
	What may not have been clear from my original messages is that there are
	ways of getting the linker to go along with it, such as commenting out
	the declaration of __MKNAME as "pascal", which will result in code being
	compiled and linked, yet which will bomb the stack when run.  Also, this
	stack framing error may not have immediate consequences, but it will
	eventually crash the machine.
	
	There is a proper fix for this, which involves making some special
	compilation rules for PC.C in the MAKEFILE, but I have not yet had a
	chance to implement and test it.  When I have, I will post the correction.
	The only thing lost by the work-around explained above is that TEMP###.$$$
	files will be created in the current directory, and will not be deleted
	if the current directory is changed by the user between file open and
	close using the tmpfile() and fclose() functions.
	
	NO!  Kelvin's advice is good for Turbo C++ 1.01, but not for Borland C++ 2.0
	because of a difference in the run-time library.  I spent the better part of
	a day hunting around for this at the assembly language level with the
	debugger, and I am very confident of what I am saying.  The problem is that
	__MKNAME is internally a near pascal function called from the tmpnam
	function within the _TEXT segment.  In the old library, you could replace
	tmpnam and make the new tmpnam call a new function, named __MKNAME or any
	other convenient thing.  In Borland C++ 2.0, you cannot do this because
	fclose no longer calls tmpnam, but calls __MKNAME directly.  Kelvin's code
	therefore will force a call to a different name-creation function at file
	creation as at file destruction, and this will (at best) leave TMP###.$$$
	files hanging around on your disk.
	
	It is gross stupidity on Borland's part, but that's life.  The only safe
	solution I have found right now is to comment out tmpnam() and __MKNAME()
	in PC.C entirely.  I have an idea on the proper correction, but I have
	not yet got a chance to do it.
	
	-- Mike Bilow, N1BEE @ KA1RCI.RI.USA.NA  (AX.25)
	               mikebw@idsvax.ids.com  (Internet)
	 
	
I am not getting feed from TCP-group today, so I am not sure if these 
messages got to the group. If so, sorry for the repeat. Anyhow it is
important. I have though compiled and run numerous copies with kelvin's
fix with no problems. I did notice .tmp files building up and my fix
was to use the enviroment variable TMP= and that seemed to solve it. 
Now I only have temp files in one directory and that appear to be closed
properly. Looking forward to the proper fix. I think Kelvin's original 
intent with this code was based on a complaint from me that .tmp files
were created in the current directory rather than where you wanted them.
That is the reason for the Enviroment variable. Kelvin - correct me if I
am wrong on this. I like the idea of having the capability to select the
.tmp drive/directory. This could be a big win when you have ramdisk.

Doug




----
From: crompton@NADC.NADC.NAVY.MIL (D. Crompton)
Date: Wed, 3 Jul 91 16:13:49 EDT
Subject: NOS_0618 BCC compile


   I have successfully compiled PA0GRI 0618 in BCC. Here are the changes
I made:

1.   In makefile  CC=TCC to CC=BCC

2.   Extern Version2 from INSIDE main in main.c to below 'extern Version' in
     global.h

3.   Inserted prototype statement for 'doarea' in mailbox.c

4.   Made Kelvin's suggested changes for __MKNAME in pc.c

 NOTE that the last change may NOT be correct - see Mike W's earlier
 message. In any event it does compile this way and seems to run. I
 have the enviroment variable TMP= defined though.

 Maybe Gerard could make the 2nd and third changes in the distribution
 source.

 It appears that code which compiles correctly under the (less forgiving)
 BCC 2.0 would be OK on earlier TC compilers?? I am not sure if this is
 a correct assumption.

Doug


----
From: adam@IGG.TNO.NL
Date: Wed, 3 Jul 91 16:05:36 +0200
Subject: NET/Mac(52).sit.hqx

 
Hello all,

NET/Mac 2.0 version pa2aga(52) has been uploaded to ucsd.edu.

The filename is:    hamradio/ka9q/incoming/NETMac52.sit.hqx

73 de Adam PA2AGA (pa2aga@igg.tno.nl)


----
From: rob@pe1chl.ampr.org (R.E. Janssen (PE1CHL))
Date: Thu, 4 Jul 91 07:23:20 GMT
Subject: tmpname(), __MKNAME()

In the light of the ongoing discussions about these functions and the
effect when using new compilers, it may be a good thing to clarify
their origin and intent.

I added these functions to the NET.PE1CHL version compiled with Turbo C 2.0,
because the library functions in that compiler created tempfiles in the
current directory.  The tempfiles often stay aroud quite long (on our
slow networks) and when the user types a "cd" command at the net> prompt
while a file is open, the original Borland code will fail to delete the
file when it is closed.

Therefore I changed the code to create the tempfiles at the directory indicated
by the TMP environment variable, which has the added advantage that you
can put it in a RAMdisk.

I sent the fix to tcp-group when someone asked for the latter feature, and
apparently somebody has also integrated it in NOS.

I fully realize that it is a compiler-dependent fix, and that it should not
be carried over to other compilers without checking of the internals of
it's library.  However, from what Mike describes it sounds to me that
the situation did not change an that it should still work.  PASCAL routines
have a different parameter passing convention and stack handling, so in
any case you should NOT drop the pascal keyword, or it will break.

I think a better idea would be for someone who has good relations with
Borland to try to convince them that the temporary file handling needs
a fix, and that we already have the fix available.
When they properly integrate it into their libraries, there will be no
more problems with this in the future.

For now, leaving tmpname and __MKNAME out of the C++ version seems te
safest to me.

Rob PE1CHL


----
From: Antonio Querubin <tony@mpg.phys.hawaii.edu>
Date: Thu, 4 Jul 91 2:30:11 HST
Subject: gateways mailing list

Just wanted to let those of you on the 'gateways@uhm.ampr.org' mailing list
know that I will be moving the mail distribution of that list to a more
reliable system.  Just before uhm crashed this afternoon, there were 50+
messages in the SMTP queue caused by several posts in quick succession. 
These humongous SMTP queues are causing the system to hang often.

You can still send to the above address but uhm will just punt the message to
another system for distribution.  Apologies for so much down time...

Tony
AH6BW


----
From: gvdg@tophat.cdh.cdc.com
Date: Thu, 4 Jul 91 12:37:55 MDT
Subject: Re: Why is the ampr.org namespace flat?

> 
> Ok, my final question for today? Inquisitive little so & so, aren't I :-)
> 
> Can someone explain why the ampr.org namespace is flat? IMHO it's a stupid
> idea! Trying to route mail to callsign.ampr.org must be hell.
> 
O NO, not again.
> My suggestion: the first subdomain below ampr.org SHOULD be the two-letter
> country prefix. After that, each country should decide its own subdomains.
> 
Everybody , get a candle.
> For example, Australia's country code is `au'. And our network here in the
> Australian Capital Territory is small enough to fit into its own subdomain,
> so I would use
> 
> 	henry.vk1xwt.act.au.ampr.org
> 	minnie.vk1xwt.act.au.ampr.org
> 
> as the names of my packet boxes.
> 
Now read that sign on the wall (hope your candle is lit by now (flames))
     NAMES ARE NO ROUTES.
Actualy 44.xx.yy.zz is a flat address space (already holding routing info,
but that is another story)
> My only other suggestion: the full domain name of each machine SHOULD
> have the callsign in it somewhere.
Forget it as fast as possible, Callsigns already have wat you want.
check the prefix and you know all you want. for /m /a /p we have rip and
rspf to help.
> 
> Cheers,
> 	Warren vk1xwt
> 

Flames off please !!!!!

-- 
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


----