Access Control for DMR #90
Conversation
|
Hmmmmm :-| As we debated, Simon - All good in practise, but this should be Some means of informing the master that you don't want the traffic and to On Sat, Jun 11, 2016 at 10:10 AM hacknix notifications@github.com wrote:
A J Corbett G0WFV |
|
Hi Tony, Thanks for your comments, which I have taken on board. I agree that doing some or all of this at the master is preferable and In fact, the slot is not locked up when traffic from the network is The other way around, for example, if a user TXs on TG91, because their On the RF side, I have been looking for a way to reject the transmission I think the short answer is, if it's useful to you, use it, if it's not, Thanks for the discussion, it's good to discuss these things and work it Cheers Simon On 11/06/16 10:25, Tony Corbett wrote:
|
|
Apologies, Simon, but a lot of this first comment may sound antoagonistic, but it's meant purely as Devil's Advocate ...
If I may, why are you running a networked repeater based on a technology where the routing and a vast amount of configuration is remote from the repeater?
This is the bit that should be configured at the master for your repeater to only accept/carry TG9 on both slots. It seems to me you and your users have issues with certain other TGs getting through - ask for them not to be sent by the master! Your repeated use of TG91 as an example only suggests that this is the offending TG; I agree, the net that takes place at certain times is like listening to paint dry! I can see BM going completely reflector based anyway; there is no need for any other TG than TG9 (or maybe TG10 for pure local in the case where TG9 is a repeater link) on Slot 1 and TG9 on Slot 2; Reflectors are far more flexible than the TG system that we inherited from DMR-MARC et al.
This is the only part of this that code I believe has real value - I agree; you should be able to prevent the transmissions at the source - which is why I strongly believe network traffic should be (where possible) prevented at source also! I'm not up-to-speed on what information is included in which part of a DMR transmission, if it were possible to present a terminal with a busy tone or similar that would be the way to go. Perhaps Jonathan knows a trick or two that may work? Whilst these changes to the way the repeater software operates will do as you intend; prevent transmission of unwanted traffic, you are bypassing the way the network is intended to be configured and you really need to ask the keeper (sysop?) of the master server to configure network traffic to your repeater as you want it - after all, it's your NOV and licence; I can't see why they'd have grounds to say no where it's in there power to comply with your reasonable request! If the system is incapable of complying, then you have a valid reason to bypass it. I'm not arguing that the ACL concept is invalid, in fact if anything it's a good idea when used in the right place! |
|
On a positive note, I've tested the code, and it works. Perhaps the output of a single log line when a blacklisted TG is attempted rather than the continual scroll for the duration of the transmission??
|
|
On 12/06/2016 10:07, Tony Corbett wrote:
As a crude way I guess the downlink TX could be deactivated but I'm not Suppose the danger with this would be he could just send his ID out You will never fully prevent abuse on the RF side. Dom G7NPW |
|
Hi Tony, I think we agree on many points. Perhaps my motivation is not entirely Comments inline. On 12/06/16 10:07, Tony Corbett wrote:
No offence taken Tony. I see it kind of differently. I run a repeater.
I have been looking at the busy tone issue, but the problem is, as far
I agree and I have. The configuration is as I require at the network and
I wonder if we could clarify some of this by explaining in more detail 73 Simon |
|
On 12/06/16 10:23, Tony Corbett wrote:
I agree Tony. I just need to work out how to do this and I will add it! Simon |
|
On 12/06/16 10:36, g7npw wrote:
HI Dom. Agree. I did try this, but it serves no purpose as it's exactly Simon |
|
Would this code prevent auto connect to reflector 4400 upon restart? I only compiled and installed this version of MMDVMHost tonight and notice now I'm not automatically connecting to 4400 but it will let me connect manually. I haven't tried my previous version to confirm yet as it is getting late. Will test more tomorrow. Just m pay first observation since upgrading. Dominic
|
|
No the audio connect is something at the master - I've got the same issue On Tue, 14 Jun 2016, 01:49 g7npw, notifications@github.com wrote:
A J Corbett G0WFV |
|
That should of course read "auto" - damn predictive text! On Tue, 14 Jun 2016, 06:07 Tony Corbett, tonyc.uk@gmail.com wrote:
A J Corbett G0WFV |
|
Thanks Tony. I thought it could be a Brandmeister issue but as I'd just updated was worried it could be a bug. Dominic
|
|
On 14/06/2016 06:08, Tony Corbett wrote:
Quick update. Mentioned issue to Jon @ UK BM Master Server in Can your code be used to ensure a talk group remains local on the Cheers Dom G7NPW |
|
On 14/06/16 12:11, g7npw wrote:
Hi, Not in it's current state it will not, but it could be expanded to do 73 Simon |
|
On 14/06/2016 12:26, hacknix wrote:
I didn't have a specific application at present for it just wondered. I I was told TG91 was user activated one day but low and behold the next Cheers Dom G7NPW |
|
That's precisely the reason I wrote the ACL in the first place. Let me look into it. On 14 June 2016 13:41:44 BST, g7npw notifications@github.com wrote:
Sent from my Android device with K-9 Mail. Please excuse my brevity. |
This request provides Access Control support for DMR destination IDs (including Talkgroups).
This functionality can be enabled and access by four new fields in MMDVM.ini:
DstIDBlackListSlot1=
DstIDBlackListSlot2=
DstIDWhiteListSlot1=
DstIDWhiteListSlot2=
Each entry represents a comma-separated list of desitnation IDs to either allow (whitelist) or deny (blacklist).
The implementation of this is consistent with the existing implementation of the "Blacklist=" configuration option for source IDs.
Added new README.DMR_ACL with the following text:
/start
To use DMR Access Control you can add the following fields to your MMDVM.ini:
Blacklist= <comma separated list of source-id's to block on RF>
DstIdBlackListSlot1=
DstIdBlackListSlot2=
DstIdWhiteListSlot1=
DstIdWhiteListSlot2=
So, for example:
DstIdBlackListSlot1=91 - block the TG91 net.
DstIdWhiteSlot1=9.5057,9990 - allows TG9, APRS SMS Gateway and Echo.
If the whitelist is null or commented out, it is disabled.
The whitelist behaves slightly differently on Slot1 than is does on Slot2.
For Slot1, the whitelist will allow all IDs above 10000 and everything in the whitelist.
For Slot2, the whitelist will allow all IDs between 4000 and 5000, IDs above 10000 and everything in the whitelist.
You can use the blacklist with the whitelist if you want to specifically block IDs within the allowed ranges above.
For example, to block users from disconnecting the reflectors, you could block ID 4000.
To block users connecting to reflector 4400 you could add ID 4400 to the blacklist for that slot.
/end
This code has been tested on GB7FR and also by Peter G7RPG and is working well.