Date   

Re: MMDVM User Authentication

Rod - KC7AAD
 

I think white listing would be better. Deny all unless they match in a list.


Re: MMDVM User Authentication

Rod - KC7AAD
 

That out of the way...

Cort, I agree that by DMR ID would be the better way. It's easy enough to blacklist (or remove from whitelist) if a user shares his ID with others. 
I do agree that administratively the user issue is tough to control. We have a few folks in our group that seem to flaunt that they push the line. Even after outright banning a user, they still continue to try and push. This is no different.
We will change the passwords at intervals, and that takes care of them for a while, until someone leaks it out.
We have around 70 users connecting to 8 servers up here in the PNW. 1 of which we allow "public" access and do share those credentials. The others have specific talkgroups allowed through them.

The VPN solution might work, though to make it seamless, it would require some work on the pi-star device and / or the openspot device. Neither of those options are easy to implement, if even possible.
I have thought about standing up instances for each user, then they could 'auth' to their own. We are using Docker to run multiple instances on one VM, varying them by UDP ports and passwords. The problem becomes how much administration would there be of this, and could the user dynamically change his own TG group? Or do we just give him one set? I'd be interested to see how Brandmeister does their setup for each hotspot being able to set up its own TG deck lineup, and having hundreds (thousands?) or users!


Regardless, Cort.. thanks for your work. I think that making a black / white list approach makes sense, barring any better way to do this without changes here as well as to the hotspots, too. That coordinated effort might not be easy.

Rod / KC7AAD


Re: MMDVM User Authentication

Rod - KC7AAD
 

YES!


Re: Allstarling.org Contact

 

On 7/11/2018 8:03 AM, Chris WB4ULK via Groups.Io wrote:
You probably won’t like the reply IF you get one. I have had this issue as well and the reply I got was. “Get a mentor. “ lol
Don't expect the folks at ASL to hold your hand.  After all, this is a hobby, one that its creator recently passed away leaving a HUGE void to fill.  Some hams expect premium support for their free software, and then cop the attitude we see here when they don't get that.  Please understand that the folks at ASL have doing the best 'they' can - considering.  Let me explain...

When Jim Dixon died, the project of AllStarLink fell onto Jim's partner Steve RoDgers.  Steve hadn't been real active with ASL at the time Jim died because of his work.  At this time, the administration of ASL was the responsibility of Tim Sawyer.  There were several people that were immediately notified of Jim's death, and I was one of them.  I was asked by Steve RoDgers my opinion, and to help assemble people that would continue with the project.  I contacted Steve Zingman, and he agreed to take AllStarLink, and make it into a project of several people so (the organization) could survive the worst.  Steve did exactly that, and so AllStarLink Inc. was formed.  AllStarLink Inc. is a NON for profit entity whose goals are to insure the continuance of the project, with the vision and usefulness that Jim Dixon intended.  AllStarLink Inc. is currently four Board members and additionally two teams of folks, one for Admin, and one for developing and patching software (DEV). AllStarLink Inc., is responsible for many things, including but not limited to vetting licensed amateur radio operators and approving new ASL memberships, issuing ASL node numbers, paying hosting bills for dedicated servers which make the system accessible by its members/users, keeping said servers running, developing software, fixing bugs, adding new features, etc.

Whether you use XIPAR, HamVoip, or the official software of AllStarLink, every public user consumes resources of AllStarLink Inc.  Please understand it's not free to run AllStarlink, and donations of money and time from its users is greatly appreciated!

Are there things that could be done better - oh heck yea....   One of the things the Board members discussed this weekend is to revamp the website at allstarlink.org making it more user friendly.  Jim Dixon was a brilliant man, but there were things that were done that seemed to only make sense to him.  One of them is the fact that once you became a member, and logged into the ASL site, the links to the software downloads would magically disappear!  We have a laundry list of things that needs done, and we simply ask your patience as we recruit more helpers and work through the list.  So far it's been a full time job just keeping AllStarLink stable and reachable, let alone making improvements to its user interfaces and providing free support.

Kevin Custer W3KKC
Board Member
AllStarLink, Inc.


Re: DMRLink - bridge streams over writing.

Cort N0MJS <n0mjs@...>
 

Peter (and group),


* None of my code EVER plays favorites with a TGID based on some designator assigned by one of the “networks”. That would go completely against what I stand for with these projects.

* Bridge.py is a retired application. It hasn’t been developed for some time and is not supported.


The goal of the contention handler routines was to keep something like this from happening. I suspect one of two scenarios – the contention handler is outright failing and sending the wrong traffic, or it’s failing not quite outright and sending BOTH streams to the repeater, which is picking the “other” stream.

I’d really like to figure out which of those things is happening. In IPSC, Motorola has some kind of convoluted (to me) method of determining who gets access to the channel. I’m sure it makes sense to them, but when you’re reverse engineering…. I really am not entirely sure how they make the choice, but it appears significantly more complicated than “who got here first”.

Can anyone duplicate this behavior with confbridge.py? If so, then I’ll dig into it for sure. If it’s just bridge.py…. then I think the best answer I have is to move to confbridge, then we’ll deal with it if it comes back. I know that’s not the answer Peter wants to hear… but it’s the one I have.

0x49 DE N0MJS


On Jul 11, 2018, at 5:11 AM, Peter M0NWI <peter-martin@...> wrote:

Cort,

As you know I've got a fairly stable DMRLink bridge, this hosts 8 repeaters.  I was asked by one keeper to link the local S2TG9 from repeater A, to  repeater B S1TG9, I added both way rules to the bridge.py files, and it seemed to be OK, when user on A keys, output is send to the repeater B no problem.

Then I got reports that while listening on repeater B (connected to bridge Master B), to the stream from repeater A (bridge Master A), if another stream arrived into repeater B, same slot, different TG, say a National or International group from Master C in the same bridge, repeater B would drop the TG9 stream and play out the new Master C stream.

I thought that as the repeater B (Master B) was already outputting network traffic, it would ignore further traffic until the first stream finished, and a hang time had expired. 

Wonder if because they are streaming from different Masters in the same bridge, that that scenario hasn't been considered, and so hold off is not invoked?

Is there a priority that can/has been set within the streams, which is allow the national groups to take precedence over the local traffic?

73,
Peter



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






Re: Allstarling.org Contact

Chris WB4ULK
 

You probably won’t like the reply IF you get one. I have had this issue as well and the reply I got was. “Get a mentor. “ lol


DMRLink - bridge streams over writing.

Peter M0NWI
 

Cort,

As you know I've got a fairly stable DMRLink bridge, this hosts 8 repeaters.  I was asked by one keeper to link the local S2TG9 from repeater A, to  repeater B S1TG9, I added both way rules to the bridge.py files, and it seemed to be OK, when user on A keys, output is send to the repeater B no problem.

Then I got reports that while listening on repeater B (connected to bridge Master B), to the stream from repeater A (bridge Master A), if another stream arrived into repeater B, same slot, different TG, say a National or International group from Master C in the same bridge, repeater B would drop the TG9 stream and play out the new Master C stream.

I thought that as the repeater B (Master B) was already outputting network traffic, it would ignore further traffic until the first stream finished, and a hang time had expired. 

Wonder if because they are streaming from different Masters in the same bridge, that that scenario hasn't been considered, and so hold off is not invoked?

Is there a priority that can/has been set within the streams, which is allow the national groups to take precedence over the local traffic?

73,
Peter



Re: Allstarling.org Contact

Mike KB8JNM
 

On 7/10/2018 11:55 AM, David KG5RDF wrote:
That did not work, sorry senior moment.

-------- Original message --------
From: David KG5RDF <David@...>
Date: 7/10/18 10:44 AM (GMT-06:00)
Subject: Re: [DVSwitch] Allstarling.org Contact

Mike, 

(Off List)

Thanks, I will look for the list to join. We have several nodes. The issue we are having, is the Allstarlink.org servers forget about registered nodes in operation. This issue is happening across the allstar community. It just hit or miss, if your nodes gets effected. Yesterday, I had to abandon a node 47613, that has been in operation for registration/connection issues and use a different node number to get the repetear linked site back up. Having a successful ping of allstarlink.org does not indicate that you will be able to connect again. Most of our effected nodes, will come around after a few hours after a reboot.

I just want to make sure the right people are aware of this issue.

Thank you for the reply!

David KG5RDF
nctc.info

-------- Original message --------
From: Mike KB8JNM <groupio@...>
Date: 7/10/18 8:04 AM (GMT-06:00)
Subject: Re: [DVSwitch] Allstarling.org Contact

Well David,
Probably should join the app_rpt mail list but,

If I understand your issue
Your issue is a matter of registration from your system.

Look in your iax.conf and see that you have a line with correct password data like this....

register = 48396:9b3e98a6aacd1@...    ; This must be changed to your node number, password
                                                    ; remove the leading ";"

You may need to verify your password for type error by checking it against that stored at the node data at allstarlink.org

Once that is rx and logged, your IP connection data will go into the list spread to all nodes within about 20 minutes and show in the list of connectable nodes
at allstarlink.org

So, if you have verified that is correct,and still having a issue, let me know. And state the node number in question.


Re: Allstarling.org Contact

David KG5RDF
 

That did not work, sorry senior moment.

-------- Original message --------
From: David KG5RDF <David@...>
Date: 7/10/18 10:44 AM (GMT-06:00)
To: main@DVSwitch.groups.io
Subject: Re: [DVSwitch] Allstarling.org Contact

Mike, 

(Off List)

Thanks, I will look for the list to join. We have several nodes. The issue we are having, is the Allstarlink.org servers forget about registered nodes in operation. This issue is happening across the allstar community. It just hit or miss, if your nodes gets effected. Yesterday, I had to abandon a node 47613, that has been in operation for registration/connection issues and use a different node number to get the repetear linked site back up. Having a successful ping of allstarlink.org does not indicate that you will be able to connect again. Most of our effected nodes, will come around after a few hours after a reboot.

I just want to make sure the right people are aware of this issue.

Thank you for the reply!

David KG5RDF
nctc.info
http://stats.allstarlink.org/getstatus.cgi?47115

-------- Original message --------
From: Mike KB8JNM <groupio@...>
Date: 7/10/18 8:04 AM (GMT-06:00)
To: main@DVSwitch.groups.io
Subject: Re: [DVSwitch] Allstarling.org Contact

Well David,
Probably should join the app_rpt mail list but,

If I understand your issue
Your issue is a matter of registration from your system.

Look in your iax.conf and see that you have a line with correct password data like this....

register = 48396:9b3e98a6aacd1@...    ; This must be changed to your node number, password
                                                    ; remove the leading ";"

You may need to verify your password for type error by checking it against that stored at the node data at allstarlink.org

Once that is rx and logged, your IP connection data will go into the list spread to all nodes within about 20 minutes and show in the list of connectable nodes
at allstarlink.org

So, if you have verified that is correct,and still having a issue, let me know. And state the node number in question.


Re: Allstarling.org Contact

David KG5RDF
 

Mike, 

(Off List)

Thanks, I will look for the list to join. We have several nodes. The issue we are having, is the Allstarlink.org servers forget about registered nodes in operation. This issue is happening across the allstar community. It just hit or miss, if your nodes gets effected. Yesterday, I had to abandon a node 47613, that has been in operation for registration/connection issues and use a different node number to get the repetear linked site back up. Having a successful ping of allstarlink.org does not indicate that you will be able to connect again. Most of our effected nodes, will come around after a few hours after a reboot.

I just want to make sure the right people are aware of this issue.

Thank you for the reply!

David KG5RDF
nctc.info
http://stats.allstarlink.org/getstatus.cgi?47115

-------- Original message --------
From: Mike KB8JNM <groupio@...>
Date: 7/10/18 8:04 AM (GMT-06:00)
To: main@DVSwitch.groups.io
Subject: Re: [DVSwitch] Allstarling.org Contact

Well David,
Probably should join the app_rpt mail list but,

If I understand your issue
Your issue is a matter of registration from your system.

Look in your iax.conf and see that you have a line with correct password data like this....

register = 48396:9b3e98a6aacd1@...    ; This must be changed to your node number, password
                                                    ; remove the leading ";"

