C4FM to SRF-IP

[Zviratko]

I am running it on Ubuntu 20.04
gcc (Ubuntu 9.4.0-1ubuntu1~20.04.1) 9.4.0

I just rebuilt it with build-debug.sh, logfiles indicate no -O flag, but again, I'm not a dev...

Code: Select all

 /usr/lib/gcc/x86_64-linux-gnu/9/cc1 -quiet -v -imultiarch x86_64-linux-gnu /usr/share/cmake-3.16/Modules/CMakeCCompilerABI.c -quiet -dumpbase CMakeCCompilerABI.c -mtune=generic -march=x86-64 -auxbase-str
ip CMakeFiles/cmTC_3ce3e.dir/CMakeCCompilerABI.c.o -version -fasynchronous-unwind-tables -fstack-protector-strong -Wformat -Wformat-security -fstack-clash-protection -fcf-protection -o /tmp/ccVzGHJY.s

In any case, that didn't help.

I patched the server then, like this:

case SRF_IP_CONN_PACKET_TYPE_DATA_C4FM:
srf_ip_conn_packet_print_data_c4fm_payload(received_packet);
packet_process_c4fm(received_packet);
break;

The output looks like this when OS4 is talking to it

Code: Select all

  seq. no: 1397900873
  call session id: 0x5043000c
  dst callsign:
  src callsign: **EBPZU
  rssi: 70 dbm
  c4fm packet type: 0 header
  payload: 0000000000747f00d471c9634d116d38dcec2201ff300ed0728278ec60330086717d5c20a66ff3c0ff6013531b5198df2363c017607f1c88bca5fdc8069b26e27db9a85aba46921014be85ae2ce80e011b9c8b75a8f77fb81110f2c6ff1f0e3e5c02c9908f3def0e84251e499464202df63957017ec18b13
  seq. no: 1397900873
  call session id: 0x5043000c
  dst callsign:
  src callsign: **EBPZU
  rssi: 70 dbm
  c4fm packet type: 0 header
  payload: 000000000074d102d471c9634d219d383593e191ff47f09182817c762cf302185af79c205327e77bc2d1817bbb04e9b6f4b2393c1c555b11485397246c3b9860202f38f664f36b111ceba9f0780f51599836cba7a1f656840d451c7718fb2234177bba047014d4a74e0d1c54483334df22cc087bbb175640
  seq. no: 1397900873
  call session id: 0x5043000c
  dst callsign:
  src callsign: **EBPZU
  rssi: 70 dbm
  c4fm packet type: 0 header
  payload: 000000000074d102d471c9634d218d40a430e182f0327891a010ec882cc3f07cacf75f830770c4d7a36ebc599861355190f74e4949101c67a583ba06ba7bba420227a0e76c6a6e451e51048bd574b05998703572b17ba0b7a7ddd0272eac17e0515999712463f43fe4b6a6ccc205e8c8f1d9ff5ddd621763
  seq. no: 1397900873
  call session id: 0x5043000c
  dst callsign:
  src callsign: **EBPZU
  rssi: 70 dbm
  c4fm packet type: 0 header
  payload: 000000000074d102d471c9634d206d384468ed81ffe7989bf282e4542ff303fbc8f95c21383cf893636e4e7bbb057451907fe4e1c4cd87416a2cfa06e85998247463b07fe4e1d099857797791574d57b99713137b07fe4e0c099d2113f0117e0e75999602037a07fe4f3f3899655dc40f1d92c7b98602127

and like this, when OS3 is talking to it

Code: Select all

  seq. no: 1397900873
  call session id: 0x5043000c
  dst callsign:
  src callsign: **EBPZU
  rssi: 70 dbm
  c4fm packet type: 32 unknown
  payload: 202020200064d100d471c9634d116d38dcec2201ff300ed0728278ec60330086717d5c20a66ff3c0ff6013531b5198df2363c017607f1c88bca5fdc8069b26e27db9a85aba46921014be85ae2ce80e011b9c8b75a8f77fb81110f2c6ff1f0e3e5c02c9908f3def0e8
4251e499464202df63957017ec18b13
  seq. no: 1397900873
  call session id: 0x5043000c
  dst callsign:
  src callsign: **EBPZU
  rssi: 70 dbm
  c4fm packet type: 32 unknown
  payload: 202020200064d102d471c9634d219d383593e191ff47f09182817c762cf302185af79c205327e77bc2d1817bbb04e9b6f4b2393c1c555b11485397246c3fdc60202f28f664f36b111dfba9f0780f517b9824e9b6a1e212941c45583318fb223417c00934e99491f74
7c14908d03734df22cc086aab057541
  seq. no: 1397900873
  call session id: 0x5043000c
  dst callsign:
  src callsign: **EBPZU
  rssi: 70 dbm
  c4fm packet type: 32 unknown
  payload: 202020200064d102d471c9634d218d40a430e182f0327891a010ec882cc3f07cacf75f830770c4d7a36ebc7b99713473b0f328684c545b01a583ba06ba7b99602127a0f3286a7e455b11048bd574b07b98620237b0f76c6848111c732eac17e0517bbb51310580e76
c7a6a114a11e8c8f1d9ff7b98603137
  seq. no: 1397900873
  call session id: 0x5043000c
  dst callsign:
  src callsign: **EBPZU
  rssi: 70 dbm
  c4fm packet type: 32 unknown
  payload: 202020200064d102d471c9634d206d384468ed81ffe7989bf282e4542ff303fbc8f95c21383cf893636e4e7bbb431236b07fe4f1d5cd96416a2cfa06e87b99713005807fe4e3f298d03397791574d57b99720337b06fe4a4819996413f0117e0e75999602026b07fe
4e3e3889755dc40f1d92c7bba513005

I'm pretty sure I'm doing this completely wrong as everything except for payload seems to be constant. I tried moving it to main.c and doing it like this:
>srf_ip_conn_packet_print_data_c4fm_payload((srf_ip_conn_data_c4fm_payload_t*)received_packet.buf);

but I simply can't code in C. Please give me something better and I'll put in the effort...
There is still a difference between what OS3 and OS4 sends, though.
Also, I can see on the tail end of the call that src callsign changes to "**" in the last packet which explains the dashboards, so at least some part of what I did works. Not sure if this is OK.

[Zviratko]

upgraded to FW v13

Still no joy, though the communication now looks more like it does with OS3 to my eye.

[Zviratko]

I recompiled the binary on another server
PRETTY_NAME="Debian GNU/Linux 10 (buster)"
gcc version 8.3.0 (Debian 8.3.0-6)

Absolutely the same behaviour. OS3 calls register, OS4 calls don't register.

I tested both C4FM with FT-5DE and DMR with BTech DMR-6x2. Same behaviour.

[Zviratko]

I spun up two srf-ip servers
188.75.128.21 (Ubuntu 20.04)
80.79.17.14 (Debian 10)

both have a password of "test" and are running the Debug release. All protocols are enabled.

Can you try connecting with OS3 and OS4 to debug the differences? Sorry for being so persistent but I'd really like to get it working... Feel free to send me any patches to test or debug...

[HA2NON]

We've tested your Debian 10 server (the Ubuntu one did not connect) and we experienced that the OS3 did not receive the OS4's DMR or C4FM stream.

However, we've just installed a virtual machine with the latest Debian (11), followed the exact steps described in the server's README.md, built both the release and debug versions of srf-ip-conn-srv and they both worked without issues with the default example config.

Did you check out jsmn to the required commit before compiling as described in the server's README.md?

[Zviratko]

Yes I did.

Sorry, the IP is 188.75.128.215 (oops).
Also, I switched the distributions, what you tested was Ubuntu 20.04...

$ git status
HEAD detached at 732d283
nothing to commit, working tree clean

Code: Select all

--- config-example.json 2022-06-24 09:48:44.021831366 +0200
+++ /home/zviratko/os3/config.json      2022-06-27 13:05:45.921363817 +0200
@@ -2,24 +2,25 @@
   "port": 65100,
   "ipv4-only": 1,
   "bind-ip": "0.0.0.0",
-  "max-clients": 1000,
+  "max-clients": 100,
   "max-api-clients": 100,
   "client-login-timeout-sec": 10,
   "client-timeout-sec": 30,
   "client-status-syslog-interval-sec": 30,
-  "server-password": "",
+  "server-password": "test",
   "auth-fail-ip-ignore-sec": 5,
   "pidfile": "srf-ip-conn-srv.pid",
   "api-socket-file": "/tmp/srf-ip-conn-srv.socket",
   "server-name": "SharkRF IP Connector Protocol Server",
-  "server-desc": "",
-  "server-contact": "",
+  "server-desc": "Zvireci",
+  "server-contact": "/dev/null",
   "allow-simultaneous-calls": 0,
   "banlist-file": "",
-  "allow-data-raw": 0,
+  "allow-data-raw": 1,
   "allow-data-dmr": 1,
   "allow-data-dstar": 1,
   "allow-data-c4fm": 1,
   "allow-data-nxdn": 1,
   "allow-data-p25": 1
 }

[Zviratko]

Heureka!

I made a fresh install of Debian 10.10 (ARM64) in Parallels and after fighting with macOS portforwarding managed to connect OS4 to it... and it does register a call! How weird.

However, once I put in any password, it breaks. OpenSpot is able to login, but no call can be made like before. Once I disable password, it starts working again. I'm going to assume you never tested it with a password

I disabled password on my other servers and it works on all of them now.

I guess whatever HMAC-like thing srf-ip-conn-srv is doing is not working correctly with OpenSpot 4 (but why only with OpenSpot 4?). As a side note, when looking at the protocol previously, what you are doing is probably not really a secure HMAC (HMAC is not a simple hash of secret and data). But that I can probably live with (just use a real HMAC function in the next protocol version)

Do you run your servers without passwords?

[HA2NON]

Thank you for helping identifying the issue, we've tested without passwords before. We've found the cause in the OS4 code and fixed it. Fix will be available in firmware v15.

We don't operate any srf-ip-conn servers.

[Zviratko]

Well, you should at least test it sometimes, there's not that many connectors so people are likely to want to use it (or at least try it) especially those who just want a private network...