Yes, this reliance on artificially generated Unix style names (of form "ethN") for adapters might cause problems if the list of network adapters changes while the sipXtapi library is active. When getContactAdapterName() is called with truename=false (as is always the case after my patch is applied), the Unix style name that is generated just reflects the adapters position in the linked list returned by GetAdaptersInfo(). If another adapter is added or removed earlier in the list, the name returned by getContactAdapterName() would change. When getContactAdapterName() is called with truename=true, then it returns the GUID based name that Windows uses internally (which should be unique and stable).
I only started looking at the DNS code because it didn't work at all for a very simple case: one Ethernet adapter, with statically configured IP and DNS servers under Windows XP. Stephen C. Steel -----Original Message----- From: Jaroslav Libak [mailto:[EMAIL PROTECTED] Sent: Wednesday, August 01, 2007 16:49 To: [EMAIL PROTECTED] Cc: 'sipXtapi developer list' Subject: Re: [sipxtapi-dev] PATCH for DNS Server List Initialization Bug in Windows Stephen C. Steel wrote: > The attached patch fixes some problems in the function > getIPHelperDNSEntries() found in the file > sipXportlib\src\os\Wnt\getWindowsDNSServers.cpp. This function attempts to > obtain the list of DNS servers from Windows using the iphlpapi.dll function > available under most versions of Windows. However, under Windows XP, this > function was ALWAYS failing. This failure was masked because > getWindowsDNSServers() calls getDNSEntriesFromRegistry() if > getIPHelperDNSEntries() doesn't find anything - getDNSEntriesFromRegistry() > is intended to deal with Windows NT4 systems that don't support > iphlpapi.dll. Under Windows XP, getDNSEntriesFromRegistry() does succeed if > the DNS server list was obtained by DHCP, but it fails if the DNS servers > are statically configured, as they are stored in a different registry > location than they were under NT4 (under an adapter specific key). > > The changes I made were as follows: > =================================== > > 1. The function pointer GetNetworkParams was being set to NULL just before > calling loadIPHelperAPI(). Not only isn't this necessary (as it is > statically initialized to NULL), if the call to loadIPHelperAPI() that > occurs here is not the first time loadIPHelperAPI() is called (and it > frequently isn't), then the address of the iphlpapi.dll function is lost as > loadIPHelperAPI() only sets the function pointers the FIRST time it is > called). > > 2. I changed getIPHelperDNSEntries() to return early for the cases where it > fails (wrong windows version or unable to load iphlpapi.dll). > > 3. The code for Windows 2000 and XP, called GetInterfaceInfo() to get a list > of adapter names and the corresponding index, and looked for and adapter > with a name matching the return value from getContractAdapterName(). > However, the test used to determine this was backwards: > > if (contactAdapterName.contains(szAdapterName)) > > Since contactAdapterName (obtained from getContactAdapterName()) returns a > name of the form "{GUID}", while szAdapterName (obtained from the list > returned from GetInterfaceInfo()) is of the form "\DEVICE\TCPIP_{GUID}". > Thus, this test never succeeded. Instead of using getContactAdapterName() to > find the adapter by name, I've changed the code to walk the list of adapters > looking for one with the correct IP address (which is how > getContactAdapterName() gets the name in the first place) and then just use > its index directly to call GetPerAdapterInfo(). > > > > I've only been able to test the code path used by Windows XP (but same code > should also be used by Windows 2000 and Windows Vista). The code path used > by Windows 98/Me systems (using the GetNetworkParams() function in > iphlpapi.dll) hasn't changed, and I haven't changed > getDNSEntriesFromRegistry() which is used for NT4. > > Stephen C. Steel The DNS code has more bugs than this. For example it uses ethN style adapter names, but if you add a new adapter, or enable a previosly disabled one, adapters can be renumbered, thus sipxtapi might not work properly at all. Jaro _______________________________________________ sipxtapi-dev mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipxtapi-dev/
