Re: [Hamlib-developer] input buffer cleanup

[Dave B <g8k...@go...>]

Hi.

Devils Advocate mode engaged....

Re Mikes comment "rigctld was never designed for random input." That may 
be the case, but...

As the TCP/Telnet port is for other applications to use for controlling 
equipment (radio, rotator, power amp, whatever) via hamlib.  (If not, 
then what was it for?)  And as such the hamlib authors have not a clue 
what might use it, then any inputs to rigctld (in particular) should at 
least be checked for "basic sanity".

That is now common if not required behavior for much 
commercial/professional software that "listens" to a TCP or other 
protocol port.

As the rigctld command "language" is documented (mostly) it should be 
possible to check any incoming traffic for valid commands and any 
parameters/values being "in range" of what might be expected, i.e. Check 
before use.

If not, the choices are:
(a) Ignore it and do nothing, not even return an error response. I.e. 
"Fail Quiet".  (The default.)
(b) Ignore it but send a response flagging an error.  (Set by a command 
line 'switch' when invoking rigctld.)

The latter for debug (of third party applications that want to use rigctld.)

What should not happen, is to attempt to process what was given and do 
something with it that is potentially "out of bounds" for whatever 
radio/rotator or whatever hardware hamlib and rigctld are setup to 
control, and or "croak" and go into a black void of internal chaos and 
become unresponsive, or worse go and meddle with something unrelated.

I also agree, that it would be great, for there be an input buffer 
clear/purge command byte or value.  Perhaps also enabled by a command 
line switch when launching rigctld or rigctl.   Such a facility should 
also purge any backed up response values or strings.  (Such a facility 
being an addition to the current situation, so as not to break any 
backward comparability.)

That would be a great help to users developing their own software that 
would use hamlib/rigctld at the very least.  (TCP ports are very easy to 
use from most programming languages, and great for remote 
installations.  Subject to being secure, via a VPN for example.)

"Ignore and Fail Quiet", is these these days not an uncommon feature for 
any software that opens and listens on a TCP port, even on Localhost 
(127.0.0.1, and whatever the IPV6 address is.) Especially anything that 
can be reached from any LAN (or WAN.)

Not all Linux machines have an active firewall enabled.  Heck, it's not 
even the default when you do a fresh install of many distro's. (But 
top's the list of many of the "things to do after you install Linux" 
websites.)

Anyway.  A belated Happy New Year to All.
And 73.

Dave G8KBV (or G0WBX)
DA mode now disengaged!)

Currently, the only use I make of Hamlib, is what came with JS8Call, and 
I configure that to use Flrig as "the" radio.
I have also used it with GPredict to great effect in the past with the 
venerable FT-736.

Even using a Python script as an intermediary, before an issue with 
Hamlib was corrected.
(I must check sometime, if that fix made it's way into V4.6  I think it 
did, but will check as sometime I plan to resurrect GPredict here.)

 >><<


On 06/01/2025 07:40, Sakari Nylund wrote:
> Yes, but...
>
> Sending just "\n" does not give any result. You can send them as many 
> as you like. Nothing happens.
>
> Sending "something" with newline added clears the situation but 
> sometimes it takes one send. Sometimes you have to send several lines 
> to clear the situation.
>
> It would be easy if something, like Ctrl+C (0x03), would halt the 
> pending command input.
>
> Usually that is not problem.  But I have seen this happen sometimes 
> while debug the traffic. I understand this is not problem when using 
> library functions, but when client program access rigctld via text 
> based telnet connection things are different.
>

-- 
Created on and sent from a Unix like PC running and using open source software: