Date   

Re: ASL <-> D-Star <-> xlxd

Steve N4IRS
 

As I found, without 127.0.0.1 xlxd is not listening on any UDP ports. I did not think xlxd HAD to be used with a vocoder if all it was to do is be a D-Star reflector.
Not high on my list of things to care about, I was just playing and or bringing up a test D-Star or DMR or YSF reflector.

Steve

On 12/19/20 9:52 PM, Charles Wiant via groups.io wrote:

If I am not mistaken the 127.0.0.1 is supposed to be ambed.

 

From: main@DVSwitch.groups.io <main@DVSwitch.groups.io> On Behalf Of Steve N4IRS
Sent: Saturday, December 19, 2020 11:23 AM
To: main@DVSwitch.groups.io
Subject: Re: [DVSwitch] ASL <-> D-Star <-> xlxd

 

[Edited Message Follows]

So,
I was playing around this morning. I'll preface this as I can't even spell xlxd.
I find xlxd listens on a number of UDP ports, some of which conflict with ircDDBGateway.
This is a systemctl status after starting xlxd on a DVSwitch Server


Dec 19 12:07:27 new xlxd[1337]: Read 162240 DMR ids from xlxapi.rlx.lu database

Dec 19 12:07:28 new xlxd[1337]: Read 6004 YSF nodes from xlxapi.rlx.lu database

Dec 19 12:07:28 new xlxd[1337]: Error opening socket on port UDP30001 on ip 44.103.34.85

Dec 19 12:07:28 new xlxd[1337]: Error opening socket on port UDP30051 on ip 44.103.34.85

Dec 19 12:07:28 new xlxd[1337]: Error opening socket on port UDP42000 on ip 44.103.34.85

Dec 19 12:07:28 new xlxd[1337]: Error opening socket on port UDP40000 on ip 44.103.34.85

Dec 19 12:07:28 new xlxd[1337]: Error opening socket on port UDP12346 on ip 44.103.34.85

Dec 19 12:07:28 new xlxd[1337]: Error opening socket on port UDP12345 on ip 44.103.34.85

Dec 19 12:07:28 new xlxd[1337]: Error opening raw socket for ICMP

Dec 19 12:07:28 new xlxd[1337]: Error starting reflector

 
It seems the default startup for xlxd is: xlxd XLX999 192.168.178.212 127.0.0.1
Question, what is xlxd listening to 127.0.0.1 for?
If I start xlxd without the 127.0.0.1 address, the daemon starts with no error.

AH! if I start xlxd without 127.0.0.1 it starts, but is not listening to any UDP ports...

Comments?



Re: ASL <-> D-Star <-> xlxd

Charles Wiant
 

If I am not mistaken the 127.0.0.1 is supposed to be ambed.

 

From: main@DVSwitch.groups.io <main@DVSwitch.groups.io> On Behalf Of Steve N4IRS
Sent: Saturday, December 19, 2020 11:23 AM
To: main@DVSwitch.groups.io
Subject: Re: [DVSwitch] ASL <-> D-Star <-> xlxd

 

[Edited Message Follows]

So,
I was playing around this morning. I'll preface this as I can't even spell xlxd.
I find xlxd listens on a number of UDP ports, some of which conflict with ircDDBGateway.
This is a systemctl status after starting xlxd on a DVSwitch Server


Dec 19 12:07:27 new xlxd[1337]: Read 162240 DMR ids from xlxapi.rlx.lu database

Dec 19 12:07:28 new xlxd[1337]: Read 6004 YSF nodes from xlxapi.rlx.lu database

Dec 19 12:07:28 new xlxd[1337]: Error opening socket on port UDP30001 on ip 44.103.34.85

Dec 19 12:07:28 new xlxd[1337]: Error opening socket on port UDP30051 on ip 44.103.34.85

Dec 19 12:07:28 new xlxd[1337]: Error opening socket on port UDP42000 on ip 44.103.34.85

Dec 19 12:07:28 new xlxd[1337]: Error opening socket on port UDP40000 on ip 44.103.34.85

Dec 19 12:07:28 new xlxd[1337]: Error opening socket on port UDP12346 on ip 44.103.34.85

Dec 19 12:07:28 new xlxd[1337]: Error opening socket on port UDP12345 on ip 44.103.34.85

Dec 19 12:07:28 new xlxd[1337]: Error opening raw socket for ICMP

