🚀 go-pugleaf

From: Anders.Klemets@cs.cmu.edu
Date: Wed, 5 Jun 91 11:20:00 -0400 (EDT)
Subject: Re: (G)ateway Funny in G1EMM NOS

> A link-layer connection to my local NET/ROM node GB7UX-2 is 
> in existance because I've got an IP connection to another
> station using NET/ROM. Someone logs into the bbs and types
> 'g 144 gb7ux-2'. Hey Presto! They *immediately* get the 
> Connected. signal but nothing they send gets sent to the
> node, nor does anything come the other way.

That is no bug. I deliberately included that behaviour as a part of the
AX.25 socket interface. Do you want NOS to send a SABM on an already
operational AX.25 connection? That will reset the AX.25 sequence
numbers, which is likely to cause any data that is in the pipe to be
discarded. And it would not be possible to tell, at the AX.25 level, if
that data (transmitted but not yet acked) got delivered or not.

Anders


----
From: kurt@cs.tamu.edu (Kurt Freiberger)
Date: Wed, 5 Jun 91 11:56:29 CDT
Subject: Re: (G)ateway Funny in G1EMM NOS

>
>That is no bug. I deliberately included that behaviour as a part of the
>AX.25 socket interface. Do you want NOS to send a SABM on an already
>operational AX.25 connection? That will reset the AX.25 sequence
>numbers, which is likely to cause any data that is in the pipe to be
>discarded. And it would not be possible to tell, at the AX.25 level, if
>that data (transmitted but not yet acked) got delivered or not.

I understand why it doesn't work;  However, could the user be told that
the link is already in use? Alternatively, (and I may get flamage for this)
could the user's call be used as the source address on outgoing calls?  I 
realize this would need some hacks in the AX.25 code.  Perhaps the call of
the IP station could be inserted as a digipeater with the repeated-bit 
already set.  If that is distasteful to the audience, I will cheerfully
accept my lumps. 8}

>Anders

73, Kurt

 
 % Kurt Freiberger, WB5BBW   Dept. of Computer Science, TAMU              %
 % Internet: kurt@cs.tamu.edu      | "Try not to become a man of success  %
 % AuralNet: 409/847-8607          |  but rather a man of value."         %
 % AMPRNet: wb5bbw@wb5bbw.ampr.org |                    - Albert Einstein %
 % Disclaimer: Not an official document of Texas A&M University           %


----
From: microsoft!trsvax!techsup!kenb@ucbvax.Berkeley.EDU
Date: Wed, 5 Jun 91 10:16:32 CDT
Subject: ip in DFW

jay, there is some ip activity in the fort worth/dallas area,
although not too much.  i've had a version of 890421 and xobbs
running on a xenix box for some time -- but just took it down
last week due to lack of use.  there are others, mostly nos
stations, still up...  kf5mg and wk8u, among others.  sorry, i
don't have their ip addresses here.

try the d.a.t.a repeater on 146.700-.  this repeater is where
most of the ip traffic is.  local addresses are in the range of
44.28.0.xx.

every now and then we have a *spurt* of interst and activity, but
we just haven't gotten it together ip-wise here yet.

some voice repeaters in the area are 146.940- in fort worth,
146.880- in dallas, and 146.860- in arlington.  usually, the
146.86 autopach is opened for everyone during hamcom.  i'm not a
member of that group anymore, so i'm not sure if it'll be the
case this year or not.  

kenb, n5lpi 44.28.0.10

...!decwrl!microsoft!trsvax!techsup!kenb


----
From: Jay Maynard <S0JM@ADMIN.HSC.UTH.TMC.EDU>
Date:  Wed, 05 Jun 91 15:53 CDT
Subject: Ham-Com IP: I'll be there...

I've gotten a couple of comments that what IP activity there is in the DFW
area is on the 146.10/70 repeater...so, that's where I'll set up. Anyone
else adventurous enough to lug their IP station along...
k5zc.ampr.org, 44.76.0.92, K5ZC-8

