http://bugs.winehq.org/show_bug.cgi?id=25377
Summary: Filemaker 11 can't access / doesn't show remote databases / servers - both in "Local hosts" and "Favorite hosts" Product: Wine Version: 1.2.1 Platform: x86 OS/Version: Linux Status: UNCONFIRMED Severity: major Priority: P2 Component: -unknown AssignedTo: wine-bugs@winehq.org ReportedBy: emerson.prado.eng@gmail.com
Created an attachment (id=32277) --> (http://bugs.winehq.org/attachment.cgi?id=32277) Full terminal output from running FM 11
When I try to open a remote db, my server doesn't appear in the "Local hosts". If I manually add my server in the "Favorite hosts", the remote files aren't shown. I tried all Windows versions from XP up. The attachment is the full terminal output from running Filemaker (the main menu icon doesn't work, so I run FM from Terminal).
http://bugs.winehq.org/show_bug.cgi?id=25377
--- Comment #1 from Emerson Prado emerson.prado.eng@gmail.com 2010-12-01 13:16:35 CST --- Forgot to mention: I installed Wine from this file: http://sourceforge.net/projects/wine/files/Mandriva%20Packages/1.2.1/wine-1.... I converted from .rpm to .deb with the command: alien -dkv <RPM package> I sticked to this version and installation method because it was the only way I found to get the current stable version (1.2) to be installed on Debian. Or should I use 1.1.42 from Lamaresh repo?
http://bugs.winehq.org/show_bug.cgi?id=25377
Juan Lang juan_lang@yahoo.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #32277|application/octet-stream |text/plain mime type| |
http://bugs.winehq.org/show_bug.cgi?id=25377
Louis Lenders xerox_xerox2000@yahoo.co.uk changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |xerox_xerox2000@yahoo.co.uk Severity|major |normal
--- Comment #2 from Louis Lenders xerox_xerox2000@yahoo.co.uk 2010-12-01 14:37:54 CST --- maybe a problem resulting from this line: fixme:service:EnumServicesStatusW 0x11f708 type=30 state=3 (nil) 0 0x76e7d0 0x76e7dc 0x76e7d8
This has been implemented in newer wine-versions, so please upgrade to the newest wine (1.3.8) and try again
http://bugs.winehq.org/show_bug.cgi?id=25377
--- Comment #3 from Emerson Prado emerson.prado.eng@gmail.com 2010-12-02 09:39:12 CST --- I upgraded to 1.3.8 and half of the problem is gone. "Local hosts" still doesn't show anything, but a manually server added is correctly accessed - a workaround for the "Local hosts" issue. (OT: it also crashed in the first attempt. But a "make depend" seems to have solved this too.)
http://bugs.winehq.org/show_bug.cgi?id=25377
--- Comment #4 from Juan Lang juan_lang@yahoo.com 2010-12-02 09:44:30 CST --- What's the console output with Wine 1.3.8?
http://bugs.winehq.org/show_bug.cgi?id=25377
Emerson Prado emerson.prado.eng@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #32277|0 |1 is obsolete| |
--- Comment #5 from Emerson Prado emerson.prado.eng@gmail.com 2010-12-02 14:14:55 CST --- Created an attachment (id=32323) --> (http://bugs.winehq.org/attachment.cgi?id=32323) Full terminal output from running FM 11
Now with latest wine
http://bugs.winehq.org/show_bug.cgi?id=25377
--- Comment #6 from Emerson Prado emerson.prado.eng@gmail.com 2010-12-02 14:18:43 CST --- If this is useful, the exact command sequence after FM 11 was opened: Clicked in "Remote", in the automatically opened "Open file" window Changed from "Favorite Hosts" to "Local Hosts" After a while (since nothing happened), cancelled Quit FM 11 Press Ctrl-C in Terminal to get my prompt back...
http://bugs.winehq.org/show_bug.cgi?id=25377
Juan Lang juan_lang@yahoo.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #32323|application/octet-stream |text/plain mime type| |
http://bugs.winehq.org/show_bug.cgi?id=25377
--- Comment #7 from Juan Lang juan_lang@yahoo.com 2010-12-02 14:36:07 CST --- Does the patch in http://www.winehq.org/pipermail/wine-devel/2010-October/087257.html help?
http://bugs.winehq.org/show_bug.cgi?id=25377
--- Comment #8 from Emerson Prado emerson.prado.eng@gmail.com 2010-12-03 06:20:47 CST --- Er... How do I (a newbie) install it?
http://bugs.winehq.org/show_bug.cgi?id=25377
--- Comment #9 from Juan Lang juan_lang@yahoo.com 2010-12-03 10:52:11 CST --- http://wiki.winehq.org/FAQ#head-7ed3c3163e2b932ee2030a48f9c5e553dc41817b If you need help, ask on wine-users or another appropriate forum.
http://bugs.winehq.org/show_bug.cgi?id=25377
--- Comment #10 from Emerson Prado emerson.prado.eng@gmail.com 2010-12-03 13:07:08 CST --- I got an error in make:
In file included from ../../include/ws2tcpip.h:23, from ../../include/http.h:25, from httpapi_main.c:27: ../../include/ws2ipdef.h:165: error: redefinition of ‘struct in_pktinfo’ make[1]: ** [httpapi_main.o] Erro 1
I went forward anyway and did a make install, which returned the exact same error. Then, I found out Wine is not installed. I uninstalled the previous version with make uninstall before any changes and applied the patch with -p1.
I noticed the article mentions ip_pktinfo, but the error mentions in_pktinfo. Could this indicate something?
May I have done something wrong? Have someone tried this patch already?
http://bugs.winehq.org/show_bug.cgi?id=25377
--- Comment #11 from Juan Lang juan_lang@yahoo.com 2010-12-03 14:31:42 CST --- Looks like that patch has a build error. Sorry about that. You might try contacting Erich Hoover, the author of that patch, to ask him about it. I was trying to see whether this bug is a duplicate of bug 19493, since WSARecvMsg and IP_PKTINFO (IPPROTO_IP optname 0x00000013) show up in your log.
We can't easily try it, since we don't have remote databases handy..
http://bugs.winehq.org/show_bug.cgi?id=25377
--- Comment #12 from Emerson Prado emerson.prado.eng@gmail.com 2010-12-03 15:12:31 CST --- I contacted him, who promptly showed this page: http://www.compholio.com/wine-kane/#patches And instructed me to apply the first two patches. So I did, then follow the remaining instructions for compiling (actually, adding the first two "optionals" to the normal procedure), and the errors are gone. But the problem isn't. FileMaker still can't find local servers. I understand how seldom one would have a remote database... Is there any test I can do or log I can grab, etc., that would help?
http://bugs.winehq.org/show_bug.cgi?id=25377
--- Comment #13 from Juan Lang juan_lang@yahoo.com 2010-12-03 16:15:46 CST --- (In reply to comment #12)
I contacted him, who promptly showed this page: http://www.compholio.com/wine-kane/#patches And instructed me to apply the first two patches. So I did, then follow the remaining instructions for compiling (actually, adding the first two "optionals" to the normal procedure), and the errors are gone. But the problem isn't. FileMaker still can't find local servers.
Okay, so it isn't a dup.
I understand how seldom one would have a remote database... Is there any test I can do or log I can grab, etc., that would help?
Time to dust off your magical debugging skills :) You might try getting a wireshark capture of a Windows system doing the same thing, then a Wine one, and see what the difference is. In other words, what protocol is Filemaker using to find the other servers? Then try to guess where that should be happening in Wine, or ask here.
http://bugs.winehq.org/show_bug.cgi?id=25377
Erich Hoover ehoover@mines.edu changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |ehoover@mines.edu
--- Comment #14 from Erich Hoover ehoover@mines.edu 2010-12-04 15:25:03 CST --- It's possible that this is an accumulation of more than one problem, as without WSARecvMsg the application may not even attempt to look for servers. A log with the patch applied might help.
I actually wouldn't be surprised to find that the application uses WSARecvMsg to find the interface necessary to connect to the server and then it performs an interface-specific bind (which would require the rest of the patches on my site). Searching for servers using UDP in an interface-bound manner is not completely uncommon, since it allows you to obtain information that you would not acquire when binding to INADDR_ANY. I know this because I used roughly the same technique when I was working for a private company. At the time I didn't know about WSARecvMsg, so I sent out a broadcast on INADDR_ANY first and then on each interface (just like what is seen in Bug #7929). Anyway, you should be able to detect if this scenario is the case if you run your application like this: --- WINEDEBUG="+winsock" wine APPNAME.EXE 2>&1 | grep WS_bind --- If you see something like the following (where the address is anything except INADDR_ANY, AKA 0.0.0.0) then your application is performing an interface-specific bind and you will need to add the rest of the patches from my site (and this bug would be a duplicate of Bug #7929): --- trace:winsock:WS_bind socket 0284, ptr 0x2cdf11c { family AF_INET, address 192.168.0.188, port 8086 }, length 16 ---
http://bugs.winehq.org/show_bug.cgi?id=25377
--- Comment #15 from Emerson Prado emerson.prado.eng@gmail.com 2010-12-06 07:26:29 CST --- That's correct. I executed FileMaker 11 thru the mentioned command, and got errors very similar to those mentioned. I don't know if it's worth noting, but the address shown was 0.0.0.0.
That fixed it! I had to uncompress source again to get rid of the mess already made and start fresh. Uninstalled (make uninstall) and installed again with the first two optionals (tools/make_requests and autoconf), and voilà! Filemaker can find remote servers and databases.
So we can close this. Dup? Many thanks!
BTW, dealing with this in FileMaker for Windows probably means dealing with Bonjour. If devs want to know: http://help.filemaker.com/app/answers/detail/a_id/7097/kw/remote%20database/...
http://bugs.winehq.org/show_bug.cgi?id=25377
--- Comment #16 from Erich Hoover ehoover@mines.edu 2010-12-06 09:21:30 CST --- (In reply to comment #15)
... the address shown was 0.0.0.0.
That fixed it! I had to uncompress source again to get rid of the mess already made and start fresh. Uninstalled (make uninstall) and installed again with the first two optionals (tools/make_requests and autoconf), and voilà! Filemaker can find remote servers and databases. ...
Excellent news! However, it sounds like it's not the interface-specific bind patches since the address shown is 0.0.0.0 (INADDR_ANY). When you originally patched and installed (make && make install) how did you launch Wine? If you had been running from a terminal with a distribution-provided copy of Wine and then installed a new custom Wine and ran from the terminal again then the terminal will not use the new Wine, you need to launch a new terminal in order for it to detect the new Wine. So, if you could try going back to just the first two patches and see if that fixes it for you then that would be greatly appreciated. For future reference, you can tell what terminals are using which Wine by running "which wine". Distribution installed copies will report "/usr/bin/wine" and custom installations will report "/usr/local/bin/wine".
http://bugs.winehq.org/show_bug.cgi?id=25377
--- Comment #17 from Emerson Prado emerson.prado.eng@gmail.com 2010-12-06 14:15:12 CST --- (In reply to comment #16)
it sounds like it's not the interface-specific bind patches since the address shown is 0.0.0.0 (INADDR_ANY)
Sorry, in fact, some of the addressess are 0.0.0.0, but there are at least other two different ones (loopback and someone from my LAN). That doesn't change throughout patches.
When you originally patched and installed (make && make install) how did you launch Wine?
~/.wine/drive_c/Arquivos de Programas/Filemaker/Filemaker Pro 11/wine Filemaker Pro.exe
if you could try going back to just the first two patches and see if that fixes it for you then that would be greatly appreciated.
I tested it unpatched, with first two patches and fully patched. Only the fully patched version could find remote servers automatically.
you can tell what terminals are using which Wine by running "which wine".
/usr/local/bin/wine
The first two versions I tried (1.0 from Debian repo and 1.1 from Lamaresh repo) were uninstalled thru apt-get remove and autoclean/autoremove. 1.2, from the RPM at Sourceforge, was removed thru Synaptic. Always uninstalling prior to installing the following major version. I also rm -(r)f everything concerning Wine I could locate.
Something interesting that I could repeat: applying the remaining patches in a source already compiled with the first two gives an error in the fourth one - one hunk from the first file fails to be patched. We can retry and choose to ignore the hunks already patched, but that ends in a fatal error during make. That is, if we already compiled from source with the two first patches applied, we have to start over from the unpatched source (expanding the tarball again).
http://bugs.winehq.org/show_bug.cgi?id=25377
--- Comment #18 from Erich Hoover ehoover@mines.edu 2010-12-06 14:48:20 CST --- (In reply to comment #17)
... Sorry, in fact, some of the addressess are 0.0.0.0, but there are at least other two different ones (loopback and someone from my LAN). That doesn't change throughout patches.
The "someone from your LAN" is either your ethernet or wireless IP address, as bind() only operates on local addresses. Any application that performs the behavior I discussed previously loops over all the available network adapters (which includes the loopback and INADDR_ANY) sending out a "are there any servers?" packet.
... I tested it unpatched, with first two patches and fully patched. Only the fully patched version could find remote servers automatically.
Ok, then this is definitely a duplicate of Bug #7929. It's nice to finally find an application that is not a game that is afflicted by this bug. If you could add 7929 to the affected versions of FileMaker Pro in the AppDB then that would be greatly appreciated. I do not have permission to mark duplicates, but when one of the Bugzilla maintainers stops by they'll likely take care of it.
... I also rm -(r)f everything concerning Wine I could locate.
That's a little excessive, but thank you for being so thorough.
... That is, if we already compiled from source with the two first patches applied, we have to start over from the unpatched source (expanding the tarball again).
Sorry about not explaining that, in this particular circumstance that is somewhat to be expected. The fourth patch includes a small addition to the wineserver component, which means that it must be applied against a clean source of the correct version. If you are interested in becoming more involved in Wine development then you can contact me privately and I will explain more.
http://bugs.winehq.org/show_bug.cgi?id=25377
Juan Lang juan_lang@yahoo.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |RESOLVED Resolution| |DUPLICATE
--- Comment #19 from Juan Lang juan_lang@yahoo.com 2010-12-07 11:50:44 CST --- Dup according to comment 18.
*** This bug has been marked as a duplicate of bug 7929 ***
http://bugs.winehq.org/show_bug.cgi?id=25377
Juan Lang juan_lang@yahoo.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #20 from Juan Lang juan_lang@yahoo.com 2010-12-07 11:53:33 CST --- Closing dup.
https://bugs.winehq.org/show_bug.cgi?id=25377
Anastasius Focht focht@gmx.net changed:
What |Removed |Added ---------------------------------------------------------------------------- URL| |https://web.archive.org/web | |/20210318020452/http://fmdl | |.filemaker.com/maint/emea_f | |ba_ftn/fmpa_11.0.3.312.exe Keywords| |download CC| |focht@gmx.net