export configuration

  • 1
  • Question
  • Updated 2 years ago
Recently I did a tcpdump on data between radio and computer. I was kind of surprised to see the communications in plaintext ASCII. Odd to me that computer-to-computer communications still uses ASCII.

But what really has me confused is... I did an export of my profiles. The file it exported is a hidden .zip file. Renamed the file to *.zip and opened to find three files within. 

Within the zip I see a file called flex_payload. Encrypted. Not just binary (bad enough) but if I understand correctly, the "Salted" header indicates maybe an openssl encrypted file.

Now why would a file be encrypted so that I cannot view it yet be sent to or from the radio as plain text? Is it to hide the configuration from the user? I think it would have been interesting to review how the profiles are actually stored and what data is stored with it. I've been having all sorts of odd behavior with profiles and had some hope that reviewing a config file might help me understand.

Kevin - K4VD
Photo of Kevin K4VD, Elroy

Kevin K4VD, Elroy

  • 775 Posts
  • 171 Reply Likes

Posted 2 years ago

  • 1
Photo of Walt - KZ1F

Walt - KZ1F

  • 3040 Posts
  • 642 Reply Likes
To your first question on the plan text. If you were to connect to the radio with telnet you could issue commands in English to the radio that it would understand. For a tcp server side app, the lowest common denominator is ascii text or ebcdic if you go back that far. To be a binary pattern there would be big-endian vs little-endian issues plus where TCP is a streaming protocol text makes sense over binary. On your second question, I would guess they want the contents of profiles to be opaque. In that way nobody is going to write code premised on what the layout was in any given release. This guarantees to the author maximum flexibility going forward.

Now, having said all that, I was not present when the designers of SSDR were doing initial design but, as I have a career designing distributed systems, that represents why I would make those same decisions.
Photo of Neal - K3NC

Neal - K3NC, Elmer

  • 427 Posts
  • 128 Reply Likes
In reality we have benefited from this since we can see how SmartSDR configures the radio so when we write our own programs we can duplicate the commands and actions. Its a great debugging aid when things go bonkers.
Photo of Kevin K4VD, Elroy

Kevin K4VD, Elroy

  • 775 Posts
  • 171 Reply Likes
I believe my point has been missed. OK fine on the ASCII transfers but c'mon. This is not the 80s. Past careers don't translate directly to today's computers and communications. I am from the age of the Sperry Univac 9300, DEC PDP-11/45, 11/70 and VAX. I understand ASCII can be considered the lowest common denominator - in the 70s and 80s.

Still, I don't really care that the transfer is in plain text and that Flex couldn't figure out how to transfer binary data. I was using the point to contrast the openness of the data transfer with the encryption on the local file.

My surprise is, the encrypted configuration file. I'm assuming this file very closely related to the information being communicated between SmartSDR and radio. Why is it encrypted and unviewable to human readers but anyone with Wireshark can pull the essentials out.

It seems to me that if I'm trying to troubleshoot or understand profiles beyond what is in the book these files would have been very useful.

So, in reality, being able to use wireshark to view the communications is good but take that a step further and don't encrypt the configuration file. Why? To prevent other people from writing code based on what they learn? Copyright it.

Kevin - K4VD
Photo of Walt - KZ1F

Walt - KZ1F

  • 3040 Posts
  • 642 Reply Likes
Kevin, that is completely unfair. You are looking at the command / response flow to/from the radio (black box). All the data IS binary on a UDP port.

The 'openness' of the the command structure facilitates cross architecture and an open 'api' to control the radio. You might not realize this but the software actually running the radio is under Linux in the black box and that chip may well be a different endian-ness than someone running on a Wintel box and chipset.

Copyrighting doesn't prevent anything. It facilitates a legal remedy AFTER the fact.  So really? What is your complaint? They have opaque objects they may well change going forward. The best way to not break users is to not give them anything they could get dependent on. Being from the Sperry Univac world there likely wasn't a lot of consumer products your company wrote. Writing software for consumers is different than writing software for corporations.
Photo of Kevin K4VD, Elroy

Kevin K4VD, Elroy

  • 775 Posts
  • 171 Reply Likes
Unfair? Linux and Microsoft and Unix and other systems can only converse by ascii because they can't come to any other agreement? I can transfer audio and video files between OS's with no concern of the Endianness of the systems involved. I'm sorry Walt. My intention is not to upset you. I think you are telling me what you believe and not necessarily the way it is.

I simply want to know why FRS locks down a file with encryption when the information is being sent in the clear over the network? This is a configuration file, not secret code. Even secretive Microsoft exports its registry in readable human text.

This isn't an attack on FRS and I think FRS needs no defense. It's a question that maybe should not have been posted to the community of product supporters but to product support.

I would like to be able to read the saved configuration so I can fully understand profiles, how they work, what they save and why I'm having issues with it. 
Photo of Walt - KZ1F

Walt - KZ1F

  • 3040 Posts
  • 642 Reply Likes
I am not the least bit upset.
Photo of Eric - KE5DTO

Eric - KE5DTO, Official Rep

  • 661 Posts
  • 203 Reply Likes
Kevin,

As you are aware, the profile interface contains a myriad of parameters.  We could have exposed the profile payload and allowed them to be easily edited, but this takes extra development time due to needing to qualify each and every field submitted.  Instead, we decided to wrap up the contents of the profile in a trusted format and keep it that way.

If our goal had been to have a profile format that was easy for users to manipulate, we might have gone with plain text.  But that's not where we ended up for profiles.  Note that we did end up with something like that for memories where the user IS encouraged to edit the fields as needed.