...Jay


----
From: Anders.Klemets@cs.cmu.edu
Date: Wed, 5 Jun 91 21:20:37 -0400 (EDT)
Subject: Re: (G)ateway Funny in G1EMM NOS

> However, could the user be told that the link is already in use? 

That is not really necessary. At the same time as one process is
transmitting NET/ROM or IP frames on an AX.25 connection, another
completely unrelated process can very well use the same connection to
transfer raw (no-level-3) data.

AX.25 frames have no connection identifier tag. A connection can only be
identified by the <source,destination> tuple. That is why you can never
have more than one connection to a given destination. (Assuming that you
only use one AX.25 callsign.)

So if you are connected to a particular AX.25 station, and a gateway
user tries to connect to the same station, he will get an error message
indicating that a socket could not be created because of the address
ambiguity.

However, if you are only shipping NET/ROM frames to a particular
station, nothing prevents the gateway user to start a raw AX.25
connection to the same station. And there is no need to transmit an SABM
because the AX.25 connection is already up. Recall that NET/ROM always
uses connected mode AX.25 at the link level. Transmitting an SABM would
not only cause a dangerous reset of the connection, but it is also
unnecessary overhead.

The AX.25 connection that is used by NET/ROM (or vc mode IP) will show
up as a control block in the "ax25 status" command, but it will have no
socket associated to it until someone (a gateway user for instance)
decides to open a raw AX.25 socket.

Anders


----
From: crompton@NADC.NADC.NAVY.MIL (D. Crompton)
Date: Wed, 5 Jun 91 22:41:09 EDT
Subject: 0531 PA0GRI

	Subject: Re:  New NOS from PA0GRI
	
	
	Here are my inital results from running the PA0GRI code - 0531
	
	I have been running G1EMM exclusively for the last year. Always picking
	up his latest version. Of course the last was 113016 issued in early
	January. I have been running this version (with a bug fix local
	compilation) since then.
	
	Here are some notes and questions on the new code. I will mention the
	the changes from G1EMM that I have seen.
	
	1. The code does not automatically load 'autoexec.net' from root. I have
	not looked at the source and I imagine it looks for a different name.
	I just changed my autoexec.bat line to 'nos autoexec.net'
	
	2. The domain suffix requires a '.' after the name. Kelvin's last did
	not. I.E. - domain suffix ampr.org.
	
	3. The param statement is not the same - I need help here. I tried
	everything I could think of! 'param ax0 1 30' - gives 'ax0 txdelay 246'!
	
	4. The fkey function key setting code is in. How do you specify a
	carriage return at end of command? I.E.  'fkey 59 "ping wa3dsp"'
	How do I put a <CR> in the command? Also have we lost the F3 last
	command recall with this code in?
	
	5. net save/load has been added to store the netrom list for later
	recall.
	
	I have to pick up the source and maybe some of these questions can be
	answered from that. If anyone (Gerard) has any info on the above questions
	I would appreciate it.
	
	The code is about max'ed out. My memory is approaching limits, especially
	if I want to use the mailer. I will compile a small version when I get the
	source. 
	
	Doug
	
	


----
From: ben@val.uucp
Date: Tue, 04 Jun 91 12:41:50 -0500
Subject: Re: (G)ateway Funny in G1EMM NOS



>Hi All,
>
>Has anyone noticed this oddity with G1EMM (901130 v1.6) ?...
>
>	A link-layer connection to my local NET/ROM node GB7UX-2 is 
>	in existance because I've got an IP connection to another
>	station using NET/ROM. Someone logs into the bbs and types
>	'g 144 gb7ux-2'. Hey Presto! They *immediately* get the 
>	Connected. signal but nothing they send gets sent to the
>	node, nor does anything come the other way.
>
>	Suggestions ?
>
>There's also another NET/ROM related strangeness but I've yet to pin
>it down completely. More news later.
>
>73.
>
>Mike
>****

