Date   

Re: Invalid command from BrandMeister #brandmeister

Peter M0NWI
 

I was thinking the same Cort, do the Zingmen know any different?

Sent from Outlook
From: main@DVSwitch.groups.io <main@DVSwitch.groups.io> on behalf of Cort N0MJS <n0mjs@...>
Sent: 04 February 2018 14:31:12
To: main@DVSwitch.groups.io
Subject: Re: [DVSwitch] Invalid command from BrandMeister #brandmeister
 
The reason you don’t see me getting too involved in connecting to Brandmeister is that, when I first released HBLink, Brandmeister had prohibited the use of HBlink to connect to their servers/network. I know many folks do it. And I have never heard anything more from Brandmeister on it. But please be aware, the last thing I did hear was that this was not allowed.

> On Feb 4, 2018, at 3:34 AM, Veijo Arponen, OH3NFC <oh3nfc@...> wrote:
>
> Hello,
>
> Communication with BM servers works despite of the error I have reported on this issue. I was just testing HB Conference Bridge and I got it work. Time has passed but I may have the configuration somewhere on my test computer. I'll check and send it as a reference if you don't get your system working. In my system was connected two SharkRF openSPOTs and there were three separate client connections to BrandMeister servers in Finland, Sweden and Hungary.
>
> Please reply to this message or directly to me if you are willing to have my config files as reference.
>
> 73 de Veijo OH3NFC
>
>
>

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









Re: Invalid command from BrandMeister #brandmeister

Cort N0MJS <n0mjs@...>
 

The reason you don’t see me getting too involved in connecting to Brandmeister is that, when I first released HBLink, Brandmeister had prohibited the use of HBlink to connect to their servers/network. I know many folks do it. And I have never heard anything more from Brandmeister on it. But please be aware, the last thing I did hear was that this was not allowed.

On Feb 4, 2018, at 3:34 AM, Veijo Arponen, OH3NFC <oh3nfc@gmail.com> wrote:

Hello,

Communication with BM servers works despite of the error I have reported on this issue. I was just testing HB Conference Bridge and I got it work. Time has passed but I may have the configuration somewhere on my test computer. I'll check and send it as a reference if you don't get your system working. In my system was connected two SharkRF openSPOTs and there were three separate client connections to BrandMeister servers in Finland, Sweden and Hungary.

Please reply to this message or directly to me if you are willing to have my config files as reference.

73 de Veijo OH3NFC


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


Re: Invalid command from BrandMeister #brandmeister

Andrii Misyurko
 

Thanks, if you can send your configuration here


Re: Invalid command from BrandMeister #brandmeister

Veijo Arponen OH4VA
 

Hello,

Communication with BM servers works despite of the error I have reported on this issue. I was just testing HB Conference Bridge and I got it work. Time has passed but I may have the configuration somewhere on my test computer. I'll check and send it as a reference if you don't get your system working. In my system was connected two SharkRF openSPOTs and there were three separate client connections to BrandMeister servers in Finland, Sweden and Hungary.

Please reply to this message or directly to me if you are willing to have my config files as reference.

73 de Veijo OH3NFC


Re: Invalid command from BrandMeister #brandmeister

Andrii Misyurko
 

But I am not able to receive groups of Brandmeister and back. May be I have not correctly configured the client?


Re: Invalid command from BrandMeister #brandmeister

Cort N0MJS <n0mjs@...>
 

Just means it received something it doesn’t understand. Doesn’t necessarily indicate there will be a problem. If you’re not experiencing any particular failure associated with the occurrence of this packet, I wouldn’t worry about it.

On Feb 3, 2018, at 4:04 PM, Andrii Misyurko <radioproffi@...> wrote:

<Захват_1.png>

????

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






Re: Invalid command from BrandMeister #brandmeister

Andrii Misyurko
 



????


Re: hblink.py - CRITICAL UPDATE

Mike Zingman - N4IRR
 

HB_Bridge has taken up Cort's changes as well as updated any other component that has changed to date.


Re: hblink.py - CRITICAL UPDATE

Steve N4IRS
 

Remember the HB_Bridge branch has not been fix yet.

Steve

On 2/2/2018 3:57 PM, David wrote:
I am loading it now on my stuff to see if it will fix the issue. 

Thank you


On Fri, Feb 2, 2018 at 2:39 PM, Cort N0MJS <n0mjs@...> wrote:
Folks,

