21 May
2005
21 May
'05
9:25 p.m.
Run it twice, in two console windows.
This exposes a bug (it seems packets get corrupted).
Emanuele Aliberti
23 May
23 May
7:28 p.m.
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.
26 May
26 May
7:45 p.m.
Gedi wrote:
ea 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.
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.
8:19 p.m.
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.
8:31 p.m.
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.
9:09 p.m.
On Thu, 26 May 2005 20:45:49 +0100
Gedi <gedi(a)ntlworld.com> wrote:
Gedi wrote:
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.
ea 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. 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.
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.
--
Here's a simple experiment. Stand on a train track between two locomotives
which are pushing on you with equal force in opposite directions. You will
exhibit no net motion. None the less, you may soon begin to notice that
something important is happening.
-- Robert Stirniman
8:38 p.m.
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.
8:59 p.m.
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
9:13 p.m.
Jakob Eriksson wrote:
art yerkes wrote:
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.
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
7056
days inactive
7061
days old
8 comments
5 participants
participants (5)
-
art yerkes -
ea -
Gedi -
Jakob Eriksson -
Phillip Susi