You may need to verify your password for type error by checking it against that stored at the node data at allstarlink.org

Once that is rx and logged, your IP connection data will go into the list spread to all nodes within about 20 minutes and show in the list of connectable nodes
at allstarlink.org

So, if you have verified that is correct,and still having a issue, let me know. And state the node number in question.


Re: Strange announcement after each keyup after about a day of running

Steve N4IRS
 

The has been no change in MMDVM_Bridge. Aanlog_Bridge has had the timer for quite a while. I do not know if there was a change in the loop detector on the BM side.

Steve

On 7/10/2018 9:45 AM, Mike KB8JNM wrote:
Funny, I did not have a issue till running apt update /upgrade and the timing issue was adjusted and went away..
So a change in the code ? My previous was installed/updated on about June 12th or so.


Re: Strange announcement after each keyup after about a day of running

Mike KB8JNM
 

Funny, I did not have a issue till running apt update /upgrade and the timing issue was adjusted and went away..
So a change in the code ? My previous was installed/updated on about June 12th or so.


Re: Allstarling.org Contact

Mike KB8JNM
 

Well David,
Probably should join the app_rpt mail list but,

If I understand your issue
Your issue is a matter of registration from your system.

Look in your iax.conf and see that you have a line with correct password data like this....

register = 48396:9b3e98a6aacd1@...    ; This must be changed to your node number, password
                                                    ; remove the leading ";"

You may need to verify your password for type error by checking it against that stored at the node data at allstarlink.org

Once that is rx and logged, your IP connection data will go into the list spread to all nodes within about 20 minutes and show in the list of connectable nodes
at allstarlink.org

So, if you have verified that is correct,and still having a issue, let me know. And state the node number in question.


Allstarling.org Contact

David KG5RDF
 

Have sent a message via the allstarlink.org, but did not hear back. Does anyone know who I can talk to at Allstarlink.org about node registration dropping off the servers?

Thanks David


Re: "MSTNAK Received" after "Repeater Configuration Sent" #brandmeister

HB9FXQ, Frank Werner-Krippendorf
 

The Export AMBE was not working - created a PR: https://github.com/n0mjs710/HBlink/pull/22/files


73

Frank


On 07/09/2018 06:54 PM, HB9FXQ, Frank Werner-Krippendorf wrote:

Thanks Steve

To those who struggle with the same situation: In this case it was the format of the LON "LONGITUDE: 007.4703"

73

HB9FXQ


On 07/09/2018 06:21 PM, Steve N4IRS wrote:
Frank,
Unfortunately, BM does not tells us much about what it does not like in a configuration. I suggest you use the stock client configuration. Change as little as possible. If login goes well, change a couple of fields and retry.

73, Steve N4IRS

On 7/9/2018 11:55 AM, mail@... wrote:
Hi

Trying to get HBlink to connect to Brandmeister without success:

Console output:

(py2_dmr) ➜  HBlink git:(master) python hblink.py
DEBUG 2018-07-09 17:45:39,910 Logging system started, anything from here on gets logged
INFO 2018-07-09 17:45:39,910 HBlink TCP reporting server configured
DEBUG 2018-07-09 17:45:39,910 Periodic reporting loop started
INFO 2018-07-09 17:45:39,910 HBlink 'HBlink.py' (c) 2016 N0MJS & the K0USY Group - SYSTEM STARTING...
DEBUG 2018-07-09 17:45:39,910 (HOTSPOT-dev) Client maintenance loop started
INFO 2018-07-09 17:45:39,911 (HOTSPOT-dev) Sending login request to master 194.146.121.130:62031
DEBUG 2018-07-09 17:45:39,911 CLIENT instance created: HOTSPOT-dev, <__main__.HBSYSTEM instance at 0x7fe2cae29ea8>
INFO 2018-07-09 17:45:39,967 (HOTSPOT-dev) Repeater Login ACK Received with 32bit ID: 497425309
INFO 2018-07-09 17:45:40,016 (HOTSPOT-dev) Repeater Authentication Accepted
INFO 2018-07-09 17:45:40,017 (HOTSPOT-dev) Repeater Configuration Sent
WARNING 2018-07-09 17:45:40,076 (HOTSPOT-dev) MSTNAK Received. Resetting connection to the Master.
DEBUG 2018-07-09 17:45:44,915 (HOTSPOT-dev) Client maintenance loop started
INFO 2018-07-09 17:45:44,916 (HOTSPOT-dev) Sending login request to master 194.146.121.130:62031
INFO 2018-07-09 17:45:45,007 (HOTSPOT-dev) Repeater Login ACK Received with 32bit ID: 1757719149
INFO 2018-07-09 17:45:45,057 (HOTSPOT-dev) Repeater Authentication Accepted
INFO 2018-07-09 17:45:45,057 (HOTSPOT-dev) Repeater Configuration Sent
WARNING 2018-07-09 17:45:45,112 (HOTSPOT-dev) MSTNAK Received. Resetting connection to the Master.
.... 
.... 
 
Anyone could guess what's wrong with my config file? Tried various master servers. All same behaviour
using Git master with last commit 416ab12c5ff582665c2e5af994c4bea6b024de0d


