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



_._,_.


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


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



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



_._,_.


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


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


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


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

_._,_._,_




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


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



Steve N4IRS
 

I really should change this topic name...
No reply from Luc. I see there are 10 pending Pull requests, so I don't think this is going anywhere.

Steve


david bencini ik5xmk
 

Hi Steve and all,

I do not know the python language, I tried but I really need some help. Can anyone address me to modify HBLink's code so that you can skip that part where XLX returns incorrect information? I understand that it is not the right way and it would serve a proper analysis. But Luc does not answer because he is busy with the job and I just want to understand if it is possible to establish a simple connection between my dmrmaster and a XLX module to enable transcoding. If this works and makes sense, then it may be important to plan ahead with further steps. Thanks to everyone, every idea is well-received.

David IK5XMK