🚀 go-pugleaf

From: Anders.Klemets@cs.cmu.edu
Date: Thu, 6 Jun 91 22:33:31 -0400 (EDT)
Subject: Re: nos 0531 from pa0gri

After seeing you autoexec.net file I now I understand what is going on.
RSPF will not try to ping a host just because it has a 32 bit entry in
the routing table, as I incorrectly said before, since one may want to
have manual routing entries for stations that are on the air only
occasionally.

However, when RSPF receives an RRH packet, or when a new entry is added
to the ARP table, or an ARP request is received, it will try to ping
that host to see if the link is bidirectional. The reason why RSPF tries
to ping a host that gets a manual ARP table entry is because RRHs are
not likely to get through from such a station. (If ARP requests don't
get through - which forces you to use a manual ARP table entry - then
RRHs won't get through either.)

The reason for your problem is your manual arp entry
> arp add 44.14.1.255 ax25 qst

Although it is not wrong, it unnecessary and confuses RSPF. It cannot
know that there is no host with the IP address 44.14.1.255. My RSPF
files included a two line modification to the function ax_send() that
made an explicit arp entry for the broadcast address unnecessary. I
don't think that the corresponding change made into enet_send() however.
So I suspect that there is currently an inconsistency between the AX.25
and Ethernet output routines. Until someone verifies and fixes this, it
seems like you would really need the statement
> arp add 128.171.41.255 ethernet ff:ff:ff:ff:ff:ff

if you were running some application that sends broadcast packets on the
Ethernet (e.g. RIP.)

A side note: I see that you are using the "ip address" command two times
in the autoexec.net file. There is nothing completely wrong with this,
but it could be hazardous, especially if you were to add any other
statements between the to "ip address" commands. I would recommend you
to set "ip address" only once and then use "ifconfig ipaddress" to set
the IP address of the ethernet interface.

Anders


----
From: Antonio Querubin <tony@mpg.phys.hawaii.edu>
Date: Thu, 6 Jun 91 19:16:45 HST
Subject: mbox gateway problem

Anyone noticed the following problem with the mbox gateway function and is 
there a workaround?

When I use the gateway command directly from the console, everything works
fine.  However, when I telnet into the system from a remote host and then use
the gateway feature, NOS will 'buffer' the output going back to me so that I 
don't see the responses coming from the station that I am connected to until
the 'buffer' has filled OR I disconnect.  It's as if I have to anticipate the
responses from the other station and act accordingly and eventually I see the
output.  I did not notice this problem with G1EMM but I do notice it with
PA0GRI.  

Any thoughts as to what's going on here?

Tony
AH6BW


----
From: Antonio Querubin <tony@mpg.phys.hawaii.edu>
Date: Thu, 6 Jun 91 19:36:32 HST
Subject: another problem with nos_0531

Is it my imagination or is the latest version of NOS failing to close 
sessions properly?  If I telnet into the mailbox and run finger several
times, it will leave several open finger sessions, even though each session 
says 'disconnected' at the end.  Same thing happens when I FTP in or Telnet
into the system.  Usually the tcp status command will show all these sessions
in the closing, time wait, or SYN sent mode - but they don't
disappear.  Eventually the number of open sockets exceeds the limit (40?)
and NOS hangs.

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


----