1. main@DVSwitch.groups.io
  2. Messages
   Date   
Analog_Bridge Source

Chris Andrist, KC7WSU
 

I am trying to run Analog_Bridge on FreeBSD. Is the source available that I can download and compile it?

I am getting the following error:

root@dmrgateway:/srv/Analog_Bridge # ./Analog_Bridge.x64
ELF binary type "0" not known.
./Analog_Bridge.x64: Exec format error. Binary file not executable.

My goal is to separate Analog Audio and the USRP Node. This way if the node dies I can just setup app_rpt again and not have to setup Analog_Bridge, HB_Bridge, and app_rpt.

Regards,
Chris Andrist, KC7WSU
DMR-UTAH
Re: New Set Up MMDVM to IPSC

Steve N4IRS
 

Correct,
I tried to use the correct terminology.
In HB Protocol MMDVMHost is the "Client" and HBlink is the "Server"
In IPSC (Motorola) DMRlink is the "Peer" ant your 8300 is the "Master"

HB_Bridge and IPSC_Bridge are referred to as "Partners" Partners talk to each other.
Other Partners are:
Analog_Bridge for connecting to AllStar and EchoLink
DummyRepeater is from G4KLX and has been modified to connect to D-Star. Not really a Partner, but it acts like one.

Other Partners to come...

73, Steve N4IRS  

On 10/11/2017 12:56 PM, stevecast2024@... wrote:
Thank You Steve,

This is exactly the info I'm looking for. My confusion was with HBlink in the process. So essentially I will run HBbridge which will be used to connect MMDVM with  DMlink then DMlink will be a peer to the 8300 master.

I'll assemble everything over the next week or so.

Thank you again,
Steve
_._,_._,_
Re: New Set Up MMDVM to IPSC

stevecast2024@...
 

Thank You Steve,

This is exactly the info I'm looking for. My confusion was with HBlink in the process. So essentially I will run HBbridge which will be used to connect MMDVM with  DMlink then DMlink will be a peer to the 8300 master.

I'll assemble everything over the next week or so.

Thank you again,
Steve
Re: New Set Up MMDVM to IPSC

Steve N4IRS
 

Steve,
Based on your post it's a pretty simple config. It will look like this:
MMDVM <---> HB_Bridge <---> IPSC_Bridge <---> XPR8300

HB_Bridge (HBlink) will be a Server for MMDVM
IPSC_Bridge (DMRlink) will be a Peer for your XPR8300.

HB_Bridge is a HBlink application. you will configure hblink.cfg to create the Server.
IPSC_Bridge is a DMRlink application. you will configure dmrlink.cfg to create the Peer.

Start hblink.py in the forground, you should see the MMDVM login.
Start dmrlink.py in the foreground, you should see it login to your Master

Stop both programs

You will now configure HB_Bridge.cfg and IPSC_Bridge.cfg to talk to each other.

Start HB_Bridge in the foreground (it will run hblink.py for you) Watch MMDVM login
Start IPSC_Bridge (it will run dmrlink.py for you) Watch it login to your master.

You should now see any traffic from MMDVM "flow" to your XPR8300 Master.

Hope this helps,

73, Steve N4IRS



On 10/10/2017 11:13 PM, stevecast2024@... wrote:
Hello All,

If I am wrong in asking this here please feel free to blast me or point me to the correct location. I have read the readme as well as the CFG files but I may be missing a key piece of information that will make this all click for me.

I have an XPR8300 that I would like to run as an IPSC master. This replaced a Kenwood TKR-850 when I switched the site over to DMR. I was going to purchase a second XPR8300 or 8400 for a new site that I am hoping to add but I have also been in the process of adding MMDVM to the Kenwood repeater. I would like to configure the Kenwood with MMDVM to act as a peer to the XPR8300 master. Can I simply connect MMDVM to DMRLINK and configure DMRLINK as a peer to connect to XPR8300 IPSC? Would I have to connect to HBLINK first, and then connect to DMRLINK? Right now I want to link just these 2 repeaters without going to BM or any other network. A basic IPSC Master with one Peer setup.

Thank You Much... You are all a huge asset to the community!
Steve

Re: Current status DMRlink, HBlink DVSwitch

david bencini ik5xmk
 