Today I identified and corrected to critical problems with hblink.py in CLIENT mode, and have pushed to the master branch on GitHub. The HB_Bridge branch is also affected, but not updated by me at this time. Both issues are related.

Issue 1:

Somewhere along the line, I walked away from the code half baked and never finished implementing the missed keep-alive counter. So it was not working correctly. It has not been extensively tested, but I believe it’s at least “pretty good” now. You will see some logging updates that go along with this.

Issue 2:

when incoming packets are received, the “command” length is variable. Mostly, they can be disambiguated with 4 characters. When this is possible, I only parse 4 characters as to not waste time re-parsing. The “MSTNAK” – master negative acknowledgment to the client can be disambiguated with “MSTN”… so what did I do? Started looking for the radio ID (next piece of data) at offset 4… forgetting about the “AK”… I should have started parsing at offset 6.

@             elif _command == 'MSTN':    # Actually MSTNAK -- a NACK from the master
-                  _radio_id = _data[4:8]
+                 _radio_id = _data[6:10]

This caused hblink.py in client mode to NOT honor MSTNAK and not reset the connection. Between this and Issue 1, it’s possible for hblink.py to continue thinking it’s connected to an application virtually forever. What’s worse, if the master it is connected to continues to answer keep-alives even if it’s disconnected a client (there’s one that does this), it’s hard to even troubleshoot… which I’ve been doing for days.

Minor Changes:

A few minor changes so that per-packet logging does not occur at debug. The lines are still there and commented out. Uncomment locally if you need to debug that deeply.


Extra props go out to Corey Dean, N3FE for helping troubleshoot this one - Thanks Corey.

0x49 DE N0MJS



Cort Buffington
785-865-7206







Re: hblink.py - CRITICAL UPDATE

David
 

I am loading it now on my stuff to see if it will fix the issue. 

Thank you


On Fri, Feb 2, 2018 at 2:39 PM, Cort N0MJS <n0mjs@...> wrote:
Folks,

Today I identified and corrected to critical problems with hblink.py in CLIENT mode, and have pushed to the master branch on GitHub. The HB_Bridge branch is also affected, but not updated by me at this time. Both issues are related.

Issue 1:

Somewhere along the line, I walked away from the code half baked and never finished implementing the missed keep-alive counter. So it was not working correctly. It has not been extensively tested, but I believe it’s at least “pretty good” now. You will see some logging updates that go along with this.

Issue 2:

when incoming packets are received, the “command” length is variable. Mostly, they can be disambiguated with 4 characters. When this is possible, I only parse 4 characters as to not waste time re-parsing. The “MSTNAK” – master negative acknowledgment to the client can be disambiguated with “MSTN”… so what did I do? Started looking for the radio ID (next piece of data) at offset 4… forgetting about the “AK”… I should have started parsing at offset 6.

@             elif _command == 'MSTN':    # Actually MSTNAK -- a NACK from the master
-                  _radio_id = _data[4:8]
+                 _radio_id = _data[6:10]

This caused hblink.py in client mode to NOT honor MSTNAK and not reset the connection. Between this and Issue 1, it’s possible for hblink.py to continue thinking it’s connected to an application virtually forever. What’s worse, if the master it is connected to continues to answer keep-alives even if it’s disconnected a client (there’s one that does this), it’s hard to even troubleshoot… which I’ve been doing for days.

Minor Changes:

A few minor changes so that per-packet logging does not occur at debug. The lines are still there and commented out. Uncomment locally if you need to debug that deeply.


Extra props go out to Corey Dean, N3FE for helping troubleshoot this one - Thanks Corey.

0x49 DE N0MJS



Cort Buffington
785-865-7206






hblink.py - CRITICAL UPDATE

Cort N0MJS <n0mjs@...>
 

Folks,

Today I identified and corrected to critical problems with hblink.py in CLIENT mode, and have pushed to the master branch on GitHub. The HB_Bridge branch is also affected, but not updated by me at this time. Both issues are related.

Issue 1:

Somewhere along the line, I walked away from the code half baked and never finished implementing the missed keep-alive counter. So it was not working correctly. It has not been extensively tested, but I believe it’s at least “pretty good” now. You will see some logging updates that go along with this.

Issue 2:

when incoming packets are received, the “command” length is variable. Mostly, they can be disambiguated with 4 characters. When this is possible, I only parse 4 characters as to not waste time re-parsing. The “MSTNAK” – master negative acknowledgment to the client can be disambiguated with “MSTN”… so what did I do? Started looking for the radio ID (next piece of data) at offset 4… forgetting about the “AK”… I should have started parsing at offset 6.

@ elif _command == 'MSTN': # Actually MSTNAK -- a NACK from the master
- _radio_id = _data[4:8]
+ _radio_id = _data[6:10]

This caused hblink.py in client mode to NOT honor MSTNAK and not reset the connection. Between this and Issue 1, it’s possible for hblink.py to continue thinking it’s connected to an application virtually forever. What’s worse, if the master it is connected to continues to answer keep-alives even if it’s disconnected a client (there’s one that does this), it’s hard to even troubleshoot… which I’ve been doing for days.

Minor Changes:

A few minor changes so that per-packet logging does not occur at debug. The lines are still there and commented out. Uncomment locally if you need to debug that deeply.


Extra props go out to Corey Dean, N3FE for helping troubleshoot this one - Thanks Corey.

0x49 DE N0MJS



Cort Buffington
785-865-7206


Re: Analog Bridge and HBBridge

David
 

With a miss count of 1 it will not do a full restart on its own.  I have to kill it manually and restart it.

On Tue, Jan 30, 2018 at 7:18 PM, Cort N0MJS <n0mjs@...> wrote:
Probably set the missed counter to 1 also


On Jan 30, 2018, at 12:47 PM, David <david@...> wrote:

I have set some of the settings for the timers down on hblink hopping it will fix it.    When ever it shows offline the log for hb_bridge/hblink has the pings and pongs not matching.  

On Sat, Jan 27, 2018 at 9:58 AM, David <david@...> wrote:
I'm using hblink

On Jan 26, 2018 7:58 PM, "Corey Dean N3FE" <n3fe@...> wrote:
Is that id associated to a smart Ptt or hblink connecting as a client so I know where to look.


On Jan 26, 2018, at 8:08 PM, David <david@...> wrote:

We do not have any issues with our pi-star repeaters.


Here is my ID for the all-star bridge
Server 3102
312026302

On Jan 26, 2018 5:22 PM, "Corey Dean N3FE" <n3fe@...> wrote:
I did apply 3 patches over the last couple of days but the mmdvm should auto connect.  I am pn 3102 and it auto connects, but I am not running pi-star either.

If you want to send me a dmr id, and you connect to 3102, 3103, or 3108, I will look in the logs.

Corey n3fe


On Jan 26, 2018, at 5:14 PM, Cort N0MJS <n0mjs@...> wrote:

My MMDVM repeaters seem to do the same with BM… in my case, keep alive are moving back and forth, no reason for MMDVM to suspect a problem, but the ability to move audio just goes away… didn’t check to see if BM says it’s off-line or not.

This happens with hblink.py as well (and as such, HB_Bridge.py is also affected). Would love to know if anyone knows why/how this happens.

0x49 DE N0MJS


On Jan 26, 2018, at 3:44 PM, David <david@...> wrote:

Running an Allstar node to BM TG and it works great most of the time.   Then every so often it partially disconnects from Brandmeister.   The status page says its offline.  If I restart the hbbridge side things begin to work for awhile.  Anywhere from 6 hours to 3 days.   When looking at the last heard on Brandmeister it shows audio coming in from analog but it is not putting it on a timeslot like it should.  Am I missing something in the config?  Or just a bug?

Cort Buffington
785-865-7206




Strange problem with HB_Bridge and Analog_Bridge

Ian Tulley
 

I have been testing the following setup and have been getting a strange error on the Brandmeister master server.
I have configured a private node on my existing Allstar server and now have Analog_Bridge and HB_bridge running on a separate server. I have the used my own DMRID + 25 added to the end so giving me 505211025 as the ID to use for connection to DMR. so my gatewaydmrid=505211025 and I can see it under my selfcare as a hotspot on the Brandmeister network, so I know it is connecting using that ID.
In HB_Bridge, I am connecting the 5051 server using TG50527 (for testing) TS2, CC1, all that is OK.
Now I am one of the Sysops for 5051 Master so I have access to the logs of that server, the following is my problem, to do my testing I am using the iaxrpt on an android device and this works fine for my other nodes, so I can connect OK and if I tail -f the hblink.log and hit PTT on the iaxrpt I get the following,
"INFO 2018-02-02 10:02:22,907 (REPEATER-1) Begin AMBE encode STREAM ID: 1153315697 SUB: 1894545 (1894545) REPEATER: 505211025 (505211025) TGID 50527 (50527), TS 2', now my problem is where is the SUB of 1894545 coming from, as when it tries to send this to the Master Server it gets an error as it does not recognise the DMRID of 1894545, so it fails to send.
Hopefully someone can enlighten me on this problem.

