Discovery method for API developers

  • 1
  • Idea
  • Updated 4 years ago

Hi, so as time allows, I've been playing with the FlexRadio api stuff (both the .net api and the Ethernet api).  It was suggested to me that I could use wireshark to sniff the network to just see what the latest commands are that are sent/received from the radio since the documentation isn't always up to date.

I've used wireshark quite a bit in the past for troubleshooting network problems, but the way it displays data sometimes makes it difficult to read the payload data in network packets.

So, several years back when Powershell was very new, I wrote a packet sniffer script, just because I wanted to see if it could be done without compiled code.  Turns out, it worked.  So I went back to that script to see if that would be useful in this case -- following a conversation to see what the latest commands were for communicating with the 6000 series radios. 

Basically, it made the job a little easier on my part.  I'll probably write a "packet decode" function to format the data received from the radio so that it is more powershell friendly, but maybe this will help some of the devs out there.

The "get-packet.ps1" script can be grabbed from here:  http://poshcode.org/764 and my original blog post about it is here: http://blog.robbiefoust.com/?p=68

And the way to run it is something like this. 

PS C:\Users\Robbie\Documents\scripts> .\get-packet.ps1 | ? { $_.protocol -eq "TCP" -and ($_.source -eq "192.168.1.133" -
or $_.destination -eq "192.168.1.133") } | select source,destination,data | fl
Using IPv4 Address: 192.168.1.149

Press ESC to stop the packet sniffer ...


Source      : 192.168.1.149
Destination : 192.168.1.133
Data        : C7776|ping


Source      : 192.168.1.133
Destination : 192.168.1.149
Data        : R7776|0|


Source      : 192.168.1.149
Destination : 192.168.1.133
Data        :

Source      : 192.168.1.149
Destination : 192.168.1.133
Data        : C7777|ping

Source      : 192.168.1.133
Destination : 192.168.1.149
Data        : V1.1.0.0
              HC3114FDF


Source      : 192.168.1.133
Destination : 192.168.1.149
Data        : M10000001|Client connected from IP 192.168.1.149


Source      : 192.168.1.149
Destination : 192.168.1.133
Data        :

Source      : 192.168.1.133
Destination : 192.168.1.149
Data        : SC3114FDF|radio slices=8 panadapters=8 lineout_gain=60 lineout_mute=0 headphone_gain=50 headphone_mute=0
              remote_on_enabled=0 pll_done=0 freq_error_ppb=-1 cal_freq=15.000


Source      : 192.168.1.133
Destination : 192.168.1.149
Data        : SC3114FDF|interlock timeout=0 acc_txreq_enable=1 rca_txreq_enable=1 acc_txreq_polarity=0
              rca_txreq_polarity=0 tx1_enabled=1 tx1_delay=0 tx2_enabled=1 tx2_delay=0 tx3_enabled=1 tx3_delay=0
              acc_tx_enabled=1 acc_tx_delay=0 tx_delay=0


Source      : 192.168.1.149
Destination : 192.168.1.133
Data        : C1|client program SmartSDR-Win


Source      : 192.168.1.149
Destination : 192.168.1.133
Data        : C2|sub tx all
              C3|sub atu all
              C4|sub meter all
              C5|sub pan all
              C6|sub slice all
              C7|sub gps all
              C8|sub audio_stream all
              C9|info
              C10|version
              C11|ant list
              C12|client udpport 4991
              C13|keepalive enable
              C14|ping


Source      : 192.168.1.133
Destination : 192.168.1.149
Data        :

Source      : 192.168.1.133
Destination : 192.168.1.149
Data        : R1|0|


Source      : 192.168.1.149
Destination : 192.168.1.133
Data        :

Source      : 192.168.1.133
Destination : 192.168.1.149
Data        : M10000001|Client connected from IP 192.168.1.149


Source      : 192.168.1.133
Destination : 192.168.1.149
Data        : SC3114FDF|radio slices=8 panadapters=8 lineout_gain=60 lineout_mute=0 headphone_gain=50 headphone_mute=0
              remote_on_enabled=0 pll_done=0 freq_error_ppb=-1 cal_freq=15.000


Source      : 192.168.1.149
Destination : 192.168.1.133
Data        :

Source      : 192.168.1.133
Destination : 192.168.1.149
Data        : SC3114FDF|interlock timeout=0 acc_txreq_enable=1 rca_txreq_enable=1 acc_txreq_polarity=0
              rca_txreq_polarity=0 tx1_enabled=1 tx1_delay=0 tx2_enabled=1 tx2_delay=0 tx3_enabled=1 tx3_delay=0
              acc_tx_enabled=1 acc_tx_delay=0 tx_delay=0


Source      : 192.168.1.149
Destination : 192.168.1.133
Data        :

Source      : 192.168.1.133
Destination : 192.168.1.149
Data        : SC3114FDF|transmit freq=7.138 lo=100 hi=2900 rfpower=100 tunepower=10 am_carrier_level=100 vox_enable=0
              vox_level=50 vox_delay=250 mic_level=40 mic_selection=MIC mic_boost=1 mic_bias=0 mic_acc=0 compander=1
              compander_level=30 dax=0 pitch=600 speed=30 iambic=1 iambic_mode=1 swap_paddles=0 break_in=1
              break_in_delay=5 monitor=0 mon_gain=80 tune=0 met_in_rx=0 hwalc_enabled=0 inhibit=0


