dvmproject / dvmhost Goto Github PK

View Code? Open in Web Editor NEW

49.0 15.0 15.0 17.07 MB

MMDVM-based Digital Voice Modem Host Software

License: GNU General Public License v2.0

C++ 97.94% Shell 0.20% CMake 1.01% C 0.28% Makefile 0.05% Python 0.37% CSS 0.14%

dmr nxdn p25 sdr trunking radio

dvmhost's People

Contributors

Stargazers

Watchers

Forkers

jelimoore centrunk mfkiwl k4yt3x cole0209 dandrzejewski imwhattherel faultywarrior ratmandu alwinhb jeroen2006 circnet-trunked-radio-system firealarmss

dvmhost's Issues

No logging or comms

Running the build from 7/28/23, no sign of acknowledgement of any system activity in the console after "Host is up and running." Tried in P25 Trunked, DMR T2 and DMR T3. P25 radios show no comms. DMR radios will not start a voice call. Showing BER in calibrate mode, so I assume it's not a hardware issue. Unsure what the cause is. As far as control channel goes, the control channels work fine and I confirmed with an SDR.

Add Ability to have Redundant FNE address's

Have the ability to have 2 fne address's configured. When it loses connection to the Pri it swaps to Secondary and checks for a good connection on Pri. I'm not asking this from safety of life viewpoint, but I don't want a wide area repeater to go down just because the auto-update went off/I tripped on the power cable of the main box/need to do FNE updates. I think it would be quite a nice feature.

Documentation: Input vs Tx offset

iden_table.dat asks for input offset, and then dvmhost shows TX offset for that channel

FNE Connection seems to time out on newest commit

CC-2023-07-16.log
VC1-2023-07-16.log

FNE Site
fnerouter-20230715.log
(FNE log was trimmed bc of size, morning was removed)

Conventional mode: Motorola GPS Location packets are not passed

Currently have a repeater & a hotspot as a testbed, both connected to the same CFNE.

SU#1 is a APX8000 is transmitting on TG1 with Location Reporting (GPS) on. Generates following error on DVMHost:

U: 900025 E: 2024-04-22 21:38:25.930 (P25) LC::encodeLC(), unknown LC value, mfId = $90, lco = $00

SU#2 is an APX7000, receives transmission correctly but no Radio ID or no location data.

Add additional fields to FNE RID ACL for identification of RIDs

We should allow for an alias field for each RID in the RID ACL file for the FNE, to allow for tools interfacing with the FNE REST API to map RIDs to specific users/radios.

This will require an update to the RID ACL handling functions as well as the REST APIs for editing/viewing the ACL.

Rolling CC

Add the ability to have mode change from CC to VC at a set interval. Would need to be coordinated with FNE?

Could also put in HS number and have it change daily with all HSs waiting until an internal counter rolls to them, Would need for all HSs to start at the same time

Or have the HS's assigned days of the week (HS1 = M,W,F HS2 = T,T,S HS3 = Sunday)

I think the last option would be the best unless we get the fabled site controller software

Missing LC_CALL_TERM messages causes VC grant denies until the TG hangtime expires

Running the latest 3.5-dev branch, the host will deny any calls to a TG after the first call until the channel grant expires.

    (First Radio Calls)
