Date   

Re: Error HBmonitor, Help me, please.

Paco EA7BHR
 

Hi guys.
First of all, sorry for my bad english. 
Talking about this issue, what web link are you using to update the peers and subscribers_ids?

Thanks.

EA7BHR - Paco

El 2 ago. 2018 9:41 p. m., <ea5gvk@...> escribió:
Thank you so much. Already solved. Thanks to the friend
KB5PBM
Super grateful, working perfectly.
Thank you all.
73 EA5GVK.



Re: island operation

Steve N4IRS
 

Ken,
You can run hblink as a Master.

On 8/3/2018 1:51 PM, Ken KE2N via Groups.Io wrote:
Lost the Internet here - probably for some time.  My ASL/DMR bridge stopped working because a connection to the 3102 master server is apparently required for my mmdvm to talk to the repeater, even though they sit on the same LAN.  Or perhaps a connection to the master is required for the repeater to talk to *anything*.

Is there something I can change in the repeater setup to have it talk to the mmdvm_bridge directly?  Or do I need to run another piece of software to emulate the action of the missing master?  

Thanks


island operation

Ken KE2N
 

Lost the Internet here - probably for some time.  My ASL/DMR bridge stopped working because a connection to the 3102 master server is apparently required for my mmdvm to talk to the repeater, even though they sit on the same LAN.  Or perhaps a connection to the master is required for the repeater to talk to *anything*.

Is there something I can change in the repeater setup to have it talk to the mmdvm_bridge directly?  Or do I need to run another piece of software to emulate the action of the missing master?  

Thanks


Re: Error HBmonitor, Help me, please.

EA5GVK Joaquin
 

Thank you so much. Already solved. Thanks to the friend
KB5PBM
Super grateful, working perfectly.
Thank you all.
73 EA5GVK.


DMRX Parrot was running DMRlink version 0.27b

Dylan KI7SBI
 

It had a great run. Updated to latest Master.
Thank you DVSwitch Team.

Dylan KI7SBI


Re: Error HBmonitor, Help me, please.

KB5PBM
 

I am currently using HBMonitor.  I had that issue.  I had to change the config file see below.  What I had to add is in bold.  The page doesn't display correctly with more than 4 Masters but the HBlink status screen below is all I am really looking at.

REPORT_NAME     = 'TARMA'  # Name of the monitored HBlink system
CONFIG_INC      = True                  # Include HBlink stats
BRIDGES_INC     = True                  # Include Bridge stats (confbrige.py)
DMRLINK_IP      = '192.168.10.236'           # HBlink's IP Address
DMRLINK_PORT    = 4321                  # HBlink's TCP reporting socket
HBLINK_IP       = '192.168.10.236'
HBLINK_PORT     = 4321
FREQUENCY       = 1                    # Frequency to push updates to web clients
WEB_SERVER_PORT = 8080                  # Has to be above 1024 if you're not running as root


Re: Error HBmonitor, Help me, please.

EA5GVK Joaquin
 

OK. Perfect. Sorry I do not know English well. I help with translators from English to Spanish. Thank you very much. I will wait for hbmonitor to be developed and tested. Thank you very much to all. A great work is done and hopefuls keep us going.


Re: Error HBmonitor, Help me, please.

JJ Cummings
 

At the end of the day, you should consider this pre-alpha code.  My suggestion to you is that you start to google things like the error that you got and poke around yourself.  It is understood that it may well be frustrating and time consuming.. but working through it on your own may well give you a much better understanding of python.  Not super helpful I know, but that's my best suggestion for you at this time.



On Thu, Aug 2, 2018 at 9:31 AM Corey Dean N3FE <n3fe@...> wrote:
I think Cort is trying to tell you it isn't even ready yet, so how could he help you with it if it isn't even ready for testing?

Corey  N3FE

On Thu, Aug 2, 2018 at 9:45 AM, <ea5gvk@...> wrote:
OK. Cort. But any help me? Many thx. Or any help step to step configure hbmonitor with hblink. 
THX Cort. But any help me. Is welcome



Re: Error HBmonitor, Help me, please.

Corey Dean N3FE <n3fe@...>
 

I think Cort is trying to tell you it isn't even ready yet, so how could he help you with it if it isn't even ready for testing?

Corey  N3FE

On Thu, Aug 2, 2018 at 9:45 AM, <ea5gvk@...> wrote:
OK. Cort. But any help me? Many thx. Or any help step to step configure hbmonitor with hblink. 
THX Cort. But any help me. Is welcome



Re: Error HBmonitor, Help me, please.

EA5GVK Joaquin
 

OK. Cort. But any help me? Many thx. Or any help step to step configure hbmonitor with hblink. 
THX Cort. But any help me. Is welcome


Re: Error HBmonitor, Help me, please.

Cort N0MJS <n0mjs@...>
 

Maybe I should explain a bit more here.

I will post a project on GitHub that is totally not ready for primetime for two reasons:

1) I then have version control, and between multiple computers I work on
2) There are technical folks among us who will try out software that’s not entirely functional and help with it

To that end, I need folks to understand that just because I posted hbmonitor to my GitHub account doesn’t mean there’s an expectation that it is ready to be used.

On Aug 2, 2018, at 7:51 AM, Cort N0MJS via Groups.Io <n0mjs@...> wrote:

Hbmonitor is completely unsupported.


On Aug 2, 2018, at 4:00 AM, ea5gvk@... wrote:

Any idea? Many thx

Cort Buffington
785-865-7206


Re: Error HBmonitor, Help me, please.

Cort N0MJS <n0mjs@...>
 

Hbmonitor is completely unsupported.


On Aug 2, 2018, at 4:00 AM, ea5gvk@... wrote:

Any idea? Many thx


Re: Error HBmonitor, Help me, please.

EA5GVK Joaquin
 

Any idea? Many thx


Direction: OpenBridge

Cort N0MJS <n0mjs@...>
 

Folks,

I have it on good authority that Brandmeister will be happy with us if we implement OpenBridge for connections to their servers and stop masquerading as MMDVM repeaters. That’s fair, and I’m pleased to have a path forward that causes them less consternation about our software.

I’ve asked Steve (Because he’s really good at this kind of stuff) to try and get some real documentation on Home-brew Repeater Protocol as BM implements it, which will help a lot. The problem today is that the only protocol specification I have is from the branch of HBP that DMR+ documented, while MMDVM and BM have moved in a slightly different direction. The document I have is incomplete, has errors we had to figure out, and at best speaks a strange dialect. The existing BM additions to HBP and documentation on OpenBridge reference the deltas between them and HBP…. without accurate base HBP protocol specifications, implementing changes to it are a bit shaky.

Why am I saying all of that? To let you all know this is going to take a little work before the real works starts.

And… to this end, I’m putting previous top priority (voice telemetry) on hold while I work on this. As soon as I resolve a structural issue with hblink.py moving to client identification based on socket address instead fo radio id, OpenBridge work will begin.

0x49 DE N0MJS

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


Re: Removing Validation from hblink.py master

Cort N0MJS <n0mjs@...>
 

Everyone following this thread…

First off – I have found the best technical way to match against socket address for validation instead of radio id. Making it efficient as possible involves saving the socket address as a tuple since on incoming packet, that requires no transformations. I looked at ways to optimize the client socket address lookup list and nothing really stood out as much different – all around 3.6uS (relative to my test system). String transformation on the other hand was about 12us.

Second off – looking through hblink.py and the applications… wow. This is going to be a pretty major PITA. To date, the primary mechanism for matching a source has been radio_id. The internal data structure that holds clients keys off of the radio_id. My choices are, change everything to key off of socket address instead, or build a second data structure with socket addresses.

The problem with changing it all to key on socket address instead of radio id is that this permeates EVERYTHING. It’s a major change, every application is affected, and the hbmonitor I was just getting off the ground is pretty much just going to be trashed.

The problem with creating a second structure to key on socket address is that there’s a lot of places where that’d still have to be correlated back to the radio ID structure – which is a time intensive process each time. And the biggest part of that is logging and debugging, where “Radio ID” no longer tells you the “source peer” in the system, which really is a deal-breaker to not have.

I’m going to hold off on changes for a while to see if a better method presents itself. Right now it looks like re-building it all with socket address as the peer identifier is the way to go…. and actually creates some nice efficiencies in processing I do not have now. The downside is that’s a “metric shit-ton” of re-writing. If I do that, I’ll need many iterations and a lot of testing, so I’ll create a branch to do it with and ask for volunteers to connect the “new” version with the “old version”, to BM, to MMDVMs, etc. and find problems.

Comments welcome

0x49 DE N0MJS

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


Error HBmonitor, Help me, please.

EA5GVK Joaquin
 