I have noticed this on my system as well.  Additionally, I have noticed
that if I have either a pending or established IP connection via NET/ROM,
an attempt to connect to the NET/ROM neighbor node using netrom connect
will result in the same behavior.

Ben


----
From: gvdg@tophat.cdh.cdc.com
Date: Thu, 6 Jun 91 10:54:07 MDT
Subject: Re: param command broaken

Hello All,
Some quick notes on NOS_0531 .
First: param command broken: A single line is missing in main.c interpreting
argv[3] into val. Fixed in 0604 comming up.
second: The autoexec file ihas an extension of .NOS so that 2 versions
(Phils and mine) can coexsist. Remember , i had a lot of domain stuff extra.
(like the required . on the end of the domain name (saved a lot of string
handling during the running process, now even more handling is done because
of the various ways querys come in. $origin is supported in domain.txt.
and the last part of a name is checked to be likely a domain or call so that
home.ka9q renders a sub-domain still in ampr.org where bimbo.axz renders
a "fully qualified" domain. (no digit in last (<= 4char) part).
There are more parts i am checking into, like the split screen seems to have
problems etc.
The cr in an fkey sequence goes like fkey 67 "ping pa0gri^M" (^M = 2 char where
the ^ makes the next char char - 0x20) (((whauw)))
so most sequences can be made (crlf escape, you name it. (check the cursor
keys for theire definition (ansi without other tsr's......)
With my Interactive Unix system at home i can fully use vi via telnet and rlogin.
I still have to pick up the environement for name and terminal type.
For Bdale: I use 4.8/14.4 bandwith of our fixed modem line (via UK) for
hdlc trunk (Phil: OSI network!!!) to the USA where i enter the internet
via one of the routers. CDCNET is a fully functional OSI network with
all required and most "wanted" features....
Regards, Gerard.
-- 
Internet: gvdg@gvdgpc.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: Antonio Querubin <tony@mpg.phys.hawaii.edu>
Date: Thu, 6 Jun 91 0:18:24 HST
Subject: nos 0531 from pa0gri

I too noticed some of those differences between the g1emm and pa0gri code.  

I suspect that you can put in a carriage return (and other unusual
characters) by using the C representation for it in strings.  So a newline
would probably be entered as a "\n" in the string.  I think a carriage
return is "\r".

SMTP does not use MX records by default.  The g1emm code did.  I
discovered this when I noticed a mail backlog on our system.

One problem I've noticed that is common to both g1emm and pa0gri is the way
RSPF handles broadcast addresses.  Our stations here will try to ping the
broadcast IP address (in this case 44.14.1.255) over and over again. 
Eventually it gives up and marks the entry as 'bad' in the rspf tables, but 
it doesn't drop the arp entry thank goodness!  Anyone know of a way to
prevent the pinging of a broadcast address by RSPF?  It would sure cut
down the amount of unnecessary packets.


Antonio Querubin  
tony@mpg.phys.hawaii.edu / ah6bw@uhm.ampr.org / querubin@uhunix.bitnet


----
From: Michael Chace <mikec@praxis.co.uk>
Date: Thu, 6 Jun 91 08:51:58 +0100
Subject: Re: PA0GRI and param


I'm also getting problems with the setting of KISS parameters
in PA0GRI v1.6h. For example, when trying to send CR CR ESC @K CR
to set my TNC running "TheFirmware" into KISS mode, results in

	Parameter 13 not supported

Even a legal 'param 144 1 xx' reports that parameter being set
to 0. So a 'param 144' reports ALL KISS params being set to 0.

73. Mike



----
From: Bdale Garbee <bdale@col.hp.com>
Date: Tue, 04 Jun 91 21:30:18 MDT
Subject: Re: TEKK radios from GRACILIS

> We ordered two of these radios at Dayton and paid for them.  Have
> heard nothing since.  I dropped a note to their internet address but
> no answer.  Has anyone gotten the radios from them?

The Telebit on ldhmi.gracilis.com took a lightning hit.  Don bought a new
T-2500 today, and we restored his mail connectivity.  I'd expect that any mail
that got stuck has now gotten to him.  It might be wise to re-email, in case
something got dropped in the bit bucket.

Bdale


----
From: ben@val.uucp
Date: Wed, 05 Jun 91 15:11:08 -0500
Subject: PA0GRI version param help


I recently compiled the newest version from Gerard and seem to be
having problems in the area of setting the KISS parameters.
The TNC is a PK-232MBX and in previous versions of NOS, I had been
setting the TNC parameters with statements in my autoexec.net file
of the form:
  param 2m 1 30
  param 2m 2 64
  ...

With the addition of the multi-port support code and the changes
in the way the param command works, I can't seem to properly set
the parameters at all.  NOS seems to grok the commands in a strange
way: alway printing a return value of 254.  I realize that KISS does
not support parameter return info, so the value of the return string
is of less concern to me than the actual setting being sent to the
TNC.

In this situation, the TNC transmits a 2.5 second txdelay and just as long
on the tail, not surprisingly.  After perusing the code, I have concluded
that the syntax shown above should still work.

Any ideas on what may be going on here?

BTW, I had to re-add user_lookup to the code because I compiled in the
PPP code and there was still a reference to it in ppppap.c

Ben
WD5HLS


----
From: mwester@sunbird.Central.Sun.COM (Mike Westerhof SE Chicago Metro)
Date: Wed, 5 Jun 91 16:42:16 CDT
Subject: AX.25 over TCP/IP

The prototype for a utility to transport AX.25 frames in and out of a
TCP/IP network nears completion.  I am now looking for brave souls to
assist in testing, and to provide some feedback.  Included is the overview
from the README file with the software.  If you are interested, let me
know!

  Mike Westerhof (KA9WSB)
  Mike.Westerhof@Central.Sun.COM


                             ax25ip
                             ======

Overview
--------

   RFC1226 describes a method of using TCP/IP based networks to transport
AX.25 frames.  The ax25ip utility uses this technique to transfer AX.25
frames in and out of TCP/IP environments.

   The interface to the AX.25 world is via KISS, with ax25ip emulating
either a standard KISS TNC or operating as a digipeater.  AX.25 frames
arriving on the KISS interface are routed to the IP interface and sent
to the appropriate IP host system.  Incoming frames from the IP interface
are filtered and sent out the KISS interface.  The operator controls the
mode (tnc or digipeater), the routing (callsign to ip host mapping), and
a few sundry controls via a configuration file, read at startup.

   In it's current implementation, ax25ip runs only on BSD UNIX machines
(SunOS 4.0.3 or greater, in particular).  It requires a serial port, and
uses a raw socket to gain access to the IP layer of the host's TCP/IP
implementation (this requires that ax25ip be started by root).


----
From: Antonio Querubin <tony@mpg.phys.hawaii.edu>
Date: Thu, 6 Jun 91 0:18:24 HST
Subject: nos 0531 from pa0gri

I too noticed some of those differences between the g1emm and pa0gri code.  

I suspect that you can put in a carriage return (and other unusual
characters) by using the C representation for it in strings.  So a newline
would probably be entered as a "\n" in the string.  I think a carriage
return is "\r".

SMTP does not use MX records by default.  The g1emm code did.  I
discovered this when I noticed a mail backlog on our system.

One problem I've noticed that is common to both g1emm and pa0gri is the way
RSPF handles broadcast addresses.  Our stations here will try to ping the
broadcast IP address (in this case 44.14.1.255) over and over again. 
Eventually it gives up and marks the entry as 'bad' in the rspf tables, but 
it doesn't drop the arp entry thank goodness!  Anyone know of a way to
prevent the pinging of a broadcast address by RSPF?  It would sure cut
down the amount of unnecessary packets.


Antonio Querubin  
tony@mpg.phys.hawaii.edu / ah6bw@uhm.ampr.org / querubin@uhunix.bitnet


----