Run it twice, in two console windows. This exposes a bug (it seems packets get corrupted).
Emanuele Aliberti
ea wrote:
Run it twice, in two console windows. This exposes a bug (it seems packets get corrupted).
Emanuele Aliberti
The ICMP packets are being picked up by the wrong process and thus the ICMP id field isn't maatching up with the process ID.
Busy at the mo, but if no one has sorted it by Wednesday, I'll have a look at it.
Regards, Ged.
Gedi wrote:
ea wrote:
Run it twice, in two console windows. This exposes a bug (it seems packets get corrupted).
Emanuele Aliberti
The ICMP packets are being picked up by the wrong process and thus the ICMP id field isn't maatching up with the process ID.
Busy at the mo, but if no one has sorted it by Wednesday, I'll have a look at it.
OK, I've had a look at this and I'm struggling to come up with decent solution. After getting a severe headache, I contacted Warren Young who runs the Winsock FAQ and he suggested there is a weakness in the MS stack.
As the bug ea spoke about is evident on Windows, this would support that theory. However as our stack has derived from Linux, and Linux doesn't replicate this bug, I'm at a loss.
My only 2 thoughts to get around this problem at the moment at to write all ICMP packets into a buffer and tell ping, tracert, etc to check the ID field before removing them, or possibly polling recvfrom with MSG_PEEK.
Both of these are obviously nasty hacks, the first more so than the second.
This will become a problem in the future, so I'd welcome any thoughts / ideas to rectify this now.
Regards, Ged.
When multiple processes are receiving raw packets with a raw socket, such as in the case of ping, I believe they are all supposed to get a copy of each packet, and then they need to check the ID field to make sure it matches the echo request packet that it sent out. Are you saying that our stack lets one process 'eat' the packet and the other process never sees it?
Gedi wrote:
OK, I've had a look at this and I'm struggling to come up with decent solution. After getting a severe headache, I contacted Warren Young who runs the Winsock FAQ and he suggested there is a weakness in the MS stack.
As the bug ea spoke about is evident on Windows, this would support that theory. However as our stack has derived from Linux, and Linux doesn't replicate this bug, I'm at a loss.
My only 2 thoughts to get around this problem at the moment at to write all ICMP packets into a buffer and tell ping, tracert, etc to check the ID field before removing them, or possibly polling recvfrom with MSG_PEEK.
Both of these are obviously nasty hacks, the first more so than the second.
This will become a problem in the future, so I'd welcome any thoughts / ideas to rectify this now.
Regards, Ged.
Phillip Susi wrote:
Are you saying that our stack lets one process 'eat' the packet and the other process never sees it?
Yes, that's what's happening. If all processes received the packet, as you will know, it would be a simple case of a process dropping packets which don't match the process ID. However as it currently stands, which ever process calls recvfrom first when a packet is in the buffer, gets that packet, the other process never sees it.
Ged.
On Thu, 26 May 2005 20:45:49 +0100 Gedi gedi@ntlworld.com wrote:
Gedi wrote:
ea wrote:
Run it twice, in two console windows. This exposes a bug (it seems packets get corrupted).
Emanuele Aliberti
The ICMP packets are being picked up by the wrong process and thus the ICMP id field isn't maatching up with the process ID.
Busy at the mo, but if no one has sorted it by Wednesday, I'll have a look at it.
OK, I've had a look at this and I'm struggling to come up with decent solution. After getting a severe headache, I contacted Warren Young who runs the Winsock FAQ and he suggested there is a weakness in the MS stack.
As the bug ea spoke about is evident on Windows, this would support that theory. However as our stack has derived from Linux, and Linux doesn't replicate this bug, I'm at a loss.
Our TCP component is imported from FreeBSD. Everything else was written originally by Casper and heavily revised by me. This includes all code related to datagram oriented protocols such as ICMP. I can visualize the bug but unfortunately, my house is torn apart for the move and I may not be able to spend any time on it before June.
My only 2 thoughts to get around this problem at the moment at to write all ICMP packets into a buffer and tell ping, tracert, etc to check the ID field before removing them, or possibly polling recvfrom with MSG_PEEK.
Both of these are obviously nasty hacks, the first more so than the second.
We need better infrastructure to support what would be equivalent to ICMP ports; treating the ID field as a port number effectively. I'm wondering if by fixing this we'll be breaking any existing apps that rely on loose handling of ICMP sockets.
This will become a problem in the future, so I'd welcome any thoughts / ideas to rectify this now.
Regards, Ged.
Thanks for looking into it. It's a really sticky problem since ICMP is really meant to be a system-level protocol, not an application protocol. As such, I'm not aware of firm rules regarding delivery of ICMP datagrams to applications, only rules regarding how they're received and dealt with at the system level.
art yerkes wrote:
Thanks for looking into it. It's a really sticky problem since ICMP is really meant to be a system-level protocol, not an application protocol. As such, I'm not aware of firm rules regarding delivery of ICMP datagrams to applications, only rules regarding how they're received and dealt with at the system level.
No problem. As it stands now, my new tracert program for ROS also has the same bug, and I'm assuming anything else which uses ICMP in this manner.
Gimmie a shout if you have any ideas I can get my hands dirty with.
Ged.
art yerkes wrote:
Thanks for looking into it. It's a really sticky problem since ICMP is really meant to be a system-level protocol, not an application protocol. As such, I'm not aware of firm rules regarding delivery of ICMP datagrams to applications, only rules regarding how they're received and dealt with at the system level.
This is a known trouble with Windows programs too. There is icmp.dll, check out: http://www.sockets.com/ms_icmp.htm
Jakob Eriksson wrote:
art yerkes wrote:
Thanks for looking into it. It's a really sticky problem since ICMP is really meant to be a system-level protocol, not an application protocol. As such, I'm not aware of firm rules regarding delivery of ICMP datagrams to applications, only rules regarding how they're received and dealt with at the system level.
This is a known trouble with Windows programs too. There is icmp.dll, check out: http://www.sockets.com/ms_icmp.htm
Yes, I'm assuming Windows uses this approach as opposed to the raw packets way as the MS ping doesn't have this problem, even though there is a problem with their stack also. But running the ROS ping on Windows highlights the same problem we are seeing on ROS.
However the raw socket approach is much more elegant, plus we don't have the ICMP.dll available in ROS.
Incidentally, I haven't tried the MS ping in ROS, and I don't have a bootable ROS at the moment. I'll try it later.
Ged.