Hi guys are there any news?

I know Luc is very busy at this time but source codes are available and if anyone knows the c ++ I think it's not difficult to understand what XLX asks and responds.

If there is a chance to do some test I am very happy, as mentioned above it is very important to get a hblink collector that takes the dmr flow from a server and sends it to XLX.

Important: On XLX, you must indicate, via a TG, which module connects at startup.

Thanks to everyone
David

2017-10-05 16:36 GMT+02:00 Cort N0MJS <n0mjs@...>:

I guess I should have said “Before we bug him again”.


On Oct 5, 2017, at 8:33 AM, Steve N4IRS <szingman@...> wrote:

Agreed,
I just wanted to report where we stood. If I hear from him before Monday, I'll let everyone know.

Steve

On 10/5/2017 10:31 AM, Cort N0MJS wrote:
Luc may be busy like us…. Give him through the weekend?

On Oct 5, 2017, at 8:24 AM, Steve N4IRS <szingman@...> wrote:

As of today 10/5/2017 I do not have a reply from Luc nor do I see any change to the XLX source.

Steve

Cort Buffington
785-865-7206


Cort Buffington
785-865-7206
New Set Up MMDVM to IPSC

stevecast2024@...
 

Hello All,

If I am wrong in asking this here please feel free to blast me or point me to the correct location. I have read the readme as well as the CFG files but I may be missing a key piece of information that will make this all click for me.

I have an XPR8300 that I would like to run as an IPSC master. This replaced a Kenwood TKR-850 when I switched the site over to DMR. I was going to purchase a second XPR8300 or 8400 for a new site that I am hoping to add but I have also been in the process of adding MMDVM to the Kenwood repeater. I would like to configure the Kenwood with MMDVM to act as a peer to the XPR8300 master. Can I simply connect MMDVM to DMRLINK and configure DMRLINK as a peer to connect to XPR8300 IPSC? Would I have to connect to HBLINK first, and then connect to DMRLINK? Right now I want to link just these 2 repeaters without going to BM or any other network. A basic IPSC Master with one Peer setup.

Thank You Much... You are all a huge asset to the community!
Steve
Re: Current status DMRlink, HBlink DVSwitch

Cort N0MJS <n0mjs@...>
 

I guess I should have said “Before we bug him again”.


On Oct 5, 2017, at 8:33 AM, Steve N4IRS <szingman@...> wrote:

Agreed,
I just wanted to report where we stood. If I hear from him before Monday, I'll let everyone know.

Steve

On 10/5/2017 10:31 AM, Cort N0MJS wrote:
Luc may be busy like us…. Give him through the weekend?

On Oct 5, 2017, at 8:24 AM, Steve N4IRS <szingman@...> wrote:

As of today 10/5/2017 I do not have a reply from Luc nor do I see any change to the XLX source.

Steve

Cort Buffington
785-865-7206


Cort Buffington
785-865-7206

?
smime.p7s

Re: Current status DMRlink, HBlink DVSwitch

Steve N4IRS
 

Agreed,
I just wanted to report where we stood. If I hear from him before Monday, I'll let everyone know.

Steve

On 10/5/2017 10:31 AM, Cort N0MJS wrote:
Luc may be busy like us…. Give him through the weekend?

On Oct 5, 2017, at 8:24 AM, Steve N4IRS <szingman@...> wrote:

As of today 10/5/2017 I do not have a reply from Luc nor do I see any change to the XLX source.

Steve

Cort Buffington
785-865-7206

_._,_._,_
Re: Current status DMRlink, HBlink DVSwitch

Cort N0MJS <n0mjs@...>
 

Luc may be busy like us…. Give him through the weekend?

On Oct 5, 2017, at 8:24 AM, Steve N4IRS <szingman@...> wrote:

As of today 10/5/2017 I do not have a reply from Luc nor do I see any change to the XLX source.

Steve

Cort Buffington
785-865-7206

?
smime.p7s

Re: Current status DMRlink, HBlink DVSwitch

Steve N4IRS
 

As of today 10/5/2017 I do not have a reply from Luc nor do I see any change to the XLX source.

Steve
Re: Current status DMRlink, HBlink DVSwitch

Steve N4IRS
 