# PROGRAM-WIDE PARAMETERS GO HERE
# PATH - working path for files, leave it alone unless you NEED to change it
# PING_TIME - the interval that clients will ping the master, and re-try registraion
#           - how often the Master maintenance loop runs
# MAX_MISSED - how many pings are missed before we give up and re-register
#           - number of times the master maintenance loop runs before de-registering a client
[GLOBAL]
PATH: ./
PING_TIME: 5
MAX_MISSED: 3
 
 
# NOT YET WORKING: NETWORK REPORTING CONFIGURATION
#   Enabling "REPORT" will configure a socket-based reporting
#   system that will send the configuration and other items
#   to a another process (local or remote) that may process
#   the information for some useful purpose, like a web dashboard.
#
#   REPORT - True to enable, False to disable
#   REPORT_INTERVAL - Seconds between reports
#   REPORT_PORT - TCP port to listen on if "REPORT_NETWORKS" = NETWORK
#   REPORT_CLIENTS - comma separated list of IPs you will allow clients
#       to connect on. Entering a * will allow all.
#
# ****FOR NOW MUST BE TRUE - USE THE LOOPBACK IF YOU DON'T USE THIS!!!****
[REPORTS]
REPORT: True
REPORT_INTERVAL: 60
REPORT_PORT: 4321
REPORT_CLIENTS: 127.0.0.1
 
 
# SYSTEM LOGGER CONFIGURAITON
#   This allows the logger to be configured without chaning the individual
#   python logger stuff. LOG_FILE should be a complete path/filename for *your*
#   system -- use /dev/null for non-file handlers.
#   LOG_HANDERLS may be any of the following, please, no spaces in the
#   list if you use several:
#       null
#       console
#       console-timed
#       file
#       file-timed
#       syslog
#   LOG_LEVEL may be any of the standard syslog logging levels, though
#   as of now, DEBUG, INFO, WARNING and CRITICAL are the only ones
#   used.
#
[LOGGER]
LOG_FILE: /tmp/hblink.log
LOG_HANDLERS: console-timed
LOG_LEVEL: DEBUG
LOG_NAME: HBlink
 
# DOWNLOAD AND IMPORT SUBSCRIBER, PEER and TGID ALIASES
# Ok, not the TGID, there's no master list I know of to download
# This is intended as a facility for other applcations built on top of
# HBlink to use, and will NOT be used in HBlink directly.
# STALE_DAYS is the number of days since the last download before we
# download again. Don't be an ass and change this to less than a few days.
[ALIASES]
TRY_DOWNLOAD: True
PATH: ./
PEER_FILE: peer_ids.csv
SUBSCRIBER_FILE: subscriber_ids.csv
TGID_FILE: talkgroup_ids.csv
STALE_DAYS: 7
 
# EXPORT AMBE DATA
# This is for exporting AMBE audio frames to an an "external" process for
# decoding or other nefarious actions.
[AMBE]
EXPORT_IP: 127.0.0.1
EXPORT_PORT: 1234
 
# MASTER INSTANCES - DUPLICATE SECTION FOR MULTIPLE MASTERS
# HomeBrew Protocol Master instances go here.
# IP may be left blank if there's one interface on your system.
# Port should be the port you want this master to listen on. It must be unique
# and unused by anything else.
# Repeat - if True, the master repeats traffic to clients, False, it does nothing.
[MASTER-1]
MODE: MASTER
ENABLED: False
REPEAT: True
EXPORT_AMBE: False
IP:
PORT: 54000
PASSPHRASE: s3cr37w0rd
GROUP_HANGTIME: 5
 
# CLIENT INSTANCES - DUPLICATE SECTION FOR MULTIPLE CLIENTS
# There are a LOT of errors in the HB Protocol specifications on this one!
# MOST of these items are just strings and will be properly dealt with by the program
# The TX & RX Frequencies are 9-digit numbers, and are the frequency in Hz.
# Latitude is an 8-digit unsigned floating point number.
# Longitude is a 9-digit signed floating point number.
# Height is in meters
# Setting Loose to True relaxes the validation on packets received from the master.
# This will allow HBlink to connect to a non-compliant system such as XLXD, DMR+ etc.
[HOTSPOT-dev]
MODE: CLIENT
ENABLED: True
LOOSE: True
EXPORT_AMBE: False
IP: 
PORT: 54001
MASTER_IP: master.ham-dmr.be
MASTER_PORT: 62031
PASSPHRASE: passw0rd
CALLSIGN: <<<<used my callsign here, 7-digits>>>>>>  
RADIO_ID: <<<<used my DMR ID here, 7-digits>>>>>>
RX_FREQ: 435400000
TX_FREQ: 435400000
TX_POWER: 1
COLORCODE: 1
SLOTS: 2
LATITUDE: 46.9854
LONGITUDE: 7.4703
HEIGHT: 101
LOCATION:  Anywhere, CH
DESCRIPTION: My Callsign here
SOFTWARE_ID: 20170620
PACKAGE_ID: MMDVM_HBlink
GROUP_HANGTIME: 5
OPTIONS: 

Best 73
HB9FXQ, Frank
 




Re: "MSTNAK Received" after "Repeater Configuration Sent" #brandmeister

HB9FXQ, Frank Werner-Krippendorf
 

Thanks Steve

To those who struggle with the same situation: In this case it was the format of the LON "LONGITUDE: 007.4703"

73

HB9FXQ


On 07/09/2018 06:21 PM, Steve N4IRS wrote:
Frank,
Unfortunately, BM does not tells us much about what it does not like in a configuration. I suggest you use the stock client configuration. Change as little as possible. If login goes well, change a couple of fields and retry.

73, Steve N4IRS

On 7/9/2018 11:55 AM, mail@... wrote:
Hi

Trying to get HBlink to connect to Brandmeister without success:

Console output:

(py2_dmr) ➜  HBlink git:(master) python hblink.py
DEBUG 2018-07-09 17:45:39,910 Logging system started, anything from here on gets logged
INFO 2018-07-09 17:45:39,910 HBlink TCP reporting server configured
DEBUG 2018-07-09 17:45:39,910 Periodic reporting loop started
INFO 2018-07-09 17:45:39,910 HBlink 'HBlink.py' (c) 2016 N0MJS & the K0USY Group - SYSTEM STARTING...
DEBUG 2018-07-09 17:45:39,910 (HOTSPOT-dev) Client maintenance loop started
INFO 2018-07-09 17:45:39,911 (HOTSPOT-dev) Sending login request to master 194.146.121.130:62031
DEBUG 2018-07-09 17:45:39,911 CLIENT instance created: HOTSPOT-dev, <__main__.HBSYSTEM instance at 0x7fe2cae29ea8>
INFO 2018-07-09 17:45:39,967 (HOTSPOT-dev) Repeater Login ACK Received with 32bit ID: 497425309
INFO 2018-07-09 17:45:40,016 (HOTSPOT-dev) Repeater Authentication Accepted
INFO 2018-07-09 17:45:40,017 (HOTSPOT-dev) Repeater Configuration Sent
WARNING 2018-07-09 17:45:40,076 (HOTSPOT-dev) MSTNAK Received. Resetting connection to the Master.
DEBUG 2018-07-09 17:45:44,915 (HOTSPOT-dev) Client maintenance loop started
INFO 2018-07-09 17:45:44,916 (HOTSPOT-dev) Sending login request to master 194.146.121.130:62031
INFO 2018-07-09 17:45:45,007 (HOTSPOT-dev) Repeater Login ACK Received with 32bit ID: 1757719149
INFO 2018-07-09 17:45:45,057 (HOTSPOT-dev) Repeater Authentication Accepted
INFO 2018-07-09 17:45:45,057 (HOTSPOT-dev) Repeater Configuration Sent
WARNING 2018-07-09 17:45:45,112 (HOTSPOT-dev) MSTNAK Received. Resetting connection to the Master.
.... 
.... 
 
