Trying to setup a basic 'Parrot', however hb_confbridge.py is not matching the RADIO_ID


Matthew 2E0SIP
 

Hi all,

I'm trying to setup a basic parrot, which consists of the following-

hb_parrot (Master) - Provides Parrot Service

hblink (Master) - Allows clients to connect to the service

hb_confbridge (Client) - Conferences the two masters together, bridging audio from 'clients' to the Parrot

My MMDVM based hotspot has successfully connected to hblink, and hblink is relaying DMR frames to hb_confbridge, however they are failing client_datagramReceived RADIO_ID validation, as they are being recieved with the ID of my handheld rather than a client. I have verified this by adding an additional line of logging to hblink.py

I feel like I'm missing something obvious, or I've got my understanding wrong.

Thanks in advance,
Matthew
2E0SIP

PARROT
[MASTER-1] MODE: MASTER ENABLED: True REPEAT: True EXPORT_AMBE: False IP: 127.0.0.1 PORT: 54001 PASSPHRASE: passw0rd GROUP_HANGTIME: 5

hblink

[MASTER-1]

MODE: MASTER
ENABLED: True
REPEAT: True
EXPORT_AMBE: False
IP:
PORT: 54000
PASSPHRASE: passw0rd
GROUP_HANGTIME: 5

hb_confbridge

[PARROT]
MODE: CLIENT
ENABLED: True
EXPORT_AMBE: False
IP: 127.0.0.1
PORT: 54011
MASTER_IP: 127.0.0.1
MASTER_PORT: 54001
PASSPHRASE: passw0rd
CALLSIGN: 2E0SIP
RADIO_ID: 312001
RX_FREQ: 449000000
TX_FREQ: 444000000
TX_POWER: 25
COLORCODE: 1
SLOTS: 2
LATITUDE: 38.0000
LONGITUDE: -095.0000
HEIGHT: 75
LOCATION: Anywhere, USA
DESCRIPTION: This is a cool repeater
URL: www.w1abc.org
SOFTWARE_ID: HBlink
PACKAGE_ID: v0.1
GROUP_HANGTIME: 5
OPTIONS:

[MASTER]
MODE: CLIENT
ENABLED: True
EXPORT_AMBE: False
IP: 127.0.0.1
PORT: 54010
MASTER_IP: 127.0.0.1
MASTER_PORT: 54000
PASSPHRASE: passw0rd
CALLSIGN: 2E0SIP
RADIO_ID: 312002
RX_FREQ: 449000000
TX_FREQ: 444000000
TX_POWER: 25
COLORCODE: 1
SLOTS: 2
LATITUDE: 38.0000
LONGITUDE: -095.0000
HEIGHT: 75
LOCATION: Anywhere, USA
DESCRIPTION: This is a cool repeater
URL: www.w1abc.org
SOFTWARE_ID: HBlink
PACKAGE_ID: v0.1
GROUP_HANGTIME: 5
OPTIONS:


Matthew 2E0SIP
 

I switched to the HB_Bridge branch and it performed a little better, in that hb_confbridge was relaying the frames to the parrot, however the parrot was still ignoring them.

I did some digging and found this was due to the fact that hb_confbridge was relaying the frames with the Radio_ID of hblink, rather than that of the Parrots 'client', so they were dropped.

I've resolved it by re-writing the RADIO_ID of the frame is being relayed to a master. I will submit a PR in due course, however I think I must be missing something as I'm surprised this hasn't picked up in the past. 

Is it unusual / unsupported for conf_bridge to bridge two Masters? 

Thanks
Matthew
2E0SIP


Cort N0MJS <n0mjs@...>
 

Your configuration does not require running hblink.py at all. You only need parrot and hb_confbridge.py. I don’t have the time right now to write it all up, but as you’re modifying code and going to submit a PR based on not using the existing code correctly, I felt I should post something to stop you before you go to more unnecessary trouble.

hb_confbridge.py calls and uses everything hblink.py does and is…. it *adds* functionality, to hblink.py, so there’s no need to run a copy of each.