Dec 19 12:07:28 new xlxd[1337]: Error starting reflector

 
It seems the default startup for xlxd is: xlxd XLX999 192.168.178.212 127.0.0.1
Question, what is xlxd listening to 127.0.0.1 for?
If I start xlxd without the 127.0.0.1 address, the daemon starts with no error.

AH! if I start xlxd without 127.0.0.1 it starts, but is not listening to any UDP ports...

Comments?


Re: ASL <-> D-Star <-> xlxd

Doug - W4DBG
 

I believe it is looking for AMBE transcoding. 

I am no expert though. 

Just trying to help :)




On Sat, Dec 19, 2020 at 11:25 AM Steve N4IRS <szingman@...> wrote:

[Edited Message Follows]

So,
I was playing around this morning. I'll preface this as I can't even spell xlxd.
I find xlxd listens on a number of UDP ports, some of which conflict with ircDDBGateway.
This is a systemctl status after starting xlxd on a DVSwitch Server

Dec 19 12:07:27 new xlxd[1337]: Read 162240 DMR ids from xlxapi.rlx.lu database
Dec 19 12:07:28 new xlxd[1337]: Read 6004 YSF nodes from xlxapi.rlx.lu database
Dec 19 12:07:28 new xlxd[1337]: Error opening socket on port UDP30001 on ip 44.103.34.85
Dec 19 12:07:28 new xlxd[1337]: Error opening socket on port UDP30051 on ip 44.103.34.85
Dec 19 12:07:28 new xlxd[1337]: Error opening socket on port UDP42000 on ip 44.103.34.85
Dec 19 12:07:28 new xlxd[1337]: Error opening socket on port UDP40000 on ip 44.103.34.85
Dec 19 12:07:28 new xlxd[1337]: Error opening socket on port UDP12346 on ip 44.103.34.85
Dec 19 12:07:28 new xlxd[1337]: Error opening socket on port UDP12345 on ip 44.103.34.85
Dec 19 12:07:28 new xlxd[1337]: Error opening raw socket for ICMP
Dec 19 12:07:28 new xlxd[1337]: Error starting reflector
 
It seems the default startup for xlxd is: xlxd XLX999 192.168.178.212 127.0.0.1
Question, what is xlxd listening to 127.0.0.1 for?
If I start xlxd without the 127.0.0.1 address, the daemon starts with no error.

AH! if I start xlxd without 127.0.0.1 it starts, but is not listening to any UDP ports...

Comments?

--
Doug Gooden
troytrojan@...


Re: ASL <-> D-Star <-> xlxd

Steve N4IRS
 
Edited

So,
I was playing around this morning. I'll preface this as I can't even spell xlxd.
I find xlxd listens on a number of UDP ports, some of which conflict with ircDDBGateway.
This is a systemctl status after starting xlxd on a DVSwitch Server

Dec 19 12:07:27 new xlxd[1337]: Read 162240 DMR ids from xlxapi.rlx.lu database
Dec 19 12:07:28 new xlxd[1337]: Read 6004 YSF nodes from xlxapi.rlx.lu database
Dec 19 12:07:28 new xlxd[1337]: Error opening socket on port UDP30001 on ip 44.103.34.85
Dec 19 12:07:28 new xlxd[1337]: Error opening socket on port UDP30051 on ip 44.103.34.85
Dec 19 12:07:28 new xlxd[1337]: Error opening socket on port UDP42000 on ip 44.103.34.85
Dec 19 12:07:28 new xlxd[1337]: Error opening socket on port UDP40000 on ip 44.103.34.85
Dec 19 12:07:28 new xlxd[1337]: Error opening socket on port UDP12346 on ip 44.103.34.85
Dec 19 12:07:28 new xlxd[1337]: Error opening socket on port UDP12345 on ip 44.103.34.85
Dec 19 12:07:28 new xlxd[1337]: Error opening raw socket for ICMP
Dec 19 12:07:28 new xlxd[1337]: Error starting reflector
 
It seems the default startup for xlxd is: xlxd XLX999 192.168.178.212 127.0.0.1
Question, what is xlxd listening to 127.0.0.1 for?
If I start xlxd without the 127.0.0.1 address, the daemon starts with no error.

AH! if I start xlxd without 127.0.0.1 it starts, but is not listening to any UDP ports...

