Hi all, I am newbe here, please forgive me for asking something that might be obvious to everybody. I've spend last few hours searching through google for "dns settings wine", "network settings wine", "nameserver wine" and through wine docs on winehq, couldn't find anything which would help me. Problem: win32 app (which uses FQDNs, not plain IP addresses) cannot connect to the Internet when running on 'wine', and it seems that DNS query fails. I've tried running nslookup.exe (win32 version, copied over from windows partition), and this is what I'm getting: rbr@airdb:~/src/bwapps$ wine nslookup.exe www.winehq.org *** Default servers are not available Server: UnKnown Address: 127.0.0.1 *** UnKnown can't find www.winehq.org: No response from server Wine exited with a successful status rbr@airdb:~/src/bwapps$ It appears that nameserver IPs are not accessible to wine? /etc/resolv.conf is fine and networking works fine under linux desktop box (IPs are assigned to the host via DHCP). Any ideas what can I do to fix this issue on my box? I've seen this bug report: http://bugs.winehq.org/show_bug.cgi?id=1360 and it says it's fixed. It's debian testing box, wine --version returns: Wine 20050628. Thanks, r.
On 10/23/05, Robertino Benis <rbenis@airyz.com> wrote:> rbr@airdb:~/src/bwapps$ wine nslookup.exe www.winehq.org > *** Default servers are not available > Server: UnKnown > Address: 127.0.0.1 > > *** UnKnown can't find www.winehq.org: No response from server ... > > /etc/resolv.conf is fine and networking works fine under linux desktop box > (IPs are assigned to the host via DHCP). > > Any ideas what can I do to fix this issue on my box? I've seen this bug > report: http://bugs.winehq.org/show_bug.cgi?id=1360 and it says it's fixed. > > It's debian testing box, wine --version returns: Wine 20050628.There have been quite a few changes since June; you might want to try building a fresh copy of Wine from CVS. I have instructions on how at http://kegel.com/wine/qa You might also post the log that Wine writes to stdout so we can see if it's complaining about anything. Finally, do applications like FTP work? I just downloaded and installed Bulletproof FTP on Wine, and it was able to look up hostnames just fine. (I would try dnslookup but I don't have a copy handy.)
On Sun, 23 Oct 2005 20:52:24 -0700, "Robertino Benis" <rbenis@airyz.com> wrote:>Hi all, > >I am newbe here, please forgive me for asking something that might be >obvious to everybody. > >I've spend last few hours searching through google for "dns settings >wine", "network settings wine", "nameserver wine" and through wine docs on >winehq, couldn't find anything which would help me.Lots, if not most, of applications would use the winsock function gethostbyname, which is handled by the Unix gethostbyname function. That works fine ;)> >Problem: win32 app (which uses FQDNs, not plain IP addresses) cannot >connect to the Internet when running on 'wine', and it seems that DNS >query fails.You think the app is doing the query itself?> >I've tried running nslookup.exe (win32 version, copied over from windows >partition), and this is what I'm getting:If I add the string registry value HKLM\System\CurrentControlset\Services\Tcpip\Parameters\DhcpNameServer and fill it the IP address of a name server it works here. A NT4 nslookup.exe worked immediately, a Win2K version only if I did set the version to NT4. Rein.
On Mon, 24 Oct 2005 12:50:47 -0700, you wrote: Please CC the mailing list as I did. Quoted in full for the list:> >On Mon, 24 Oct 2005 03:25:18 -0700, Rein Klazes <wijn@wanadoo.nl> wrote: > >> On Sun, 23 Oct 2005 20:52:24 -0700, "Robertino Benis" <rbenis@airyz.com> >> wrote: >> >>> Hi all, >>> >>> I am newbe here, please forgive me for asking something that might be >>> obvious to everybody. >>> >>> I've spend last few hours searching through google for "dns settings >>> wine", "network settings wine", "nameserver wine" and through wine docs >>> on >>> winehq, couldn't find anything which would help me. >> >> Lots, if not most, of applications would use the winsock function >> gethostbyname, which is handled by the Unix gethostbyname function. >> That works fine ;) >> >>> >>> Problem: win32 app (which uses FQDNs, not plain IP addresses) cannot >>> connect to the Internet when running on 'wine', and it seems that DNS >>> query fails. >> >> You think the app is doing the query itself? >> >>> >>> I've tried running nslookup.exe (win32 version, copied over from windows >>> partition), and this is what I'm getting: >> >> If I add the string registry value >> HKLM\System\CurrentControlset\Services\Tcpip\Parameters\DhcpNameServer >> and fill it the IP address of a name server it works here. >> >> A NT4 nslookup.exe worked immediately, a Win2K version only if I did set >> the version to NT4. >> >> Rein. >>>Hi, > >Do you have any other reg key valuse there, besides DhcpNameServer? >Setting up just that reg key didn't help. BTW,I did run wine like: WINEDEBUG=+relay wine /path/to/nslookup.exe 2>&1 | less and looked in the output what it was doing. It is doing more, especially if the value is not found. Some of that looks like security/permission checks, it may not be that easy to decipher those. That is why the older version of nslookup works easier, I think. Because of the what nslookup works it is to be expected to do the low level DNS queries itself. I am not convinced that an ordinary application would go into this kind of trouble, they usually use some high level api like winsock. But then, I do not know your app.>ftp returns something like >this: > >wine ftp.exe 192.168.0.11 >wine: Call from 0x1005184 to unimplemented function >WS2_32.dll.getaddrinfo, aborting >wine: Unhandled exception (thread 0009), starting debugger... >Usage: winedbg [--auto] [--gdb] cmdlineYour winedbg registry set-up is out of date. It needs to be something like ( ~/.wine/system.reg): | [Software\\Microsoft\\Windows NT\\CurrentVersion\\AeDebug] 1102496326 | "Auto"="1" | "Debugger"="winedbg %ld %ld">Wine failed with return code 1 > >I don't quite understand how WS2_32.dll doesn't have getaddrinfo()? I >copied it over from XP partition...Because wine is using the built-in dll. No need to try native, the winsock dll's cannot be used that way. A patch to implement getaddrinfo was sent yesterday is but is not committed yet. Rein.