Will,
We are discussing the protocol of the communications between the client (MMDVMGost, DMRGateway HBlink) and the server (BM, HBlink, DMR+).

Thanks, Steve
Re: Current status DMRlink, HBlink DVSwitch

Will - W4WWM <w4wwm@...>
 


Steve,

John - K6KD and Bob- W6KD and his group has XLX313 transcoding server and it returns DMR ID's and call sign. 

Will / W4WWM


On 10/3/2017 11:21 AM, Steve N4IRS wrote:
David,
That is true that MMDVMHost does not have a problem connecting to XLX. MMDVM host does not have a problem connecting to XLX because it ignores the response. Just as HB does not have a problem connecting to DMRGateway, BM, and DMR Master.
As Matthew pointed out, "XLX950 is not returning the Repeater ID after the RPTACK" Which I believe it should.

Steve

On 10/3/2017 11:42 AM, david bencini ik5xmk wrote:
Hi Steve, you are right, but MMDVM repeaters have no problems to connect to XLX servers at the moment, so can we find a solution/patch to hblink project ?
Can i help you in any ways? Have you a code to test "on the fly" ? :)
It is very import to have finally a dmr data flow from a dmr net to an xlx reflector with transcoder on board.
My systems are available for any test

Thank you very much guys

David

2017-10-03 16:08 GMT+02:00 Steve N4IRS <szingman@...>:
Matthew,
Thank you for the captures and comments. That's consistent with what we think are the inconstancy of HB Protocol. The published document, The source code without comments and multiple servers do it "their way" Maybe a effort to create a true protocol document would be worthwhile. Something that actually documents what is happening. We could use it to convince the different parties to come to some agreement.  

Thanks, Steve

--
The nice thing about standards is that there are so many to choose from!


On 10/2/2017 7:12 PM, Matthew 2E0SIP wrote:

Hi Steve,

Heres the login details for XLX950-

Address=xlx950.epf.lu
Port=62030
Password=passw0rd

I performed some packet captures direct from MMDVMHost and it looks as though XLX950 is not returning the Repeater ID after the RPTACK. I've checked the source and it doesn't look like MMDVMHost or DMRGateway are validating the repeater ID but HBLink is, causing it to fail. Interestingly enough, DMRGateway does include the Repeater ID when it ACK's the MMDVMHost login. 


I've attached the packet captures-

mmdvm_bm.pcap (successful BM login, showing RPTACK with Repeater ID)

mmdvm_xlx.pcap (succesfull XLX login, showing RPTACK without Repeater ID)

 

I guess to be inline with MMDVMHost and DMRGateway, HBlink shouldn't validate the repeater ID when it receives an RTPACK from a master, but should include the ID when it sends a RPTACK to a master.

I hope that helps,

Matthew

2E0SIP



_._,_.
Re: Current status DMRlink, HBlink DVSwitch

Steve N4IRS
 

I have sent Luc a E-Mail requesting a change to XLX to provide the repeater ID along with the ACK. I'll post when I get a reply.

73, Steve N4IRS

On 10/3/2017 12:30 PM, Cort N0MJS wrote:
Guys,

With your help, I now have a functioning config with hblink.py connecting to XLX and have isolated what is happening.

The real fix isn’t likely as simple as making whatever the easiest code modification to hblink.py is to get XLX to work. We also don’t know what (if any) other changes to the protocol exist in XLX. It’s going to take just a little big longer to try and fix this the right way as opposed to fixing it the fastest way.

Please give us a few days to get this sorted. It’s a hobby for us. Steve, Mike and I all have day jobs and lives to juggle here. Our commitment to “free and open” comes with a price — and that price is usually giving us a bit of space to work. We’ll get it soon — but the goal here is the right fix, not the fastest thing we can do to make hblink.py connect to XLX.

0x49 DE N0MJS


On Oct 3, 2017, at 11:21 AM, Steve N4IRS <szingman@...> wrote:

David,
That is true that MMDVMHost does not have a problem connecting to XLX. MMDVM host does not have a problem connecting to XLX because it ignores the response. Just as HB does not have a problem connecting to DMRGateway, BM, and DMR Master.
As Matthew pointed out, "XLX950 is not returning the Repeater ID after the RPTACK" Which I believe it should.

Steve

On 10/3/2017 11:42 AM, david bencini ik5xmk wrote:
Hi Steve, you are right, but MMDVM repeaters have no problems to connect to XLX servers at the moment, so can we find a solution/patch to hblink project ?
Can i help you in any ways? Have you a code to test "on the fly" ? :)
It is very import to have finally a dmr data flow from a dmr net to an xlx reflector with transcoder on board.
My systems are available for any test

Thank you very much guys

David

2017-10-03 16:08 GMT+02:00 Steve N4IRS <szingman@...>:
Matthew,
Thank you for the captures and comments. That's consistent with what we think are the inconstancy of HB Protocol. The published document, The source code without comments and multiple servers do it "their way" Maybe a effort to create a true protocol document would be worthwhile. Something that actually documents what is happening. We could use it to convince the different parties to come to some agreement.  

Thanks, Steve

--
The nice thing about standards is that there are so many to choose from!


On 10/2/2017 7:12 PM, Matthew 2E0SIP wrote:

Hi Steve,

Heres the login details for XLX950-

Address=xlx950.epf.lu
Port=62030
Password=passw0rd

I performed some packet captures direct from MMDVMHost and it looks as though XLX950 is not returning the Repeater ID after the RPTACK. I've checked the source and it doesn't look like MMDVMHost or DMRGateway are validating the repeater ID but HBLink is, causing it to fail. Interestingly enough, DMRGateway does include the Repeater ID when it ACK's the MMDVMHost login. 


I've attached the packet captures-

mmdvm_bm.pcap (successful BM login, showing RPTACK with Repeater ID)

mmdvm_xlx.pcap (succesfull XLX login, showing RPTACK without Repeater ID)

 

I guess to be inline with MMDVMHost and DMRGateway, HBlink shouldn't validate the repeater ID when it receives an RTPACK from a master, but should include the ID when it sends a RPTACK to a master.

I hope that helps,

Matthew

2E0SIP



_._,_.

Cort Buffington
785-865-7206
Re: Current status DMRlink, HBlink DVSwitch

Cort N0MJS <n0mjs@...>
 

Guys,

With your help, I now have a functioning config with hblink.py connecting to XLX and have isolated what is happening.

The real fix isn’t likely as simple as making whatever the easiest code modification to hblink.py is to get XLX to work. We also don’t know what (if any) other changes to the protocol exist in XLX. It’s going to take just a little big longer to try and fix this the right way as opposed to fixing it the fastest way.

Please give us a few days to get this sorted. It’s a hobby for us. Steve, Mike and I all have day jobs and lives to juggle here. Our commitment to “free and open” comes with a price — and that price is usually giving us a bit of space to work. We’ll get it soon — but the goal here is the right fix, not the fastest thing we can do to make hblink.py connect to XLX.

0x49 DE N0MJS


On Oct 3, 2017, at 11:21 AM, Steve N4IRS <szingman@...> wrote:

David,
That is true that MMDVMHost does not have a problem connecting to XLX. MMDVM host does not have a problem connecting to XLX because it ignores the response. Just as HB does not have a problem connecting to DMRGateway, BM, and DMR Master.
As Matthew pointed out, "XLX950 is not returning the Repeater ID after the RPTACK" Which I believe it should.

Steve

On 10/3/2017 11:42 AM, david bencini ik5xmk wrote:
Hi Steve, you are right, but MMDVM repeaters have no problems to connect to XLX servers at the moment, so can we find a solution/patch to hblink project ?
Can i help you in any ways? Have you a code to test "on the fly" ? :)
It is very import to have finally a dmr data flow from a dmr net to an xlx reflector with transcoder on board.
My systems are available for any test

Thank you very much guys

David

2017-10-03 16:08 GMT+02:00 Steve N4IRS <szingman@...>:
Matthew,
Thank you for the captures and comments. That's consistent with what we think are the inconstancy of HB Protocol. The published document, The source code without comments and multiple servers do it "their way" Maybe a effort to create a true protocol document would be worthwhile. Something that actually documents what is happening. We could use it to convince the different parties to come to some agreement.  

Thanks, Steve

--
The nice thing about standards is that there are so many to choose from!


