Date   

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







Re: MMDVM User Authentication

Steve N4IRS
 

I think OpenBridge is fine for server to server but it requires BM admin intervention. Not suited for most of what we want to do.

Steve

On 7/6/2018 11:14 AM, Cort N0MJS via Groups.Io wrote:
To Matthew’s point, I won’t modify HBP. It’s bad enough that BM, MMDVM and DMR+ can’t stay on the same page, I won’t be the 4th dialect :)

But agree that a better way would be nice!


On Jul 6, 2018, at 8:59 AM, Matthew 2E0SIP <groups.io@...> wrote:

Cort - I think to make this work reliably as you would need a 1:1 mapping between Radio IDs and Passwords, and potentially limit the clients that can connect using those credentials. That way if someone shares their credentials they would then get kicked from the server.

It would be quite nice if authentication on the MMDVM protocol was improved (I quite like BM's OpenBridge implementation) but that's a discussion for another day and would also some collaboration with G4KLX etc

That said, Rod - Have you considered controlling access using a VPN ? Something like https://www.zerotier.com/ would work very well for this application



Re: MMDVM User Authentication

Peter M0NWI
 

Rod,


I thought I'd offered a response about using sub_acl.py last Sunday, did that not suit your needs, to allow/deny bridging for given radio ID's?


If you really want to lock it down, and I know it's a bit of work, but you could stand a master up for each client with a unique password, define specific bridge rules between these masters, and switch on sub_ACL so only those who have both the correct radio Id, correct talk group and correct password for the master instance will get in?


73,

Peter




From: main@DVSwitch.groups.io <main@DVSwitch.groups.io> on behalf of Rod - KC7AAD <kc7aad@...>
Sent: 06 July 2018 14:12
To: main@DVSwitch.groups.io
Subject: Re: [DVSwitch] MMDVM User Authentication
 
Anyone?? Ideas? Thoughts?


Re: MMDVM User Authentication

Cort N0MJS <n0mjs@...>
 

To Matthew’s point, I won’t modify HBP. It’s bad enough that BM, MMDVM and DMR+ can’t stay on the same page, I won’t be the 4th dialect :)

But agree that a better way would be nice!


On Jul 6, 2018, at 8:59 AM, Matthew 2E0SIP <groups.io@...> wrote:

Cort - I think to make this work reliably as you would need a 1:1 mapping between Radio IDs and Passwords, and potentially limit the clients that can connect using those credentials. That way if someone shares their credentials they would then get kicked from the server.

It would be quite nice if authentication on the MMDVM protocol was improved (I quite like BM's OpenBridge implementation) but that's a discussion for another day and would also some collaboration with G4KLX etc

That said, Rod - Have you considered controlling access using a VPN ? Something like https://www.zerotier.com/ would work very well for this application


Re: MMDVM User Authentication

Matthew 2E0SIP
 

Cort - I think to make this work reliably as you would need a 1:1 mapping between Radio IDs and Passwords, and potentially limit the clients that can connect using those credentials. That way if someone shares their credentials they would then get kicked from the server.

It would be quite nice if authentication on the MMDVM protocol was improved (I quite like BM's OpenBridge implementation) but that's a discussion for another day and would also some collaboration with G4KLX etc

That said, Rod - Have you considered controlling access using a VPN ? Something like https://www.zerotier.com/ would work very well for this application


Re: MMDVM User Authentication

Cort N0MJS <n0mjs@...>
 

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






Re: MMDVM User Authentication

Rod - KC7AAD
 

Anyone?? Ideas? Thoughts?


Re: DMR <-> P25

Steve N4IRS
 

Jerry,
You are on the right track building from the outside in. P25 to DMR requires transcoding. That is your next step. P25 to DMR looks like this:

P25Reflector <-> P25Gateway <-> MMDVM_Bridge <-> Analog_Bridge_1 <-> Analog_Bridge_2 <-> MMDVM_Bridge <-> BrandMeister

The 2 copies of Analog_Bridge are connected "back to back" to transcode P25 to DMR.   Analog_bridge_1 is configured for IMBE (P25) and Analog_Bridge_2 is configured for AMBE (DMR).

[USRP] Analog_Bridge_1                  [USRP] Analog_Bridge_2
address = 127.0.0.1                     address = 127.0.0.1
txPort = 32001                          txPort = 34001
rxPort = 34001                          rxPort = 32001
aslAudio = AUDIO_UNITY                  aslAudio = AUDIO_UNITY
agcGain = -20                           agcGain = -20
dmrAudio = AUDIO_UNITY                  dmrAudio = AUDIO_UNITY
dmrGain = 0.35                          dmrGain = 0.35

Above is the [USRP] stanza from each copy of Analog_Bridge. Notice the "crossover" of the TX and RX ports.

In the above diagram, You only need 1 copy of MMDVM_Bridge. P25 points to Analog_Bridge_1 and DMR points to Analog_Bridge_2

Hope this helps,

73, Steve N4IRS

On 07/06/2018 06:03 AM, va3czk@... wrote:
Good morning,
I'm just getting my head wrapped around this and trying to set up P25<-->DMR and here is what I have done so far.
- P25 Gateway up and running and conectend to the reflector
- MMDVM_Bridge P25.ini modified with my and BM credentials, both P25 and DMR enabled.
When both running I can see traffic from both sides flowing to MMDVM_Bridge in the log file.
 
What else is missing to make this combo work.

73' Jerry va3czk
 


DMR <-> P25

va3czk@...
 

Good morning,
I'm just getting my head wrapped around this and trying to set up P25<-->DMR and here is what I have done so far.
- P25 Gateway up and running and conectend to the reflector
- MMDVM_Bridge P25.ini modified with my and BM credentials, both P25 and DMR enabled.
When both running I can see traffic from both sides flowing to MMDVM_Bridge in the log file.
 
What else is missing to make this combo work.

73' Jerry va3czk
 


Re: Trying to set up Parrot

KB5PBM
 

Its now working .. Thank you. 

8041 - 8060 of 9820