llrp_manager_example: Hangs on discovery about rdmnet

[samkearney]

Still, even the remote device is faulty, it should not stop the process from completing?

Yes, very true. It looks to me like the LLRP target you are using is responding to each probe request even though its UID is present in the Known UID list. I recommend asking the developer to have a look at ANSI E1.33 section 5.7.3.

However, you're right that this shouldn't cause discovery to go on forever. I've added an issue to our internal issue tracker to address this. We should be able to get to it soon. Thanks for bringing this up.

[vanvught]

Please see https://github.com/vanvught/rpidmx512/blob/master/lib-rdm/src/llrp/rdmhandlere1372.cpp#L45

When DMX_WORKSHOP_DEFECT is defined then there is no check for Interface ID. This is per default defined in the Makefile

[vanvught]

this is a bug in dmx_workshop, opi dmx, or RDMnet?

At the time I am testing, for sure a bug in DMX Workshop, hence the #define in my code. Just remove the define in the makefile when not working with DMX Workshop.

[ChristianReese]

Hello @TdatRJ !

Looking at the Wireshark file you attached, the LLRP target is already a part of the known UID list, but it's still responding to every probe request even though it shouldn't. Instead it should be checking if it's part of the known UID list - if it is, it shouldn't respond again since it was already discovered (see section 5.7.3 of e1.33). As Sam mentioned, we have a ticket to address this on the manager side (it should be robust enough to handle devices that do this, even though they break the standard's 5.7.3 requirement). The ticket hasn't been worked on yet, however I think I'll be able to have a look at it this Friday. That way you can update and the manager will ignore the redundant probe replies, avoiding the infinite loop. I'll post back here once the work is done.

[samkearney]

Hi @TdatRJ:

It means that the two controllers that we used are not compliant as well.

Actually, I think that the other controllers you used are fine - it just means that they have different reactions to noncompliant behavior by a responder. Like most technical standards, the RDMnet standard does not specify in all cases what implementations should do when they encounter noncompliant behavior, as there could be infinite variation in such behaviors, and the document needs to be a finite length 😄

[ChristianReese]

I've finally gotten around to fixing this LLRP manager defect - it will no longer continue indefinitely if there's a target responding to every request. Rather, instead it will log a warning when this happens instead of prolonging discovery.

[samkearney]

Could you provide some more information about your test setup? Are you testing with LLRP target software that you are developing?

Could you provide a Wireshark trace of the network activity while you're running this test? The newest released version of Wireshark has support for RDMnet protocols (use rdmnet as a filter) and since LLRP is an all-multicast protocol, you should be able to capture its traffic even between software running on the same machine.

[hippyau]

I am using a device by @vanvught as well as the ./rdmnet_device_example locally.

I disconnected Arjan's device, and it completes successfully.

Still, even the remote device is faulty, it should not stop the process from completing?

This conversation happens every 2 seconds. I'll look into a new version of wireshark too ;)

No.     Time           Source                Destination           Protocol Length Info
     74 8.055997324    192.168.1.49          239.255.250.133       UDP      126    54560 → 5569 Len=84

Frame 74: 126 bytes on wire (1008 bits), 126 bytes captured (1008 bits) on interface 0
Ethernet II, Src: Dell_3e:b6:95 (34:e6:d7:3e:b6:95), Dst: IPv4mcast_7f:fa:85 (01:00:5e:7f:fa:85)
Internet Protocol Version 4, Src: 192.168.1.49, Dst: 239.255.250.133
User Datagram Protocol, Src Port: 54560, Dst Port: 5569
    Source Port: 54560
    Destination Port: 5569
    Length: 92
    Checksum: 0x38d8 [unverified]
    [Checksum Status: Unverified]
    [Stream index: 6]
Data (84 bytes)

0000  00 10 00 00 41 53 43 2d 45 31 2e 31 37 00 00 00   ....ASC-E1.17...
0010  f0 00 44 00 00 00 0a 3b b9 7d 02 a1 13 4f 52 ae   ..D....;.}...OR.
0020  62 89 0c d4 c2 e3 5f f0 00 2d 00 00 00 01 fb ad   b....._..-......
0030  82 2c bd 0c 4d 4c bd c8 7e ab eb c8 5a ff 00 00   .,..ML..~...Z...
0040  00 00 f0 00 12 01 00 00 00 00 00 00 ff ff ff ff   ................
0050  ff ff 00 00                                       ....
    Data: 001000004153432d45312e3137000000f000440000000a3b...
    Text: 
    [Length: 84]

