Hackrf tcp server #6

ellisgl · 2025-07-24T22:15:07Z

Figured a C/C++ TCP server that works with Hackrf would be nice.

Theldus · 2025-07-27T05:32:16Z

Hi @ellisgl,
Thank you for the tool for HackRF, seems pretty neat.
As I don't have a HackRF, I can't test it myself, but regarding the code I have some comments.

Theldus · 2025-07-27T05:40:29Z

demos/hackrf_tcp_server/main.cpp

+        return 1;
+    }
+
+    int PORT        = config["PORT"];


Although I agree with the appeal of json, it bothers me a bit to bring a 25k LOC library into the repo for just 6 paramaters... maybe they could be environment variables?

Having a single vars.sh like:

PORT= SAMPLE_RATE= BITRATE= AMPLITUDE= FREQ_DEV TX_GAIN=

so the user can just 'source it': . vars.sh before using the tool.

Good point. I'll look into that

Theldus · 2025-07-27T05:43:25Z

demos/hackrf_tcp_server/main.cpp

+ *
+ * @return std::vector<double>  A vector of doubles representing the FSK modulated signal.
+ */
+std::vector<double> generate_fsk_signal(


I didn't see this function being used anywhere, please consider using it or removing it entirely.

rlaneth · 2025-07-28T00:20:35Z

demos/hackrf_tcp_server/main.cpp

+    // Define the type of socket address, in this case IPv4
+    address.sin_family = AF_INET;
+    // Allow connections from any IP address
+    address.sin_addr.s_addr = INADDR_ANY;
+    // Set the port number
+    address.sin_port = htons(PORT);
+
+    // Bind the socket to the address and port
+    if (bind(server_fd, (struct sockaddr *)&address, sizeof(address)) < 0) {
+        perror("bind failed");
+        return 1;
+    }


I noticed the server currently binds to all IPv4 addresses by default.

Since this looks like it's intended as a simple server without built-in authentication, it might be safer to default to localhost only. This would prevent accidental exposure on network interfaces.

Please consider:

Default to binding localhost (127.0.0.1)

Add a configuration option so users can explicitly choose to bind to other network interfaces when needed

A BIND_ADDRESS environment variable could work.

rlaneth · 2025-07-28T00:23:01Z

demos/hackrf_tcp_server/main.cpp

+        int capcode = std::stoi(capcode_str);
+        int frequency = std::stoi(freq_str);


There's a stability issue with the input parsing that might be worth addressing.

The server currently uses std::stoi() to parse capcode and frequency values from network input:

int capcode = std::stoi(capcode_str); // Line 175 int frequency = std::stoi(freq_str); // Line 176

Since std::stoi() throws exceptions on invalid input (like non-numeric strings or values outside int range), any malformed data will currently crash the server. This could happen accidentally with corrupted data or if someone sends unexpected input.

Quick test case:
If you connect via nc localhost 16175 and send something like 123|test message|not_a_number, the server will terminate with an unhandled exception.

Possible fix:
We could wrap these conversions in try-catch blocks to handle bad input gracefully:

try { int capcode = std::stoi(capcode_str); int frequency = std::stoi(freq_str); // ... continue processing } catch (const std::exception& e) { printf("Skipping invalid input: %s\n", e.what()); close(client_fd); continue; // Handle next client/input }

This way the server stays running even when it receives unexpected data. What do you think about this approach?

Good catch. I'm working on breaking things down. I figured having all the stuff just shoved in main is kind of sloppy. I will admit to being lazy and letting the nice AI overlords take one for the team. heh.

…idation.

geekinsanemx · 2025-07-30T19:40:28Z

Hi Guys!, hope everyone is doing great !, I'm following the thread, and I have a HackRF One to test with, I tried to compile and run the code, but faced some errors, I already fixed in the code the errors, and tested with a real hackrf and advisor elite,

but wanted ask first if is okay to push my changes here?, don't want to disturb anybody

ellisgl · 2025-07-30T21:30:36Z

Hey @geekinsanemx
I was going to start over from scratch for the most part. If you want to take this on, go right ahead. =)

Hi Guys!, hope everyone is doing great !, I'm following the thread, and I have a HackRF One to test with, I tried to compile and run the code, but faced some errors, I already fixed in the code the errors, and tested with a real hackrf and advisor elite,

but wanted ask first if is okay to push my changes here?, don't want to disturb anybody

geekinsanemx · 2025-07-30T22:56:23Z

Thank you so much @ellisgl unable to update over here, but pushed a PR at your fork: ellisgl#2

proposing some Hackrf tcp server fix

Hackrf tcp server v2

Theldus · 2025-08-02T03:27:40Z

Hi guys,
Thank you very much for the teamwork in reviewing the points raised by me and @rlaneth.

@geekinsanemx thanks for polishing @ellisgl’s work and addressing the comments I made =).

The only thing that bothered me a bit was that changes were also made to the GNURadio demo. I'm not sure if that was accidental or not, but I would have preferred that to be in a separate PR if possible. Still, I can go ahead and merge this as-is, excluding those changes.

