[nos-bbs] winlink express lzhuf complications ? and VARA update
M Langelaar
maiko at pcsinternet.ca
Wed Jun 2 00:27:59 EDT 2021
I am baffled ... trying to forward between JNOS and Winlink Express.
Any lzhuf (recv_yapp) that I've ever seen is always something like this :
soh [len] subject stuff
stx [len] message data
eot [chksum]
using rawcap and watching two winlink express going at each other,
I am seeing NO eot [chksum] (not as a separate packet anyways).
It 'seems' to be included in the message data, so if I didn't know any
better the stx [len] is BOTH message data and EOT [chksum], which
to my understanding is wrong. Basically the STX len value should NOT
include the eot [chksum] ... OR it simply does not send the EOT [chksum],
but I think I see it at the end.
To make matters worse, it would 'seem' that if I do work arounds to catch
the EOT [chskum], the message decoded is gibberish after the from and
date message headers, meaning I wonder if the lzhuf table is 'different'.
That complicates things, and here I've been fighting with VARA trying
to get JNOS to forward to Winlink Express the past month. The VARA
access mode is working, I'm convinced of that now. The flow is very
nice, JNOS to JNOS might actually work now.
I know this is a bit technical, but if anyone in the know can comment
or has their own observations, I would be interested in hearing what you
have to say. Or I am simply blind or not seeing something that could be
obvious, the data traces don't lie, so I'm kinda stumped here.
Rats !
Maiko / VE4KLM
More information about the nos-bbs
mailing list