No.     Time           Source                Destination           Protocol Length Info
     75 8.056211019    192.168.1.122         239.255.250.134       UDP      125    5569 → 5569 Len=83

Frame 75: 125 bytes on wire (1000 bits), 125 bytes captured (1000 bits) on interface 0
Ethernet II, Src: 02:42:3c:42:09:13 (02:42:3c:42:09:13), Dst: IPv4mcast_7f:fa:86 (01:00:5e:7f:fa:86)
Internet Protocol Version 4, Src: 192.168.1.122, Dst: 239.255.250.134
User Datagram Protocol, Src Port: 5569, Dst Port: 5569
    Source Port: 5569
    Destination Port: 5569
    Length: 91
    [Checksum: [missing]]
    [Checksum Status: Not present]
    [Stream index: 7]
Data (83 bytes)

0000  00 10 00 00 41 53 43 2d 45 31 2e 31 37 00 00 00   ....ASC-E1.17...
0010  f0 00 43 00 00 00 0a 02 c0 01 42 84 70 46 20 b8   ..C.......B.pF .
0020  94 06 18 3c 42 09 13 f0 00 2c 00 00 00 02 3b b9   ...<B....,....;.
0030  7d 02 a1 13 4f 52 ae 62 89 0c d4 c2 e3 5f 00 00   }...OR.b....._..
0040  00 00 f0 00 11 01 50 00 3c 42 09 13 02 42 3c 42   ......P.<B...B<B
0050  09 13 ff                                          ...
    Data: 001000004153432d45312e3137000000f000430000000a02...
    Text: 
    [Length: 83]

No.     Time           Source                Destination           Protocol Length Info
    100 10.099528366   192.168.1.49          239.255.250.133       UDP      132    54560 → 5569 Len=90

Frame 100: 132 bytes on wire (1056 bits), 132 bytes captured (1056 bits) on interface 0
Ethernet II, Src: Dell_3e:b6:95 (34:e6:d7:3e:b6:95), Dst: IPv4mcast_7f:fa:85 (01:00:5e:7f:fa:85)
Internet Protocol Version 4, Src: 192.168.1.49, Dst: 239.255.250.133
User Datagram Protocol, Src Port: 54560, Dst Port: 5569
    Source Port: 54560
    Destination Port: 5569
    Length: 98
    Checksum: 0x976f [unverified]
    [Checksum Status: Unverified]
    [Stream index: 6]
Data (90 bytes)

0000  00 10 00 00 41 53 43 2d 45 31 2e 31 37 00 00 00   ....ASC-E1.17...
0010  f0 00 4a 00 00 00 0a 3b b9 7d 02 a1 13 4f 52 ae   ..J....;.}...OR.
0020  62 89 0c d4 c2 e3 5f f0 00 33 00 00 00 01 fb ad   b....._..3......
0030  82 2c bd 0c 4d 4c bd c8 7e ab eb c8 5a ff 00 00   .,..ML..~...Z...
0040  00 01 f0 00 18 01 00 00 00 00 00 00 ff ff ff ff   ................
0050  ff ff 00 00 50 00 3c 42 09 13                     ....P.<B..
    Data: 001000004153432d45312e3137000000f0004a0000000a3b...
    Text: 
    [Length: 90]

No.     Time           Source                Destination           Protocol Length Info
    101 10.099725660   192.168.1.122         239.255.250.134       UDP      125    5569 → 5569 Len=83

