[nos-bbs] BUG data detail - connect ptcpro call - here at k8rra today

[George (Skip) VerDuin]

I confirm a bug in 2.0d1 and provided detail for all?
This command is documented as NOT-OK in a Maiko posting on making HF
connects.
The "should be" conditions are documented by myself in "JNOS Owners
Manual" along with the bug note.

I issued a "c ptcpro ve4klm" from administrator status display.
The result I expected was "NO connect" because power is set to < 10
watts & propagation is bad...

The display immediately switched into session #1 blank with "telnet"
shown as the session command.
The xcvr immediately did the 50-second dance with the connect frame for
pactor (I believe / did not listen).
This seems normal expecting to enter "chat mode" after connecting to
ve4klm...

After ? minutes the status line #3 returned to "0 command:", and line #1
"Ses: 1 >blinking<"...
But the session #1 screen (lines 4 thru 24) remained empty, and did nor
return to session #0.
The session display never provided output nor permits a termination.

The "ctl-]" toggles nicely from session #1 to session #0, 
The "F10" toggles nicely from session #1 to session #0, 
The "+++<CR>" does not respond from session #1,
The "<cr>" from session #0 toggles nicely to session #1 as the current
session,
The "...> look 1" from session #0 responds 'User socket error!' that is
no surprise to me...
The "session" cmd from session #0 displays the session #1 and shows it
in "limbo".
all like they should?

While session #1 blinks and behaves badly, I tried "c vhf n8yjt via pix"
using a std KISS TNC.
This action progressed normally and terminated after not reaching the
target station.
The session #2 terminated normally and jnos returned to sesion #1
blinking.

SO - my interpretation is:
JNOS has data to pass to session #1 but OOPS session #1 has been aborted
and can not receive the data.
JNOS did not totally abort session #1 because it continues to allow
toggles back and forth (etc).
Other sessions can be opened, used, and terminated, without harm from
the buggy session.

I've attached a log extract to demonstrate JNOS process at that time.
I find no work-around used to "kill" session #1 and get rid of the
body...
Therefore I will restart jnos soon to clear the bug and go on...

Please note I authored a similar report last Wed 3/1 from the BBS
command & Maiko responded that the code is still experimental for this
function.  He also provided a work-around for mail transfer.
Please also do NOT use this note to expedite a bug fix - it will be
repaired in it's own time (just like good wine).

73
de Skip k8rra k


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.tapr.org/pipermail/nos-bbs_lists.tapr.org/attachments/20060304/16082be2/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 03Mar06
Type: application/octet-stream
Size: 855 bytes
Desc: not available
URL: <http://lists.tapr.org/pipermail/nos-bbs_lists.tapr.org/attachments/20060304/16082be2/attachment.obj>