[Bug 17996] inetmib1 test page faults

[wine-bugs at winehq.org]

http://bugs.winehq.org/show_bug.cgi?id=17996





--- Comment #60 from Juan Lang <juan_lang at yahoo.com>  2009-05-07 14:10:26 ---
(In reply to comment #58)
> So there must be a bug in how entries are searched in the table.  Hm..

I think I'm onto the problem:  if more than one entry in the forward table
shares the same numerical destination address, the function to find the entry
in the table will always find the first entry.  This results in an infinite
loop in enumerating the table.  This, combined with a memory leak, causes the
test to fail on your machine.

I have a patch for the memory leak, but not for the loop.

Having two entries with the same address is not an invalid configuration, as
the entries should be disambiguated by some other field, such as the next hop. 
The current code doesn't allow that to happen.  I need to test more on Windows
what's happening, but I don't have access to a Windows machine at the moment,
so I won't have a fix soon.

Here's what I think is happening:

When enumerating the addresses, the SnmpExtensionQuery function starts with a
base oid, finds the next matching oid, then appends enough information to
identify it so the subsequent query will find the subsequent oid.  The ip
forward table identifies entries by the destination IP address.

So, for example, let's assume that the IP forward table has two entries, with
destination addresses 0.0.0.0 and 0.0.0.1.  Assume the first query is for
1.3.6.1.2.1.4.21.1, the MIB 2 ipForwardTable oid.  The code finds the first
entry in the ipForwardTable, and appends the IP destination address oid (.1)
and IP address of the row to it, so it returns 1.3.6.1.2.1.4.21.1.1.0.0.0.0 as
the oid.  On the subsequent run, it finds the next matching oid after this,
which is the address 0.0.0.1, so it returns 1.3.6.1.2.1.4.21.1.1.0.0.0.1.  On
the subsequent run, no IP addresses match, so mip2IpRouteQuery returns
SNMP_ERRORSTATUS_NOSUCHNAME, and SnmpExtensionQuery goes looking for another
part the MIB 2 table that matches.

Now assume there are only two entries in the route table.  Both of them share
the same destination address, a.  They have different next hop addresses, g1
and g2.  The rest of the entries are the same.  So the table looks like this:
Destination address    Next hop
a                      g1
a                      g2

When called with 1.3.6.1.2.1.4.21.1, SnmpExtensionQuery will return the oid of
the first entry, 1.3.6.1.2.1.4.21.1.1.a.  When called with this a second time,
it'll match the first entry in the table (a/g1), and return the subsequent
entry, for (a/g2), but it'll return the oid 1.3.6.1.2.1.4.21.1.1.a.  When
called a third time, it'll match the first entry, as it only has enough
information to match the destination address, and can't distinguish the first
entry from the second.

I believe what needs to happen is that more information needs to be included in
the oid of an ip route table entry, such as the next hop address.  From RFC
1354, the index of an ipForwardEntry is:
             INDEX {
                 ipForwardDest,
                 ipForwardProto,
                 ipForwardPolicy,
                 ipForwardNextHop
                 }
That is, the destination address, protocol, policy, and next hop should all be
considered the index into the table.  I need to check on Windows whether it
includes all of these in the oid corresponding to a route table entry before
changing anything.


-- 
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
Do not reply to this email, post in Bugzilla using the
above URL to reply.
------- You are receiving this mail because: -------
You are watching all bug changes.