[Hamlib-developer] [Fwd: Re: An alternative to the hamlib/xmlrpc-c++ modificatlion]

[Nate B. <n0...@n0...>]

----- Forwarded message from w1hkj <w1...@gm...> -----

Date: Sat, 22 Aug 2026 08:51:18 -0500
From: w1hkj <w1...@gm...>
To: "Joseph A. Counsil" <jos...@gm...>,  Nate Bargmann
 <n0...@n0...>
Subject: Re: An alternative to the hamlib/xmlrpc-c++ modificatlion

You found another packaging mistake. The previous file looked like a patch,
but its @@ hunk headers were missing line ranges, so patch quite correctly
treated it as garbage.

I regenerated it as a real unified diff and verified both:

patch --dry-run -p1   PASS
patch -p1             PASS

against the 4.7.2 flrig.c, and I also verified that the patched result is
byte-for-byte identical to the supplied replacement file.

Download the corrected legacy hardening v2 kit

From the Hamlib 4.7.2 source root, use:

patch --dry-run -p1 < 0001-flrig-legacy-http-framing-hardening-v2.patch

and if that is clean:

patch -p1 < 0001-flrig-legacy-http-framing-hardening-v2.patch

The archive also contains a complete replacement flrig.c in case you prefer
that route.

One additional improvement came from rechecking Hamlib 4.7.2's I/O
implementation: read_block() does return the actual number of bytes read,
so using it to consume exactly the HTTP Content-Length body is consistent
with the Hamlib API.

This one is ready for the build/test step.

TRY AGAIN.  SRI

David

On Sat, Aug 22, 2026 at 8:36 AM w1hkj <w1...@gm...> wrote:

> I directed ChatGPT to create an alternative to the proposed fix for the
> latency issue with JS8Call.
>
> "*Yes. I think it is worth having a credible legacy-preserving
> alternative ready for exactly that reason.*
>
> *I reviewed the 4.7.2 legacy path again, and there are three weaknesses
> that stand out. First, read_transaction() reads the HTTP response
> line-by-line and decides the response is complete when it happens to
> encounter </methodResponse>; second, write_transaction() unconditionally
> calls rig_flush() on the persistent network socket before each request; and
> third, flrig_transaction() explicitly ignores the return value from
> read_transaction() and continues parsing anyway.*
>
> *That is a fragile combination for a persistent TCP connection. Hamlib's
> lower-level read_string() is itself timeout- and packet-arrival-sensitive,
> and the source even contains a special FLRig-specific experiment for
> </methodResponse>, suggesting response framing had already been recognized
> as unusual.*
>
> *I prepared an experimental legacy hardening patch that keeps the existing
> socket/XML implementation rather than replacing it:*
>
> *Download the Hamlib 4.7.2 legacy hardening experiment*
>
> *The proposed change does four main things:*
>
>    -
>
>    *reads the HTTP headers and uses Content-Length to consume exactly one
>    complete XML-RPC body;*
>    -
>
>    *removes the unconditional rig_flush() before every request, because
>    once responses are consumed precisely, that flush is unnecessary and can
>    race late-arriving bytes;*
>    -
>
>    *propagates read_transaction() timeout/I/O/protocol errors instead of
>    ignoring them;*
>    -
>
>    *does not automatically retransmit a failed RPC, because a setter such
>    as PTT may already have executed.*
>
> *The basic model becomes:*
>
> *write request
>      ↓
> read HTTP status + headers
>      ↓
> parse Content-Length
>      ↓
> read exactly N body bytes
>      ↓
> validate XML-RPC terminator
>      ↓
> parse result*
>
> *rather than:*
>
> *flush socket
> write request
> read line
> read line
> read line
> ...
> hope </methodResponse> appears
> ignore read error*
>
> *I would be careful how we present this to Nate: this is a reasoned
> repair, not yet a proven fix. The xmlrpc-c++/Curl implementation has the
> real FT-817 validation. This legacy patch needs the same Joe
> stress/recovery test before we can claim equivalence.*
>
> *If it passes, however, the committee would have a very attractive choice:
> retain Michael Black's original architecture, but harden its HTTP framing
> and error handling; or use the already validated xmlrpc-c++ transport as
> the preferred path. That would make the upstream discussion much less
> binary."*
>
> Joe and I need to test this independently before it is ready as an
> alternate path for the maintainer-list's consideration.
>
> The patch is attached.  Joe, please apply to a fresh hamlib-4.7.2, and use
> the JS8Call-improved / instrumented executable to discover any timing
> issues.
>
> 73, David
>
>



----- End forwarded message -----

-- 
"The optimist proclaims that we live in the best of all
possible worlds.  The pessimist fears this is true."
Web: https://www.n0nb.us
Projects: https://github.com/N0NB
GPG fingerprint: 82D6 4F6B 0E67 CD41 F689 BBA6 FB2C 5130 D55A 8819