Anyone could guess what's wrong with my config file? Tried various master servers. All same behaviour
using Git master with last commit 416ab12c5ff582665c2e5af994c4bea6b024de0d


# PROGRAM-WIDE PARAMETERS GO HERE
# PATH - working path for files, leave it alone unless you NEED to change it
# PING_TIME - the interval that clients will ping the master, and re-try registraion
#           - how often the Master maintenance loop runs
# MAX_MISSED - how many pings are missed before we give up and re-register
#           - number of times the master maintenance loop runs before de-registering a client
[GLOBAL]
PATH: ./
PING_TIME: 5
MAX_MISSED: 3
 
 
# NOT YET WORKING: NETWORK REPORTING CONFIGURATION
#   Enabling "REPORT" will configure a socket-based reporting
#   system that will send the configuration and other items
#   to a another process (local or remote) that may process
#   the information for some useful purpose, like a web dashboard.
#
#   REPORT - True to enable, False to disable
#   REPORT_INTERVAL - Seconds between reports
#   REPORT_PORT - TCP port to listen on if "REPORT_NETWORKS" = NETWORK
#   REPORT_CLIENTS - comma separated list of IPs you will allow clients
#       to connect on. Entering a * will allow all.
#
# ****FOR NOW MUST BE TRUE - USE THE LOOPBACK IF YOU DON'T USE THIS!!!****
[REPORTS]
REPORT: True
REPORT_INTERVAL: 60
REPORT_PORT: 4321
REPORT_CLIENTS: 127.0.0.1
 
 
# SYSTEM LOGGER CONFIGURAITON
#   This allows the logger to be configured without chaning the individual
#   python logger stuff. LOG_FILE should be a complete path/filename for *your*
#   system -- use /dev/null for non-file handlers.
#   LOG_HANDERLS may be any of the following, please, no spaces in the
#   list if you use several:
#       null
#       console
#       console-timed
#       file
#       file-timed
#       syslog
#   LOG_LEVEL may be any of the standard syslog logging levels, though
#   as of now, DEBUG, INFO, WARNING and CRITICAL are the only ones
#   used.
#
[LOGGER]
LOG_FILE: /tmp/hblink.log
LOG_HANDLERS: console-timed
LOG_LEVEL: DEBUG
LOG_NAME: HBlink
 
# DOWNLOAD AND IMPORT SUBSCRIBER, PEER and TGID ALIASES
# Ok, not the TGID, there's no master list I know of to download
# This is intended as a facility for other applcations built on top of
# HBlink to use, and will NOT be used in HBlink directly.
# STALE_DAYS is the number of days since the last download before we
# download again. Don't be an ass and change this to less than a few days.
[ALIASES]
TRY_DOWNLOAD: True
PATH: ./
PEER_FILE: peer_ids.csv
SUBSCRIBER_FILE: subscriber_ids.csv
TGID_FILE: talkgroup_ids.csv
STALE_DAYS: 7
 
# EXPORT AMBE DATA
# This is for exporting AMBE audio frames to an an "external" process for
# decoding or other nefarious actions.
[AMBE]
EXPORT_IP: 127.0.0.1
EXPORT_PORT: 1234
 
# MASTER INSTANCES - DUPLICATE SECTION FOR MULTIPLE MASTERS
# HomeBrew Protocol Master instances go here.
# IP may be left blank if there's one interface on your system.
# Port should be the port you want this master to listen on. It must be unique
# and unused by anything else.
# Repeat - if True, the master repeats traffic to clients, False, it does nothing.
[MASTER-1]
MODE: MASTER
ENABLED: False
REPEAT: True
EXPORT_AMBE: False
IP:
PORT: 54000
PASSPHRASE: s3cr37w0rd
GROUP_HANGTIME: 5
 
# CLIENT INSTANCES - DUPLICATE SECTION FOR MULTIPLE CLIENTS
# There are a LOT of errors in the HB Protocol specifications on this one!
# MOST of these items are just strings and will be properly dealt with by the program
# The TX & RX Frequencies are 9-digit numbers, and are the frequency in Hz.
# Latitude is an 8-digit unsigned floating point number.
# Longitude is a 9-digit signed floating point number.
# Height is in meters
# Setting Loose to True relaxes the validation on packets received from the master.
# This will allow HBlink to connect to a non-compliant system such as XLXD, DMR+ etc.
[HOTSPOT-dev]
MODE: CLIENT
ENABLED: True
LOOSE: True
EXPORT_AMBE: False
IP: 
PORT: 54001
MASTER_IP: master.ham-dmr.be
MASTER_PORT: 62031
PASSPHRASE: passw0rd
CALLSIGN: <<<<used my callsign here, 7-digits>>>>>>  
RADIO_ID: <<<<used my DMR ID here, 7-digits>>>>>>
RX_FREQ: 435400000
TX_FREQ: 435400000
TX_POWER: 1
COLORCODE: 1
SLOTS: 2
LATITUDE: 46.9854
LONGITUDE: 7.4703
HEIGHT: 101
LOCATION:  Anywhere, CH
DESCRIPTION: My Callsign here
SOFTWARE_ID: 20170620
PACKAGE_ID: MMDVM_HBlink
GROUP_HANGTIME: 5
OPTIONS: 

Best 73
HB9FXQ, Frank
 