On 10/2/2017 7:12 PM, Matthew 2E0SIP wrote:

Hi Steve,

Heres the login details for XLX950-

Address=xlx950.epf.lu
Port=62030
Password=passw0rd

I performed some packet captures direct from MMDVMHost and it looks as though XLX950 is not returning the Repeater ID after the RPTACK. I've checked the source and it doesn't look like MMDVMHost or DMRGateway are validating the repeater ID but HBLink is, causing it to fail. Interestingly enough, DMRGateway does include the Repeater ID when it ACK's the MMDVMHost login. 


I've attached the packet captures-

mmdvm_bm.pcap (successful BM login, showing RPTACK with Repeater ID)

mmdvm_xlx.pcap (succesfull XLX login, showing RPTACK without Repeater ID)

 

I guess to be inline with MMDVMHost and DMRGateway, HBlink shouldn't validate the repeater ID when it receives an RTPACK from a master, but should include the ID when it sends a RPTACK to a master.

I hope that helps,

Matthew

2E0SIP



_._,_.

Cort Buffington
785-865-7206

?
smime.p7s

Re: Current status DMRlink, HBlink DVSwitch

Steve N4IRS
 

David,
That is true that MMDVMHost does not have a problem connecting to XLX. MMDVM host does not have a problem connecting to XLX because it ignores the response. Just as HB does not have a problem connecting to DMRGateway, BM, and DMR Master.
As Matthew pointed out, "XLX950 is not returning the Repeater ID after the RPTACK" Which I believe it should.

Steve

On 10/3/2017 11:42 AM, david bencini ik5xmk wrote:
Hi Steve, you are right, but MMDVM repeaters have no problems to connect to XLX servers at the moment, so can we find a solution/patch to hblink project ?
Can i help you in any ways? Have you a code to test "on the fly" ? :)
It is very import to have finally a dmr data flow from a dmr net to an xlx reflector with transcoder on board.
My systems are available for any test

Thank you very much guys

David

2017-10-03 16:08 GMT+02:00 Steve N4IRS <szingman@...>:
Matthew,
Thank you for the captures and comments. That's consistent with what we think are the inconstancy of HB Protocol. The published document, The source code without comments and multiple servers do it "their way" Maybe a effort to create a true protocol document would be worthwhile. Something that actually documents what is happening. We could use it to convince the different parties to come to some agreement.  

Thanks, Steve

--
The nice thing about standards is that there are so many to choose from!


On 10/2/2017 7:12 PM, Matthew 2E0SIP wrote:

Hi Steve,

Heres the login details for XLX950-

Address=xlx950.epf.lu
Port=62030
Password=passw0rd

I performed some packet captures direct from MMDVMHost and it looks as though XLX950 is not returning the Repeater ID after the RPTACK. I've checked the source and it doesn't look like MMDVMHost or DMRGateway are validating the repeater ID but HBLink is, causing it to fail. Interestingly enough, DMRGateway does include the Repeater ID when it ACK's the MMDVMHost login. 


I've attached the packet captures-

mmdvm_bm.pcap (successful BM login, showing RPTACK with Repeater ID)

mmdvm_xlx.pcap (succesfull XLX login, showing RPTACK without Repeater ID)

 

I guess to be inline with MMDVMHost and DMRGateway, HBlink shouldn't validate the repeater ID when it receives an RTPACK from a master, but should include the ID when it sends a RPTACK to a master.

I hope that helps,

Matthew

2E0SIP



_._,_.
Re: Current status DMRlink, HBlink DVSwitch

david bencini ik5xmk
 

Hi Steve, you are right, but MMDVM repeaters have no problems to connect to XLX servers at the moment, so can we find a solution/patch to hblink project ?
Can i help you in any ways? Have you a code to test "on the fly" ? :)
It is very import to have finally a dmr data flow from a dmr net to an xlx reflector with transcoder on board.
My systems are available for any test

Thank you very much guys

David

2017-10-03 16:08 GMT+02:00 Steve N4IRS <szingman@...>:

Matthew,
Thank you for the captures and comments. That's consistent with what we think are the inconstancy of HB Protocol. The published document, The source code without comments and multiple servers do it "their way" Maybe a effort to create a true protocol document would be worthwhile. Something that actually documents what is happening. We could use it to convince the different parties to come to some agreement.  