pi@raspberrypi:~/Applications/HBmonitor $ sudo python web_tables.py
INFO:root:web_tables.py starting up
INFO:root:ID ALIAS MAPPER: 'peer_ids.csv' is current, not downloaded
INFO:root:ID ALIAS MAPPER: 'subscriber_ids.csv' is current, not downloaded
INFO:root:ID ALIAS MAPPER: peer_ids dictionary is available
INFO:root:ID ALIAS MAPPER: subscriber_ids dictionary is available
Traceback (most recent call last):
  File "web_tables.py", line 404, in <module>
    reactor.connectTCP(HBLINK_IP, HBLINK_PORT, reportClientFactory())
NameError: name 'HBLINK_IP' is not defined


Re: Removing Validation from hblink.py master

Cort N0MJS <n0mjs@...>
 

I’ll bet that matching a tilde is much faster than a :

On Jul 31, 2018, at 8:45 PM, Mike KB8JNM <groupio@midnighteng.com> wrote:

Yes, after I wrote that, I realized there may be some confusion using a colon and would recommend using a comma or something else like a tilde
" ~ " and slot number so not to confuse it with a 'port' .

...mike/kb8jnm

On 7/31/2018 9:37 PM, Cort N0MJS via Groups.Io wrote:
I believe I just said that I’ll use the IP address and the port… or are you recommend it be a string concatenation of the dotted quad IP address, a colon, and the string representation of the port number?
I’ll be looking for the fastest way to do the match for each packet. I don’t mind spending processor time when a machine registers building the identifier then – a few cycles doesn’t bother me during registration, but here we’re also talking about a match that has to take place on every packet traversing the system * number of clients in the system.
Are you thinking that a string comprehension with an integer to string conversion is the fastest way to do that?
On Jul 31, 2018, at 7:52 PM, Mike KB8JNM <groupio@midnighteng.com> wrote:

Could it be - "IP:slot"
12.345.123.123:01

????????

Just a thought !

...mike/kb8jnm

On 7/30/2018 7:49 AM, Cort N0MJS via Groups.Io wrote:
Fair enough. That’s what I was looking for: Someone to present an argument to the contrary.
I still have the issue of identifying clients for local repeat… Really don’t want to use IP, which really means IP/Port — b/c as soon as I make it IP only, someone will have 2 behind the same NAT. May not be another clean way around it.
On Jul 30, 2018, at 4:14 AM, Matthew 2E0SIP <groups.io@marrold.co.uk> wrote:

Hi Cort,

I asked Brandmeister / DMR+ a very long time ago and they both said they do not validate the Repeater ID. They both send the Repeater ID of the connected client in messages MST -> RPT. I checked the source for MMDMV / DMRGateway sometime ago and whilst it conforms to the standard when sending a frame, it's a bit more liberal when receiving them, and doesn't validate the Repeater ID.

The MMDVM protocol was only ever intended to be "single hop" so I think it's a safe assumption that the intention was for the Repeater ID to be that of the last hop.

Overwriting it will work, but I think there is some value in having the actual source repeater ID when chaining applications together, such as confbridge and the parrot. That way you can see the source of the transmission to the Parrot in its own logs rather than just the ID of the confbridge.

Cheers

Cort Buffington
785-865-7206

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

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


Re: Removing Validation from hblink.py master

Mike KB8JNM
 

Yes, after I wrote that, I realized there may be some confusion using a colon and would recommend using a comma or something else like a tilde
" ~ " and slot number so not to confuse it with a 'port' .

...mike/kb8jnm

On 7/31/2018 9:37 PM, Cort N0MJS via Groups.Io wrote:
I believe I just said that I’ll use the IP address and the port… or are you recommend it be a string concatenation of the dotted quad IP address, a colon, and the string representation of the port number?
I’ll be looking for the fastest way to do the match for each packet. I don’t mind spending processor time when a machine registers building the identifier then – a few cycles doesn’t bother me during registration, but here we’re also talking about a match that has to take place on every packet traversing the system * number of clients in the system.
Are you thinking that a string comprehension with an integer to string conversion is the fastest way to do that?

On Jul 31, 2018, at 7:52 PM, Mike KB8JNM <groupio@midnighteng.com> wrote:

Could it be - "IP:slot"
12.345.123.123:01

????????

Just a thought !

...mike/kb8jnm

On 7/30/2018 7:49 AM, Cort N0MJS via Groups.Io wrote:
Fair enough. That’s what I was looking for: Someone to present an argument to the contrary.
I still have the issue of identifying clients for local repeat… Really don’t want to use IP, which really means IP/Port — b/c as soon as I make it IP only, someone will have 2 behind the same NAT. May not be another clean way around it.
On Jul 30, 2018, at 4:14 AM, Matthew 2E0SIP <groups.io@marrold.co.uk> wrote:

Hi Cort,

I asked Brandmeister / DMR+ a very long time ago and they both said they do not validate the Repeater ID. They both send the Repeater ID of the connected client in messages MST -> RPT. I checked the source for MMDMV / DMRGateway sometime ago and whilst it conforms to the standard when sending a frame, it's a bit more liberal when receiving them, and doesn't validate the Repeater ID.

The MMDVM protocol was only ever intended to be "single hop" so I think it's a safe assumption that the intention was for the Repeater ID to be that of the last hop.

Overwriting it will work, but I think there is some value in having the actual source repeater ID when chaining applications together, such as confbridge and the parrot. That way you can see the source of the transmission to the Parrot in its own logs rather than just the ID of the confbridge.

Cheers

Cort Buffington
785-865-7206

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


Re: Removing Validation from hblink.py master

Cort N0MJS <n0mjs@...>
 

I believe I just said that I’ll use the IP address and the port… or are you recommend it be a string concatenation of the dotted quad IP address, a colon, and the string representation of the port number?

I’ll be looking for the fastest way to do the match for each packet. I don’t mind spending processor time when a machine registers building the identifier then – a few cycles doesn’t bother me during registration, but here we’re also talking about a match that has to take place on every packet traversing the system * number of clients in the system.

Are you thinking that a string comprehension with an integer to string conversion is the fastest way to do that?

On Jul 31, 2018, at 7:52 PM, Mike KB8JNM <groupio@midnighteng.com> wrote:

Could it be - "IP:slot"
12.345.123.123:01

????????

Just a thought !

...mike/kb8jnm

On 7/30/2018 7:49 AM, Cort N0MJS via Groups.Io wrote:
Fair enough. That’s what I was looking for: Someone to present an argument to the contrary.
I still have the issue of identifying clients for local repeat… Really don’t want to use IP, which really means IP/Port — b/c as soon as I make it IP only, someone will have 2 behind the same NAT. May not be another clean way around it.
On Jul 30, 2018, at 4:14 AM, Matthew 2E0SIP <groups.io@marrold.co.uk> wrote:

Hi Cort,

I asked Brandmeister / DMR+ a very long time ago and they both said they do not validate the Repeater ID. They both send the Repeater ID of the connected client in messages MST -> RPT. I checked the source for MMDMV / DMRGateway sometime ago and whilst it conforms to the standard when sending a frame, it's a bit more liberal when receiving them, and doesn't validate the Repeater ID.

The MMDVM protocol was only ever intended to be "single hop" so I think it's a safe assumption that the intention was for the Repeater ID to be that of the last hop.

Overwriting it will work, but I think there is some value in having the actual source repeater ID when chaining applications together, such as confbridge and the parrot. That way you can see the source of the transmission to the Parrot in its own logs rather than just the ID of the confbridge.

Cheers

Cort Buffington
785-865-7206

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


Re: Removing Validation from hblink.py master

Mike KB8JNM
 

Could it be - "IP:slot"
12.345.123.123:01

????????

Just a thought !

...mike/kb8jnm

On 7/30/2018 7:49 AM, Cort N0MJS via Groups.Io wrote:
Fair enough. That’s what I was looking for: Someone to present an argument to the contrary.
I still have the issue of identifying clients for local repeat… Really don’t want to use IP, which really means IP/Port — b/c as soon as I make it IP only, someone will have 2 behind the same NAT. May not be another clean way around it.

On Jul 30, 2018, at 4:14 AM, Matthew 2E0SIP <groups.io@marrold.co.uk> wrote:

Hi Cort,

I asked Brandmeister / DMR+ a very long time ago and they both said they do not validate the Repeater ID. They both send the Repeater ID of the connected client in messages MST -> RPT. I checked the source for MMDMV / DMRGateway sometime ago and whilst it conforms to the standard when sending a frame, it's a bit more liberal when receiving them, and doesn't validate the Repeater ID.

The MMDVM protocol was only ever intended to be "single hop" so I think it's a safe assumption that the intention was for the Repeater ID to be that of the last hop.

Overwriting it will work, but I think there is some value in having the actual source repeater ID when chaining applications together, such as confbridge and the parrot. That way you can see the source of the transmission to the Parrot in its own logs rather than just the ID of the confbridge.

Cheers

Cort Buffington
785-865-7206

7761 - 7780 of 9775