-
Notifications
You must be signed in to change notification settings - Fork 12
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
LLRP_Manager Hangs Discovery is fixed but IP issue #55
Comments
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. The report below was already posted in the previous report that you closed pt |
@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 |
@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 |
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
The text was updated successfully, but these errors were encountered: