search

ETCLabs / RDMnet

Implementation of ANSI E1.33
https://etclabs.github.io/RDMnetDocs
Apache License 2.0
40 stars 12 forks source link

llrp_manager_example: Hangs on discovery #50

Closed hippyau closed 8 months ago

hippyau commented 3 years ago

On Linux...

hip@hip-Alienware-13:~/ext/development/RDMnet/build/examples/llrp_manager$ ./llrp_manager_example
ETC Example LLRP Manager version 0.4.0.2 initializing...
2021-08-12 16:16:09.000+10:00 [INFO] RDMnet: Initializing multicast network interfaces...
Discovered network interfaces:
Handle Address                        MAC               Name
0      127.0.0.1                      00:00:00:00:00:00 lo
1      ::1                            00:00:00:00:00:00 lo
2      192.168.1.49                   34:e6:d7:3e:b6:95 enp2s0
3      fe80::f10f:a22d:2bf7:9a73      34:e6:d7:3e:b6:95 enp2s0
4      172.17.0.1                     02:42:7d:2e:90:a8 docker0
LLRP Manager Commands:
    ?: Print commands
    d <netint_handle>: Perform LLRP discovery on network interface indicated by
        netint_handle
    pt: Print discovered LLRP Targets
    pi: Print network interfaces
    i <target_handle>: Get DEVICE_INFO from Target <target_handle>
    l <target_handle>: Get DEVICE_LABEL from Target <target_handle>
    gi <target_handle>: Get LIST_INTERFACES from Target <target_handle>
    sf <target_handle>: Set FACTORY_DEFAULTS on Target <target_handle>
    si <target_handle>: Toggle IDENTIFY_DEVICE on/off on Target <target_handle>
    sl <target_handle> <label>: Set DEVICE_LABEL to <label> on Target
        <target_handle>
    sr <target_handle>: Set RESET_DEVICE on Target <target_handle>
    sz <target_handle> <interface_id>: Set IPV4_ZEROCONF_MODE
        with Set INTERFACE_APPLY_CONFIGURATION on Target <target_handle>
    m <target_handle>: Get MANUFACTURER_LABEL from Target <target_handle>
    c <target_handle>: Get DEVICE_MODEL_DESCRIPTION from Target <target_handle>
    s <target_handle> <scope_slot>: Get COMPONENT_SCOPE for Scope Slot
        <scope_slot> from Target <target_handle>
    ss <target_handle> <scope_slot> <scope> [ip:port]: Set COMPONENT_SCOPE to
        <scope> for Scope Slot <scope_slot> on Target <target_handle> with
        optional static Broker address ip:port
    q: Quit
d 2
Starting LLRP discovery...
Adding LLRP Target, UID 5000:3c420913, with handle 0

But it never returns...

However, if I use an interface with no targets, like 127.0.0.1, or a IPv6, it finds nothing (as expected) but does return...

hip@hip-Alienware-13:~/ext/development/RDMnet/build/examples/llrp_manager$ ./llrp_manager_example
ETC Example LLRP Manager version 0.4.0.2 initializing...
2021-08-12 16:19:28.000+10:00 [INFO] RDMnet: Initializing multicast network interfaces...
Discovered network interfaces:
Handle Address                        MAC               Name
0      127.0.0.1                      00:00:00:00:00:00 lo
1      ::1                            00:00:00:00:00:00 lo
2      192.168.1.49                   34:e6:d7:3e:b6:95 enp2s0
3      fe80::f10f:a22d:2bf7:9a73      34:e6:d7:3e:b6:95 enp2s0
4      172.17.0.1                     02:42:7d:2e:90:a8 docker0
LLRP Manager Commands:
    ?: Print commands
    d <netint_handle>: Perform LLRP discovery on network interface indicated by
        netint_handle
    pt: Print discovered LLRP Targets
    pi: Print network interfaces
    i <target_handle>: Get DEVICE_INFO from Target <target_handle>
    l <target_handle>: Get DEVICE_LABEL from Target <target_handle>
    gi <target_handle>: Get LIST_INTERFACES from Target <target_handle>
    sf <target_handle>: Set FACTORY_DEFAULTS on Target <target_handle>
    si <target_handle>: Toggle IDENTIFY_DEVICE on/off on Target <target_handle>
    sl <target_handle> <label>: Set DEVICE_LABEL to <label> on Target
        <target_handle>
    sr <target_handle>: Set RESET_DEVICE on Target <target_handle>
    sz <target_handle> <interface_id>: Set IPV4_ZEROCONF_MODE
        with Set INTERFACE_APPLY_CONFIGURATION on Target <target_handle>
    m <target_handle>: Get MANUFACTURER_LABEL from Target <target_handle>
    c <target_handle>: Get DEVICE_MODEL_DESCRIPTION from Target <target_handle>
    s <target_handle> <scope_slot>: Get COMPONENT_SCOPE for Scope Slot
        <scope_slot> from Target <target_handle>
    ss <target_handle> <scope_slot> <scope> [ip:port]: Set COMPONENT_SCOPE to
        <scope> for Scope Slot <scope_slot> on Target <target_handle> with
        optional static Broker address ip:port
    q: Quit
d 0
Starting LLRP discovery...
LLRP Discovery finished.

with strace ./llrp_manager_example I can see it just loops for eternity...

write(1, "        <scope> for Scope Slot <"..., 75        <scope> for Scope Slot <scope_slot> on Target <target_handle> with
) = 75
write(1, "        optional static Broker a"..., 47        optional static Broker address ip:port
) = 47
write(1, "    q: Quit\n", 12    q: Quit
)           = 12
fstat(0, {st_mode=S_IFCHR|0620, st_rdev=makedev(136, 1), ...}) = 0
read(0, d 2
"d 2\n", 1024)                  = 4
write(1, "Starting LLRP discovery...\n", 27Starting LLRP discovery...
) = 27
sendto(12, "\0\20\0\0ASC-E1.17\0\0\0\360\0D\0\0\0\n\323\374\271S@\331A\207\273"..., 84, 0, {sa_family=AF_INET, sin_port=htons(5569), sin_addr=inet_addr("239.255.250.133")}, 16) = 84
nanosleep({tv_sec=0, tv_nsec=100000000}, Adding LLRP Target, UID 5000:3c420913, with handle 0
NULL) = 0
nanosleep({tv_sec=0, tv_nsec=100000000}, NULL) = 0
nanosleep({tv_sec=0, tv_nsec=100000000}, NULL) = 0
nanosleep({tv_sec=0, tv_nsec=100000000}, NULL) = 0
nanosleep({tv_sec=0, tv_nsec=100000000}, NULL) = 0
nanosleep({tv_sec=0, tv_nsec=100000000}, NULL) = 0
nanosleep({tv_sec=0, tv_nsec=100000000}, NULL) = 0
nanosleep({tv_sec=0, tv_nsec=100000000}, NULL) = 0
nanosleep({tv_sec=0, tv_nsec=100000000}, NULL) = 0
nanosleep({tv_sec=0, tv_nsec=100000000}, NULL) = 0
nanosleep({tv_sec=0, tv_nsec=100000000}, NULL) = 0
nanosleep({tv_sec=0, tv_nsec=100000000}, NULL) = 0
...
...

...until I kill it.

Fresh clone today and compiles without incident.

samkearney commented 3 years ago

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 commented 3 years ago

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]
samkearney commented 3 years ago

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.

hippyau commented 3 years ago

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.

vanvught commented 3 years ago

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

hippyau commented 3 years ago

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

hippyau commented 3 years ago

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

vanvught commented 3 years ago

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.

TdatRJ commented 1 year ago

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

ChristianReese commented 1 year ago

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 commented 1 year ago

@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 commented 1 year ago

@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 commented 1 year ago

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:

samkearney commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

@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 commented 1 year ago

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

LLRP manager gives: LLRP manager response

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

ChristianReese commented 1 year ago

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

ChristianReese commented 8 months ago

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.