Re: "MSTNAK Received" after "Repeater Configuration Sent" #brandmeister

Steve N4IRS
 

Frank,
Unfortunately, BM does not tells us much about what it does not like in a configuration. I suggest you use the stock client configuration. Change as little as possible. If login goes well, change a couple of fields and retry.

73, Steve N4IRS

On 7/9/2018 11:55 AM, mail@... wrote:
Hi

Trying to get HBlink to connect to Brandmeister without success:

Console output:

(py2_dmr) ➜  HBlink git:(master) python hblink.py
DEBUG 2018-07-09 17:45:39,910 Logging system started, anything from here on gets logged
INFO 2018-07-09 17:45:39,910 HBlink TCP reporting server configured
DEBUG 2018-07-09 17:45:39,910 Periodic reporting loop started
INFO 2018-07-09 17:45:39,910 HBlink 'HBlink.py' (c) 2016 N0MJS & the K0USY Group - SYSTEM STARTING...
DEBUG 2018-07-09 17:45:39,910 (HOTSPOT-dev) Client maintenance loop started
INFO 2018-07-09 17:45:39,911 (HOTSPOT-dev) Sending login request to master 194.146.121.130:62031
DEBUG 2018-07-09 17:45:39,911 CLIENT instance created: HOTSPOT-dev, <__main__.HBSYSTEM instance at 0x7fe2cae29ea8>
INFO 2018-07-09 17:45:39,967 (HOTSPOT-dev) Repeater Login ACK Received with 32bit ID: 497425309
INFO 2018-07-09 17:45:40,016 (HOTSPOT-dev) Repeater Authentication Accepted
INFO 2018-07-09 17:45:40,017 (HOTSPOT-dev) Repeater Configuration Sent
WARNING 2018-07-09 17:45:40,076 (HOTSPOT-dev) MSTNAK Received. Resetting connection to the Master.
DEBUG 2018-07-09 17:45:44,915 (HOTSPOT-dev) Client maintenance loop started
INFO 2018-07-09 17:45:44,916 (HOTSPOT-dev) Sending login request to master 194.146.121.130:62031
INFO 2018-07-09 17:45:45,007 (HOTSPOT-dev) Repeater Login ACK Received with 32bit ID: 1757719149
INFO 2018-07-09 17:45:45,057 (HOTSPOT-dev) Repeater Authentication Accepted
INFO 2018-07-09 17:45:45,057 (HOTSPOT-dev) Repeater Configuration Sent
WARNING 2018-07-09 17:45:45,112 (HOTSPOT-dev) MSTNAK Received. Resetting connection to the Master.
.... 
.... 
 
Anyone could guess what's wrong with my config file? Tried various master servers. All same behaviour
using Git master with last commit 416ab12c5ff582665c2e5af994c4bea6b024de0d


# PROGRAM-WIDE PARAMETERS GO HERE
# PATH - working path for files, leave it alone unless you NEED to change it
# PING_TIME - the interval that clients will ping the master, and re-try registraion
#           - how often the Master maintenance loop runs
# MAX_MISSED - how many pings are missed before we give up and re-register
#           - number of times the master maintenance loop runs before de-registering a client
[GLOBAL]
PATH: ./
PING_TIME: 5
MAX_MISSED: 3
 
 
# NOT YET WORKING: NETWORK REPORTING CONFIGURATION
#   Enabling "REPORT" will configure a socket-based reporting
#   system that will send the configuration and other items
#   to a another process (local or remote) that may process
#   the information for some useful purpose, like a web dashboard.
#
#   REPORT - True to enable, False to disable
#   REPORT_INTERVAL - Seconds between reports
#   REPORT_PORT - TCP port to listen on if "REPORT_NETWORKS" = NETWORK
#   REPORT_CLIENTS - comma separated list of IPs you will allow clients
#       to connect on. Entering a * will allow all.
#
# ****FOR NOW MUST BE TRUE - USE THE LOOPBACK IF YOU DON'T USE THIS!!!****
[REPORTS]
REPORT: True
REPORT_INTERVAL: 60
REPORT_PORT: 4321
REPORT_CLIENTS: 127.0.0.1
 
 
# SYSTEM LOGGER CONFIGURAITON
#   This allows the logger to be configured without chaning the individual
#   python logger stuff. LOG_FILE should be a complete path/filename for *your*
#   system -- use /dev/null for non-file handlers.
#   LOG_HANDERLS may be any of the following, please, no spaces in the
#   list if you use several:
#       null
#       console
#       console-timed
#       file
#       file-timed
#       syslog
#   LOG_LEVEL may be any of the standard syslog logging levels, though
#   as of now, DEBUG, INFO, WARNING and CRITICAL are the only ones
#   used.
#
[LOGGER]
LOG_FILE: /tmp/hblink.log
LOG_HANDLERS: console-timed
LOG_LEVEL: DEBUG
LOG_NAME: HBlink
 
# DOWNLOAD AND IMPORT SUBSCRIBER, PEER and TGID ALIASES
# Ok, not the TGID, there's no master list I know of to download
# This is intended as a facility for other applcations built on top of
# HBlink to use, and will NOT be used in HBlink directly.
# STALE_DAYS is the number of days since the last download before we
# download again. Don't be an ass and change this to less than a few days.
[ALIASES]
TRY_DOWNLOAD: True
PATH: ./
PEER_FILE: peer_ids.csv
SUBSCRIBER_FILE: subscriber_ids.csv
TGID_FILE: talkgroup_ids.csv
STALE_DAYS: 7
 
# EXPORT AMBE DATA
# This is for exporting AMBE audio frames to an an "external" process for
# decoding or other nefarious actions.
[AMBE]
EXPORT_IP: 127.0.0.1
EXPORT_PORT: 1234
 
# MASTER INSTANCES - DUPLICATE SECTION FOR MULTIPLE MASTERS
# HomeBrew Protocol Master instances go here.
# IP may be left blank if there's one interface on your system.
# Port should be the port you want this master to listen on. It must be unique
# and unused by anything else.
# Repeat - if True, the master repeats traffic to clients, False, it does nothing.
[MASTER-1]
MODE: MASTER
ENABLED: False
REPEAT: True
EXPORT_AMBE: False
IP:
PORT: 54000
PASSPHRASE: s3cr37w0rd
GROUP_HANGTIME: 5
 
