Discovery method for API developers

rfoust

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:UsersRobbieDocumentsscripts> .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.149Press 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

Steve-N5AC

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.

rfoust

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.    

rfoust

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.

rfoust

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

Richard G7EIX

Nice work.  

James Whiteway

Robbie, very neat utility! Is this a Windows program?
james
WD5GWY

Walt - KZ1F

I didn't realize that either Steve, thanks!

rfoust

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

Walt - KZ1F

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.