Frame 101: 125 bytes on wire (1000 bits), 125 bytes captured (1000 bits) on interface 0
Ethernet II, Src: 02:42:3c:42:09:13 (02:42:3c:42:09:13), Dst: IPv4mcast_7f:fa:86 (01:00:5e:7f:fa:86)
Internet Protocol Version 4, Src: 192.168.1.122, Dst: 239.255.250.134
User Datagram Protocol, Src Port: 5569, Dst Port: 5569
    Source Port: 5569
    Destination Port: 5569
    Length: 91
    [Checksum: [missing]]
    [Checksum Status: Not present]
    [Stream index: 7]
Data (83 bytes)

0000  00 10 00 00 41 53 43 2d 45 31 2e 31 37 00 00 00   ....ASC-E1.17...
0010  f0 00 43 00 00 00 0a 02 c0 01 42 84 70 46 20 b8   ..C.......B.pF .
0020  94 06 18 3c 42 09 13 f0 00 2c 00 00 00 02 3b b9   ...<B....,....;.
0030  7d 02 a1 13 4f 52 ae 62 89 0c d4 c2 e3 5f 00 00   }...OR.b....._..
0040  00 01 f0 00 11 01 50 00 3c 42 09 13 02 42 3c 42   ......P.<B...B<B
0050  09 13 ff                                          ...
    Data: 001000004153432d45312e3137000000f000430000000a02...
    Text: 
    [Length: 83]

No.     Time           Source                Destination           Protocol Length Info
    108 12.143428512   192.168.1.49          239.255.250.133       UDP      132    54560 → 5569 Len=90

Frame 108: 132 bytes on wire (1056 bits), 132 bytes captured (1056 bits) on interface 0
Ethernet II, Src: Dell_3e:b6:95 (34:e6:d7:3e:b6:95), Dst: IPv4mcast_7f:fa:85 (01:00:5e:7f:fa:85)
Internet Protocol Version 4, Src: 192.168.1.49, Dst: 239.255.250.133
User Datagram Protocol, Src Port: 54560, Dst Port: 5569
    Source Port: 54560
    Destination Port: 5569
    Length: 98
    Checksum: 0x976e [unverified]
    [Checksum Status: Unverified]
    [Stream index: 6]
Data (90 bytes)

0000  00 10 00 00 41 53 43 2d 45 31 2e 31 37 00 00 00   ....ASC-E1.17...
0010  f0 00 4a 00 00 00 0a 3b b9 7d 02 a1 13 4f 52 ae   ..J....;.}...OR.
0020  62 89 0c d4 c2 e3 5f f0 00 33 00 00 00 01 fb ad   b....._..3......
0030  82 2c bd 0c 4d 4c bd c8 7e ab eb c8 5a ff 00 00   .,..ML..~...Z...
0040  00 02 f0 00 18 01 00 00 00 00 00 00 ff ff ff ff   ................
0050  ff ff 00 00 50 00 3c 42 09 13                     ....P.<B..
    Data: 001000004153432d45312e3137000000f0004a0000000a3b...
    Text: 
    [Length: 90]

No.     Time           Source                Destination           Protocol Length Info
    109 12.143630547   192.168.1.122         239.255.250.134       UDP      125    5569 → 5569 Len=83

Frame 109: 125 bytes on wire (1000 bits), 125 bytes captured (1000 bits) on interface 0
Ethernet II, Src: 02:42:3c:42:09:13 (02:42:3c:42:09:13), Dst: IPv4mcast_7f:fa:86 (01:00:5e:7f:fa:86)
Internet Protocol Version 4, Src: 192.168.1.122, Dst: 239.255.250.134
User Datagram Protocol, Src Port: 5569, Dst Port: 5569
    Source Port: 5569
    Destination Port: 5569
    Length: 91
    [Checksum: [missing]]
    [Checksum Status: Not present]
    [Stream index: 7]
Data (83 bytes)

