This is a partial repost from the main group with more information. N4IRS suggested that I port here verses the main group for assistance.

I have tried yet again to make this work without success.  I have been running these bridges on various hardware for a few years with few problems.  But this one has me stumped because the EXACT same configuration works FB on a RPi & a different VM... but does not seem to work on the aforementioned VirMach.  Attached are the key configuration files and logs.  Originally I had iptables running but I disabled that to ensure it was not part of the problem.  I did turn on DEBUG and logging from the original working configuration put nothing else.  IPSC_Bridge connects to the c-Bridge OK but HB_Bridge does not seem to be able to log into IPSC_Bridge.  Mind you as I mentioned the EXACT same .cfg files work on different hardware so it should not be a port typo or anything like that.  I have confirmed that non of the ports I have chosen are in use my the system.  The attached files have external IP & Ports redacted for security reasons.

The end result which works FB on other hardware is:
c-Bridge<->IPSC_Bridge<->HB_Bridge<->hblink3<->mmdvm repeater or hotspot
But until I IPSC_Bridge & HB_Bridge on this VirMach VPS I am Dead in the Water.

It appears that the internal ports don't communicate with each other.  I can only assume that I will also have the same issue problem with hblink3 as the next step.  Does anyone have any idea why I have the problem only on this VPS.

73
Jon
K1IMD

--- Previous Post ---
Has anyone by chance managed to get IPSC_Bridge<->HB_Bridge to run on a VirMach VPS (Elite+ LITE Package) with Debian 9 OS?

I have tried on and off for well more than a year to try to get it to work.  Prior to moving the system to the VPS I bench tested it on a RPi running Debian 9 and it worked fine.

I set it up on the VPS, everything runs with no complaints BUT the dmrlink & hblink to not "talk" to one another.  Thinking as I always do... I wonder what I did wrong because the machine is never at fault it is always the human... right?

To prove myself wrong I took the exact same configuration and installed it on a different system, in this case a VM also running Debian 9 and it works fine.  I even replicated the bridge 5 times for different connections and they all have worked flawlessly for over a year.

The VirMach VPS is their low end service, the lowest end service Value+ LITE did not have enough memory (512MB) to load so I bumped up to the Elite+ LITE (1GB) and everything loads fine.

What appears to be the problem is that the internal in IPSC_Bridge fromGatewayPort = 31000 & toGatewayPort = 31003 don't communicate with HB_Bridge ports fromGatewayPort = 31003 & toGatewayPort = 31000

Since the exact same configuration works fine on other systems it would appear that the problem is somewhere in the architecture of the VPS.

Anyone have any ideas or been successful using VirMach for bridging?

If you're using multiple sources for broadband, you should look into OSPF or similar routing protocols to ensure that you can safely fail-over to the backup broadband provider. Perhaps you're already doing it.

Glad that the problem is sorted out. I always appreciate having it be something other than HBLink :)
--
Randy Hall AA6RH (not K7AGE, quit asking) 😁

Hi again, thanks for answering Dean,
okey i tried now different approach it turns out the problem was all along on my network.
as I use double internet connection to my servers on internal IP:s (yes i use bound for 2x service providers) it was all along the problem.
it seems the UDP packets reach 2x times on destination and hblink cannot intrepid it right as I'm using bounding for sending packets on both internet service provides to have high avalibity, if internet disconnects or have hangups, it has lossless interruption. as i need lossless connection to server rather than speed. and this 4G LTE internets is bad here they keep hanging and disconnect, this way i have lossless connection to my server most of the time.

i think this problem is very very rare, as not much people using this way :) only work around for this, is route the packets through other internet via public IP. using internet IP through VPN tunnels is not an option this time. i was to do test server and use that internal-ip but well, we cannot always win..

sorry for the inconvenience for everyone I bring along :) Nice to have it working. i though it was on debian10 problem as it was only difference.
best 73, OH1E

Hblink3, dvswitch, all those work find in Debian 10.  No problems at all.  Why don’t you try posting the errors you are getting in Linux so we can help you along?

Heya Randy, thanks for answer.
the other version was hblink 3.x too. let me explain better:

i did clean install debian 10.8, hblink wont work there. the issue is on debian libraries not on hblink3.
i just don't know where to start looking the problem as debug log show only that challenge thing what is related I think on sha265?.

On other system where I have hblink3 still running is ubuntu 16. it has nothing to do with this, but I copied that hblink to new system and it gave same error.

riku oh1e

I try the fix but it won’t help.

maybe other ideas ?

Hi there,

Is this your first time with hblink3 (that is, the previous installs were HBLink on Python 2.x)?

The only difference I see between the two version (HBLink to hblink3) is that the salt for the SHA256 hash is generated "similarly". That salt generation might be enough to make it so that it doesn't match between the versions.

I've never had to support someone who was running HBLink and having it connect to HBLink3, and I would've figured this would have come up as an issue prior to this, given how deeply Cort was involved in both projects.

You should totally be able to host HBLink and DVSwitch apps on the same box.

--R
--
Randy Hall AA6RH (not K7AGE, quit asking) 😁

copied hblink3(with working conf files) from a working operating system to debian 10, and still doing the same FAILED. no luck. it just loop reconnect.
so what OS I need to use where I can put dvswitch and hblink on the same? is this even possible with 10.8?
To reproduce error install debian 10.8 and run hblink3 then connect hotspot to it.

riku OH1E

I have exacly same issue radio id is replaced here as "xx"
I have followed instructions https://dvswitch.groups.io/g/main/wiki/12099 and also replaced URL https://github.com/HBLink-org
Everything is fine and no errors on install. I'm running debian 10.8, guide is for 10

Thing is Is i have over years using hblink but the os on that server is way older(and still works). tried now do a testing system, but well... putting dvswitch there but well..
So to replicate this problem, just install newest debian and follow that guide, you cannot get it working. or i have done something very wrong. tried default port other ports, couple hotspots (openspot1 and mmdvm) all do the same error, i think this is related to sha256?

INFO 2021-03-21 22:42:44,302 (MASTER-1) Repeater Logging in with Radio ID: xx, 10.0.3.210:52009
INFO 2021-03-21 22:42:44,302 (MASTER-1) Sent Challenge Response to xx for login: 3612796019
INFO 2021-03-21 22:42:44,302 (MASTER-1) Repeater Logging in with Radio ID: xx, 10.0.3.210:52009
INFO 2021-03-21 22:42:44,302 (MASTER-1) Sent Challenge Response to xx for login: 1936826194
INFO 2021-03-21 22:42:44,331 (MASTER-1) Peer xx has FAILED the login exchange successfully
WARNING 2021-03-21 22:42:44,342 (MASTER-1) Login challenge from Radio ID that has not logged in: xx
WARNING 2021-03-21 22:42:44,343 (MASTER-1) Peer info from Radio ID that has not logged in: xx
WARNING 2021-03-21 22:42:44,343 (MASTER-1) Peer info from Radio ID that has not logged in: xx

best 73 OH1E

Thank you Randy,

73 from PU2XTL.

The latest from nostar (maintainer of DudeStar):

Ah yes, the terminator frame was not being sent correctly. Try the latest git.

So Heitor, I would suggest you take a look at the latest code drop for DudeStar and try your setup again.

In the meantime, we will take up the task of hardening playback.py so that it is more robust and able to recover cleanly from a situation like this in the future.

--R
--
Randy Hall AA6RH (not K7AGE, quit asking) 😁

I don't think line 128 factors into this. The playback.py script is pretty stripped down, so it's easy to see what's going on.

• Sets up the Twisted reactor object based on configuration
• The only thing added to this app is the dmrd_received() method, which only gets called when network traffic comes in. <<==== THIS RIGHT HERE is the reason timers and timeouts inside of dmrd_received will not work. The method can't sit around waiting to see if a voice terminator packet shows up. That's because this is UDP and there's no connection per se. The playback.py app processes whatever comes in, and nothing else.
• There are other things we can leverage in Twisted, including timers that will dispatch regularly where in-process voice streams can be swept up and handled. That's where I'm looking to make changes. I don't think there's necessarily any change needed in dmrd_received() in the code as it is written right now. That conclusion might change, but it won't be a huge rewrite of the method, just tweaks.

Thanks for looking into it. Read up on LoopingCall (https://twistedmatrix.com/documents/current/api/twisted.internet.task.LoopingCall.html) in Twisted if you want to understand what I'm thinking about here.

--R
--
Randy Hall AA6RH (not K7AGE, quit asking) 😁

I wish it were that simple.

The problem stems from the following: the app, as written, only does processing when it receives network traffic. That's what the dmrd_received() function is all about.

So what does it mean if the network traffic the app is looking for never arrives? You can't just delay() and expect it to work. The only time this function gets called is when there's network traffic coming in.

I'll have to devise something else. I'll look at other parts of the code base to see if and what Cort did to address this, because this isn't the only situation where this might happen. Pretty sure bridge.py has something.

I'll let you know what I find.

--R
--
Randy Hall AA6RH (not K7AGE, quit asking) 😁

On Fri, Mar 19, 2021 at 06:58 AM, Randy AA6RH wrote:

or a network where the voice terminator packets get lost or never arrive

https://www.chrishoodblog.com/make-your-own-dmr-server/
and
http://sp2ong.noip.pl/pl/blog/stworz-swoj-wlasny-serwer-dmr

with some modifications only in "rultes.py"

However, based on your last 2 messages i believe that my first question was answered.
The idea to put a timer after no packet reception is great.
When you get the code for that i can run the tests in my server, if you want.
It is already online and i can send the configs for client conections and  do the tests.
I have signed a VPS until Abril 10, so its my dead line to help with this task.

[hblink3:master] New Comment on Issue #11 IPv6 Support
By randybuildsthings:

For later reference:

config.py assumes that IP addresses are IPv4 and uses socket.gethostbyname() in order to resolve hostnames to IP addresses (but which only resolves to IPv4 addresses). IPv6 addresses put into the config file end up causing an error message:

Traceback (most recent call last): File "bridge.py", line 747, in <module> CONFIG = config.build_config(cli_args.CONFIG_FILE) File "/opt/hblink3/config.py", line 274, in build_config 'TARGET_SOCK': (gethostbyname(config.get(section, 'TARGET_IP')), config.getint(section, 'TARGET_PORT')), socket.gaierror: [Errno -9] Address family for hostname not supported

The likeliest approach is to use socket.getaddrinfo() which will resolve to a list of IP addresses (and ports, which are also required as part of the method) that meet the criteria given in the method call. Trouble is that using getaddrinfo() is not even close to a drop-in replacement for gethostbyname(), so there is some work to do here.

It's also worth noting that this is a lot of duplicated code. I'd like to start factoring this out into private methods or at least function calls that provide one place to make fixes, so that we're not doing find/replace all day long when discovering problems like this.

---

[hblink3:master] New Comment on Issue #11 IPv6 Support
By randybuildsthings:

For later reference:

config.py assumes that IP addresses are IPv4 and uses socket.gethostbyname() in order to resolve hostnames to IP addresses (but which only resolves to IPv4 addresses). IPv6 addresses put into the config file end up causing an error message:

Traceback (most recent call last):
  File "bridge.py", line 747, in <module>
    CONFIG = config.build_config(cli_args.CONFIG_FILE)
  File "/opt/hblink3/config.py", line 274, in build_config
    'TARGET_SOCK': (gethostbyname(config.get(section, 'TARGET_IP')), config.getint(section, 'TARGET_PORT')),
socket.gaierror: [Errno -9] Address family for hostname not supported

The likeliest approach is to use socket.getaddrinfo() which will resolve to a list of IP addresses (and ports, which are also required as part of the method) that meet the criteria given in the method call. Trouble is that using getaddrinfo() is not even close to a drop-in replacement for gethostbyname(), so there is some work to do here.

It's also worth noting that this is a lot of duplicated code. I'd like to start factoring this out into private methods or at least function calls that provide one place to make fixes, so that we're not doing find/replace all day long when discovering problems like this.

[hblink3:master] Label added to issue #11 IPv6 Support by K2IE.

Yeah, it's like the lightbulb went on here.

Playback.py is dead simple as far as a parrot application goes. It's also not particularly well-designed or executed (no slight on Cort or Steve for writing it that way, I think it was put in the repo as a proof-of-concept, not a complete parrot/echo app.)

Playback.py relies entirely on seeing a voice terminator packet come in as the trigger to play out the audio. There really should be some kind of timer that expires after a few hundred milliseconds of not receiving any more voice packets from the stream, but no such timer exists in the app as written (which is what I mean by the app being proof-of-concept rather than a robust app for end-user enjoyment).

No voice terminator packet, no echo. It took the subscriber radio on the second transmission to knock playback.py loose and allow it to play out the stored audio.

Another checklist item, I suppose. If we're going to have a playback.py app in the repo, it should be robust enough to deal with a badly-behaving subscriber, or a network where the voice terminator packets get lost or never arrive.

--R
--
Randy Hall AA6RH (not K7AGE, quit asking) 😁

Wait a second. The parrot you're using here, is it playback.py from this repository?

I need to see your config file for HBLink. Please copy/paste it in a reply or attach it, redacted if necessary.

--R
--
Randy Hall AA6RH (not K7AGE, quit asking) 😁