Restricting P25 groups

Help with P25 issues
Post Reply
ae4ml
Posts: 11
Joined: Thu Apr 12, 2018 10:56 am

Restricting P25 groups

Post by ae4ml »

I have looked on wikis and Facebook. I have seen the questions without answers.
How can I restrict what P25 talkgroups actually key up my repeater ?
I have only a couple talkgroups that I would like to hear come through the repeater.

Thanks

Mike
W1MSG
Posts: 29
Joined: Wed Apr 04, 2018 10:20 pm

Re: Restricting P25 groups

Post by W1MSG »

The only way you would be able to is to edit the P25Hosts.txt file and remove the ones you dont want. However in Pi-Star it pulls the current authorized talk groups from the Github site and it would overwrite any changes.

Craig
User avatar
N9OIG
Posts: 18
Joined: Wed Apr 11, 2018 3:28 pm
Location: SE Wisconsin
Contact:

Re: Restricting P25 groups

Post by N9OIG »

I've asked for this in the request section. Like Craig said is to delete the ones you dont want but, when it auto updates it will replace them. The only current option is to stop the auto updates.

Kevin
N9OIG
Kevin
N9OIG
N6MIK
Posts: 59
Joined: Wed Apr 18, 2018 12:53 am

Re: Restricting P25 groups

Post by N6MIK »

I asked the 'inverse' of this question - how to stop the nightly updates from erasing a custom p25hosts file. I suspect the same answer will get you what you want... drop a modified p25hosts file into the /root directory and it will be copied into the /usr/local/etc instead of the auto-updated version.

check out viewtopic.php?f=3&t=149
KR0SIV
Posts: 6
Joined: Mon May 07, 2018 12:57 am
Contact:

Re: Restricting P25 groups

Post by KR0SIV »

I would like to clarify a bit on how Pi-star, specifically in the case of P25Gateway handles talk group ids.

Lets say you've modified your P25Hosts list to include the following talk group ids.
50100, 50102 and 50103. No other talk groups are in your P25Hosts list in this example.

P25Gateway, the software that interfaces the P25 portion of pi-star with various P25 reflectors is used to steer your repeater to these talk groups (reflectors).

In the event you attempt to bring up a repeater using a talk group id that is not in the hosts list it will simply bring it up without steering it.

for example, using the talk groups I listed above. Let's say we are parked on 50100 and someone tries to bring up the repeater on talk group 10200 which in this example does not exist in our P25Hosts list. This will still bring up the repeater but it will stay on talk group 50100.

So while you can prevent someone from bringing up groups like North America for example (by removing them from your hosts list) if you choose, you cannot (currently) prevent said talk group from bringing up your repeater.
N6MIK
Posts: 59
Joined: Wed Apr 18, 2018 12:53 am

Re: Restricting P25 groups

Post by N6MIK »

Thanks for that explanation - it helps tremendously!

For a "local" TG then - it seems I need to stick the local TG into the hosts file with a bogus IP address (or 127.0.0.1?) so it pulls traffic away from the networked group, but it doesn't route anywhere. Is that right?
KR0SIV
Posts: 6
Joined: Mon May 07, 2018 12:57 am
Contact:

Re: Restricting P25 groups

Post by KR0SIV »

You could give that a try, I'm not 100% sure if that will work because the p25 Gateway on mmdvm will understand that there is nothing at that address and it will time out.

However that may still prevent audio frames from being passed elsewhere. Give it a try and let me know how that works for you an alternative would be to set up a p25 reflector and point unwanted talk groups to it.

Although if it comes to that let me know I would be willing to develop a simple python based server that will take the frames and simply throw them away so that way you don't get a time out and you don't have to use the reflector where it isn't needed.
N6MIK
Posts: 59
Joined: Wed Apr 18, 2018 12:53 am

Re: Restricting P25 groups

Post by N6MIK »

KR0SIV wrote: Tue May 15, 2018 12:33 pm ...Give it a try and let me know how that works for you an alternative would be to set up a p25 reflector and point unwanted talk groups to it.
I've got a P25 Reflector running, so I ran a tail of the log while I transmitted on the 'intended' TG for the reflector and verified the logs. I then switched to a TG that had no corresponding entry in the hosts file and transmitted again. The reflector still received and reflected traffic on the 'correct' TG, even though the radio was on another TG. So, it's clear that the reflector isn't concerned with the inbound TG ID.

Next, I added a "Local" TG to the host file with an IP of 127.0.0.1, port 41000.

Repeating the test by sending data to the intended TG, the logs flow as expected. Switching to the "local" TG, and transmitting, there was zero log activity on the reflector and the repeater repeated locally.

So - I think it's safe to say that a local TG needs to have a non-routable IP entry in the hosts file, or any transmission on the "local" TG will go out the last reflector connected.

N6MIK
Post Reply