# CLIENT INSTANCES - DUPLICATE SECTION FOR MULTIPLE CLIENTS
# There are a LOT of errors in the HB Protocol specifications on this one!
# MOST of these items are just strings and will be properly dealt with by the program
# The TX & RX Frequencies are 9-digit numbers, and are the frequency in Hz.
# Latitude is an 8-digit unsigned floating point number.
# Longitude is a 9-digit signed floating point number.
# Height is in meters
# Setting Loose to True relaxes the validation on packets received from the master.
# This will allow HBlink to connect to a non-compliant system such as XLXD, DMR+ etc.
[HOTSPOT-dev]
MODE: CLIENT
ENABLED: True
LOOSE: True
EXPORT_AMBE: False
IP: 
PORT: 54001
MASTER_IP: master.ham-dmr.be
MASTER_PORT: 62031
PASSPHRASE: passw0rd
CALLSIGN: <<<<used my callsign here, 7-digits>>>>>>  
RADIO_ID: <<<<used my DMR ID here, 7-digits>>>>>>
RX_FREQ: 435400000
TX_FREQ: 435400000
TX_POWER: 1
COLORCODE: 1
SLOTS: 2
LATITUDE: 46.9854
LONGITUDE: 7.4703
HEIGHT: 101
LOCATION:  Anywhere, CH
DESCRIPTION: My Callsign here
SOFTWARE_ID: 20170620
PACKAGE_ID: MMDVM_HBlink
GROUP_HANGTIME: 5
OPTIONS: 

Best 73
HB9FXQ, Frank
 


"MSTNAK Received" after "Repeater Configuration Sent" #brandmeister

HB9FXQ, Frank Werner-Krippendorf
 

Hi

Trying to get HBlink to connect to Brandmeister without success:

Console output:

(py2_dmr) ➜  HBlink git:(master) python hblink.py
DEBUG 2018-07-09 17:45:39,910 Logging system started, anything from here on gets logged
INFO 2018-07-09 17:45:39,910 HBlink TCP reporting server configured
DEBUG 2018-07-09 17:45:39,910 Periodic reporting loop started
INFO 2018-07-09 17:45:39,910 HBlink 'HBlink.py' (c) 2016 N0MJS & the K0USY Group - SYSTEM STARTING...
DEBUG 2018-07-09 17:45:39,910 (HOTSPOT-dev) Client maintenance loop started
INFO 2018-07-09 17:45:39,911 (HOTSPOT-dev) Sending login request to master 194.146.121.130:62031
DEBUG 2018-07-09 17:45:39,911 CLIENT instance created: HOTSPOT-dev, <__main__.HBSYSTEM instance at 0x7fe2cae29ea8>
INFO 2018-07-09 17:45:39,967 (HOTSPOT-dev) Repeater Login ACK Received with 32bit ID: 497425309
INFO 2018-07-09 17:45:40,016 (HOTSPOT-dev) Repeater Authentication Accepted
INFO 2018-07-09 17:45:40,017 (HOTSPOT-dev) Repeater Configuration Sent
WARNING 2018-07-09 17:45:40,076 (HOTSPOT-dev) MSTNAK Received. Resetting connection to the Master.
DEBUG 2018-07-09 17:45:44,915 (HOTSPOT-dev) Client maintenance loop started
INFO 2018-07-09 17:45:44,916 (HOTSPOT-dev) Sending login request to master 194.146.121.130:62031
INFO 2018-07-09 17:45:45,007 (HOTSPOT-dev) Repeater Login ACK Received with 32bit ID: 1757719149
INFO 2018-07-09 17:45:45,057 (HOTSPOT-dev) Repeater Authentication Accepted
INFO 2018-07-09 17:45:45,057 (HOTSPOT-dev) Repeater Configuration Sent
WARNING 2018-07-09 17:45:45,112 (HOTSPOT-dev) MSTNAK Received. Resetting connection to the Master.
.... 
.... 
 
Anyone could guess what's wrong with my config file? Tried various master servers. All same behaviour
using Git master with last commit 416ab12c5ff582665c2e5af994c4bea6b024de0d


# PROGRAM-WIDE PARAMETERS GO HERE
# PATH - working path for files, leave it alone unless you NEED to change it
# PING_TIME - the interval that clients will ping the master, and re-try registraion
#           - how often the Master maintenance loop runs
# MAX_MISSED - how many pings are missed before we give up and re-register
#           - number of times the master maintenance loop runs before de-registering a client
[GLOBAL]
PATH: ./
PING_TIME: 5
MAX_MISSED: 3
 
 
# NOT YET WORKING: NETWORK REPORTING CONFIGURATION
#   Enabling "REPORT" will configure a socket-based reporting
#   system that will send the configuration and other items
#   to a another process (local or remote) that may process
#   the information for some useful purpose, like a web dashboard.
#
#   REPORT - True to enable, False to disable
#   REPORT_INTERVAL - Seconds between reports
#   REPORT_PORT - TCP port to listen on if "REPORT_NETWORKS" = NETWORK
#   REPORT_CLIENTS - comma separated list of IPs you will allow clients
#       to connect on. Entering a * will allow all.
#
# ****FOR NOW MUST BE TRUE - USE THE LOOPBACK IF YOU DON'T USE THIS!!!****
[REPORTS]
REPORT: True
REPORT_INTERVAL: 60
REPORT_PORT: 4321
REPORT_CLIENTS: 127.0.0.1
 
 
# SYSTEM LOGGER CONFIGURAITON
#   This allows the logger to be configured without chaning the individual
#   python logger stuff. LOG_FILE should be a complete path/filename for *your*
#   system -- use /dev/null for non-file handlers.
#   LOG_HANDERLS may be any of the following, please, no spaces in the
#   list if you use several:
#       null
#       console
#       console-timed
#       file
#       file-timed
#       syslog
#   LOG_LEVEL may be any of the standard syslog logging levels, though
#   as of now, DEBUG, INFO, WARNING and CRITICAL are the only ones
#   used.
#
[LOGGER]
LOG_FILE: /tmp/hblink.log
LOG_HANDLERS: console-timed
LOG_LEVEL: DEBUG
LOG_NAME: HBlink
 