Thanks
Ian (VK2HK)


Re: Analog Bridge and HBBridge

Cort N0MJS <n0mjs@...>
 

Probably set the missed counter to 1 also


On Jan 30, 2018, at 12:47 PM, David <david@...> wrote:

I have set some of the settings for the timers down on hblink hopping it will fix it.    When ever it shows offline the log for hb_bridge/hblink has the pings and pongs not matching.  

On Sat, Jan 27, 2018 at 9:58 AM, David <david@...> wrote:
I'm using hblink

On Jan 26, 2018 7:58 PM, "Corey Dean N3FE" <n3fe@...> wrote:
Is that id associated to a smart Ptt or hblink connecting as a client so I know where to look.


On Jan 26, 2018, at 8:08 PM, David <david@...> wrote:

We do not have any issues with our pi-star repeaters.


Here is my ID for the all-star bridge
Server 3102
312026302

On Jan 26, 2018 5:22 PM, "Corey Dean N3FE" <n3fe@...> wrote:
I did apply 3 patches over the last couple of days but the mmdvm should auto connect.  I am pn 3102 and it auto connects, but I am not running pi-star either.

If you want to send me a dmr id, and you connect to 3102, 3103, or 3108, I will look in the logs.

Corey n3fe


On Jan 26, 2018, at 5:14 PM, Cort N0MJS <n0mjs@...> wrote:

My MMDVM repeaters seem to do the same with BM… in my case, keep alive are moving back and forth, no reason for MMDVM to suspect a problem, but the ability to move audio just goes away… didn’t check to see if BM says it’s off-line or not.

This happens with hblink.py as well (and as such, HB_Bridge.py is also affected). Would love to know if anyone knows why/how this happens.

0x49 DE N0MJS


On Jan 26, 2018, at 3:44 PM, David <david@...> wrote:

Running an Allstar node to BM TG and it works great most of the time.   Then every so often it partially disconnects from Brandmeister.   The status page says its offline.  If I restart the hbbridge side things begin to work for awhile.  Anywhere from 6 hours to 3 days.   When looking at the last heard on Brandmeister it shows audio coming in from analog but it is not putting it on a timeslot like it should.  Am I missing something in the config?  Or just a bug?

Cort Buffington
785-865-7206



Re: Analog Bridge and HBBridge

David
 

I have set some of the settings for the timers down on hblink hopping it will fix it.    When ever it shows offline the log for hb_bridge/hblink has the pings and pongs not matching.  

On Sat, Jan 27, 2018 at 9:58 AM, David <david@...> wrote:
I'm using hblink

On Jan 26, 2018 7:58 PM, "Corey Dean N3FE" <n3fe@...> wrote:
Is that id associated to a smart Ptt or hblink connecting as a client so I know where to look.

Sent from my iPhone

On Jan 26, 2018, at 8:08 PM, David <david@...> wrote:

We do not have any issues with our pi-star repeaters.


Here is my ID for the all-star bridge
Server 3102
312026302

On Jan 26, 2018 5:22 PM, "Corey Dean N3FE" <n3fe@...> wrote:
I did apply 3 patches over the last couple of days but the mmdvm should auto connect.  I am pn 3102 and it auto connects, but I am not running pi-star either.

If you want to send me a dmr id, and you connect to 3102, 3103, or 3108, I will look in the logs.

Corey n3fe

Sent from my iPhone

On Jan 26, 2018, at 5:14 PM, Cort N0MJS <n0mjs@...> wrote:

My MMDVM repeaters seem to do the same with BM… in my case, keep alive are moving back and forth, no reason for MMDVM to suspect a problem, but the ability to move audio just goes away… didn’t check to see if BM says it’s off-line or not.

This happens with hblink.py as well (and as such, HB_Bridge.py is also affected). Would love to know if anyone knows why/how this happens.

0x49 DE N0MJS


On Jan 26, 2018, at 3:44 PM, David <david@...> wrote:

Running an Allstar node to BM TG and it works great most of the time.   Then every so often it partially disconnects from Brandmeister.   The status page says its offline.  If I restart the hbbridge side things begin to work for awhile.  Anywhere from 6 hours to 3 days.   When looking at the last heard on Brandmeister it shows audio coming in from analog but it is not putting it on a timeslot like it should.  Am I missing something in the config?  Or just a bug?

Cort Buffington
785-865-7206



Re: Analog Bridge and HBBridge

David
 

I'm using hblink

On Jan 26, 2018 7:58 PM, "Corey Dean N3FE" <n3fe@...> wrote:
Is that id associated to a smart Ptt or hblink connecting as a client so I know where to look.

Sent from my iPhone

On Jan 26, 2018, at 8:08 PM, David <david@...> wrote:

We do not have any issues with our pi-star repeaters.


Here is my ID for the all-star bridge
Server 3102
312026302

On Jan 26, 2018 5:22 PM, "Corey Dean N3FE" <n3fe@...> wrote:
I did apply 3 patches over the last couple of days but the mmdvm should auto connect.  I am pn 3102 and it auto connects, but I am not running pi-star either.

If you want to send me a dmr id, and you connect to 3102, 3103, or 3108, I will look in the logs.

Corey n3fe

Sent from my iPhone

On Jan 26, 2018, at 5:14 PM, Cort N0MJS <n0mjs@...> wrote:

My MMDVM repeaters seem to do the same with BM… in my case, keep alive are moving back and forth, no reason for MMDVM to suspect a problem, but the ability to move audio just goes away… didn’t check to see if BM says it’s off-line or not.

This happens with hblink.py as well (and as such, HB_Bridge.py is also affected). Would love to know if anyone knows why/how this happens.

0x49 DE N0MJS


On Jan 26, 2018, at 3:44 PM, David <david@...> wrote:

Running an Allstar node to BM TG and it works great most of the time.   Then every so often it partially disconnects from Brandmeister.   The status page says its offline.  If I restart the hbbridge side things begin to work for awhile.  Anywhere from 6 hours to 3 days.   When looking at the last heard on Brandmeister it shows audio coming in from analog but it is not putting it on a timeslot like it should.  Am I missing something in the config?  Or just a bug?

Cort Buffington
785-865-7206


Re: Analog Bridge and HBBridge

Corey Dean N3FE <n3fe@...>
 

Is that id associated to a smart Ptt or hblink connecting as a client so I know where to look.

Sent from my iPhone

On Jan 26, 2018, at 8:08 PM, David <david@...> wrote:

We do not have any issues with our pi-star repeaters.


Here is my ID for the all-star bridge
Server 3102
312026302

On Jan 26, 2018 5:22 PM, "Corey Dean N3FE" <n3fe@...> wrote:
I did apply 3 patches over the last couple of days but the mmdvm should auto connect.  I am pn 3102 and it auto connects, but I am not running pi-star either.

If you want to send me a dmr id, and you connect to 3102, 3103, or 3108, I will look in the logs.

Corey n3fe

Sent from my iPhone

On Jan 26, 2018, at 5:14 PM, Cort N0MJS <n0mjs@...> wrote:

My MMDVM repeaters seem to do the same with BM… in my case, keep alive are moving back and forth, no reason for MMDVM to suspect a problem, but the ability to move audio just goes away… didn’t check to see if BM says it’s off-line or not.

This happens with hblink.py as well (and as such, HB_Bridge.py is also affected). Would love to know if anyone knows why/how this happens.

0x49 DE N0MJS


On Jan 26, 2018, at 3:44 PM, David <david@...> wrote:

Running an Allstar node to BM TG and it works great most of the time.   Then every so often it partially disconnects from Brandmeister.   The status page says its offline.  If I restart the hbbridge side things begin to work for awhile.  Anywhere from 6 hours to 3 days.   When looking at the last heard on Brandmeister it shows audio coming in from analog but it is not putting it on a timeslot like it should.  Am I missing something in the config?  Or just a bug?

Cort Buffington
785-865-7206


Re: Analog Bridge and HBBridge

Steve N4IRS
 

I don't know if it's a bug, I have a few bridges connected to BM. 3102 mostly. Don't have the issue. Not saying it's not there.

Stev

On 01/26/2018 08:08 PM, David wrote:
We do not have any issues with our pi-star repeaters.


