ping -t 127.0.0.1

[ea]

Run it twice, in two console windows.
This exposes a bug (it seems packets get corrupted).

Emanuele Aliberti

[Gedi]

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]

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.

[Phillip Susi]

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.

[Gedi]

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.

[art yerkes]

On Thu, 26 May 2005 20:45:49 +0100
Gedi [e-mail] 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.
-- 
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

[Gedi]

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.

[Jakob Eriksson]

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

[Gedi]

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.