BPQITEMS.TXT  Revised 27-Jun-92  (Item 19 added)
------------------------------------------------

This file started as PROBLEMS.GO in the DX-BBS BPQINFO.ZIP file.
It will document items which are identified that a SYSOP feels should
be addressed.  The author of each item will be identified.  The source
or any response will also be identified.  24-Jun-92 and after items will
also be dated.

The item numbers will not be changed.  This will make it easier for 
comments to be related to items.  Just identify the item by number.  To
manage the size of this file, closed items will at some time in the 
future be moved to a closed items file.

==============================================================================


1. BPQ needs to tell PacketCluster which input port is receiving the 
connect so that PacketCluster can determine if user connects are 
permissible on that frequency.  If PC/TNC can do it, so can 
BPQ/DEDHOST. (W6GO item)

(G8BPQ response)
   Would need significant changes to the way DEDHOST works,  and would  then
   only  be  relevant for L2 connects.   The switch was written to help with
   packet networking.  If in can be used in other ways, then thats fine, but
   I am not going to modify  it  for  use  only as a L2 access system.   I'm
   afraid the only alternative is to use the DRSI drivers.
(W6GO reply)
   Well, VALIDCALLS would really provide the functionality, but only
   if they could be changed on an ad-hoc basis.  If VALIDCALLS are used
   they should be changeable via the SYSOP function.  Presently, to
   allow a new node to connect on a non-user frequency, we add the node
   call to the NODE table with a SET/NODE command.  To change BPQ's
   VALIDCALLS list now, you must reboot the computer.  This is NOT a
   satisfactory condition, as potentially 60 connections or so must be
   dumped to update the table.  Is it feasible to provide that capability?
(G8BPQ 24-Jun-92)
   I hadn't foreseen a requirement to change these frequently, and the way
   they are currently  stored  makes  changing  them  difficult.  I'll look
   into providing a more flexible system.
(W6GO 27-Jun-92)
   How about an indirect file lookup? If a full path of a file is put in
   VALIDCALLS (Like VALIDCALLS=C:\PACKCLUS\BPQ\VALID1.TXT) then go and read
   that file?  Perhaps one callsign per line.  If the file is specified but
   is missing, then allow any connect callsign.  In this way you could 
   restrict radio ports on an ad-hoc basis, even those who are normally not
   restricted.  Leave the present functionality also intact for ports that
   aren't subject to change.
 

2. The ESCi command in PC/TNC allows the callsign to be changed for 
the next outgoing connect.  This is used for troubleshooting (by 
using a totally different callsign) and also to get around jammers 
who trash a Network Node by setting up a TNC with the callsign of a 
connecting node.  By using different SSIDs to connect on subsequent 
connect scripts, you can get around such a jammer.  How can you get 
the same functionality with G8BPQ?  It appears that all outgoing 
connects are forced to come from the same exact callsign-ssid. (W6GO item)

(G8BPQ response)
   ESC/I (Change callsign) function is provided by *** LINKED TO feature.
(W6GO reply)
   It sure is!  And, it works as advertised.  Thanks, John.
[CLOSED ITEM]


3. Need way to query BPQ about a particular connect or list of 
connects, to find out what ports they are on, their connect status 
(retries, packets outstanding, etc).  (W6GO item)

(G8BPQ response)
   Need to query BPQ about connects....    Dont understand.
(W6GO reply)
   PacketCluster now can query PC/TNC (WA8DED) and get a response
   which is displayed to the SYSOP telling him what port a specific
   stream's connect is actually on, plus the status of the connect
   and the number of retries.  This display gives the SYSOP the
   opportunity to see what radio the connect is coming in on, and
   to monitor the quality of that connect.  PacketCluster updates
   this display on an almost real-time basis, so it is very useful
   in resolving connect problems with specific stations.

   It appears that the HOST mode would provide this info if properly
   written.  Perhaps a specific replacement for the DEDHOST should
   be written which would support all 64 connects from PacketCluster
   and provide these additional user evaluation features.
(G8BPQ 24-Jun-92)
   You can find which port a user is on from the switch (USERS,LINKS
   commands),and check link quality to other nodes from ROUTES.  For
   a level 2 connect the port information is available via the host
   interface, but it isn't easy to map that onto the DEDHOST interface.
   The best answer would be for the PacketCluster software to talk
   directly to the BPQ Host interface, but that is obviously a fair
   bit of work for Dick.


4. SH/TNC_STA retries is always 0 because it is just talking to the 
DEDHOST. BPQ should report retries to PacketCluster just like PC/TNC 
did.  (W6GO item)

(G8BPQ response)
   SH/TNC_STA shows 0 retries, as there arent any between cluster and
   switch. Same comments as in 1.