Thanks, Steve

--
The nice thing about standards is that there are so many to choose from!


On 10/2/2017 7:12 PM, Matthew 2E0SIP wrote:

Hi Steve,

Heres the login details for XLX950-

Address=xlx950.epf.lu
Port=62030
Password=passw0rd

I performed some packet captures direct from MMDVMHost and it looks as though XLX950 is not returning the Repeater ID after the RPTACK. I've checked the source and it doesn't look like MMDVMHost or DMRGateway are validating the repeater ID but HBLink is, causing it to fail. Interestingly enough, DMRGateway does include the Repeater ID when it ACK's the MMDVMHost login. 


I've attached the packet captures-

mmdvm_bm.pcap (successful BM login, showing RPTACK with Repeater ID)

mmdvm_xlx.pcap (succesfull XLX login, showing RPTACK without Repeater ID)

 

I guess to be inline with MMDVMHost and DMRGateway, HBlink shouldn't validate the repeater ID when it receives an RTPACK from a master, but should include the ID when it sends a RPTACK to a master.

I hope that helps,

Matthew

2E0SIP
Re: Current status DMRlink, HBlink DVSwitch

Matthew 2E0SIP
 

Hi Steve,

No problem. I was reading the specification and scratching my head because as you say it has been implemented differently in various projects.
I think the application of RFC2119 to the specification would be a good idea in future.

Cheers,

Matthew
Re: Current status DMRlink, HBlink DVSwitch

Steve N4IRS
 

Matthew,
Thank you for the captures and comments. That's consistent with what we think are the inconstancy of HB Protocol. The published document, The source code without comments and multiple servers do it "their way" Maybe a effort to create a true protocol document would be worthwhile. Something that actually documents what is happening. We could use it to convince the different parties to come to some agreement.  

Thanks, Steve

--
The nice thing about standards is that there are so many to choose from!


On 10/2/2017 7:12 PM, Matthew 2E0SIP wrote:

Hi Steve,

Heres the login details for XLX950-

Address=xlx950.epf.lu
Port=62030
Password=passw0rd

I performed some packet captures direct from MMDVMHost and it looks as though XLX950 is not returning the Repeater ID after the RPTACK. I've checked the source and it doesn't look like MMDVMHost or DMRGateway are validating the repeater ID but HBLink is, causing it to fail. Interestingly enough, DMRGateway does include the Repeater ID when it ACK's the MMDVMHost login. 


I've attached the packet captures-

mmdvm_bm.pcap (successful BM login, showing RPTACK with Repeater ID)

mmdvm_xlx.pcap (succesfull XLX login, showing RPTACK without Repeater ID)

 

I guess to be inline with MMDVMHost and DMRGateway, HBlink shouldn't validate the repeater ID when it receives an RTPACK from a master, but should include the ID when it sends a RPTACK to a master.

I hope that helps,

Matthew

2E0SIP
Re: Current status DMRlink, HBlink DVSwitch

david bencini ik5xmk
 

Hi Steve and all, 

i've a dedicated MMDVM DMR RPT to connect our XLX reflector,

this is MMDVM.ini configuration for DMR section to use DMRGateway software:


[DMR Network]
Enable=1
Address=127.0.0.1
Port=62031
Jitter=300
Local=62032
Password=passw0rd
Options=
Slot1=1
Slot2=1
Debug=0

This is DMRGateway.ini configuration, to connect XLX039 for trascoding module B (Italy (TG 4002 to link and TG 222 to speak)) on SLOT 1 and XLX077 (Module R (4018 and TG 22251 to speak), Tuscany Region) on SLOT 2 


[General]
Timeout=10
RptAddress=127.0.0.1
RptPort=62032
LocalAddress=127.0.0.1
LocalPort=62031
RuleTrace=0
Daemon=0
Debug=0

[XLX Network 1]
#*************************************
# CONNESSIONE SLOT 1 A NAZIONALE DSTAR
#*************************************
Enabled=1
Name=XLX039
Port=62030
Slot=1
TG=222
Base=4000
Startup=4002
Relink=10
Password=passw0rd
Debug=0