Comments?


Re: ASL <-> D-Star <-> xlxd

Steve N4IRS
 

Ircddbgateway is installed by the image or by the system builder script.

Sent by smoke signal (AT&T)


From: main@DVSwitch.groups.io <main@DVSwitch.groups.io> on behalf of Ken KE2N via groups.io <ke2n@...>
Sent: Friday, December 18, 2020 11:23:13 PM
To: main@DVSwitch.groups.io <main@DVSwitch.groups.io>
Subject: Re: [DVSwitch] ASL <-> D-Star <-> xlxd
 
NXDN, P25 and YSF gateways are included with DVSM.  But ircddbgateway is not..
Where should I pull ircddbgateway from (to be assured it will work with MMDVM_Bridge)?

Is it this one?     

https://github.com/g4klx/ircddbgateway



Tnx
Ken
KE2N


Re: Adding P25 to existing YSF and DMR bridge

Steve N4IRS
 

Complete bridge end to end. From what you told me, if only one bridge is running it works fine (either one) I want you to capture the UDP data for tach bridge running on its own.

On 12/18/2020 3:35 PM, Gary, KE8O wrote:
Ken

For clarification. When you say bridge are you referring to the MB instances only, or the complete bridge end to end..... i.e MB only for my YSF to DMR, then stop that MB, and for the P25 to DMR start its MB and both AB's ?

Thanks


Re: Dmr Utils

Don Poaps
 

root@dvswitch-server:/opt/dmr_utils3# ls
dmr_utils3  install.sh  LICENSE  README.rst  setup.py
root@dvswitch-server:/opt/dmr_utils3# cd dmr_utils3
root@dvswitch-server:/opt/dmr_utils3/dmr_utils3# ls
ambe.py        const.py   encode.py        hamming.py   rs129.py
ambe_utils.py  crc.py     golay.py         __init__.py  utils.py
bptc.py        decode.py  golay_tables.py  qr.py
root@dvswitch-server:/opt/dmr_utils3/dmr_utils3#

Something I did setup. I don't see HBlink3 directory.

Lost and still looking

73

Don va7dgp/va7qu


Re: Adding P25 to existing YSF and DMR bridge

Gary, KE8O
 

Sorry meant to say Steve, was talking to K2KXK Ken when I was typing.


Re: Adding P25 to existing YSF and DMR bridge

Gary, KE8O
 

Ken

For clarification. When you say bridge are you referring to the MB instances only, or the complete bridge end to end..... i.e MB only for my YSF to DMR, then stop that MB, and for the P25 to DMR start its MB and both AB's ?

Thanks


Re: Adding P25 to existing YSF and DMR bridge

Steve N4IRS
 

Gary,
That is not what I suggested yo do. This is.

With only one of your bridges running, run
/opt/MMDVM_Bridge/dvswitch.sh getUDPPortsForProcess ALL

The stop that bridge and start the other bridge
/opt/MMDVM_Bridge/dvswitch.sh getUDPPortsForProcess ALL

compare the 2 outputs.

On 12/18/2020 2:57 PM, Gary, KE8O wrote:
Steve, 

I ran dvswitch.sh getUDPPortsForProcess ALL with all instances of MB and AB stopped. With all instances stopped the only ports showing in use where those associated with P25Gateway 6074, 42010, 42020. The other ports not displayed used are 41000 - P25 reflector, and 42002 - YSF reflector. I did not find any conflicts. I attached the output for review. 


 


Re: Adding P25 to existing YSF and DMR bridge

Gary, KE8O
 

Now the files are attached. 


Re: Adding P25 to existing YSF and DMR bridge

Gary, KE8O
 

Steve, 

I ran dvswitch.sh getUDPPortsForProcess ALL with all instances of MB and AB stopped. With all instances stopped the only ports showing in use where those associated with P25Gateway 6074, 42010, 42020. The other ports not displayed used are 41000 - P25 reflector, and 42002 - YSF reflector. I did not find any conflicts. I attached the output for review. 


 


Re: Current Best-Practices for Linking with Brandmeister

J M
 

I'm not sure I understand your comment about the channels then. I should only need two channels to transcode between D-STAR and DMR within xlxd via ambed. Isn't the point of MMDVMBrdige/DVSwitch to translate between DMR and YSF by changing the data stream but not needing to be transcoded becuase YSF and DMR is the same AMBE version?