(W6GO reply)
   See my comments in 3 above.  I'm not saying G8BPQ specifically 
   should provide these features, just that they are needed. 


5. SH/TNC_CONNECTIONS always reports port 1.   See #1 above: The 
port number should be passed to PacketCluster.  (W6GO item)

(G8BPQ response)
   SH/TNC_CONNECTIONS always shows port 1. Same comments apply - there
   is only one port between Cluster and Switch.
(W6GO reply)
   Same reply as 4 above.  Yes, there is only one port between Packet-
   Cluster and the switch, but there are many ports between the switch
   and the connected stations.  It is that port number which is important
   to the PacketCluster SYSOP ("what radio is this 'bloke' coming in on?")


6. The signoff messages don't get to the users.  A user types "B" 
and all looks normal from the SYSOP screen.  The CUL message goes 
out on the SYSOP PacketCluster monitor screen.  However, it isn't 
sent to the user!  Apparently BPQ processes a disconnect in such a 
manner that it cancels outstanding packets.  (W6GO item)

(G8BPQ response)
   Lost signoff  messages.    Should   be  fixed  in 4.05b.   Disconnect was
   discarding queued data if there was insufficient time between  last  send
   and disconnect.
(W6GO reply)
   Yes!  Thank you, it works perfectly in 4.05b.  Much appreciated.