Here is my ID for the all-star bridge
Server 3102
312026302

On Jan 26, 2018 5:22 PM, "Corey Dean N3FE" <n3fe@...> wrote:
I did apply 3 patches over the last couple of days but the mmdvm should auto connect.  I am pn 3102 and it auto connects, but I am not running pi-star either.

If you want to send me a dmr id, and you connect to 3102, 3103, or 3108, I will look in the logs.

Corey n3fe

Sent from my iPhone

On Jan 26, 2018, at 5:14 PM, Cort N0MJS <n0mjs@...> wrote:

My MMDVM repeaters seem to do the same with BM… in my case, keep alive are moving back and forth, no reason for MMDVM to suspect a problem, but the ability to move audio just goes away… didn’t check to see if BM says it’s off-line or not.

This happens with hblink.py as well (and as such, HB_Bridge.py is also affected). Would love to know if anyone knows why/how this happens.

0x49 DE N0MJS


On Jan 26, 2018, at 3:44 PM, David <david@...> wrote:

Running an Allstar node to BM TG and it works great most of the time.   Then every so often it partially disconnects from Brandmeister.   The status page says its offline.  If I restart the hbbridge side things begin to work for awhile.  Anywhere from 6 hours to 3 days.   When looking at the last heard on Brandmeister it shows audio coming in from analog but it is not putting it on a timeslot like it should.  Am I missing something in the config?  Or just a bug?

Cort Buffington
785-865-7206



Re: Analog Bridge and HBBridge

David
 

We do not have any issues with our pi-star repeaters.


Here is my ID for the all-star bridge
Server 3102
312026302

On Jan 26, 2018 5:22 PM, "Corey Dean N3FE" <n3fe@...> wrote:
I did apply 3 patches over the last couple of days but the mmdvm should auto connect.  I am pn 3102 and it auto connects, but I am not running pi-star either.

If you want to send me a dmr id, and you connect to 3102, 3103, or 3108, I will look in the logs.

Corey n3fe

Sent from my iPhone

On Jan 26, 2018, at 5:14 PM, Cort N0MJS <n0mjs@...> wrote:

My MMDVM repeaters seem to do the same with BM… in my case, keep alive are moving back and forth, no reason for MMDVM to suspect a problem, but the ability to move audio just goes away… didn’t check to see if BM says it’s off-line or not.

This happens with hblink.py as well (and as such, HB_Bridge.py is also affected). Would love to know if anyone knows why/how this happens.

0x49 DE N0MJS


On Jan 26, 2018, at 3:44 PM, David <david@...> wrote:

Running an Allstar node to BM TG and it works great most of the time.   Then every so often it partially disconnects from Brandmeister.   The status page says its offline.  If I restart the hbbridge side things begin to work for awhile.  Anywhere from 6 hours to 3 days.   When looking at the last heard on Brandmeister it shows audio coming in from analog but it is not putting it on a timeslot like it should.  Am I missing something in the config?  Or just a bug?

Cort Buffington
785-865-7206


Re: Analog Bridge and HBBridge

Corey Dean N3FE <n3fe@...>
 

I did apply 3 patches over the last couple of days but the mmdvm should auto connect.  I am pn 3102 and it auto connects, but I am not running pi-star either.

If you want to send me a dmr id, and you connect to 3102, 3103, or 3108, I will look in the logs.

Corey n3fe

Sent from my iPhone

On Jan 26, 2018, at 5:14 PM, Cort N0MJS <n0mjs@...> wrote:

My MMDVM repeaters seem to do the same with BM… in my case, keep alive are moving back and forth, no reason for MMDVM to suspect a problem, but the ability to move audio just goes away… didn’t check to see if BM says it’s off-line or not.

This happens with hblink.py as well (and as such, HB_Bridge.py is also affected). Would love to know if anyone knows why/how this happens.

0x49 DE N0MJS


On Jan 26, 2018, at 3:44 PM, David <david@...> wrote:

Running an Allstar node to BM TG and it works great most of the time.   Then every so often it partially disconnects from Brandmeister.   The status page says its offline.  If I restart the hbbridge side things begin to work for awhile.  Anywhere from 6 hours to 3 days.   When looking at the last heard on Brandmeister it shows audio coming in from analog but it is not putting it on a timeslot like it should.  Am I missing something in the config?  Or just a bug?

Cort Buffington
785-865-7206

9261 - 9280 of 10054