[Mono-bugs] [Bug 627330] New: Mono doesn't track ICMP Pings and their responses correctly leading to unreliable results under a privileged account

[bugzilla_noreply at novell.com]

http://bugzilla.novell.com/show_bug.cgi?id=627330

http://bugzilla.novell.com/show_bug.cgi?id=627330#c0


           Summary: Mono doesn't track ICMP Pings and their responses
                    correctly leading to unreliable results under a
                    privileged account
    Classification: Mono
           Product: Mono: Class Libraries
           Version: SVN
          Platform: x86-64
        OS/Version: Ubuntu
            Status: NEW
          Severity: Normal
          Priority: P5 - None
         Component: System
        AssignedTo: mono-bugs at lists.ximian.com
        ReportedBy: michael at michael.ie
         QAContact: mono-bugs at lists.ximian.com
          Found By: ---
           Blocker: ---


Created an attachment (id=379721)
 --> (http://bugzilla.novell.com/attachment.cgi?id=379721)
Test program

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US)
AppleWebKit/533.4 (KHTML, like Gecko) Chrome/5.0.375.125 Safari/533.4

The System.Net.NetworkInformation.Ping class has a bug in how it tracks pings
and their pingResponses under privileged user accounts on Linux.

When a ping is sent as root from an app under mono, every sent ICMP Echo (ping)
packet has a fixed Identifier of 0x0100 and a non-incrementing Sequence number
of 0x0000. This leads to Mono unable to track individual pings and responses
between this host and that Endpoint because there is no way to differenciate
each ping response from the Ping that sent it.

The impact of this is serious in my use case where there is a continuous
testing of endpoints on a network, because any ping response will be valid for
any ping request it means *packet loss can be detected accurately* (as the next
response from that endpoint will satisfy the outstanding request, and so on).
It also means the Roundtrip Time can't be accurately measured.

>From my packet captures I see that Windows 7 seems to have a fixed identifier
and an incrementing sequence number for every ping. Ping under Ubuntu seems to
have a different identifier for every process, and an incrementing sequence
number for every sent ping packet. Perhaps mono could adopt one of these
schemes.

The RTT values and individual timeouts are left completely wrong in many
circumstances due to this.

Reproducible: Always

Steps to Reproduce:
1. I spun up an Ubuntu Maverick instance on EC2
2. Running Mono JIT compiler version 2.7 (master/93a12ba Sun Aug  1 17:31:26
UTC 2010)
3. Compile and run the attached demo code to hit any address (tweak timeouts).
mono MonoPingTestAsync2.exe 173.45.237.169
Actual Results:  
ubuntu at ip-10-48-99-38:~$ mono MonoPingTestAsync2.exe 173.45.237.169
Response: Success (176) expected:AAAAAAAAAAAAAAAAAAAAAAAA
got:AAAAAAAAAAAAAAAAAAAAAAAA
Response: Success (109) expected:BBBBBBBBBBBBBBBBBBBBBBBB
got:BBBBBBBBBBBBBBBBBBBBBBBB
Response: Success (111) expected:CCCCCCCCCCCCCCCCCCCCCCCC
got:CCCCCCCCCCCCCCCCCCCCCCCC
Response: Success (109) expected:1234567 got:1234567 # This is a different bug
in the unpriv code.
Response: Success (110) expected:DDDDDDDDDDDDDDDDDDDDDDDD
got:DDDDDDDDDDDDDDDDDDDDDDDD
Response: Success (110) expected:EEEEEEEEEEEEEEEEEEEEEEEE
got:EEEEEEEEEEEEEEEEEEEEEEEE
Response: Success (109) expected:FFFFFFFFFFFFFFFFFFFFFFFF
got:FFFFFFFFFFFFFFFFFFFFFFFF

ubuntu at ip-10-48-99-38:~$ su
root at ip-10-48-99-38:/home/ubuntu# mono MonoPingTestAsync2.exe 173.45.237.169
Response: Success (107) expected:AAAAAAAAAAAAAAAAAAAAAAAA
got:??7AAAAAAAAAAAAAAAA
Response: TimedOut (0) expected:BBBBBBBBBBBBBBBBBBBBBBBB got:
Response: Success (20) expected:CCCCCCCCCCCCCCCCCCCCCCCC
got:??7BBBBBBBBBBBBBBBB
Response: Success (86) expected:1234567 got:??7CCCCCCCCCCCCCCCC
Response: Success (107) expected:DDDDDDDDDDDDDDDDDDDDDDDD
got:??7DDDDDDDDDDDDDDDD
Response: TimedOut (0) expected:EEEEEEEEEEEEEEEEEEEEEEEE got:


Expected Results:  
>From the privileged execution as root, I expected:
Response: Success (176) expected:AAAAAAAAAAAAAAAAAAAAAAAA
got:AAAAAAAAAAAAAAAAAAAAAAAA
Response: TimedOut(0) expected:BBBBBBBBBBBBBBBBBBBBBBBB got:
Response: Success (111) expected:CCCCCCCCCCCCCCCCCCCCCCCC
got:CCCCCCCCCCCCCCCCCCCCCCCC
Response: TimedOut(0) expected:1234567 got:
Response: Success (110) expected:DDDDDDDDDDDDDDDDDDDDDDDD
got:DDDDDDDDDDDDDDDDDDDDDDDD
Response: TimedOut(0) expected:EEEEEEEEEEEEEEEEEEEEEEEE got:
Response: Success (109) expected:FFFFFFFFFFFFFFFFFFFFFFFF
got:FFFFFFFFFFFFFFFFFFFFFFFF

Note: On the EC2 Maverick instance I'm running (US-West AMI: ami-c997c68c) the
ping of 1234567 should always fail due to the firewall or network restrictions
of a payload too small. 
The other two timeouts should be set very low to demo the issue.
Also note the constant ping times of over 109ms vrs skewed results in Actual
(due to answer for different ping)

Also attached is a packet capture (caught with pcapdump -i eth0 -T 15 -w
UbuntuMaverick.pcap) which shows the app running unprivileged and then
privileged. It shows the Identifier changing for every ping as mono calls out
to the ping binary for each run, and the Sequence being 0x0001 as it's the only
packet from that ping instance)
The Privileged execution has an Identifier of 0x0100 always and always has the
same Sequence number of 0x0000 (Please note: I patched the source to check
something else to send 0x3700 - it's notmally 0x0000)

-- 
Configure bugmail: http://bugzilla.novell.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
You are the assignee for the bug.