7. There needs to be a way to access the SYSOPH function from 
PacketCluster without using the ATTACH command.  There doesn't seem 
to be a way to establish a connect to the SYSOPH function using a 
connect script and then turn control over to the SYSOP keyboard.    
Instead, SYSOP must identify a clear stream, type ATTACH (stream#) 
(Enter) (ESC) c (space) (Enter) *SYS (Enter) to access the 
facility.  It should be possible to automate this.  (W6GO item)

(G8BPQ response)
   Automated  access to SYSOPH.  I cant see how I can do anything about this
   - a change  to the cluster code is needed.  Or run DESQview, with cluster
   and SYSOPH in different windows.
(W6GO reply)
   You are right!  This is one for AK1A.


8. There is no way to reserve host streams for outgoing connects.  
If enough incoming connects occur to fill up all of the host port 
streams, a user must be disconnected to free a stream before an 
outgoing connect (like to another node) may be established. (W6GO item)

(G8BPQ response)
   Reserving Streams for outgoing  connects.   DEDHOST  only  activates  the
   number  of  ports  specified in  param 1, but will allow you to use up to
   32.   So  if you set DEDHOST param  1  to less than the number of streams
   defined  in  SYSOP.DAT,  the additional ones will be reserved.   The only
   snag is that the autotimer function wont be enabled on the  extra  ports.
   This won't  matter  if  you  have  disabled  the  node  timeout,   or are
   connecting to another cluster node running BPQ.   I'll change DEDHOST  to
   allow the number of incoming comments to be specified.
(W6GO reply)
   I think I understand.  If DEDHOST is set for 30 streams and Packet-
   Cluster is set for 32, then as I understand you, the DEDHOST will 
   accept PacketCluster connects to streams 32 and 31 but would only 
   allow the switch to connect to streams 1-30.  This may well take care
   of the potential problem.  Needs experimentation!  Thanks for the 
   clarification.


9. If I go to DOS, then the Node will only accept three packets from a
station before it starts sending RNR frames.  I don't know how many a 
PC/TNC equipped node would accept, but I suspect it is a lot more than 
three.  It is like BPQ goes to sleep.  (W6GO item)

(G8BPQ response)
   This is about the node sending RNRs when cluster shells to DOS.
   The system will send RNRs when more than MAXFRAME packets are queued  on
   the  receive  buffers.    This is done to protect the buffer pool in the
   switch. There seems little point in  accepting  more input from the user
   if the cluster software isn't running to process them. 
(W6GO reply)
   Well, just because we are used to PC/TNC accepting gobs of packets that
   it can't handle because we are out in DOS doesn't mean that is "right".
   I think G8BPQ's philosophy is a valid one, and we should see if it 
   causes a problem before we do anything other than call attention to the
   difference.
(W6GO 27-Jun-92)
   See item 12.  This could be a problem if RNRs are hard-coded to force
   disconnects.

 
10. VALIDCALLS doesn't work.  I have a list of VALIDCALLS for my DRSI ports
3,4,5,and 6.  Ports 1 and 2 do not have VALIDCALLS lists.  I can connect to
ANY port with ANY callsign, whether in the VALIDCALLS list or not.  The
SYSOP feature reports the VALIDCALLS list correctly, as specified in BPQCFG
for each port.  I do not know for sure if this worked prior to 4.05b, but I
certainly know it does not work in 4.05b! (W6GO item)
(G8BPQ 24-Jun-92)
   I will check this out - I havent deliberately changed anything in this 
   area!
(W6GO reply 27-Jun-92)
   I am using two lines of VALIDCALLS.  The exact syntax from my BPQCFG.TXT
   file is as follows:
     VALIDCALLS=K6LLK,N6IXX,WB2CHO,WA6JCD,KI3V,W6OAT,N6ST,KJ6NN,W6OTC,WA7G,
     VALIDCALLS=K6HHD,WA6RGA,WA6ALZ,AA7EN,K6AYA,K6PBT
   It doesn't work!  Anyone can connect.


11. Stream 32 not used.  G8BPQ in a readme file recommends that stream 32
in the DEDHOST not be used by PacketCluster.  Has that been corrected in 
4.05b?  What was the symptom of the failure so that we can be aware of what
to look for should we enable stream 32? (W6GO item)
(G8BPQ 24-Jun-92)
   The rule is not that you can't use 32,  but you may have problems if you
   use BPQ stream 1 with DEDHOST.  I still haven't found why.  The symptom
   is a lot of DEDHOST error messages reported by the cluster.  The reason I
   recommended using only 31 is that the default setup for the TNC2 
   interface (BPQHTNC2) start at port 33, so if you are using any 
   applications that need TNC2 support, DEDHOST and hence the cluster are
   limited to streams 2-32.
(W6GO reply 27-Jun-92)
   Boy am I confused now!  I thought TNC2 support had been removed from the
   G8BPQ code.  As we don't need TNC2 support, the point is moot.  Does this
   mean that we can change the second DEDHOST to 32 streams with no problems?


12. RNR disconnect.  Kantronics has implemented a RNR feature in their 
TNCs which should be available in BPQ.  Each radio port needs either a
RNR frame counter or a timer which determines how long a stream has been
sending RNR frames.  The parm could be RN time (argument) or RN frames
(argument).  After reaching that limit, the stream would be disconnected.
Default would be 0 (disabled).  This is used to counter the user who 
connects and then turns off his terminal, leaving his TNC connected.  
When his buffer fills, he begins sending RNR frames and uses buffers at
the node.  This parameter would defend the node buffer space against 
such an instance.  (W6GO item)
(G8BPQ 24-Jun-92)
   I've never noticed a need for this, but if Kantronics think it is a
   good idea, I'll put it in.   I can't really see that it needs to be a
   parameter - just make it the standard behaviour.
(W6GO 27-Jun-92)
   I think that some "real" networking situations might want a bit more
   leeway in allowing RNRs to continue (perhaps even forever) than we 
   would.  It is possible that even PacketCluster could require two 
   different settings.  One for the user connects which is very intolerant
   of RNR frames, and another for the "backbone", or node-to-node 
   connections which would be very tolerant because if the other node was
   off in DOS for some reason, it (now) cannot accept packets and will 
   send RNR frames indicating it is busy.  With the WA8DED drivers the 
   nodes could buffer a LOT of data when off-line.  However (see item 9),
   BPQ will not allow such buffering, resulting in RNR frames.  Under this
   condition we would not want an automatic disconnect!  I think it should
   be a parameter, set by radio port.


13. FRACK timer.  The beta version of PC/TNC and the latest version of
Net/Rom starts the FRACK timer from the time that PTT is released, 
rather than when the transmission is finished to a stream.  In this 
way, when a broadcast is taking place to a large number of users, 
keeping the transmitter keyed for transmissions to 20 users or so, the
FRACK timer will not expire on the first few streams before all of the
transmissions are completed.  G8BPQ APPEARS (but I'm not entirely sure)
to start the FRACK timer at the end of the transmission to a particular
stream when that transmission is completed.  Granted this is an 
inefficient use of AX.25, but it IS what it IS and WA8DED has proven
this new scheme works better for PacketCluster.  Can BPQ be changed also?  
(W6GO item)
(G8BPQ 24-Jun-92)
   Yes, it starts when the frame has been sent.  It would be fairly simple
   (I think!) to wait till all frames are sent.  It isnt really a problem
   over here, as our users tend to be spread over a number of ports, and 
   most are via other nodes.
(W6GO 27-Jun-92)
   Several of us have a "beta" WA8DED driver which starts FRACK when the 
   transmitter goes off the air.  This has proven beneficial, especially
   when there are lots (32!) of connects to the node.  John, your
   attention to this item would be much appreciated.


14. Need ability to display G8BPQ displays into a window and also into
a file for review.  STATS, LINKS, USERS, etc.  As it is now, often the
displays occupy more than a full screen, making it difficult to use the
displays.  Also, there is no way to redirect the displays into a file(s)
for later review.  PacketCluster should provide this functionality 
without interaction with connect activities in the connect queue. 
SH/GSTATS, SH/GLINKS, etc.  (W6GO item)
(G8BPQ 24-Jun-92)
   This would best be done in the cluster software.  Or run DESQview, and
   use something like BPQTERM for interrogating the switch.
(W6GO 27-Jun-92)
   DesqView is out for some of us, especially where the machine is also
   a Lantastic Server.  Hopefully Dick will be able to accomodate us.


15. If an incoming connect is via a Net/Rom node, it is not clear exactly 
which port the connection is actually on.  For example:

     Incoming connect from K6LLK on TNC/2 Stream 16 via DEDHOST #2.
     TNC/2 Stream 16 is mapped to Host stream 17.
        BPQ Users display says:
            Circuit (N6IXX-2 K6LLK) <--> Host17(W6GO)
        BPQ Links display says:
            N6IXX-3 W6GO S=5 P=4 T=3 V=2

This connect really comes in on the port connected to N6IXX-3, just as
it says.  However, it could just as easily have come in on Port 3, which 
could be connected to N6IXX-2.  There should be a non-ambiguous way to
associate the DEDHOST streams to specific radio ports, and at least in 
this case, I don't know a way to conclusively identify the incoming radio
port without a separate monitor receiver and TNC.  (W6GO item)
(G8BPQ 24-Jun-92) 
   Identifying ports on L4 connects:  There is no fixed relationship, as 
   the Level 3 routing function can redirect stuff form one port to 
   another during a connect, due to changing condtions or equipment failure.
   You can find which port you are currently sending stuff on from the 
   NODES and ROUTES displays,  but there is no way, short of monitoring,
   of knowing which port incomming stuff is on.   It is by no means unusual
   for stuff in opposite directions to be on different ports.
(W6GO 27-Jun-92)
   Wow!  I didn't know that.  Is there anyone out there with a text or
   file that will explain this network gobbledegook to those of us who
   aren't phd's?


16. A repeat of an earlier determined problem.  If you attempt outgoing
connects on the highest number streams of TNC/2 it will crash your 
computer.  I recently verified this is still present with BPQ405b.
Moral of the story.....  Only make outgoing connects on TNC1, and that
with the BPQHOSTS loaded in reverse order as detailed in the W6GO 
BPQCFG files.  (W6GO Item 23-Jun-92)


17. This is a response by G8BPQ to an issue I raised where links were
staying up "forever" to users who disconnected, forcing them to use a
different SSID to reconnect.  I then recommended to everyone that the 
T3 timer never be set to 0, so the links would be tested occasionally.
(W6GO item)
(G8BPQ 24-Jun-92)
   I don't recommend setting T3=0, but it shoudln't have that effect.  I'll
   investigate.


18. This issue was raised in a K1XX message on DX-BBS.  The CRC errors
reported by the BPQ STATS display seemed very high to Charlie, and several
others of us agreed. (K1XX Item)
(G8BPQ 24-Jun-92)
   CRC errors are not a reliable indication of link performance.  A shared
   channel will always give a significant number,  due to collisions.   
   Running SOFTDCD with open squelch will cause large numbers of CRC errors
   to be counted, even when there is no traffic.  The best indication of
   performance is the ratio of L2 frames sent to L2 timeouts (for L2 users),
   and the %retry in the ROUTES * display for node-node links.
(G3VMW 27-Jun-92)
   CRC 'errors' are a bit of a red herring really! Open squelch tends to
   distort the CRC error counter and DRSI PC*PA boards with open squelch
   will tend to give a false display.  John is working on this right now,
   and he has a fix for the Data Engine version.  What is much more
   pertinent is the percentage retries given by the R R command, or R R 
   (Port Number) if you prefer.  A good radio link should have a retry rate
   somewhat less than 10%, and preferably below 5%.  This is a fair measure
   of how well a link is performing and for the time being at least, I 
   suggest that the CRC errors are ignored.

19. W6GO Item, 7/26/92.  
   One bit of functionality which is missing in the BPQ code is the 
ability to refuse connects via AX.25 digipeaters.  This is a 
capability which is provided in the SET/TNC line in PacketCluster 
that is not implemented in the BPQ code or in DEDHOST, as far as I 
can determine.
   NODIGI is a feature which has helped to force users to improve their
connects rather than relying on someone else to turn on AX.25 digipeat,
thus adding even more clutter to our busy user channels.


FROM W6GO:
Note to all... This is JUST a start on this file.  PLEASE... Your inputs.
Remember, if you want a programmer to make a change, you need to give 
full information, including (perhaps) the syntax or command you would
use as SYSOP to implement whatever the change might be.  You also must
explain why, to convince the programmer the change is worthwhile......