0000  00 10 00 00 41 53 43 2d 45 31 2e 31 37 00 00 00   ....ASC-E1.17...
0010  f0 00 43 00 00 00 0a 02 c0 01 42 84 70 46 20 b8   ..C.......B.pF .
0020  94 06 18 3c 42 09 13 f0 00 2c 00 00 00 02 3b b9   ...<B....,....;.
0030  7d 02 a1 13 4f 52 ae 62 89 0c d4 c2 e3 5f 00 00   }...OR.b....._..
0040  00 02 f0 00 11 01 50 00 3c 42 09 13 02 42 3c 42   ......P.<B...B<B
0050  09 13 ff                                          ...
    Data: 001000004153432d45312e3137000000f000430000000a02...
    Text: 
    [Length: 83]

No.     Time           Source                Destination           Protocol Length Info
    114 14.187451014   192.168.1.49          239.255.250.133       UDP      132    54560 → 5569 Len=90

Frame 114: 132 bytes on wire (1056 bits), 132 bytes captured (1056 bits) on interface 0
Ethernet II, Src: Dell_3e:b6:95 (34:e6:d7:3e:b6:95), Dst: IPv4mcast_7f:fa:85 (01:00:5e:7f:fa:85)
Internet Protocol Version 4, Src: 192.168.1.49, Dst: 239.255.250.133
User Datagram Protocol, Src Port: 54560, Dst Port: 5569
    Source Port: 54560
    Destination Port: 5569
    Length: 98
    Checksum: 0x976d [unverified]
    [Checksum Status: Unverified]
    [Stream index: 6]
Data (90 bytes)

0000  00 10 00 00 41 53 43 2d 45 31 2e 31 37 00 00 00   ....ASC-E1.17...
0010  f0 00 4a 00 00 00 0a 3b b9 7d 02 a1 13 4f 52 ae   ..J....;.}...OR.
0020  62 89 0c d4 c2 e3 5f f0 00 33 00 00 00 01 fb ad   b....._..3......
0030  82 2c bd 0c 4d 4c bd c8 7e ab eb c8 5a ff 00 00   .,..ML..~...Z...
0040  00 03 f0 00 18 01 00 00 00 00 00 00 ff ff ff ff   ................
0050  ff ff 00 00 50 00 3c 42 09 13                     ....P.<B..
    Data: 001000004153432d45312e3137000000f0004a0000000a3b...
    Text: 
    [Length: 90]

No.     Time           Source                Destination           Protocol Length Info
    115 14.187655686   192.168.1.122         239.255.250.134       UDP      125    5569 → 5569 Len=83

Frame 115: 125 bytes on wire (1000 bits), 125 bytes captured (1000 bits) on interface 0
Ethernet II, Src: 02:42:3c:42:09:13 (02:42:3c:42:09:13), Dst: IPv4mcast_7f:fa:86 (01:00:5e:7f:fa:86)
Internet Protocol Version 4, Src: 192.168.1.122, Dst: 239.255.250.134
User Datagram Protocol, Src Port: 5569, Dst Port: 5569
    Source Port: 5569
    Destination Port: 5569
    Length: 91
    [Checksum: [missing]]
    [Checksum Status: Not present]
    [Stream index: 7]
Data (83 bytes)

0000  00 10 00 00 41 53 43 2d 45 31 2e 31 37 00 00 00   ....ASC-E1.17...
0010  f0 00 43 00 00 00 0a 02 c0 01 42 84 70 46 20 b8   ..C.......B.pF .
0020  94 06 18 3c 42 09 13 f0 00 2c 00 00 00 02 3b b9   ...<B....,....;.
0030  7d 02 a1 13 4f 52 ae 62 89 0c d4 c2 e3 5f 00 00   }...OR.b....._..
0040  00 03 f0 00 11 01 50 00 3c 42 09 13 02 42 3c 42   ......P.<B...B<B
0050  09 13 ff                                          ...
    Data: 001000004153432d45312e3137000000f000430000000a02...
    Text: 
    [Length: 83]

[hippyau]

Hey @vanvught, check this out... ;) ANSI E1.33 section 5.7.3.

This is on my hub75 panel, latest.

¯_(ツ)_/¯ No stress.... just gearing up for node.

[hippyau]

Wow, 15 seconds.... a record for you @vanvught :) :) :)

