🚀 go-pugleaf

From: gvdg@cdc.com (Gerard Van Der Grinten)
Date: Thu, 4 Jul 91 7:38:45 CDT
Subject: Re: Comments/questions on PA0GRI NOS_0618

Hello Tom et all.
> 
> Gerard -- I am trying your version of nos_0618 on tomcat and have several
> comments/questions:
> 
> 1. Regarding the fkey command: For one of our VAXes, I need to set some
> key like <del> to be the delete key, 0x7f. I have tried a lot of combinations
> to map the delete key back into being a delete key and none work! If the
> leading character in the field is a "^", then it maps the next character as 
> a standard control character, and passes the rest thru as a string. I have
> tried to use the "<alt>127" sequence and that doesn't work at all. Any
> suggestions?
> 
Oops, a typo , grew up with octal but had typed 127 i.s.o. 177. del works again.
> 2. Regarding "mem" -- there are two new options I don't understand, "circular"
> and "efficient/slower". Can you explain?
> 
Mem eff is a switch to go to the already used memory or not (best fit search)
mem circ is just an compile time if from Phil externalized. Pure testing....
> 3. Apparently "mail" is equivalent to "smtp kick"?
> 
No, mail starts a BM session (space permitting)(memory)
> 4. How do you set up rlogin entries?
> 
Forget rlogin, i still have to take it out or make the login name (gvdg)
a environement variable. Due to NOS's problems handling expedited data it
does not work that great.
> 5. Can you explain "source" and "tail"?
> 
source is an read configuration command from a file. (extension to autoexec.nos)
tail is like more butonly a last part of the file. like tail(1)
> 6. Can you explain the "watchdog" on/off for me?
> 
watchdog  looks if the pc (+++) still runs, if it appears to die it resets the
machine. So no long shell escapes with watchdog on...Mountain top feature.
> 7. Am I correct that "comm" merely sends out a character string to the
> designated iface?
> 
looks that way to me too.
> 8. A suggestion: when you set domain verbose&translate on, the "tcp stat"
> line overflows because the local host name name is fully expanded. Maybe
> "half-verbose" (not expanding the local host). Also, the socket number
> runs into the following field. Perhaps one white space would make it more
> readible.
> 
you are lucky, if i switch it on i get overflows on the stack. three finger
salut solves it .....
> 9. A feature in Phil's code which is lacking in yours is "domain query"
> which implements an nslookup function.
> 
I know, I had it in untill 0808 complete with a domain server. The domain code
is in such a state i dont like it anymore. A large collection of unstructures.
See above for the translation problem. If i ever get to it i will rewrite
(again) everyting. I hate the current rewrite of the domain file, etc.
O whell it is amatuer stuff.
> 10. Although rarp says that it allows for ethernet address queries:
> 
> >  net> rarp q
> >  Usage: rarp query <interface> <ether addr|callsign> [<ether addr|callsign>]
> 
> And I have ethernet defined as a device on tomcat, I get the following reply
> to a valid ethernet address on our LAN:
> 
> >  net> rarp q ethernet 08:00:20:07:83:22
> >  Only AX25 interfaces allowed
> 
I changed  the dock inside as rarp via ethernet (packet drivers) still goes
wrong. I have to look into that.
> 11. General comments: The "ftype" switch is nice. Also, it looks like mget 
> works again. If you are doing things with fkeys, it would be nice to have
> the default <f3> replay the last line typed in. I still haven't set up pop --
> a good tutorial from someone would be a big help!
> 
add fkey 83 ^b  and your f3 does what you want. (control b does it as well,
the fkey is a mere remap. (old kelvins code).
I saw the good pop tutorial come by, no further additions. Thanks.
> 73, Tom
> 

A 73 to you to, and a happy 4th july.

-- 


----
From: Gareth Howell <sadss!garethh@relay.EU.net>
Date: Thu, 04 Jul 91 13:54:15 BST
Subject: 

I am reposting this as I didn't see it appear in tcp-digest. Apologies
if you have seen this before. - Gareth
----
Hi all,
I realise that this is not specifically related purely to tcp/ip
over radio links, but as there is a large body of knowledge in this
list and I haven't had a great response from comp.protocols.tcp-ip I
thought I would try here. Please humour me :-)

I wonder if someone can help me with a tricky problem I am trying to come to 
grips with.

I have the (un)enviable taks of coming up with an Internet Addressing 
Strategy for the UK Department of Social Security's internet (note small 
'i':-). This comprises (or soon will) 2500+ Ethernet LANs: each with 
anything from 4-50 PCs, Unix application servers and gateways on them; all 
interconnected using the Government Data Network (X.25 (1980)). Most of the 
operational systems use OSI protocols, but there is a significant amount of 
IP traffic, mainly for SNMP hub, bridge and host management on the LANs.

What I need is a sanitory way to split up the population to ease number 
allocation and permit local administration of each LAN. What I have come up 
with are two proposals, and I would like comments (good or bad :-):

1. 
Allocate a Class A network number and subnet it.

