On 2014-09-10 13:36, Gustavo Conrad wrote:
> One possible way to mitigate the dtmf issue is to have a separate
> receiver, tuned to a different frequency (maybe different band), just to
> receive dtmf commands. Of course the system won't be able to be
> controlled by all the users but the owner/operator still will be able to
> do some tasks via RF.
That's an interesting idea and pretty cheap to implement if using an
RTL2832U DVB-T dongle as a receiver. Of course the computer need to be
powerful enough to run the SDR stuff though.
> Another approach is to implement an authentication scheme in the
> software, for example: one time passwords: prefix the command with a
> dtmf sequence thas is valid for one use, challenge-response: the system
> sends via voice some sequence that you may use to look on a table for a
> password, also the method that many packet radio TNCs implements for
> remote access (you set a master phrase on the system, the system sends a
> number sequence and you return the characters that matches the numbers
> positions in the phrase).
Another approach is to use a timed one time password (TOTP) app on a
smartphone, like FreeOTP. On the server side it's very easy to verify a
password using the oathtool utility for example:
oathtool --totp --base32 'HELLOWORLD'
'HELLOWORLD' is the shared secret that has to be present on both the
server and entered in the app. The generated number will be valid for 30
seconds. I guess it should be easy enough to implement in TCL (or C++)
to open up DTMF command reception for a minute or so after receiving a
73's de SM0SVX / Tobias
> Gustavo - LU8WFY
> On 09/10/2014 07:46 AM, Mischa van Santen wrote:
>> Regarding the first point (DTMF limitation):
>> As I feared already from start, some unidentified person(s) have
>> disturbed the repeaters behavior time and time again in the last weeks
>> by sending DTMF commands to the repeater, initiating all kinds of
>> undesired behavior (continuous info messages, active echolink
>> disconnects, random Echolink connects, etc.). This made us decide to
>> disable DTMF fully. Apparently immaturity rises with time, making all
>> nice functions that have been developed unusable. It has turned our
>> repeaters into a basic voice repeater now.
>> Ideas how to overcome this would be welcome. Finding the initiator is
>> impossible (using a handheld device, could be everywhere). Informing
>> the radio authority is not applicable - they won't do anything against
>> it (from experience).
>> Vy. 73,
>> Mischa, PA1OKZ
>> 2014-08-31 23:02 GMT+02:00 Tobias Blomberg <sm0svx@...>:
>>> On 2014-08-04 10:18, Mischa van Santen wrote:
>>> Hello Tobias,
>>> I recently came accross two minor points that would, from my perception,
>>> further improve the user experience of Svxlink:
>>> 1. DTMF limitation:
>>> Unfortunately, some users nowadays appear to make fun out of transmitting
>>> DTMF codes just for the sake of it, having the (in this case) repeater
>>> continuously doing things and creating messages that disturb the regular
>>> communication. I've heard this on several repeaters already, both in NL and
>>> GER. This has caused that we decided to disable DTMF functionallity in our
>>> repeaters PI3UTR and PI2NOS. It is a rather limiting decision at the same
>>> time of course and therefore undesired. It would therefore be useful if, for
>>> example, the amount of DTMF commands would be time limited within a defined
>>> timeframe. For example, limit the number of DTMF commands to three or five
>>> per hour. I know that we introduce a limitation for serious users here as
>>> well, but it's always better then the alternative I suppose.
>>> Yes, we also have some saboteurs but it's not a big problem here though. The
>>> best of course would be to solve the problem by finding the saboteur and let
>>> the authorities deal with it. Not always so easy though. The bad guys seem
>>> to always find new ways to destroy for all others so I wonder if it's really
>>> any use in trying to fight them using technical features. They may even get
>>> more interested in breaking the system.
>>> A cool feature would be transmitter fingerprinting. Look at stuff like
>>> frequency offset, DTMF tone offsets, DTMF tone twist, CTCSS characteristics
>>> etc. But anyway, I'd rather use my time to implement useful features than
>>> trying to fight there idiots.
>>> I saw that Rob probably have a solution already and it should indeed be
>>> possible to implement what you want in TCL.
>>> 2. FX_GAIN_NORMAL delay
>>> When the FX_GAIN is set to LOW due to activity at the repeater and suddenly
>>> the transmission stops, the FX_GAIN turn instantly back to normal again
>>> after (e.g.) squelch close. This causes sort of a "gapless" transition from
>>> the users voice to the repeaters voice. This sounds rather confusing. A
>>> 'delayed back to normal' setting would be helpful here to prevent such
>>> confusion. It just sounds better I suppose.
>>> Agreed. Enter a feature request in the GitHub issue tracker.
>>> 73's de SM0SVX / Tobias
>>> Hope these ideas inspire to consider some extra flexibility....
>>> Vy. 73,
>>> Mischa, PA1OKZ