@rlaneth any additional thoughts on this PR? It looks good to me now.

geekinsanemx · 2025-08-02T05:26:07Z

Hi @Theldus !!

ohhh yeap, that's because when I tested with my hackrf find out that I'm using osmosdr_sink, don't know why soapy_hackrf_sink does not work for me, tried to configure hackrf=0 as device argument but unable to send message, I though was more like a simulated sink, that's why changed for osmosdr_sink to actually be able to transmit messages

reverting back file to original and adding osmosdr_sink too :)

if you exclude those gnuradio changes at merging this, I can open a new PR for adding the osmosdr_sink if you wish! :)

rlaneth

Hi everyone,

I agree that modifying hackrf_file_tx_demo.grc is probably not in the scope of this PR. There's a few concerns that have been raised about this flowchart by other users (as in Issue #7), so it might be due to changes in the near future anyway.

As for the TCP server itself, I see no more issues! I have also tested basic functionality with my own HackRF and pagers, and it works flawlessly.

LGTM

reverting back soapy_hackrf_sink, but adding osmosdr_sink

Theldus · 2025-08-02T23:47:33Z

Thank you guys for the excellent work, merged in 702f14d.

ellisgl added 2 commits July 24, 2025 17:05

Push all the things!

4161bfc

try...catch.

962021a

Theldus requested review from Theldus and rlaneth July 27, 2025 01:29

Theldus reviewed Jul 27, 2025

View reviewed changes

rlaneth requested changes Jul 28, 2025

View reviewed changes

ellisgl added 2 commits July 28, 2025 07:44

[WIP] Breaking down and securing

9dd3825

[WIP] Moving things out into their own files. Try...Catches. More val…

498b51b

…idation.

geekinsanemx mentioned this pull request Jul 30, 2025

proposing some fixes from ellisgl:hackrf-tcp-server branch ellisgl/tinyflex#1

Closed

geekinsanemx added 4 commits July 30, 2025 16:44

replacing osmosdr sink to transmit with real hackrf device

97bf5cf

removing reference for removed file

f4645c4

changing int expected value for string matching case

5fe6e6c

fixing some int references and segfaults at runtime

205f66c

geekinsanemx mentioned this pull request Jul 30, 2025

proposing some Hackrf tcp server fix ellisgl/tinyflex#2

Merged

ellisgl and others added 3 commits July 30, 2025 18:34

Merge pull request #2 from geekinsanemx/hackrf-tcp-server-fix

0c346a5

proposing some Hackrf tcp server fix

changing config.txt to config.ini and including BIND_ADDRESS configs

afe49e2

adding: verbosity, EMR sync, help, handle config vars

71eebd3

geekinsanemx mentioned this pull request Aug 1, 2025

Hackrf tcp server v2 ellisgl/tinyflex#3

Merged

geekinsanemx and others added 3 commits August 1, 2025 00:18

is one message, not two

186b5f7

updating readme file

6fb927a

Merge pull request #3 from geekinsanemx/hackrf-tcp-server-v2

dcc0c75

Hackrf tcp server v2

reverting back soapy_hackrf_sink, but adding osmosdr_sink

e6e2be6

geekinsanemx mentioned this pull request Aug 2, 2025

reverting back soapy_hackrf_sink, but adding osmosdr_sink ellisgl/tinyflex#4

Merged

rlaneth approved these changes Aug 2, 2025

View reviewed changes

Merge pull request #4 from geekinsanemx/hackrf-tcp-server-osmosdr

398c957

reverting back soapy_hackrf_sink, but adding osmosdr_sink

Theldus merged commit 702f14d into Theldus:master Aug 2, 2025
1 check passed

		int capcode = std::stoi(capcode_str);
		int frequency = std::stoi(freq_str);

Uh oh!

Hackrf tcp server #6

Hackrf tcp server #6

Uh oh!

Conversation

ellisgl commented Jul 24, 2025

Uh oh!

Theldus commented Jul 27, 2025

Uh oh!

Theldus Jul 27, 2025

Choose a reason for hiding this comment

Uh oh!

ellisgl Jul 27, 2025

Choose a reason for hiding this comment

Uh oh!

Theldus Jul 27, 2025

Choose a reason for hiding this comment

Uh oh!

rlaneth Jul 28, 2025

Choose a reason for hiding this comment

Uh oh!

rlaneth Jul 28, 2025

Choose a reason for hiding this comment

Uh oh!

ellisgl Jul 28, 2025

Choose a reason for hiding this comment

Uh oh!

geekinsanemx commented Jul 30, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

ellisgl commented Jul 30, 2025

Uh oh!

geekinsanemx commented Jul 30, 2025

Uh oh!

Theldus commented Aug 2, 2025

Uh oh!

geekinsanemx commented Aug 2, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

rlaneth left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Theldus commented Aug 2, 2025

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

geekinsanemx commented Jul 30, 2025 •

edited

Loading

geekinsanemx commented Aug 2, 2025 •

edited

Loading