2.
Allocate a single non-subnetted Class B address to the X.25 GDN (2500+ hosts).
Allocate a number of Class B addresses to clusters of LANs, and subnet each 
of these networks in accordance with RFC950 and RFC1219.

I have one outstanding issue relating to option 2, and that is whether dynamic 
routing protocols will cope with this environment. Specifically, will a host 
on LAN 'A' (which is a subnet of network 'X') be able to reach a host on LAN 
'B' (which is a subnet of network 'Y') by routing across the GDN. The 
problem seems to be whether the routing tables in LAN 'A's GDN gateway, 
know that to get to LAN 'B' you have to go to LAN 'B's GDN gateway: which 
implies that LAN 'A's gateway (on network 'X'), knows the subnet mask of 
network 'Y'. 

Option 1 is the easiest technically, but has political problems which I
can't go into here. If it is significantly better than option 2 I will
brave the brickbats and hatchets and go ahead with it anyway; but I would
like to be sure of the benefits first :-)
Any ideas?
Gareth Howell
garethh%sadss.uucp@ukc.ac.uk (I think that's the best route for mail)
 _____________________________________________________________________________
|                   |                                       |                 |
| EMAIL:            | ADDRESS:                              |                 |
| ukc!sadss!garethh | DSS, Moorlands Road, Lytham St Annes, | PHONE:          |
| ukc!cix!garethh   | Lancs, England.                       | +44 253 797205  |
|___________________|_______________________________________|_________________|


----
From: BARRY TITMARSH <BTITMARS@ESOC.BITNET>
Date:  Fri, 05 Jul 91 04:10:13 CET
Subject:  New WNOS Version 2.B

Hello this version has been sent to tomcat.gsfc.nasa.gov, today.
The new feature of this version is that is now has a Monitor window
switchable to monitor any traceing you have truned on along with the
nice feature of the F1-F8 keys to switch sessions and a top of screen
status line to show the current users. This system has auto ax25 routeing
and auto save of ip # and ip routes. Code is written by DB3FL in germany
and includes the new experimental WAMPES system in the ax25 radio bits ...
Enjoy.
DC0HK/GM8SAU  dc0hk @ db0ie.deu.eu  dc0hk.ampr.org [44.130.24.71]
btitmars@esoc.bitnet
[Thanks to gerry n5jxs for the tomcat transfer]


----
From: skcm@echo.canberra.edu.au (Carl Makin)
Date: Fri, 5 Jul 91 3:02:45 EST
Subject: Re: Why is the ampr.org namespace flat?

> The AMPR.ORG namespace is flat at the first level so that using it will
> be the same as using callsigns.  There is NO NEED to make it more complex,
> since callsigns are already unique worldwide.

The callsigns are unique, but doesn't having the "flat" namespace mean that
"when" there is a domain nameserver operational it will have to handle the
entire "44" subnet.

How can we handle it otherwise?

> Remember, names are not routes.  Names imply addresses.  Addresses are not
> routes either.

Ok, does this mean then that allocating IP address based on geographical
location (ie 44.136/16 is Australia etc) will be phased out at some point.

If this happens, what are the alternative routing methods?


Carl.


----
From: wd0efl@wd0efl.ampr.org (Brian K. Teravskis)
Date:  Thu, 4 Jul 1991 20:49:50 -0500
Subject: Compiling problems with TC++ V1.0

I'm rather new at this, and I am wondering if someone would help me
with some compiling problems I am having with TC++ V1.0 and the source
code src_0605.

I get a lot of errors like the following:

Error bmutil 720: type mismatch in parameter 'm' in function mbox

I have also had problems in the past with a properly compiled version
of NOS that turns out to be stone deaf to the serial line...Everything
else works fine, but when it comes time to read/write to the serial
buffer nothing happens..

Any help would be appreciated.

Brian Teravskis  -- WD0EFL

AX25 :  WD0EFL @ N0DAI.MN.USA.NA
Internet : wd0efl@g1xrl.vware.mn.org


----
From: hb9cat@hb9zz.ethz.ch
Date: Fri, 05 Jul 91 01:20:51 UTC
Subject: memory leakage (my own)

Hi all,

could someone please remind me the (long!) sequence of commands needed
to set the pk232 in kiss mode ? My tnc2 clone just gave up his soul...

Thanks

Marco
HB9CAT


----
From: Marco Zollinger <hb9zz@bernina.ethz.ch>
Date: Thu, 4 Jul 91 17:19:19 MET DST
Subject: gateway list addendum

Hi Warren,

thanks for your efforts in collecting infos; here tha data about hb9zz:


Gateway to: 44.142/16  Switzerland | 44.130/16 Germany | 44.137/16 Holland
Internet address: hb9zz.ethz.ch			129.132.20.19
Packet address: hb9zz.ampr.org			44.142.1.1
AX25 mycall: hb9zz (->interlink), hb9zz-1 (local port)
Run by: Marco Zollinger hb9cat & Marcel Wiget hb9rwm
Internet email address: sysop@hb9zz.ethz.ch, hb9zz@bernina.ethz.ch
Bitnet: hb9zz@czheth5a
X.400:G=marco/S=zollinger/OU=tap/O=telematik-netze/PRMD=alcatel/ADMD=arcom/C=ch
Servers: telnet ftp smtp finger (nntp server planned)
Axip: yes
Other useful IP addresses: dl8yq.ampr.org/WNOS pilot station with domain server
			   pi8hrl.ampr.org/smtp-ax.25 bbs gateway
			   hb9ab.ampr.org/planned E-mail->Fax gateway 






actual configuration for encap & axip :

attach axip ai1 256 129.177.122.10 hb9zz-2
attach axip ai2 256 131.236.20.90 hb9zz-3
attach axip ai3 256 128.171.41.250 hb9zz-4

route add [44.64.0.0]/16        encap   switch.ka9q.ampr.org
route add [44.14.0.0]/16        encap   128.171.41.250
route add [44.62.0.0]/16        encap   192.100.76.2
route add [44.136.0.0]/16       encap   131.236.20.90



best regards,

Marco
HB9CAT


----
From: brian@ucsd.Edu (Brian Kantor)
Date: 4 Jul 91 13:46:12 GMT
Subject: Re: Why is the ampr.org namespace flat?


The AMPR.ORG namespace is flat at the first level so that using it will
be the same as using callsigns.  There is NO NEED to make it more complex,
since callsigns are already unique worldwide.

So, you can have
	wb6cyt.ampr.org
	pc.wb6cyt.ampr.org

Other than typing exercise, why would you want it otherwise?

Remember, names are not routes.  Names imply addresses.  Addresses are not
routes either.

I'm sorry to report: it's a bad idea.  Let's just gently forget about it.
	- Brian


----
From: Marco Zollinger <hb9zz@bernina.ethz.ch>
Date: Thu, 4 Jul 91 17:11:05 MET DST
Subject: wnos2a

I've uploaded wnos2a.exe on ucsd.edu, in the /hamradio/ka9q/incoming
directory.

It is stil an alpha version, Michael warned there are still bugs (I didn't
see any), but it contains the packet driver many users were missing.

Another version, with an experimental domain server, should be soon
available.

73s

Marco
HB9CAT


----
From: brian@ucsd.Edu (Brian Kantor)
Date: 4 Jul 91 13:46:12 GMT
Subject: Re: Why is the ampr.org namespace flat?


The AMPR.ORG namespace is flat at the first level so that using it will
be the same as using callsigns.  There is NO NEED to make it more complex,
since callsigns are already unique worldwide.

So, you can have
	wb6cyt.ampr.org
	pc.wb6cyt.ampr.org

Other than typing exercise, why would you want it otherwise?

Remember, names are not routes.  Names imply addresses.  Addresses are not
routes either.

I'm sorry to report: it's a bad idea.  Let's just gently forget about it.
	- Brian


----
From: brian@ucsd.edu (Brian Kantor)
Date: Thu, 4 Jul 91 06:53:18 -0700
Subject: Administrivia

It's summertime, and that means that it's time to experiment with new
versions of sendmail.

That's why you got a bunch of copies of the last few messages.  Sorry
about that.  I'm working on it.
	- Brian


----
From: Marco Zollinger <hb9zz@bernina.ethz.ch>
Date: Fri, 5 Jul 91 14:37:44 MET DST
Subject: Re: route to 44.137

> 
> Looks like both of you may be routes to 44.137.  Which host
> (gr08pc.cdh.cdc.com or hb9zz.ethz.ch) is more likely to be running all the
> time?  Perhaps two different routes to subnets of 44.137 may be in order
> here?

I guess that routing through Gerard makes much more sense; I just don't know
how Dutch PTTs are behaving, since I was asked to forward the group to
pi8hrl via smtp on ax.25. I think Gerard can go on with encap and axip,
I'll keep forwarding smtp traffic. Is that ok, Gerard ?

Marco
HB9CAT
 


----
From: Bob Hoffman <hoffman@cs.pitt.edu>
Date: Fri, 5 Jul 91 10:17:35 EDT
Subject: Re: Why is the ampr.org namespace flat?

Marc T. Kaufman <kaufman@Neon.Stanford.EDU> writes:
> I want to
> be wb6ece.ampr.org [44.4.0.33] whereever I may go.

It is certainly desirable that the name be the same no matter where
you are.  It is also easy to accomplish.

The IP address is another matter.  If I were to move from Pitt across
the valley to CMU, I would not be able to keep my 130.49.x.x address;
it would have to change to 128.2.x.x.  All of the routers in the Internet
would continue to route all 130.49 packets onto the Pitt campus.

Names, addresses, and routes are disjoint entities, however addresses
do imply routes.  If network 44 were fully connected, I would expect
to send all 44.4.x.x packets to the Bay area.  If those addresses were
permitted to move around at will, it would be a management nightmare.
My routing table would have to have specific entries for everyone who
wasn't in their "home" area.

	---Bob.


----