M: 2023-06-15 18:05:41.640 (RF) P25_DUID_TSDU (Trunking System Data Unit), TSBK_IOSP_GRP_VCH (Group Voice Channel Request), srcId = 3118336, dstId = 56001
M: 2023-06-15 18:05:41.640 (HOST) P25 Affiliation, granting channel, chNo = 1782, dstId = 56001, srcId = 3118336
A: 2023-06-15 18:05:41.641 P25 RF group grant request from 3118336 to TG 56001
M: 2023-06-15 18:05:41.641 (RF) P25_DUID_TSDU (Trunking System Data Unit), TSBK_IOSP_GRP_VCH (Group Voice Channel Grant), emerg = 0, encrypt = 0, prio = 4, chNo = 1782, srcId = 3118336, dstId = 56001
M: 2023-06-15 18:05:42.616 (RF) P25_DUID_TSDU (Trunking System Data Unit), TSBK_IOSP_GRP_VCH (Group Voice Channel Request), srcId = 3118336, dstId = 56001
A: 2023-06-15 18:05:42.616 P25 RF group grant request from 3118336 to TG 56001
M: 2023-06-15 18:05:42.617 (RF) P25_DUID_TSDU (Trunking System Data Unit), TSBK_IOSP_GRP_VCH (Group Voice Channel Grant), emerg = 0, encrypt = 0, prio = 4, chNo = 1782, srcId = 3118336, dstId = 56001
M: 2023-06-15 18:05:43.668 (RF) P25_DUID_TSDU (Trunking System Data Unit), TSBK_IOSP_GRP_VCH (Group Voice Channel Request), srcId = 3118336, dstId = 56001
A: 2023-06-15 18:05:43.668 P25 RF group grant request from 3118336 to TG 56001
M: 2023-06-15 18:05:43.668 (RF) P25_DUID_TSDU (Trunking System Data Unit), TSBK_IOSP_GRP_VCH (Group Voice Channel Grant), emerg = 0, encrypt = 0, prio = 4, chNo = 1782, srcId = 3118336, dstId = 56001
    (Second Radio is Denied)
M: 2023-06-15 18:05:54.201 (RF) P25_DUID_TSDU (Trunking System Data Unit), TSBK_IOSP_GRP_VCH (Group Voice Channel Request), srcId = 3118337, dstId = 56001
W: 2023-06-15 18:05:54.201 (RF) P25_DUID_TSDU (Trunking System Data Unit), TSBK_IOSP_GRP_VCH (Group Voice Channel Request) denied, traffic in progress, dstId = 56001
M: 2023-06-15 18:05:54.201 (RF) P25_DUID_TSDU (Trunking System Data Unit), TSBK_OSP_DENY_RSP (Deny Response), AIV = 0, reason = $67, srcId = 3118337, dstId = 56001
A: 2023-06-15 18:05:54.201 P25 RF group grant request from 3118337 to TG 56001 denied
M: 2023-06-15 18:05:55.097 (RF) P25_DUID_TSDU (Trunking System Data Unit), TSBK_IOSP_GRP_VCH (Group Voice Channel Request), srcId = 3118337, dstId = 56001
W: 2023-06-15 18:05:55.097 (RF) P25_DUID_TSDU (Trunking System Data Unit), TSBK_IOSP_GRP_VCH (Group Voice Channel Request) denied, traffic in progress, dstId = 56001
M: 2023-06-15 18:05:55.097 (RF) P25_DUID_TSDU (Trunking System Data Unit), TSBK_OSP_DENY_RSP (Deny Response), AIV = 0, reason = $67, srcId = 3118337, dstId = 56001
A: 2023-06-15 18:05:55.098 P25 RF group grant request from 3118337 to TG 56001 denied
    (Channel Grant is released)
M: 2023-06-15 18:05:58.652 (HOST) P25 Affiliation, releasing channel grant, chNo = 1782, dstId = 56001
    (Second Radio is Granted)
M: 2023-06-15 18:06:00.012 (RF) P25_DUID_TSDU (Trunking System Data Unit), TSBK_IOSP_GRP_VCH (Group Voice Channel Request), srcId = 3118337, dstId = 56001
M: 2023-06-15 18:06:00.012 (HOST) P25 Affiliation, granting channel, chNo = 1794, dstId = 56001, srcId = 3118337
A: 2023-06-15 18:06:00.012 P25 RF group grant request from 3118337 to TG 56001
M: 2023-06-15 18:06:00.013 (RF) P25_DUID_TSDU (Trunking System Data Unit), TSBK_IOSP_GRP_VCH (Group Voice Channel Grant), emerg = 0, encrypt = 0, prio = 4, chNo = 1794, srcId = 3118337, dstId = 56001
M: 2023-06-15 18:06:00.941 (RF) P25_DUID_TSDU (Trunking System Data Unit), TSBK_IOSP_GRP_VCH (Group Voice Channel Request), srcId = 3118337, dstId = 56001
A: 2023-06-15 18:06:00.941 P25 RF group grant request from 3118337 to TG 56001
M: 2023-06-15 18:06:00.942 (RF) P25_DUID_TSDU (Trunking System Data Unit), TSBK_IOSP_GRP_VCH (Group Voice Channel Grant), emerg = 0, encrypt = 0, prio = 4, chNo = 1794, srcId = 3118337, dstId = 56001
M: 2023-06-15 18:06:01.884 (RF) P25_DUID_TSDU (Trunking System Data Unit), TSBK_IOSP_GRP_VCH (Group Voice Channel Request), srcId = 3118337, dstId = 56001
A: 2023-06-15 18:06:01.884 P25 RF group grant request from 3118337 to TG 56001
M: 2023-06-15 18:06:01.885 (RF) P25_DUID_TSDU (Trunking System Data Unit), TSBK_IOSP_GRP_VCH (Group Voice Channel Grant), emerg = 0, encrypt = 0, prio = 4, chNo = 1794, srcId = 3118337, dstId = 56001
M: 2023-06-15 18:06:16.878 (HOST) P25 Affiliation, releasing channel grant, chNo = 1794, dstId = 56001

The LC_CALL_TERM message is missing at the conclusion of the first call, which means subsequent radios trying to call the same group are denied.

TGIDs and RIDs not updating at specified intervals

After adding a new RID to the FNE whitelist, I noticed that DVM still throws Reg Refused at the radio, even after the two-minute update setting for RID ACL updates. The same goes for TGIDs; no update after the specified interval. I am unsure if this is a host issue or an FNE issue, but I figured I'd open the issue here.

REST handler cannot handle segmented HTTP requests

The REST/HTTP server (specifically tested in the FNE, but likely all the REST servers) cannot handle segmented TCP HTTP requests.

The issue is described here: https://stackoverflow.com/questions/50213271/python-requests-splits-tcp-packet

We need to figure out why the TCP handler gets upset at segmented PDUs.

DVMhost dynamic config Update

Allow for the active config to refresh after X amount of time.

Say, to change the VC list without tearing down the CC

RID ACLs larger than 50 are not properly sent over the network

When running RID ACL lists on the FNE, I noticed that random RIDs would be missing.

It appears that the CFNE only sends new RIDs in the first batch of 50, and subsequent RID updates send duplicates. The total number of RIDs sent matches the length of the list, it's just the wrong RIDs being sent in the second message:

D: 2024-02-24 04:30:34.913 (HOST) Adding new RID 1409703 () to ACL
D: 2024-02-24 04:30:34.913 (HOST) Adding new RID 3896300 () to ACL
D: 2024-02-24 04:30:34.913 (HOST) Adding new RID 3892800 () to ACL
D: 2024-02-24 04:30:34.913 (HOST) Adding new RID 334000 () to ACL
D: 2024-02-24 04:30:34.914 (HOST) Adding new RID 3550150 () to ACL
D: 2024-02-24 04:30:34.914 (HOST) Adding new RID 3550103 () to ACL
D: 2024-02-24 04:30:34.914 (HOST) Adding new RID 3851003 () to ACL
D: 2024-02-24 04:30:34.914 (HOST) Adding new RID 3816300 () to ACL
D: 2024-02-24 04:30:34.914 (HOST) Adding new RID 3312512 () to ACL
D: 2024-02-24 04:30:34.914 (HOST) Adding new RID 3891100 () to ACL
D: 2024-02-24 04:30:34.914 (HOST) Adding new RID 3550105 () to ACL
D: 2024-02-24 04:30:34.914 (HOST) Adding new RID 3550121 () to ACL
D: 2024-02-24 04:30:34.914 (HOST) Adding new RID 3312504 () to ACL
D: 2024-02-24 04:30:34.914 (HOST) Adding new RID 3312501 () to ACL
D: 2024-02-24 04:30:34.915 (HOST) Adding new RID 501703 () to ACL
D: 2024-02-24 04:30:34.915 (HOST) Adding new RID 3536901 () to ACL
D: 2024-02-24 04:30:34.915 (HOST) Adding new RID 502301 () to ACL
D: 2024-02-24 04:30:34.915 (HOST) Adding new RID 3031100 () to ACL
D: 2024-02-24 04:30:34.915 (HOST) Adding new RID 3832400 () to ACL
D: 2024-02-24 04:30:34.915 (HOST) Adding new RID 3574202 () to ACL
D: 2024-02-24 04:30:34.915 (HOST) Adding new RID 548300 () to ACL
D: 2024-02-24 04:30:34.915 (HOST) Adding new RID 3648202 () to ACL
D: 2024-02-24 04:30:34.915 (HOST) Adding new RID 1409700 () to ACL
D: 2024-02-24 04:30:34.915 (HOST) Adding new RID 3502700 () to ACL
D: 2024-02-24 04:30:34.915 (HOST) Adding new RID 501702 () to ACL
D: 2024-02-24 04:30:34.915 (HOST) Adding new RID 3550112 () to ACL
D: 2024-02-24 04:30:34.915 (HOST) Adding new RID 501700 () to ACL
D: 2024-02-24 04:30:34.915 (HOST) Adding new RID 501701 () to ACL
D: 2024-02-24 04:30:34.915 (HOST) Adding new RID 3550111 () to ACL
D: 2024-02-24 04:30:34.915 (HOST) Adding new RID 500401 () to ACL
D: 2024-02-24 04:30:34.916 (HOST) Adding new RID 3312502 () to ACL
D: 2024-02-24 04:30:34.916 (HOST) Adding new RID 1409702 () to ACL
D: 2024-02-24 04:30:34.916 (HOST) Adding new RID 3551501 () to ACL
D: 2024-02-24 04:30:34.916 (HOST) Adding new RID 3550104 () to ACL
D: 2024-02-24 04:30:34.916 (HOST) Adding new RID 3851004 () to ACL
D: 2024-02-24 04:30:34.916 (HOST) Adding new RID 541500 () to ACL
D: 2024-02-24 04:30:34.916 (HOST) Adding new RID 541501 () to ACL
D: 2024-02-24 04:30:34.916 (HOST) Adding new RID 501704 () to ACL
D: 2024-02-24 04:30:34.916 (HOST) Adding new RID 3312500 () to ACL
D: 2024-02-24 04:30:34.916 (HOST) Adding new RID 3550110 () to ACL
D: 2024-02-24 04:30:34.916 (HOST) Adding new RID 3536902 () to ACL
D: 2024-02-24 04:30:34.916 (HOST) Adding new RID 3312503 () to ACL
D: 2024-02-24 04:30:34.916 (HOST) Adding new RID 4377600 () to ACL
D: 2024-02-24 04:30:34.916 (HOST) Adding new RID 3851000 () to ACL
D: 2024-02-24 04:30:34.916 (HOST) Adding new RID 4718500 () to ACL
D: 2024-02-24 04:30:34.916 (HOST) Adding new RID 3550100 () to ACL
D: 2024-02-24 04:30:34.916 (HOST) Adding new RID 3544200 () to ACL
D: 2024-02-24 04:30:34.916 (HOST) Adding new RID 3576001 () to ACL
D: 2024-02-24 04:30:34.916 (HOST) Adding new RID 3648201 () to ACL
D: 2024-02-24 04:30:34.917 (HOST) Adding new RID 3851001 () to ACL
M: 2024-02-24 04:30:34.917 (NET) Network Announced 50 whitelisted RIDs
D: 2024-02-24 04:30:34.922 (HOST) No changes made to RID 3031100 () in ACL
D: 2024-02-24 04:30:34.922 (HOST) No changes made to RID 3832400 () in ACL
D: 2024-02-24 04:30:34.922 (HOST) No changes made to RID 3574202 () in ACL
D: 2024-02-24 04:30:34.922 (HOST) No changes made to RID 548300 () in ACL
D: 2024-02-24 04:30:34.922 (HOST) No changes made to RID 3648202 () in ACL
D: 2024-02-24 04:30:34.922 (HOST) No changes made to RID 1409700 () in ACL
D: 2024-02-24 04:30:34.923 (HOST) No changes made to RID 3502700 () in ACL
D: 2024-02-24 04:30:34.923 (HOST) No changes made to RID 501702 () in ACL
D: 2024-02-24 04:30:34.923 (HOST) No changes made to RID 3550112 () in ACL
D: 2024-02-24 04:30:34.923 (HOST) No changes made to RID 501700 () in ACL
D: 2024-02-24 04:30:34.923 (HOST) No changes made to RID 501701 () in ACL
D: 2024-02-24 04:30:34.923 (HOST) No changes made to RID 3550111 () in ACL
D: 2024-02-24 04:30:34.923 (HOST) No changes made to RID 500401 () in ACL
D: 2024-02-24 04:30:34.923 (HOST) No changes made to RID 3312502 () in ACL
D: 2024-02-24 04:30:34.923 (HOST) No changes made to RID 1409702 () in ACL
D: 2024-02-24 04:30:34.923 (HOST) No changes made to RID 3551501 () in ACL
D: 2024-02-24 04:30:34.923 (HOST) No changes made to RID 3550104 () in ACL
M: 2024-02-24 04:30:34.923 (NET) Network Announced 17 whitelisted RIDs

DMR Protocol

@gatekeep @jelimoore @ratmandu @majmongoose @k4yt3x Does this repo contains source code for DMR data link and control layers? [Tier 1/2]

TSBK_OSP_TIME_DATE_ANN Not broadcasting after merge

Unhandled Exception For REST API Resets Causes Segfaults

If a remote REST peer sends a reset packet; DVMHost fails to gracefully handle the exception and instead segfaults, simply returning the upstream error from the Linux IP stack as seen in the screenshot below.

Support for split NAC and multi nac.

I recommend the addition of split NAC and multi NAC(allows use of DVM project in community repeaters) to the DVM project.

Test Issue Please Ignore

SN-DATA_CHN_ANN_EXP has wrong UPLINK frequency announced

SN-DATA_CHN_ANN_EXP transmits wrong uplink frequency.

Block transmitted over the air:
SN-DATA_CHN_ANN_EXP DSO=00 TXch=438.175 RXch=438.175 DAC=0001

iden_table entrys:

ChId,Base Freq,Spacing (khz),Input Offset (mhz),Bandwidth (khz),

0,438100000,6.25,-5.000,12.5,
1,145575000,6.25,-0.600,12.5,
2,438100000,6.25,-7.600,12.5,
3,439450000,6.25,-9.400,12.5,
4,438100000,6.25,-7.5875,12.5,

config.yml entrys:
config:
channelId: 0
channelNo: c
dmrNetId: 1
voiceChNo:
- c
colorCode: 1
nac: 13D

txNAC: 293

    pSuperGroup: FFFF
    netId: DEE00
    sysId: 13B
    rfssId: 1
    siteId: D

Host transmitting via HS when not suppose to.

I have a DVM host setup with a hotspot running on a PI. I have duplex set to false and hang time set to 0, but even after changing those settings and restarting my DVM will still transmit once it stops receiving. Below you can see my SDR picking up my radio transmitting and then the hotspot transmitting.

Add ability to limit certain RID to certain TGID via ACL.

Also added to FNE.

Talkgroups With No Affiliations Are Repeated Reguardless Of Authoritative Or Supervisor Status

Title says it more or less entirely. I've got a 2 channel (1 CC, 1 VC) site. CC has Authoritative and Supervisor both set to true, VC has Authoritative set to true and Supervisor set to false. Talkgroup on the FNE has Affiliated set to true. I have only 1 radio powered on and affiliated to TG 31611. My VC repeats traffic for all TGs regardless of an affiliation to it. In my specific instance, TG 1056 happened to be very active; and was basically making the site unusable on any other TG.

FNE and DVMHost builds:
Host: 952606b
FNE: 1058110

dvmhost 3.0-dev P25 Site Trunking

Radios are showing as site trunking while dvmhost is connected to FNE. Verified connectivity to FNE as ADJ STS BCAST messages are passing in both directions.

Duplex shift from iden_table not correct transmitted over the air

A duplex shift in the iden_table is not correct transmitted in the bandplan data over the air. The part dehind the decimal is cutted off.

Example iden_table entry:
0,438100000,6.25,-7.600,12.5,

Bandplan over the air:
Bandplan #0: Base=438.1 Offset=-7 Spacing=6.25 BW=12.5

Conv -> Trunk

Grant not generated when talking from a conv site to a Trunking site

Should add grant demand like with dvmbridge?