Re: Dmr Utils

Steve N4IRS
 

Things have changed since 2017.
I suggest you ask here <https://dvswitch.groups.io/g/HBlink>

Steve N4IRS

On 12/18/2020 1:02 PM, Don Poaps wrote:
On Sat, Jun 24, 2017 at 03:56 PM, Steve N4IRS wrote:
cd dmr_utils/
It is creating the folder dmr/utils/ directory I did ls and I hope this screencap shows the error. I'm running this on my dvswitch pi.

later

73

Don va7dgp






Re: Dmr Utils

Don Poaps
 

On Sat, Jun 24, 2017 at 03:56 PM, Steve N4IRS wrote:
cd dmr_utils/
It is creating the folder dmr/utils/ directory I did ls and I hope this screencap shows the error. I'm running this on my dvswitch pi.

later

73

Don va7dgp





Re: Current Best-Practices for Linking with Brandmeister

 

Its not a hardware problem. Only 2 channels  are being used. With the third not being used.  That's where the problem lies. You need a pair. 


From: main@DVSwitch.groups.io <main@DVSwitch.groups.io> on behalf of Patrick Perdue <patrick@...>
Sent: Friday, December 18, 2020 3:12:06 PM
To: main@DVSwitch.groups.io <main@DVSwitch.groups.io>
Subject: Re: [DVSwitch] Current Best-Practices for Linking with Brandmeister
 

Though I am using DVSwitch for part of my bridge, the way I'm hosting things now is that XLXD itself is acting as a YSF reflector, compiled with changes to the source to autolink module A to the room. The YSF reflector Registry officially supports XLXD now, so I don't need to run a separate service to host YSF. Thus, MMDVM_Bridge isn't needed to make that connection. I am using HBlink connected to 4001 to bridge from XLX to both the regular and prime TGIF servers, then DVSwitch to connect that to ASL, but BM, YSF and DStar are not using DVSwitch to make any part of that connection. I have a pair of ThumbDV's connected remotely (XLXD lives on a nearby VPS, two dongles are connected to a repurposed 2011 Mac Mini running Stretch in my house) and I can go months without restarting anything.

If my home internet goes down, which rarely happens, transcoding to/from DStar is messed up until the connection is re-established, but everything else is fine. I don't have to manually do anything to make that happen.

If I do need to restart a service, say, to upgrade the DVSwitch binaries or something like that, only the connection between the digital modes and ASL is broken for the duration.

Not saying this is necessarily the best solution, but it works for me.


On 12/18/2020 8:59 AM, Ernie Gm7kbk wrote:
Your problem  is your ambe dongle. Dropped one of them in my system and I got the same results. A pair may work better.  Reverted back to my single 3006


From: main@DVSwitch.groups.io <main@DVSwitch.groups.io> on behalf of J M <jason@...>
Sent: Friday, December 18, 2020 12:36:11 PM
To: main@DVSwitch.groups.io <main@DVSwitch.groups.io>
Subject: Re: [DVSwitch] Current Best-Practices for Linking with Brandmeister
 
Well, XLX interlink with a BM server seems to be the root of the problem I'm experiencing which is why I'm asking if there are better alternatives. Right now MMDVMBridge is communicating with xlxd running on the same host locally. I'm pulling XLX:4001 in with MMDVMBridge and then sending that to a YSFReflector running on the same host as well (and obviously the reverse). Without any logged reason the DMR <> MMDVMBridge connection will cease functioning properly. If receiving a YSF transmission, MMDVM is keying up in the log but there is no audio and xlxd does not seem to "see" the transmission properly. Periodically the xlxd log will report strange errors about "localhost xlxd: ambed 1552 of 414 packets timed out" when this happens. D-STAR works for a period of time and then everything about xlxd will degrade. We were not having this problem before the introduction of the DMR Interlink (D-STAR and YSF were served directly by xlxd).

I'm trying to figure out a way to decouple DMR/BM from xlxd so that D-STAR and YSF can survive through these DMR hiccups we're seeing.


Re: Current Best-Practices for Linking with Brandmeister

Patrick Perdue
 

