[nos-bbs] 2.0k status and weird linfbb eol termination stuff

[Michael Fox - N6MEF]

I previously reported this (CRLF vs. just CR from FBB) for incoming (FBB -> JNOS) connections.  See my email on 4/19 with subject "timeouts when incoming command ends with CR only"

It's not exactly harmless.  The behavior I described in the above email was: when JNOS gets a line ending with CR only, JNOS will wait for the LF from FBB (which never comes) and both systems will sit there for about 5 minutes until the session times out.  Maybe that's not exactly "harmful".  But what can happen is that this continues to occur on the next connection so that little to no forwarding gets done.

>From what I recall, FBB doesn't seem to care if JNOS sends CRLF or just CR-only.  I'm not sure if that's right either, since it could have unintended consequences.  

Michael
N6MEF


> -----Original Message-----
> From: nos-bbs [mailto:nos-bbs-bounces at tapr.org] On Behalf Of Maiko
> Langelaar
> Sent: Wednesday, June 1, 2016 10:27 AM
> To: TAPR xNOS Mailing List <nos-bbs at tapr.org>
> Subject: [nos-bbs] 2.0k status and wierd linfbb eol termination stuff
> 
> 
> Hi everyone, just wanted to let you know that I have been wanting to
> release the original bleeding source with additions for the last few
> weeks, but am caught up on one problem I've run into regarding
> forwarding with linfbb (well, Bob's ve3tok version anyways).
> 
> I have confirmed that linfbb is not being consistent with sending EOL
> sequences during forwarding of proposals. For instance I might get a
> few proposals coming in terminated with 0x0d 0x0a, then I send a few
> proposals of my own back to linfbb, then I get another batch of incoming
> proposals, but they turn out to be terminated with just 0x0d. JNOS thinks
> there should be an 0x0a, and gobbles up the byte (which turns out to be
> the start byte of an incoming proposal, and forwarding breaks). It seems
> to be harmless, but it's disruptive.
> 
> I'm trying to find a fix for this (on my end), and I think I can make it
> work, so far so good, I have some code in place that confirms the issue,
> just have to make it so that the forwarding doesn't break.
> 
> Also, what's keeping me from releasing 2.0k is that outbound forwarding
> to a BPQ right now just results in a connection and that's it. Trying to
> figure that out as well. Incoming BPQ is working flawlessly (with Bob's
> test system).
> 
> Maiko
> _______________________________________________
> nos-bbs mailing list
> nos-bbs at tapr.org
> http://www.tapr.org/mailman/listinfo/nos-bbs