On Jul 13, 2017, at 7:37 PM, Matthew 2E0SIP <groups.io@...> wrote:

I switched to the HB_Bridge branch and it performed a little better, in that hb_confbridge was relaying the frames to the parrot, however the parrot was still ignoring them.

I did some digging and found this was due to the fact that hb_confbridge was relaying the frames with the Radio_ID of hblink, rather than that of the Parrots 'client', so they were dropped.

I've resolved it by re-writing the RADIO_ID of the frame is being relayed to a master. I will submit a PR in due course, however I think I must be missing something as I'm surprised this hasn't picked up in the past. 

Is it unusual / unsupported for conf_bridge to bridge two Masters? 

Thanks
Matthew
2E0SIP

--
Cort Buffington
H: +1-785-813-1501
M: +1-785-865-7206






Matthew 2E0SIP
 

Hi Both,
 
Richard - Thanks for sending your diagram, it helps to see things 'visually'

Cort - Thanks for the heads up. Now that you've mentioned it, its obvious that MMDVM clients could connect straight to hb_confbridge. Doh!
 
The code change adds about 5 lines, so not much is lost if it turns out to be unnecessary - although there may be a use case for my change.
 
We can pick this up when you get time - I'm in no huge rush.
 
Thanks again for your help,
 
Matthew
2E0SIP 


Cort N0MJS <n0mjs@...>
 

Mathew,

Good point. I did it that way to obfuscate the origin of the traffic to an upstream Network.

Let's not just change it, but make it a configurable option to either masquerade or preserve the source ID.

Sent from my iPhone

On Jul 13, 2017, at 8:01 PM, Matthew 2E0SIP <groups.io@...> wrote:

Hi Both,
 
Richard - Thanks for sending your diagram, it helps to see things 'visually'

Cort - Thanks for the heads up. Now that you've mentioned it, its obvious that MMDVM clients could connect straight to hb_confbridge. Doh!
 
The code change adds about 5 lines, so not much is lost if it turns out to be unnecessary - although there may be a use case for my change.
 
We can pick this up when you get time - I'm in no huge rush.
 
Thanks again for your help,
 
Matthew
2E0SIP 


Matthew 2E0SIP
 

Hi Cort,

On Fri, Jul 14, 2017 at 06:09 am, Cort N0MJS wrote:
Let's not just change it, but make it a configurable option to either masquerade or preserve the source ID.

To clarify, I am referring to the RADIO_ID variable in the HB_Link code, which is known as the 'Repeater ID' in the MMDVM protocol spec. I am not talking about the DMR ID of the radio that sent the transmission.

I don't mind making it a configurable option, however in the HB_Link implementation at least, if a Master receives a frame from a client, with a different RADIO_ID (Repeater ID) to the ID the client sent during the login process, it will be dropped.

Do you know if the Brandmeister / DMR+ implementations also validate the Repeater ID?  

Cheers
Matthew


OH1E Riku
 

i have this exact same problem.
i try create a small dmr network, but sending frames to masters are filtered because the radio id. what lines did you exacly changed to it accept any id?

you can recreate this problem very easly you need to hotspots.
create a master and parrot. configure them working propelly.
then connect with one more client who has different id than firstone, the parrot will filter them.

this issue is on hblink aswell it will filter them if you sending trafic between masters..


Matthew 2E0SIP
 

Hi Riku,

As it happens I've been using HB_Bridge today.

I've taken a look at the code, and HB_Bridge doesn't rewrite the RptrId, referred to as the radio_id in the code, but a 'master' will validate it on arrival to ensure its one of the connected clients.

So the following is currently impossible-


MMDVMHost --> ( HBLink Master | HBLink Client ) --> HBLink Master.

To make this work, its either necessary to re-write the RptrId as it passes through the intermediate instance of HBLink, or to not validate it on arrival at the master.

 


Mike Zingman - N4IRR
 

HB_Bridge does rewrite the repeater id.  See dmr_utils/ambe_bridge.py lines 453-455


Matthew 2E0SIP
 

Hi Mike,

Unless I'm missing something, that function from dmr_utils isn't imported into hb_confbridge.py. It looks like it's only present in HB_Bridge.py.

Also as far as I can tell it only rewrites the rptr_id on packets going Master to Client, It doesn't rewrite it when going Client to Master.

Cheers

Matthew

2E0SIP


OH1E Riku
 

heya, thanks for answers, it seems ppl understanding what is about.
is there any way to easily change the code to get this working?
the id of mmdvm and openspot (and connecting client of main hub) must be same to route any other place.. rptr_id i think is the issue
wanted also create multiple TG:s. for each tg need a separate master.. like a parrot is tg and main hub just route right tg for it.
creating mini dmr network what is self sustained in case other network its broken
de OH1E


Bob kc2cwt
 

Would be nice to see Hytrea repeater in thair ..

KC2CWT
Bob Schneider
kc2cwt@...
(914)497-5502


-----Original Message-----
From: OH1E Riku <riku@...>
To: DVSwitch@groups.io
Sent: Mon, 20 Nov 2017 6:06 PM
Subject: Re: [DVSwitch] Trying to setup a basic 'Parrot', however hb_confbridge.py is not matching the RADIO_ID

heya, thanks for answers, it seems ppl understanding what is about.
is there any way to easily change the code to get this working?
the id of mmdvm and openspot (and connecting client of main hub) must be same to route any other place.. rptr_id i think is the issue
wanted also create multiple TG:s. for each tg need a separate master.. like a parrot is tg and main hub just route right tg for it.
creating mini dmr network what is self sustained in case other network its broken
de OH1E


Matthew 2E0SIP
 

Hi Bob,

There is some software written by OE1KBC to convert the Hytera protocol to the MMDVM protocol available here - http://ham-dmr.at/index.php/download/
I don't have access to a Hytera repeater so I've not tested it personally, but I understand it works well. 

Riku, I will let the other guys comment on the best practices to setup what you need.

Cheers
Matthew
2E0SIP


Bob kc2cwt
 

Thanks i will have a look , Wen i have a min .

I just pick up a 2 Hytrea repeater i will give it a try



On 11/20/2017 09:05 PM, Matthew 2E0SIP wrote:

Hi Bob,

There is some software written by OE1KBC to convert the Hytera protocol to the MMDVM protocol available here - http://ham-dmr.at/index.php/download/
I don't have access to a Hytera repeater so I've not tested it personally, but I understand it works well. 

Riku, I will let the other guys comment on the best practices to setup what you need.

Cheers
Matthew
2E0SIP


-- 
Bob KC2CWT
Carmel NewYork USA
(914)497-5502


Steve N4IRS
 

As Matthew said, Kurt OE1KBC has a closed source Hytera to MMDVM solution. It should work to bring a Hytera into a HB Network. I asked for information on the protocol and was told it is proprietary. There is some information on the net and I think some other systems are built on the same protocol. That all being said, without Hytera repeaters and time, reverse engineering the Hytera protocol is not going to happen anytime soon.

73, Steve N4IRS

On 11/20/2017 09:05 PM, Matthew 2E0SIP wrote:

Hi Bob,

There is some software written by OE1KBC to convert the Hytera protocol to the MMDVM protocol available here - http://ham-dmr.at/index.php/download/
I don't have access to a Hytera repeater so I've not tested it personally, but I understand it works well. 

Riku, I will let the other guys comment on the best practices to setup what you need.

Cheers
Matthew
2E0SIP



Steve N4IRS
 

Matthew,
You are correct dmr_utils is not imported into hb_confbridge.py In your previous message you referenced HB_Bridge, where it is used.

73, Steve N4IRS

On 11/20/2017 04:23 AM, Matthew 2E0SIP wrote:

Hi Mike,

Unless I'm missing something, that function from dmr_utils isn't imported into hb_confbridge.py. It looks like it's only present in HB_Bridge.py.

Also as far as I can tell it only rewrites the rptr_id on packets going Master to Client, It doesn't rewrite it when going Client to Master.

Cheers

Matthew

2E0SIP