http://bugs.winehq.org/show_bug.cgi?id=17996
--- Comment #60 from Juan Lang juan_lang@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.