If multiple hubs are connected, a jumbo frame will occur if there is a jumbo frame supported hub on the route. Depending on the program, disconnections may occur.
Please long-term test.
A process has been added to add the PSH flag to the message of the UST F/W process. This prevents jumbo frames regardless of hub type.
It is recommended that the sensor F/W be updated before use.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thanks for the response, really appreciate it, here are some follow up questions according to your answer.
Before that, some background: I am using UST-10LX connecting to the PC via multiple hubs, using ROS urg_node library.
Recently, I've encountered some serious connection issue, after some investigation (by tcpdump), I found that it keeps sending SYN (connection start), which means that it keeps on establishing new connection.
Therefore, I decide to add some log to the ROS urg_node lib, and found out it prints URG_INVALID_RESPONSE, then URG_NO_RESPONSE, but can't figure out why. The bandwidth seems fine (using iftop).
So, my questions are:
I imagine that Jumbo Frame is done by inspecting the source and destination of TCP packet, if those are the same, then append the new message to old one, until it reached MTU, am I right?
Isn't Jumbo Frame issue applicable to all hub that support it, no matter multiple hubs or not?
Again, thanks for the response, I've learned a lot from it!
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I imagine that Jumbo Frame is done by inspecting the source and destination of TCP packet, if those are the same, then append the new message to old one, until it reached MTU, am I right?
Isn't Jumbo Frame issue applicable to all hub that support it, no matter multiple hubs or not?
In both of the above cases, you are correct.
Ubuntu also has a setting(GRO). Please check there.
Recently, I've encountered some serious connection issue, after some investigation (by tcpdump), I found that it keeps sending SYN (connection start), which means that it keeps on establishing new connection.
Therefore, I decide to add some log to the ROS urg_node lib, and found out it prints URG_INVALID_RESPONSE, then URG_NO_RESPONSE, but can't figure out why. The bandwidth seems fine (using iftop).
If no connection is established, communication between the sensor and the PC has failed. If a connection is established but communication is unstable, the communication network is unstable.
Please try the operation check.
Verify that you can connect to the sensor by pinging the sensor's IP address.
If you cannot connect, check that the IP address of the sensor is set as expected. (you can change it using UrgBenriPlus, described below).
If multiple nodes are launched and connection issues occur, as in ros launch, check to see if connection issues no longer occur when only ros run and urg_node are launched.
Would connecting the UST-10LX directly to a PC without a hub solve the connection issue?
Would connecting to the UST-10LX with UrgBenriPlus (Windows application) solve the connection issue?
If multiple nodes are launched and connection issues occur, as in ros launch, check to see if connection issues no longer occur when only ros run and urg_node are launched.
Could you elaborate? I don't think the issue is related to ROS, since they do function normally, just that they disconnected every now and then
If multiple nodes are launched and connection issues occur, as in ros launch, check to see if connection issues no longer occur when only ros run and urg_node are launched.
Would connecting the UST-10LX directly to a PC without a hub solve the connection issue?
Before changing the hub, I've checked the IP, MAC of these UST-10LX, all good, and I can receive data from them. As stated previously, all these sensors stop publishing data and return normal after approximately 5 seconds every now and then, during investigation, I came across the latest firmware note from URG website, so I decide to ask here.
The problem seems to be resolved by changing the faulty hub to a new one, but I would like to know the root cause to make sure I am on the right direction or not.
Would connecting to the UST-10LX with UrgBenriPlus (Windows application) solve the connection issue?
Unfortunately, the PC runs on Linux, and I don' t have PC that runs Windows at hand, so can't confirm.
One more question: from my understanding, assuming there is a hub that support jumbo packet (e.g. packet with length = 2000), and my PC MTU is set to 1500, I should be able to identify it on my PC, by checking MF flag in IP header using tcpdump, if that doesn't happen, then it is safe to say that even though the hub support jumbo packets, it didn't send jumbo packet, am I right?
Again, thank you for your precious time, really appreciate it!
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Could you elaborate? I don't think the issue is related to ROS, since they do function normally, just that they disconnected every now and then.
Regarding isolating the problem, the CPU occupancy differs when multiple nodes are running and when they are not. I asked this question because in other inquiries, there were cases where communication failed when CPU occupancy was high.
However, if the problem was cured by replacing the hub, then the cause can only be the hub.
One more question: from my understanding, assuming there is a hub that support jumbo packet (e.g. packet with length = 2000), and my PC MTU is set to 1500, I should be able to identify it on my PC, by checking MF flag in IP header using tcpdump, if that doesn't happen, then it is safe to say that even though the hub support jumbo packets, it didn't send jumbo packet, am I right?
Contact the hub manufacturer to determine if the hub supports this type of transmission and, if so, how it is transmitted.
If replacing the hub solves the problem, the sensor and hub may not be compatible.
Sensor and hub compatibility issues occur regardless of the sensor version.
👍
1
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi, regarding the release note in the latest release firmware ver.4.0.2A.
The note states that it Fixed an issue where communication would be interrupted with specific hubs or multiple hubs connected.
I would like to ask for a little more information
Thank you
https://en.wikipedia.org/wiki/Jumbo_frame
A process has been added to add the PSH flag to the message of the UST F/W process. This prevents jumbo frames regardless of hub type.
It is recommended that the sensor F/W be updated before use.
Hi, Kobayashi Rin:
Thanks for the response, really appreciate it, here are some follow up questions according to your answer.
Before that, some background: I am using UST-10LX connecting to the PC via multiple hubs, using ROS urg_node library.
Recently, I've encountered some serious connection issue, after some investigation (by tcpdump), I found that it keeps sending SYN (connection start), which means that it keeps on establishing new connection.
Therefore, I decide to add some log to the ROS urg_node lib, and found out it prints URG_INVALID_RESPONSE, then URG_NO_RESPONSE, but can't figure out why. The bandwidth seems fine (using iftop).
So, my questions are:
Again, thanks for the response, I've learned a lot from it!
In both of the above cases, you are correct.
Ubuntu also has a setting(GRO). Please check there.
about
https://docs.kernel.org/networking/segmentation-offloads.html
setting(This article is written in Japanese. Please use a translation tool.)
https://qiita.com/semind/items/9b48c6655ced95a42b03
If no connection is established, communication between the sensor and the PC has failed. If a connection is established but communication is unstable, the communication network is unstable.
Please try the operation check.
If you cannot connect, check that the IP address of the sensor is set as expected. (you can change it using UrgBenriPlus, described below).
UrgBenriPlus DL
https://urgbenri.sourceforge.net/
Hi, Kobayashi Rin:
Could you elaborate? I don't think the issue is related to ROS, since they do function normally, just that they disconnected every now and then
Before changing the hub, I've checked the IP, MAC of these UST-10LX, all good, and I can receive data from them. As stated previously, all these sensors stop publishing data and return normal after approximately 5 seconds every now and then, during investigation, I came across the latest firmware note from URG website, so I decide to ask here.
The problem seems to be resolved by changing the faulty hub to a new one, but I would like to know the root cause to make sure I am on the right direction or not.
Unfortunately, the PC runs on Linux, and I don' t have PC that runs Windows at hand, so can't confirm.
One more question: from my understanding, assuming there is a hub that support jumbo packet (e.g. packet with length = 2000), and my PC MTU is set to 1500, I should be able to identify it on my PC, by checking MF flag in IP header using tcpdump, if that doesn't happen, then it is safe to say that even though the hub support jumbo packets, it didn't send jumbo packet, am I right?
Again, thank you for your precious time, really appreciate it!
Regarding isolating the problem, the CPU occupancy differs when multiple nodes are running and when they are not. I asked this question because in other inquiries, there were cases where communication failed when CPU occupancy was high.
However, if the problem was cured by replacing the hub, then the cause can only be the hub.
Contact the hub manufacturer to determine if the hub supports this type of transmission and, if so, how it is transmitted.
If replacing the hub solves the problem, the sensor and hub may not be compatible.
Sensor and hub compatibility issues occur regardless of the sensor version.
Sorry broken English. All sentence used Translation Tool.
Hi Kobayashi Rin:
No worries. I can fully understand it, just need some additional context to understand it better sometime
I'll keep investigating, check what kind of hardware issue it is. Anyway, thanks for your help!