Skip to content
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

Open
TdatRJ opened this issue Jan 12, 2024 · 9 comments
Open

LLRP_Manager Hangs Discovery is fixed but IP issue #55

TdatRJ opened this issue Jan 12, 2024 · 9 comments

Comments

@TdatRJ
Copy link

TdatRJ commented Jan 12, 2024

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

@ChristianReese
Copy link
Contributor

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.

@ChristianReese
Copy link
Contributor

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!

@TdatRJ
Copy link
Author

TdatRJ commented Jan 12, 2024

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 X for the Handle Address is not working you have to use d to make it work. The other commands are simular which is confusing as the help guide is showing a space after the command character.

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

@ChristianReese
Copy link
Contributor

@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
Copy link
Author

TdatRJ commented Jan 12, 2024

image

@ChristianReese
Copy link
Contributor

@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.

@ChristianReese
Copy link
Contributor

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.

@TdatRJ
Copy link
Author

TdatRJ commented Jan 12, 2024

Very good, it does the trick. Thanks

@ChristianReese
Copy link
Contributor

No problem, glad to help.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants