|
Analog Bridge and HBBridge
David
Running an Allstar node to BM TG and it works great most of the time. Then every so often it partially disconnects from Brandmeister. The status page says its offline. If I restart the hbbridge side things begin to work for awhile. Anywhere from 6 hours to 3 days. When looking at the last heard on Brandmeister it shows audio coming in from analog but it is not putting it on a timeslot like it should. Am I missing something in the config? Or just a bug?
|
|
|
|
Re: Invalid command from BrandMeister
#brandmeister
Andrii Misyurko
I have a similar problem. How to fix it?
Traffic is not going to Brandmeister and back
|
|
|
|
Re: HBLink Testing
Cort N0MJS <n0mjs@...>
Some answers inline
Yes. In the hblink.cfg file, you may specify any number of masters and clients. There is no limit to the number you can create – there is only a practical limit with the resources of the computer you’re running it on. This would be a good time to note that multi-core doesn’t really help here. Python will only execute on a single core. So, all other things being roughly equal, a dual-core at 3GHz is going to be a better bet than 8 cores at 2GHz… Not that hblink really uses much processor anyway, but I don’t recall discussion of that on here, so thought I’d mention it.
All repeaters connected to the same master will share all traffic (if repeat is set to true). In confbridge_rules.py, create a “bridge” entry for each TS/TGID combination you wish to share. You make an entry in each bridge for each master you want to share traffic between. Example: Here’s an example for hblink.cfg with two masters. Each may have one or more repeaters connected: [MASTER-1] MODE: MASTER ENABLED: True REPEAT: True EXPORT_AMBE: False IP: PORT: 54000 PASSPHRASE: s3cr37w0rd GROUP_HANGTIME: 5 [MASTER-2] MODE: MASTER ENABLED: True REPEAT: True EXPORT_AMBE: False IP: PORT: 54001 PASSPHRASE: s3cr37w0rd GROUP_HANGTIME: 5 Now let’s say, for example, you want to share TS1/TGID100 between them. You’d need a bridge configuration like this (note the name of the bridge is arbitrary): BRIDGES = { ’TALKGROUP 100': [ {'SYSTEM': 'MASTER-1', 'TS': 1, 'TGID': 100, 'ACTIVE': True, 'TIMEOUT': 2, 'TO_TYPE': ’NONE', 'ON': [], 'OFF': []}, {'SYSTEM': ‘MASTER-2', 'TS': 1, 'TGID': 100, 'ACTIVE': True, 'TIMEOUT': 2, 'TO_TYPE': ’NONE', 'ON': [], 'OFF': []}, ], } Note, TIMEOUT is meaningless, since you’re we’re not talking about more advanced features. TO_TYPE is ‘NONE’ and ON and OFF are empty lists. ACTIVE is true to enable both of the systems (MASTER-1 and MASTER-2).
What you’re talking about doing is what confbridge is for. A whitelist is used for access control – what you’re really talking about is call routing between masters, and that’s what confbridge.py is for. Why? because pretty soon, you’ll probably decide that you want it to be TGID100 on one repeater and TGID200 on another that are connected. Whitelists can’t do that. They also cannot translate Timeslots either. Then as you grow a bit more, you may decide you want to only selectively turn on a connection between repeaters when a user wants it. hblink.py is intended to pretty much be a protocol stack for Homebrew repeater protocol. It’s not intended to handle call-routing functions – and what you’re talking about here is call-routing between MMDVM repeaters. To do all of this, you need to do nothing more than run confbridge.py instead of hblink.py and define the “bridges” you want to use. I’ll throw a bit more in here – let’s say you have three MMDVM repeaters, you want nothing shared between them. They’re connected to three masters, and you want TS1/TGID100 on repeater1 connected to TS1/TGID100 on repeater2 and TS2/TGID33 on repeater3… the bridge would look like this: BRIDGES = { ’MyRule1': [ {'SYSTEM': 'MASTER-1', 'TS': 1, 'TGID': 100, 'ACTIVE': True, 'TIMEOUT': 2, 'TO_TYPE': ’NONE', 'ON': [], 'OFF': []}, {'SYSTEM': ‘MASTER-2', 'TS': 1, 'TGID': 100, 'ACTIVE': True, 'TIMEOUT': 2, 'TO_TYPE': ’NONE', 'ON': [], 'OFF': []}, {'SYSTEM': ‘MASTER-3', 'TS': 2, 'TGID': 33, 'ACTIVE': True, 'TIMEOUT': 2, 'TO_TYPE': ’NONE', 'ON': [], 'OFF': []}, ], } Let’s say you want to do that again, only TS1/TGID3000 connecting all… that would look like: BRIDGES = { ’BRIDGE1': [ {'SYSTEM': 'MASTER-1', 'TS': 1, 'TGID': 100, 'ACTIVE': True, 'TIMEOUT': 2, 'TO_TYPE': ’NONE', 'ON': [], 'OFF': []}, {'SYSTEM': ‘MASTER-2', 'TS': 1, 'TGID': 100, 'ACTIVE': True, 'TIMEOUT': 2, 'TO_TYPE': ’NONE', 'ON': [], 'OFF': []}, {'SYSTEM': ‘MASTER-3', 'TS': 2, 'TGID': 33, 'ACTIVE': True, 'TIMEOUT': 2, 'TO_TYPE': ’NONE', 'ON': [], 'OFF': []}, ], ’BRIDGE2': [ {'SYSTEM': 'MASTER-1', 'TS': 1, 'TGID': 3000, 'ACTIVE': True, 'TIMEOUT': 2, 'TO_TYPE': ’NONE', 'ON': [], 'OFF': []}, {'SYSTEM': ‘MASTER-2', 'TS': 1, 'TGID': 3000, 'ACTIVE': True, 'TIMEOUT': 2, 'TO_TYPE': ’NONE', 'ON': [], 'OFF': []}, {'SYSTEM': ‘MASTER-3', 'TS': 1, 'TGID': 3000, 'ACTIVE': True, 'TIMEOUT': 2, 'TO_TYPE': ’NONE', 'ON': [], 'OFF': []}, ], } I hope this helps. A whitelist is an access control list that specifies something is accepted on ingress…. but it does not define what systems that traffic would egress on. In a sense, it’s only 1/2 of what you need to do the whole job. Yes, you could set up a fairly elaborate set of ingress access control lists (ACLs) to effectively achieve what you want, but it’s not really the right way because it doesn’t scale or allow more complex configurations. 0x49 DE N0MJS Cort Buffington 785-865-7206
|
|
|
|
Re: HBLink Testing
Nicola IT9FXF <onetechct@...>
Hi, I wanted to ask you if you can use confbridge connected to 2 hblink masters on the same computer. I made a small local network of testing and I would like to enable a TG for all connected repeaters and one in local to not commit all. Can you give me some advice? If there were any whitelist on the hblink master it would be very convenient to filter only the ones you need. At the moment I have 4 X MMDVM repeaters but we would like to connect others.Unfortunately from mmdvm we can do a whitelist only on the RF side and not on the network. I thank you in advance
|
|
|
|
Re: HBLink: Adhoc clients with routing rules, conferences etc
Cort N0MJS <n0mjs@...>
I don’t see it going beyond the ACL logic from the bridging apps: An (allow | deny) a list of subscriber IDs (list meaning multiple entries, including ranges) and the same for destination TGIDs… with the allow/drop action on ingress.
Those are basic sanity and security filters… really beyond that and we’re starting to talk more about selective call routing… which belongs elsewhere. 0x49 DE N0MJS
Cort Buffington 785-865-7206
|
|
|
|
Re: HBLink: Adhoc clients with routing rules, conferences etc
I agree with Cort, Getting to far afield of the basic premise of hblink would be a problem. In my opinion that type of traffic control would best be included in the bridge. That might make it a little more complex for HB_Bridge if a user wanted to control traffic through HB_Link and on to a Partner. As long as a simple pass everything config would just be hblink and HB_Bridge, I'm good.
Steve, N4IRS
|
|
|
|
Re: HBLink: Adhoc clients with routing rules, conferences etc
Cort N0MJS <n0mjs@...>
That would be in my part of the project, most likely.
I’d like to have the whole thing worked out first though… whitelists imply someone else will want a blacklist. For the whole system (most of you would call that a “master”)? Or based on a per-client connection? Do we just whitelist destination TGIDs? What about source subscriber IDs? When we have general consensus, and it doesn’t extend hblink.py too far (it was intended to be a protocol stack, not a full-blown application), I’ll add it. 0x49 DE N0MJS
Cort Buffington 785-865-7206
|
|
|
|
Re: HBLink: Adhoc clients with routing rules, conferences etc
Nicola IT9FXF <onetechct@...>
Hi Steve,
I read in this post that you were thinking of integrating a whitelist when using hblink as a simple master. It would be interesting. Have you planned something? Nicola
|
|
|
|
Re: hb_confbridge configuration
Stephen Brown - K1LNX
Well please excuse me... I've had my 1st dumbass moment for the day today... I had it statically setup on slot 1 and not 2 in the BM portal... so I'll go back to my regularly scheduled lurking now.... lol. I see the traffic now in the console as well as hitting my OpenSPOT :) Thanks guys!!! Stephen K1LNX
On Wed, Jan 24, 2018 at 10:57 AM, Steve N4IRS <szingman@...> wrote:
|
|
|
|
Re: hb_confbridge configuration
Are you seeing the traffic from BM in the log or console?
toggle quoted messageShow quoted text
On 1/24/2018 10:52 AM, Stephen Brown -
K1LNX wrote:
|
|
|
|
Re: hb_confbridge configuration
Stephen Brown - K1LNX
Oh yes... I do, I should have mentioned that.
On Wed, Jan 24, 2018 at 10:55 AM, Steve N4IRS <szingman@...> wrote:
|
|
|
|
Re: hb_confbridge configuration
Do you have TG 3100 setup as static on the self care page for that
DMR ID?
toggle quoted messageShow quoted text
On 1/24/2018 10:47 AM, Stephen Brown -
K1LNX wrote:
|
|
|
|
Re: hb_confbridge configuration
Stephen Brown - K1LNX
Thanks Steve and Cort, In that case you need multiple “master” instances set up and use the rules to bridge between them. I suspected maybe this was the case, so thanks for clarifying. Are you running hblink.py or hb_confbridge.py? hb_confbridge.py sub-class' (or calls if you wish) hblink.py I am running hb_confbridge.py. I understand the first piece now, but concerning the second piece (Brandmeister) should I be seeing traffic using the configuration I have? Thanks, Stephen K1LNX On Wed, Jan 24, 2018 at 10:48 AM, Steve N4IRS <szingman@...> wrote:
|
|
|
|
Re: hb_confbridge configuration
Stephen,
toggle quoted messageShow quoted text
Are you running hblink.py or hb_confbridge.py? hb_confbridge.py sub-class' (or calls if you wish) hblink.py Steve
On 1/24/2018 10:36 AM, Stephen Brown -
K1LNX wrote:
|
|
|
|
Re: hb_confbridge configuration
Cort N0MJS <n0mjs@...>
In that case you need multiple “master” instances set up and use the rules to bridge between them.
Cort Buffington 785-865-7206
|
|
|
|
hb_confbridge configuration
Stephen Brown - K1LNX
Hi guys, I am getting my feet wet with HBlink and doing some minimal testing. I had some questions on a few things: For starters, one planned use of a master is for my hotspots only, as such I have defined this: # hotspots [K1LNX-HOTSPOTS-MASTER] MODE: MASTER ENABLED: True REPEAT: False EXPORT_AMBE: False IP: PORT: 57890 PASSPHRASE: xxxxxxxxxxxxxxxxxxx GROUP_HANGTIME: 5 If I specify explicit bridging rules in hb_confbridge_rules.py, can I leave REPEAT: set to False? My understanding is that if it's set to TRUE it routes all traffic regardless. I am trying to explicitly route certain talkgroups to and from this master with 2-3 hotspots connected. Here is what I set in hb_confbridge_rules.py (note, K1LNX-REPEATERS-MASTER is another system built identical to the HOTSPOTS master): BRIDGES = { 'LNXNET': [ {'SYSTEM': 'K1LNX-HOTSPOTS-MASTER', 'TS': 2, 'TGID': 5780, 'ACTIVE': True, 'TIMEOUT': 2, 'TO_TYPE': 'NONE', 'ON': [], 'OFF': []}, {'SYSTEM': 'K1LNX-REPEATERS-MASTER', 'TS': 1, 'TGID': 5780, 'ACTIVE': True, 'TIMEOUT': 2, 'TO_TYPE': 'NONE', 'ON': [], 'OFF': []} ], I don't have any ability to test this yet, but I assume this will work as configured? I think this will pass traffic from "K1LNX-HOTSPOTS-MASTER" to "K1LNX-REPEATERS-MASTER" but what about passing to directly connected clients on the HOTSPOTS master? Next question is concerning a client connection to Brandmeister. I created a client in hblink.cfg: # Brandmeister 3108 [BM-3108] MODE: CLIENT ENABLED: True EXPORT_AMBE: False IP: PORT: 62030 MASTER_IP: 3108.repeater.net MASTER_PORT: 62031 PASSPHRASE: xxxxxxxxxx CALLSIGN: K1LNX RADIO_ID: xxxxxxxxx RX_FREQ: 436500000 TX_FREQ: 436500000 TX_POWER: 1 COLORCODE: 1 SLOTS: 2 LATITUDE: 035.9617 LONGITUDE: -083.9234 HEIGHT: 0 LOCATION: Knoxville, TN, USA DESCRIPTION: K1LNX MMDVM URL: SOFTWARE_ID: 20170620 PACKAGE_ID: MMDVM GROUP_HANGTIME: 5 OPTIONS: It seems to login to the server with no issues, so I created an entry for 3100 for testing to see if I can get traffic: 'BM-3100': [ {'SYSTEM': 'K1LNX-HOTSPOTS-MASTER', 'TS': 2, 'TGID': 3100, 'ACTIVE': True, 'TIMEOUT': 2, 'TO_TYPE': 'NONE', 'ON': [], 'OFF': []}, {'SYSTEM': 'BM-3108', 'TS': 2, 'TGID': 3100, 'ACTIVE': True, 'TIMEOUT': 2, 'TO_TYPE': 'NONE', 'ON': [], 'OFF': []}, ] I connected my OpenSPOT to the HOTSPOTS master, but I do not appear to be getting traffic from 3100. Do my configs look correct? Should this work as-is? tnx and 73 Stephen K1LNX
|
|
|
|
Re: Request for information
Lito,
toggle quoted messageShow quoted text
Hi and welcome. <https://github.com/n0mjs710/HBlink/tree/HB_Bridge> git clone -b HB_Bridge https://github.com/n0mjs710/HBlink.git Steve
On 1/22/2018 11:37 AM, Roselito de los
Reyes wrote:
|
|
|
|
Re: Request for information
Folks,
Thank you all so much for providing the information I requested. The results are helpful and somewhat telling. Keep it coming as new people run across the the post. 73, Steve N4IRS
|
|
|
|
Re: Request for information
DIAL Raspberry Pi2 latency_timer = 1 Ed W8VT
On 01/17/2018 09:14 AM, Steve N4IRS wrote:
We have been working on the next revision of Analog_Bridge. Along with adding features and refining settings, we are trying to squash bugs. While testing the NWDigital DV300u (ThumbDV) we encountered a problem with data transfer . Some of the packets were not being processed in the required window. The NWD DV3000u uses a FTDI chip to communicate with the host computer. Under Linux, or at least Debian the driver is the FTDI serial. On the machine under test, a older Dell 2950 with more then enough horsepower and no history of issues with USB, we were not getting data in a timely manner. There is a value that can be adjusted to resolve this. /sys/bus/usb-serial/devices/ttyUSB0/latency_timer. The default looks to be 16. The 2950 was set at 16. So far so good. Well, I have a machine running a full time DMR <---> D-Star bridge using two of the DV3000u. When I checked the latency_timer, it was set to 1. Huh? I know I did not change it.
|
|
|
|
Re: Request for information
Mike, AA9VI
Steve, mine is also 1 with Debian 8 Jessie.
|
|
|