Open TdatRJ opened 10 months ago
Hello @TdatRJ -
I have been unable to reproduce this on my setup, but I have a theory as to what's going on. The current code traces the route to the source address to get the network interface. If that fails then it will not process the incoming packet - instead it will log a warning "Couldn't reply to LLRP message from [...] because no reply route could be found." - could you please confirm whether this is being logged on your side (on either side)?
Assuming this is the case, I will look into cutting a build that switches to using recvmsg to get the netint, avoiding the trace route altogether.
Update: RDMnet v1.0.0.5 has been released with the aforementioned switch to recvmsg. @TdatRJ could you please try the new build and let me know if it fixes the issue? And if it doesn't, could you please provide a Wireshark trace? Thanks!
It seems working but I need to try it on our Test Rig on Monday. It case of error I will send a Wireshark trace.
I noticed that the use of the commands might have changed:
For example: d
The report below was already posted in the previous report that you closed Also the Component type that LLRP manager returns is incorrect: it should say Non RDM Target as Component Type and not Invalid LLRP Component type
pt Handle UID CID Type Hardware ID 0 09ae:06500002 01020304-0060-3712-3457-09ae06500002 Invalid LLRP Component Type 00:60:37:12:34:57
@TdatRJ I previously filed a ticket for the non-RDM target bug - I will try to look at that soon.
Could you clarify the output that results when you enter the command? I was running this today and was able to enter d 5
and it seemed to work as intended. Does it output or log any errors suggesting it's having trouble with the interface you specified?
@TdatRJ The issue there is that you need to omit the angle brackets - those are just used to signify that it's a parameter of the command. So you'll want d 2
- that should work.
And the first one didn't work because it was missing a space. So including a space and excluding the brackets should do the trick.
Very good, it does the trick. Thanks
No problem, glad to help.
Hello,
The hangs on discovery is fixed but there is another issue, but this time related to IP. If the fixture IP range is not the same as the network interface the fixture cannot be discovered.
Example: Fixture 2.168.10.161 Network interface: 192.168.10.161 In this example the fixture is not found which is not correct.
Our implementation is correct as DMXworshop works and Netron CLU as well if we set up the fixture as per example above.
Regards