Source      : 192.168.1.133
Destination : 192.168.1.149
Data        : R2|0|


Source      : 192.168.1.149
Destination : 192.168.1.133
Data        :

Source      : 192.168.1.133
Destination : 192.168.1.149
Data        : SC3114FDF|transmit freq=7.138 lo=100 hi=2900 rfpower=100 tunepower=10 am_carrier_level=100 vox_enable=0
              vox_level=50 vox_delay=250 mic_level=40 mic_selection=MIC mic_boost=1 mic_bias=0 mic_acc=0 compander=1
              compander_level=30 dax=0 pitch=600 speed=30 iambic=1 iambic_mode=1 swap_paddles=0 break_in=1
              break_in_delay=5 monitor=0 mon_gain=80 tune=0 met_in_rx=0 hwalc_enabled=0 inhibit=0





Photo of Robbie - KI4TTZ

Robbie - KI4TTZ

  • 480 Posts
  • 77 Reply Likes

Posted 5 years ago

  • 1
Photo of Steve - N5AC

Steve - N5AC, VP Engineering / CTO

  • 1031 Posts
  • 1002 Reply Likes
You can get the same data from wireshark by finding one packet from the TCP/IP stream and then right click on it and select "follow conversation."  It will show you everything between the client and radio color coded for each direction.
Photo of Robbie - KI4TTZ

Robbie - KI4TTZ

  • 480 Posts
  • 77 Reply Likes
Yeah, but the data field in wireshark is hard to read because it shows it in two columns instead of just straight plain text.  There might be an option to display it differently but I haven't found it yet.  :)  
Photo of Robbie - KI4TTZ

Robbie - KI4TTZ

  • 480 Posts
  • 77 Reply Likes
I'm sorta lazy, I'll put in the work so that it just tells me exactly what I want to know, so that I can do less work later. :-) haha  -- If I can type in a command at the prompt and just see exactly want I want, then I'm all for it. ;)  I like to make my job obsolete.
Photo of Walt - KZ1F

Walt - KZ1F

  • 3040 Posts
  • 643 Reply Likes
I didn't realize that either Steve, thanks!
Photo of Robbie - KI4TTZ

Robbie - KI4TTZ

  • 480 Posts
  • 77 Reply Likes


Steve, you were totally right -- I don't think I had gone far enough into the "follow conversation" feature of Wireshark to realize it would highlight the data that way.  Very cool!  I'll definitely make use of that.

Either way, I couldn't help myself (i'm a nerd) so I kept working on my own "data decode" thingy in Powershell.  So far this is what I've come up with:

http://screencast.com/t/TFeQUzCsA

(sorry, you'll have to click on the image a few times to zoom in enough to read it)

Basically it displays data real-time.  I'm mostly doing this to learn how to decode/translate the data so that I can do some other super-neat stuff but I could also see tweaking this particular function to save the radio language that it "hears" to a version file, then when it detects a new SmartSDR version, show notices for new language words (key/value pairs, I guess) that it didn't know about previously.  Sort of a simple way to discover new features that got added that just haven't made it to published documentation/wiki yet.

Also it could keep track of sequence numbers sent/received and if it doesn't hear a reply, display a warning or something.

Why is this useful?  Heck if I know, I'm having a blast playing with this stuff and learning. Also I'll be able to use the decode functions to write cmdlets that can (hopefully) save and restore slice receiver and panadapter settings or profiles or something from the command line.  Don't know if it'll work till I try it. :-)

Robbie - KI4TTZ


Photo of Richard Clafton W4/G7EIX

Richard Clafton W4/G7EIX, Elmer

  • 455 Posts
  • 117 Reply Likes
Nice work.  
Photo of James Whiteway

James Whiteway

  • 905 Posts
  • 222 Reply Likes
Robbie, very neat utility! Is this a Windows program?
james
WD5GWY
Photo of Robbie - KI4TTZ

Robbie - KI4TTZ

  • 480 Posts
  • 77 Reply Likes
Wow this is an old thread. :) Thanks James -- it's actually just a shell script.  I've included it in the "FlexModule" powershell module, which is now on GitHub.

https://github.com/rfoust/FlexModule

The packet sniffer script drops a lot of data so it isn't very reliable.  I haven't figured out a way to get it to process incoming requests faster, all of the UDP packets coming in seem to cause the buffer to drop packets.  It's probably just a side effect of using a shell script to process that much data, but it could also be a limitation of my coding skills...

-Robbie
Photo of Walt - KZ1F

Walt - KZ1F

  • 3040 Posts
  • 643 Reply Likes
In the very late 80's I worked with the company who made Bridge for Windows, it was basically an steroid version of the Windows Batch language. PowerShell is likely that product. Where I am going with this Robbie, you could, in theory, write an entire SDR app in it. Kind of like doing it in Python, but not. Actually, that would probably be a very fun project. PythonSDR.