[hippyau]

Okay, I'm out of my depth here..... this is a bug in dmx_workshop, opi dmx, or RDMnet?

[TdatRJ]

Hello,
We are implementing LLRP. It is fully working with DMXworkshop but as as hippyau post we have LLRP manager in a constant loop. We checked what Sam recommended but it looks ok for us. From Wireshark we cannot see anything wrong, see file below.

Remove the .txt from the file name to get a Wireshark file
ETC LLRP manager.pcapng.txt

Thanks

[samkearney]

@ChristianReese semi-related question: is there a public build of Concert available that supports LLRP operations? @TdatRJ was asking me if I knew of any other LLRP controllers and that was the only other option I could think of (although I suppose it probably would be using the same code)

[ChristianReese]

@samkearney - Concert has had RDMnet support (including the broker service) since 4.3 - however, unfortunately it doesn't support LLRP operations (either as an LLRP target or manager).

[TdatRJ]

Hello,
Thank you for the help on this.
We really thought that we were good as our LLRP implementation works fine with DMXworkshop and also with Netron Central Utility from Obsidian. I have also an EN 12 Netron with has LLRP. We have a Node from Artistic licence that works with DMXworkshop but not tested with other controllers.
To sum up:

• I have two devices not working with ETC dev kit. It means that the two controllers that we used are not compliant as well.
• When my colleague is back from holiday end of August, we will look at the 5.7.3 issue and will report.
• It means also that the overall implementation of RDMnet is going to be a not easy ride especially in terms of compatibility.
• Meanwhile I will contact Wayne (Singularity-DMXWorkshop) and Mathias (Obsidian) to let them know what I am experiencing.

[ChristianReese]

I'm in agreement with @samkearney - those controllers are neither compliant nor noncompliant in this regard, since handling such LLRP target behavior is outside of the scope of e1.33. In all honesty it sounds like those controllers are handling this situation better than the RDMnet library currently, thus the aforementioned ticket.

Speaking of that - I implemented the ticket, it is currently in review. I'll post back once it's integrated into a new library build.

RDMnet is going to be a not easy ride especially in terms of compatibility.

All I can advise here is to review the requirements of e1.33 against your current implementation - that's going to be the key to making that ride easier and reaching full compatibility with other RDMnet devices/controllers.

Thank you for the help on this.

Absolutely, glad to help! 😄

[RichardTea]

It would be very useful for the LLRP Manager to log warnings for responses that don't 100% strictly comply with the standard - fussy mode ;)

Otherwise people developing LLRP Targets will see their device get discovered and never realise if they made a mistake.

In this case the target appeared to work ok with DMX Workshop, but would have caused really hard to diagnose issues once people started using lots of them in real systems.

[TdatRJ]

Thanks everyone for the help.

It seems now that we are compatible with ETC implementation. LLRP manager is no longer in infinite loop.
As RichardTea requested a log warnings would be very helpful for other developer.

We have noticed this:
Handle UID CID Type Hardware ID
0 09ae:06500002 01020304-0060-3712-3457-09ae06500002 Invalid LLRP Component Type 00:60:37:12:34:57

What does it mean in Type : Invalid LLRP Component?

[ChristianReese]

@TdatRJ LLRP component types describe the type of RDMnet component with which an LLRP target is associated. The component types that are currently valid are RDMnet Device, RDMnet Controller, RDMnet Broker, and LLRP Only (see section 5.4.2.2 of e1.33, and Table A-23). If the LLRP target is not reporting one of these types, you will see Invalid LLRP Component Type instead. I would double check what value the target is reporting for this in the probe replies currently.

[TdatRJ]

@ChristianReese Table A.23 says that LLRP_COMPONENT_TYPE_NON_RDMNET the value must 0xFF that's what we implemented.
Wireshark capture confirms it:

• see attached file:
  

LLRP manager gives:

Maybe 0xFF is not the correct value or there is a bug somewhere.

[ChristianReese]

@TdatRJ Thanks, based on your findings I agree this is likely a bug, I have filed a ticket.