[XLX Network 2]
#***************************************
# CONNESSIONE SLOT 2 A REGIONALE R DSTAR
#***************************************
Enabled=1
Name=XLX077
Port=62030
Slot=2
TG=22251
Startup=4018
Relink=10
Password=passw0rd
Debug=0

All is working very well, with a good audio (using 2 ThumbDV USB to transcode).

Our RPT dashboard: http://185.109.24.70:8080/


Our DMR MASTER (where i do tests) dashboard: http://dmrmaster.grupporadiofirenze.net/

Thank you

David IK5XMK



2017-10-02 23:55 GMT+02:00 Steve N4IRS <szingman@...>:

David,
That was as I expected. We are looking at this. I will say that the HBlink client instance has no trouble connecting to BM, DMR Master, DMRGateway and HBlink server instance. We are still going to see if we can isolate the issue. I do have a request, to make our lives easier can someone supply us with the login info needed to connect to a existing XLX DMR?

Thanks, Steve N4IRS

On 10/02/2017 06:24 AM, david bencini ik5xmk wrote:
Hi Steve,

i'm making some tests, to dmr master server no problem to connect to, 
but on xlx side i've this error:

DEBUG 2017-10-02 06:13:39,719 Logging system started, anything from here on gets logged
INFO 2017-10-02 06:13:39,720 HBlink 'HBlink.py' (c) 2016 N0MJS & the K0USY Group - SYSTEM STARTING...
DEBUG 2017-10-02 06:13:39,721 (REPEATER-1) Client maintenance loop started
INFO 2017-10-02 06:13:39,722 (REPEATER-1) Sending login request to master 185.203.118.66:55555
DEBUG 2017-10-02 06:13:39,722 CLIENT instance created: REPEATER-1, <__main__.HBSYSTEM instance at 0x7fbf0433aab8>
DEBUG 2017-10-02 06:13:39,723 (REPEATER-2) Client maintenance loop started
INFO 2017-10-02 06:13:39,723 (REPEATER-2) Sending login request to master 5.249.151.111:62030
DEBUG 2017-10-02 06:13:39,723 CLIENT instance created: REPEATER-2, <__main__.HBSYSTEM instance at 0x7fbf040fb878>
INFO 2017-10-02 06:13:39,724 (REPEATER-1) Repeater Login ACK Received with 32bit ID: 2225069
INFO 2017-10-02 06:13:39,725 (REPEATER-1) Repeater Authentication Accepted
INFO 2017-10-02 06:13:39,725 (REPEATER-1) Repeater Configuration Sent
DEBUG 2017-10-02 06:13:39,726 (REPEATER-1) MSTPONG Received. Pongs Since Connected: 1
INFO 2017-10-02 06:13:39,727 (REPEATER-1) Repeater Configuration Accepted
INFO 2017-10-02 06:13:39,727 (REPEATER-1) Connection to Master Completed
INFO 2017-10-02 06:13:39,768 (REPEATER-2) Repeater Login ACK Received with 32bit ID: 1228258867
ERROR 2017-10-02 06:13:39,813 (REPEATER-2) Master ACK Contained wrong ID - Connection Reset
Re: Current status DMRlink, HBlink DVSwitch

Matthew 2E0SIP
 

Hi Steve,

Heres the login details for XLX950-

Address=xlx950.epf.lu
Port=62030
Password=passw0rd

I performed some packet captures direct from MMDVMHost and it looks as though XLX950 is not returning the Repeater ID after the RPTACK. I've checked the source and it doesn't look like MMDVMHost or DMRGateway are validating the repeater ID but HBLink is, causing it to fail. Interestingly enough, DMRGateway does include the Repeater ID when it ACK's the MMDVMHost login. 


I've attached the packet captures-

mmdvm_bm.pcap (successful BM login, showing RPTACK with Repeater ID)

mmdvm_xlx.pcap (succesfull XLX login, showing RPTACK without Repeater ID)

 

I guess to be inline with MMDVMHost and DMRGateway, HBlink shouldn't validate the repeater ID when it receives an RTPACK from a master, but should include the ID when it sends a RPTACK to a master.

I hope that helps,

Matthew

2E0SIP

?
mmdvm_bm.pcap
?
mmdvm_xlx.pcap

10321 - 10340 of 10775