Though I am using DVSwitch for part of my bridge, the way I'm hosting things now is that XLXD itself is acting as a YSF reflector, compiled with changes to the source to autolink module A to the room. The YSF reflector Registry officially supports XLXD now, so I don't need to run a separate service to host YSF. Thus, MMDVM_Bridge isn't needed to make that connection. I am using HBlink connected to 4001 to bridge from XLX to both the regular and prime TGIF servers, then DVSwitch to connect that to ASL, but BM, YSF and DStar are not using DVSwitch to make any part of that connection. I have a pair of ThumbDV's connected remotely (XLXD lives on a nearby VPS, two dongles are connected to a repurposed 2011 Mac Mini running Stretch in my house) and I can go months without restarting anything.

If my home internet goes down, which rarely happens, transcoding to/from DStar is messed up until the connection is re-established, but everything else is fine. I don't have to manually do anything to make that happen.

If I do need to restart a service, say, to upgrade the DVSwitch binaries or something like that, only the connection between the digital modes and ASL is broken for the duration.

Not saying this is necessarily the best solution, but it works for me.


On 12/18/2020 8:59 AM, Ernie Gm7kbk wrote:
Your problem  is your ambe dongle. Dropped one of them in my system and I got the same results. A pair may work better.  Reverted back to my single 3006


From: main@DVSwitch.groups.io <main@DVSwitch.groups.io> on behalf of J M <jason@...>
Sent: Friday, December 18, 2020 12:36:11 PM
To: main@DVSwitch.groups.io <main@DVSwitch.groups.io>
Subject: Re: [DVSwitch] Current Best-Practices for Linking with Brandmeister
 
Well, XLX interlink with a BM server seems to be the root of the problem I'm experiencing which is why I'm asking if there are better alternatives. Right now MMDVMBridge is communicating with xlxd running on the same host locally. I'm pulling XLX:4001 in with MMDVMBridge and then sending that to a YSFReflector running on the same host as well (and obviously the reverse). Without any logged reason the DMR <> MMDVMBridge connection will cease functioning properly. If receiving a YSF transmission, MMDVM is keying up in the log but there is no audio and xlxd does not seem to "see" the transmission properly. Periodically the xlxd log will report strange errors about "localhost xlxd: ambed 1552 of 414 packets timed out" when this happens. D-STAR works for a period of time and then everything about xlxd will degrade. We were not having this problem before the introduction of the DMR Interlink (D-STAR and YSF were served directly by xlxd).

I'm trying to figure out a way to decouple DMR/BM from xlxd so that D-STAR and YSF can survive through these DMR hiccups we're seeing.


Re: Current Best-Practices for Linking with Brandmeister

J M
 

You mean there's a hardware problem with the AMBE dongle? It's DVStick33 with three transcoder channels so it shouldn't be resource exhaustion.


Re: connection Ycs server

luiz sergio
 

Hi,
Was I able to speak for any YCS server and be heard?

tune:
191.252.101.21:42000

Thanks

Pu1loy


Re: Current Best-Practices for Linking with Brandmeister

 

Your problem  is your ambe dongle. Dropped one of them in my system and I got the same results. A pair may work better.  Reverted back to my single 3006


From: main@DVSwitch.groups.io <main@DVSwitch.groups.io> on behalf of J M <jason@...>
Sent: Friday, December 18, 2020 12:36:11 PM
To: main@DVSwitch.groups.io <main@DVSwitch.groups.io>
Subject: Re: [DVSwitch] Current Best-Practices for Linking with Brandmeister
 
Well, XLX interlink with a BM server seems to be the root of the problem I'm experiencing which is why I'm asking if there are better alternatives. Right now MMDVMBridge is communicating with xlxd running on the same host locally. I'm pulling XLX:4001 in with MMDVMBridge and then sending that to a YSFReflector running on the same host as well (and obviously the reverse). Without any logged reason the DMR <> MMDVMBridge connection will cease functioning properly. If receiving a YSF transmission, MMDVM is keying up in the log but there is no audio and xlxd does not seem to "see" the transmission properly. Periodically the xlxd log will report strange errors about "localhost xlxd: ambed 1552 of 414 packets timed out" when this happens. D-STAR works for a period of time and then everything about xlxd will degrade. We were not having this problem before the introduction of the DMR Interlink (D-STAR and YSF were served directly by xlxd).

I'm trying to figure out a way to decouple DMR/BM from xlxd so that D-STAR and YSF can survive through these DMR hiccups we're seeing.

2001 - 2020 of 9886