# DOWNLOAD AND IMPORT SUBSCRIBER, PEER and TGID ALIASES
# Ok, not the TGID, there's no master list I know of to download
# This is intended as a facility for other applcations built on top of
# HBlink to use, and will NOT be used in HBlink directly.
# STALE_DAYS is the number of days since the last download before we
# download again. Don't be an ass and change this to less than a few days.
[ALIASES]
TRY_DOWNLOAD: True
PATH: ./
PEER_FILE: peer_ids.csv
SUBSCRIBER_FILE: subscriber_ids.csv
TGID_FILE: talkgroup_ids.csv
PEER_URL: http://dmr-marc.net/static/rptrs.csv
SUBSCRIBER_URL: http://dmr-marc.net/static/users.csv
STALE_DAYS: 7
 
# EXPORT AMBE DATA
# This is for exporting AMBE audio frames to an an "external" process for
# decoding or other nefarious actions.
[AMBE]
EXPORT_IP: 127.0.0.1
EXPORT_PORT: 1234
 
# MASTER INSTANCES - DUPLICATE SECTION FOR MULTIPLE MASTERS
# HomeBrew Protocol Master instances go here.
# IP may be left blank if there's one interface on your system.
# Port should be the port you want this master to listen on. It must be unique
# and unused by anything else.
# Repeat - if True, the master repeats traffic to clients, False, it does nothing.
[MASTER-1]
MODE: MASTER
ENABLED: False
REPEAT: True
EXPORT_AMBE: False
IP:
PORT: 54000
PASSPHRASE: s3cr37w0rd
GROUP_HANGTIME: 5
 
# CLIENT INSTANCES - DUPLICATE SECTION FOR MULTIPLE CLIENTS
# There are a LOT of errors in the HB Protocol specifications on this one!
# MOST of these items are just strings and will be properly dealt with by the program
# The TX & RX Frequencies are 9-digit numbers, and are the frequency in Hz.
# Latitude is an 8-digit unsigned floating point number.
# Longitude is a 9-digit signed floating point number.
# Height is in meters
# Setting Loose to True relaxes the validation on packets received from the master.
# This will allow HBlink to connect to a non-compliant system such as XLXD, DMR+ etc.
[HOTSPOT-dev]
MODE: CLIENT
ENABLED: True
LOOSE: True
EXPORT_AMBE: False
IP: 
PORT: 54001
MASTER_IP: master.ham-dmr.be
MASTER_PORT: 62031
PASSPHRASE: passw0rd
CALLSIGN: <<<<used my callsign here, 7-digits>>>>>>  
RADIO_ID: <<<<used my DMR ID here, 7-digits>>>>>>
RX_FREQ: 435400000
TX_FREQ: 435400000
TX_POWER: 1
COLORCODE: 1
SLOTS: 2
LATITUDE: 46.9854
LONGITUDE: 7.4703
HEIGHT: 101
LOCATION:  Anywhere, CH
DESCRIPTION: My Callsign here
URL: http://www.hb9fxq.ch
SOFTWARE_ID: 20170620
PACKAGE_ID: MMDVM_HBlink
GROUP_HANGTIME: 5
OPTIONS: 

Best 73
HB9FXQ, Frank
 


Re: DMR <-> P25

va3czk@...
 

Thanks Steve,

73' Jerry VA3CZK


Re: MMDVM User Authentication

Jon K1IMD <jon@...>
 

Cort,
As you pointed out not the original intention but I have seen numerous c-Bridges using HBlink for dongle/hotspot access.

I had a discussion with a couple c-Bridge ops 2 months ago and they were concerned and wishing for some sort of control of access.  So I get the problem as dongles & hotspots almost equals the number of DMR users so it seems and it would be pretty possible to overload a wimpy network connection.

Although not for really necessary for my own application, I will say "YES" it would be helpful for the sake of the couple c-Bridge ops I know.

However, Matthew 2E0SIP makes a very good point... VPN access could control the users as well.  I use a VPN called SoftEther that is very flexible and configurable.  Check it out!

73
Jon


On 7/6/2018 9:32 AM, Cort N0MJS via Groups.Io wrote:
First off, in your original post you said: "Is there a way to have an "authorized user" list in the MMDVM Server?”

I don’t know what an “MMDVM Server” is because I didn’t write any programs called that. I *think* what you want is a black/white list option for allowing clients to connect to hblink.py when it’s configured as a master. Is this what you’re asking for? I know you’re probably cussing me right now for being pedantic, but believe me, after 5 years on this project, I’ve learned we have to be accurate and explicit. If it is what you’re asking, here are my thoughts:

1) HBlink wasn’t written to be a hotspot aggregator, though I realize it’s become that to a number of users.
2) This sounds like a solution b/c systems operators are not adequately controlling their end-users – I know, it’s really hard to control some people.

So how would we go about doing this? IP address isn’t good because too many NAT addresses change too often. It would almost have to be by the radio ID of the client connecting. But if you have users tossing about the password, would they not do the same with the radio ID of their hotspot? The only reasonable way I can think of is by radio ID.

Adding the “feature” would not be complicated. I could kick it out in the next few days. My concern is whether or not it would adequately address the issue, or just push it off into yet another issue. Because there’s one thing I will not do, which is keep chasing solutions for problems that only exist because bad actors are passing around login credentials on one system out there.

I’d like more than one person to say “this would be really beneficial to me”, and all of you who say that to tell me that if the users just find another way to be bad, you won’t be back for another technical solution to an administrative problem – because using technology to continually solve an administrative (human) problem usually creates collateral damage and diminishing returns.

I’d like to see 5 YES votes before I proceed. I can make a poll for the group, but would rather just see some replies to this with one word “YES” or “NO”.

0x49 DE N0MJS


On Jul 6, 2018, at 8:12 AM, Rod - KC7AAD <kc7aad@...> wrote:

Anyone?? Ideas? Thoughts?

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






7801 - 7820 of 9589