It happened again: Lost host on network

[dvalley]

This happened last summer on a different machine: Server cannot be seen in Hosts list. Server is working (Dell PowerEdge 600/Win 2K Server/FM Server 5.0), and you can force it by specifying the IP address, but the host is gone by name. This loss did not effect anyone using the files at the time, but anyone trying to open a file hosted by that machine was SOL unless he knew the IP Address.

[trevorg]

A lot depends on your network configuration. The process of locating the FM Server relies on a broadcast. Routers, bridges, and repeaters typically don't pass on a broadcast. Has something changed on your network that might be blocking a broadcast?

[Will]

If stopping and restarting the Filemaker service or rebooting the server doesn't return it to the hosts list then trevorg is probably right - something must have changed in your network.

[Anatoli]

Does FM server appear if you specify the name of the machine?

[dvalley]

I restarted the server and it came back again. I did not try to specify the name, but the problem is solved but not resolved.

[Anatoli]

I guess the best is set "opener" file and copy that to user machines.

Then they can simple forget the hassle with server.

[dvalley]

Our launcher files fail to see the server to open and run scripts in this case.

[Anatoli]

Did you set the opener files with IP address of server?

[djgogi]

The following post deals with such problems.

Dj

[dvalley]

The launcher files refered to the host name, not IP address.

[bubba1]

This is happening to me also. Did you ever resolve it?

Thanks

[Ted S]

Hi gang,

I have had the same or very similar problem. We traced the problem to two different causes:

a. We had a CLIENT PC in bad shape. IPCONFIG showed bogus IP addresses. A reboot w/ CHKDSK fixed the problem. Anytime this user clicked on his HOSTS button the entire domain would go blank.

b. Any client PC with multiple (more than 1) network card makes our server behave as described (host list gone).

* We are running FMP3.0v6 on on W2K and XP.

-Ted

[Anatoli]

RE: * We are running FMP3.0v6 on on W2K and XP.

It is not officially supported. That is old, obsolete version.

[olias88]

This has been happening to us for a long time (years) very intermittently. Now it is occurring once or twice a week. We have two W2K FMP 5.5 servers hosting about 160 files between them. Our site has about 120 clients, mostly on FMP 6.0v4, but some in the shop on various earlier versions. Sometimes both servers disappear from the list, sometimes only one. Usually if one disappears, the other one will also within a few hours. After rebooting the servers, everything is fine (until the next time).

Over the course of time I have replaced the servers, upgraded FM server and replaced our hubs and switches and can't get rid of the problem.

I'm getting ready to set up a sniffer on the network to capture net traffic. I tried a paid call to Filemaker, but their offical response was that there were "no known issues".

Becasue of the dynamic nature of our active databases, opener files would be hard to manage. Does anyone have any other ideas?

[Anatoli]

RE: I tried a paid call to Filemaker, but their offical response was that there were "no known issues".

Bullsh**.

Only server IP will work 100%. But looks to me, that FMS version 5 has less such problems, than FM 5.5.

[olias88]

Just in case anyone else is searching on this thread, I've found a couple of things that contribute to the hosts disappearing. We have a group of remote users that connected to us through a pair of cisco routers. I blocked access to filemaker through the routers and forced them to use Filemaker through a terminal server at our location and the problem "almost" disappeared.

As Ted S. mentioned previously, a client with dual network cards can cause problems too. We purchased a new laptop this spring for one of our sales reps. It had a regular nic and a Wi-Fi adapter built in. He uses the nic while at the office and the Wi-Fi while on the road. Soon after he got the laptop, we started losing the hosts files in Filemaker whenever he would search the list to open a file. I had to show him how to disable the Wi-Fi card in Windows while he was in the office.

We are currently on FM Server 5.5, clients are all 6.0v4. We just started testing FMP 7, I don't know yet if it has the same issues.

[kudodorf]

im having the same exact problem but we have no remote users. everything is on lan. were using win2k server and filemaker server 5.5. this dissappearence happens once in a while. after rebooting it reappears but then gone a while later again. I cant keep doing this casue its starting to happen way too often. does anyone have a solotion to this problem? i was thinking of redoing the server but since that isnt going to fix the problem then i wont.

[Zardoz]

This has been happening to us for the past month or so ever since we switched our server environment from NT to Windows 2003. Prior to this, under NT, the FileMaker Server service would just suddenly stop, whereas now under Windows 2003, the service is still running but the host is not visible. Anybody who is currently connected can still use the databases (and it seems that they can still open other databases hosted on the server), but no one else can connect. In both scenarios, restarting the service fixes the problem until the next occurrence, which can be anywhere from a few minutes to about one month later.

Our situation is eerily similar to that reported by Ted S in the Hosts Problem thread: we are running 3.0v6 on XP and Server 3.0v4 on Windows 2003, and we've been in the process of phasing out FileMaker for the past few years. However, the company has recently made a commitment to upgrade our FileMaker environment. This will take a while, though. I realize the versions we are currently running are no longer supported, but until we get to 7.0, I am desperate to fix this lost host problem, as this is undermining the credibility of some wonderful solutions that have been built so far using FileMaker.

Like Ted S, I've performed file recoveries, studied the FM server logs to try to establish some sort of pattern of when this occurs (I've kept log histories for the past two years dating back to the NT days), and pinged the server during outages with good results. The Server team have even rebuilt the server, but this has not solved the problem. It just seems to be a totally random thing.

I was excited to see some potential causes identified in this thread which would seem to explain the randomness, but I'm not sure how to test for these (I'm not a server or network person, just a business user who loves FileMaker). Our FileMaker solutions have about 1000 clients, many of whom use laptops and are widely dispersed geographically. I will pursue the dual network card and router theories with some network people, but I would be interested in hearing some insights into the following questions regarding some of the other theories:

1. Are there methods for finding bad client PCs on the network? I really wish I could have the eureka experience described by Ted S in his YIKES post in the Hosts Problem thread!

2. This one may be more for Ted S: what is a bogus IP address and how can these be found? Can anyone explain (to a non-techie like me) how the presence of bogus IP addresses on a client machine could result in losing the host on the network for everybody?

3. What role, if any, can the FileMaker Server log file play in tracking down the problem? For example, in the log files, I can see the name of the last person who was able to make a connection and I can see the names of all persons who were connected at the time that the problem occurred. Will this help at all, or, as in Ted S's case, are we looking for someone who just simply was not able to connect and who took the host down with them?

4. We use a lot of HP printers (e.g., HP 5si LaserJets), and I've heard that there are potential conflicts with certain HP printer drivers. Is it possible that the problem occurs when a connected user prints something from a hosted FileMaker database? If so, what is the mechanism of this type of failure?

Thank you very much!

[Tripod]

Could it be that your DNS is flaking out?

[Zardoz]

It doesn't appear to be related to the DNS alias. I've reconfigured all openers and relationships to use IP address, and the problem still occurs. Also, I've tried connecting with a wireless NIC activated on the client, but this did not replicate the problem.

I do have a clearer understanding of the symptoms of the problem, but unfortunately still do not know why it is happening. The problem does appear to be related to the UDP portion of the client/server exchange. UDP packets are exchanged during the initial discovery phase. Following successful discovery, all subsequent exchanges use TCP. When the problem occurs, TCP continues to work fine for everyone who had already established a connection. However, any attempts to establish new connections fail, as the UDP exchange does not work properly.

We performed network analysis upon occurrence of the problem and found that UDP packets from the client were reaching the server and were not generating any ICMP 'destination unreachable' messages. This suggests that the UDP packets are reaching port 5003 and that the port is open. However, no return UDP packet is seen from the server.

A comparison of the UDP packets from the client in a working versus broken state revealed that, with the exception of bytes representing the source port and checksum portions of the packet, the packets are identical, including the data or payload portions. Differences in the checksum and source port bytes are to be expected, so it does not appear to be a case of the client UDP packet being corrupted.

But this is a comparison after the occurrence of the problem. It might still be possible that one or more corrupt UDP packets were received when everything was working fine, and that the receipt of corrupt UDP packets is what is causing the problem in the first place. But I'm not sure how to test for this.

The Netstat and PortQuery utilities also suggest that UDP port 5003 is still open. But I'm wondering whether it is possible that FileMaker Server (FMS) has become unbound from UDP port 5003. Does anyone know of a mechanism that would cause FMS to unbind from UDP port 5003 but remain bound to TCP port 5003?

At some level, I think the problem has to do with a difference between Windows 2003 Server and Windows NT. Maybe if consecutive corrupt packets are received, Windows 2003 somehow unbinds the process/service from that port, whereas this would not occur on Windows NT?

Any suggestions will be most appreciated.

[DykstrL]

I have seen similar situations on 2 client machines, not server, but it may be a starting point. The client machines could not see or connect to any FM server. The problem ended up being a corrupt IP stack. The solution was to remove the network card and all networking DLLs and APIs and reinstall a new network card and IP stack. I suspect that the network cards were bad, thereby corrupting the IP stack, but all utilities showed that the card was OK. We sent the cards in for replacement (3Com) under a lifetime warranty.

[Ted S]

Zardoz,

I'm impressed with your research. Nice work!

Do me a favor and post your findings here. I'll be interested because although our system has been running flawlessly for a couple of months now, I suspect it won't last and it would be nice to "bottom out" on this.

[Himitsu]

Just to add to this. When mine does the same thing, I notice the IP mask from the router changed from a local to an external. All my PC's go down. When I umplug the router and then plug them back in, the IP's reset and everything goes great again. My case might be different but when you lose your connection, check to see if you can access your mail or other resources. My local network stays active, as in, I can access other PC's from My network Places. That stays running.

[fmpwizard]

I had the same problem, running server 5.0 on Windows 2k Advance Server, running 60 files.

What I started doing was restarting the whole server, not just the service, once a week and the problem does not appear any more, but I know that it's not the best solution.

[Zardoz]

Thanks everyone for the feedback. I'll review your suggestions with my network and server contacts to see what we can try. What we're doing now is attempting to capture a few network traces around the time that the problem occurs to see if there are common patterns of packet activity into UDP port 5003 just prior to the problem. We captured a few such traces yesterday, but I don't yet have the results--there is a lot of data to wade through. If we find anything significant, I'll be sure to post it here.

[Zardoz]

While I wait for the results of our network traces, there are a couple of things I'm wondering about:

1. Is this problem occurring for anybody in FMS 7 on W2K3 server?

2. To troubleshoot this problem, has anyone tried running the older versions of FMP and FMS in compatibility mode with an appropriate earlier version of Windows?

I was just reviewing the troubleshooting information for W2K3 server and it suggests that, for "an application that stops responding, quits or behaves improperly," to try running it in compatibility mode with the version of Windows for which it was originally designed. In our case, I imagine we would try running FMS 3 in compatibility mode with Windows NT. This selection is made by right-clicking the application, choosing properties and picking the appropriate option on the compatibility tab. I've seen similar suggestions in other threads in this forum to run older FMP clients in compatibility mode on the newer OSes. In our case, XP is our OS and we would run FMP 3 in compatibility mode with Windows NT.

Not sure if this has anything to do with the problem, but I might give it a try if the network traces don't yield anything useful.

[spb]

This subject came up in a thread last October. It was happening to me as well. The problem is frustratingly not duplicatable, it seems to happen at random only. I thought I had an agle on it, wherein some kinds of load on the files (huge replace operations) seemed to trigger it every time. However, the host vanishings *also* happened during the day under normal load.

My problem happened every other day for two frustrating weeks, then seemed to go away on its own. It hasn't returned (knock wood) but I'm following this thread with interest.

FYI, here is my post from October, outlining my experience:

----------------------------------------------------------------

I'm having the same problem and have been watching this thread to see if something comes up. How big are your files? Mine total up to about half a gig, with 50,000 records in the most populated file (the others average around 10,000 to 20,000 records, fifty files in all). I'm running Win2000 server, with FM 5.5 server running as a service. Nothing else runs on that box.

I've noticed that when my files vanish, I can log directly into the server and see everything apparently working normally. FM 5.5 thinks it is still serving the files. Only a reboot seems to fix the problem. I do know that RAM usage is not the issue. During a cache flush after heavy usage, RAM usage spikes up to a max of 47%. If it was over 90%, I'd be worried about it.

I've been scrutinizing my event logs, trying to figure out what triggers the problem. One thing that happened recently is that I had 73 files being served. I thought I'd pull off and archive about 20 that didn't really need to be there, hoping to lighten the load. I did this and left myself a trap.

I have my FM files set up to do a few hours of processing in the middle of the night. A master updater script performs a set of about thirty external scripts, opening files and running updates one after another. My trap was that a couple of my files had calc fields on the default layout that referred to now-archived old files. So I'd come in, find an error halt about not finding the file (I'm doing this in a Win2000 client machine running FM 6). It gives me a nav window. To get the processing done, I direct FM through the nav window to where the old files are now archived. The processing picks up and finishes.

This happened two days in a row (before I'd found and killed all those old calc fields). Both times, right after pointing FM to the archived files, after processing finished, the hosts vanished. This morning, after processing normally without needing redirection, no host vanishing.

The problem here is that this may have something to do with it, but it isn't all there is. I've had host vanishings happen three times in the middle of the afternoon without anything like the above happening at all.

__________________________________________

Steve Brown

[Zardoz]

Thanks Steve. I agree this is a very frustrating and seemingly random problem that so far has proven impossible to replicate. Many times I think I've solved it only to see it happen again. As you state, the only things that work are restarting the service or restarting the server. This allows clients to once again "discover" the server. Our files are not particularly large, and I don't believe there are any heavy calculation or replace operations going on. The problem does occur at any time of the day.

Two quick updates to report.

1. Very preliminary results from the network traces indicate that the server is receiving ICMP "destination unreachable" messages around the time of the problem. This would mean that the server is attempting to send packets but the packets cannot be delivered to the destination(s). At this time, I'm not even certain whether these are TCP or UDP packets or whether they have anything to do with FMS. I'll attempt to find out more details as soon as possible.

2. Late last week, the problem was occurring 4-5 times per day, but it hasn't occurred in the past 32 hours ever since I restarted FMS 3 in compatibility mode with Windows NT. Far too early to tell if this is something to get excited about....

[Zardoz]

Well, using compatibility mode does not solve this problem. However, a review of the network traces has shed some significant light.

We now have three network traces that show the transition from a working state to a broken state, and I have had a chance to examine one of them in some detail so far. In this trace, the break occurs during a seemingly normal attempt by a client to "discover" the FMS.

In a normal discovery exchange (normal at least for FMS 3), the client sends two consecutive UDP packets to FMS (port 5003). This occurs when a client doubleclicks an opener file or clicks the hosts button (or specifies a host by name or IP address). When the first UDP packet is received, FMS sends a UDP packet back to the client. When the second UDP packet from the client arrives, FMS sends another UDP packet to the client. After this mutual exchange of two UDP packets, which presumably confirms that the FMS is available and listening (this produces the list of available databases in the hosts window for a client using File/Open/Hosts), the client clicks a database and establishes a TCP connection (or, if an opener file is used, a TCP connection is then made to the specified database) and all further exchanges occur via TCP. The FMS logfile (FMSRVLOG.txt) captures the moment of the TCP connection; it does not capture the UDP-driven discovery phase.

What's happening at the moment of the break is that, after FMS has sent the second UDP packet to the client, the server is receiving two consecutive ICMP "destination unreachable" messages, which are saying that the two UDP packets sent from the server via port 5003 are not reaching their destination. This client is then unable to establish a TCP connection to a database.

What's interesting is what is seen on the trace after the receipt of these two ICMP messages. The trace shows continued exchange of TCP packets for clients who had already established a TCP connection. However, for every subsequent client who attempts to "discover" FMS, only the two inbound UDP packets from the client into port 5003 on the server are seen; there are no return UDP packets going from FMS to the client. It seems as if FMS is no longer even attempting to respond to any more UDP packets after the two ICMP messages were received.

There is still more work to be done, as I understand that ICMP messages have an inherent meaning of their own which can reveal the reason why the message has been generated. And I want to confirm that this is what is happening on the other two traces and get some additional traces to review as further confirmation. Also, it would be interesting to determine if there are any commonalities among the clients for whom these ICMP messages are being generated (i.e., are they from the same subnet, using the same router(s), etc.).

But this does potentially explain why remediation attempts that focus on something to do with specific databases do not resolve the problem--the problem appears to occur even before a connection is established to any database.

I hope to have some additional information in the next few days.

[curious99]

Hi,

I'm happy to have found this thread . Indeed, for the past few weeks I loose my host and get the message (traducted from french the french message : la communication avec l'utilisateur principal a

[DykstrL]

That error code (-70) is not a FileMaker error, it is a Windows error code. Good luck getting anything from Microsoft.

[Zardoz]

I have now examined five network traces that show network traffic into and out of the server (W2K3 in our case) when the FMS (3.0v4 in our case) host disappears. A clear pattern has emerged. In all five cases, the host disappearance appears to be associated with the receipt, by the server, of an Internet Control Message Protocol (ICMP) packet from a client (FM 3.0v6 in our case) who has just completed the mutual exchange of two UDP packets with FMS.

The first trace (described in an earlier post) turns out to be a bit anomalous in that the client sent two ICMP packets and was unable to initiate a TCP conversation with the FMS. In all four of the other traces, the client sends only one ICMP packet and is able to initiate and establish a TCP connection with the FMS. However, the end result in all five traces is the same: after the host server receives the ICMP packet, FMS does not respond to any further UDP packets from any FileMaker clients until the FMS service is restarted.

In all five cases, the ICMP packet is a Type 3--Code 3, which translates as "Destination Unreachable--Port Unreachable". When a destination unreachable--port unreachable ICMP packet is received, it signifies to the receiving computer that a packet that it sent was able to traverse the entire network path successfully to the destination computer but was unable to be delivered to the specified port on that destination computer because there was no process listening on that port. The ICMP message identifies the packet that was unable to be delivered. In the first trace, there were two ICMP messages--one identified the first UDP packet sent by the server to the client, the other identified the second UDP packet sent by the server to the client. In the other four traces, there is only one ICMP message, and in each case, the ICMP message identifies the second UDP packet sent by the server as the one that could not be delivered to the specified port on the client.

There is lots of information to summarize, and I'll get to more of it later this weekend.

[Zardoz]

So what seems to be happening in the other four traces is that the second UDP packet from FMS cannot be delivered because the FMP client is no longer listening on the UDP port. The FMP client seems to be listening on the UDP port long enough to receive the first UDP packet from the FMS, but not long enough to receive the second UDP packet. The inability of the second UDP packet from the server to find the specified port on the client computer generates the ICMP message back to the server.

In the sense that the client in each of these four cases is able to establish a TCP connection, successful receipt of the second UDP packet from FMS does not seem to matter--a TCP connection can be established based on receipt of the first UDP packet from the server. However, successful receipt of the second UDP packet seems to be critical in order to avoid the generation of the ICMP message and to ensure continued UDP response from FMS for subsequent clients. As soon as one client anywhere on the network fails to receive the second UDP packet from FMS, the host "disappears" and no new connections are possible.

This raises at least two questions. First, why is the FMP client not staying around long enough on the UDP port to receive the second UDP packet? Second, why is the receipt of the ICMP message on the host server proving fatal for the UDP functionality of FMS but not for the TCP functionality of FMS? The traces do not appear to provide any answers to these questions, but I've got some theories which I'll share next time.

[Zardoz]

I'm not confident that all the pieces of the puzzle are in place yet, but an answer to why the host disappears is starting to crystallize. The explanation will be lengthy, so please bear with me. This might take a few posts to complete.

The answer appears to lie in Windows Sockets (Winsock) programming considerations. An important bit of information is found in Microsoft KnowledgeBase article number 245442 entitled "INFO: Winsock Ignores ICMP Port Unreachable Control Messages". This article states that ICMP port unreachable messages are ignored by the Winsock layer in Windows NT Server and in other pre-W2K versions of Windows. In other words, when an ICMP port unreachable message is received by one of these earlier versions of Windows, the winsock layer does not perform any handling on it--i.e., it does not translate the error into a winsock error message and does not pass any information about the ICMP message to the Winsock UDP application in the application layer (i.e., to FMS). FMS can carry on as if nothing unusual happened. The article states that if the ICMP port unreachable message is received when the Winsock UDP application (i.e., FMS) is waiting for a response from the remote host (i.e., the client), the receipt of the ICMP message goes undetected by the Winsock UDP application, and the application will continue to wait for a response from the client. The application will be in what is referred to as a "blocked" state--it cannot perform any other UDP operations until the expected response from the client is received.

Other socket programming resources that I've consulted suggest that a blocked UDP application would continue to receive incoming UDP requests from clients and would queue them in a UDP receive buffer. It would not be able to respond to any of them until the block is cleared (i.e., until the expected response is received).

This is interesting, and it might provide a mechanism to explain occurrences of the disappearing hosts problem in Windows NT, but it does not seem to be consistent with our scenario for a couple of reasons. Firstly, according to the network traces, the problem is occurring after FMS has sent the second UDP response to the client. After FMS has sent the second UDP response, nothing in the traces indicates that FMS is expecting any further UDP response from the client. In a normal UDP transaction between FMS and a client, all that is exchanged are two UDP packets each way, and then the client initiates a TCP connection. There is never a third UDP packet sent from the client to FMS. So FMS does not appear to be waiting for another UDP response from the client. Since it is not waiting for any further UDP response, I don't believe that, in the Windows NT Server environment, the scenario of the server receiving an ICMP port unreachable message in response to the second UDP packet from the server would cause FMS to enter a blocked state. Secondly, I believe that everyone who has posted here regarding this problem is using something later than Windows NT (typically W2K or W2K3) for their server operating system. This disappearing host problem does not appear to be much of an issue on Windows NT.

Although FMS is not expecting a further UDP response from the client after sending the second UDP packet, it is certainly not expecting to receive an ICMP port unreachable message, either. In the W2K and W2K3 server environments, though, this is exactly what is happening--the Winsock layers in these newer server operating system environments are passing information about the ICMP port unreachable message back to FMS. This is at the heart of the disappearing hosts problem, and I'll provide more details in my next post.

[Zardoz]

The Microsoft article mentioned earlier (#245442) provides another important clue as to what is going on. It states that a feature has been added on Windows 2000 to unblock a Winsock UDP application that has received an ICMP port unreachable message. In this new feature, receipt of the ICMP message is handled by the winsock layer and translated as a WSAECONNRESET error message (message #10054), which is then passed along to the Winsock UDP application for processing, presumably under the assumption that the Winsock UDP application contains error trapping code to deal appropriately with receipt of this error message. Remember that this is new behaviour at the winsock layer in Windows 2000; previously under Windows NT, ICMP port unreachable messages were simply ignored at the winsock layer.

The WSAECONNRESET message type is described in the Windows Sockets 2 API (ftp://ftp.microsoft.com/bussys/winsock/winsock2/WSAPI22.DOC) as follows: "An existing connection was forcibly closed by the remote host. This normally results if the peer application on the remote host is suddenly stopped, the host is rebooted, or the remote host used a 'hard close'."

This new feature was likely added as a fix to the problem of a Winsock UDP application waiting for, and consequently blocking on, a client response that will never come because the client has closed the connection and returned an ICMP port unreachable message to the server. This fix would be very useful to a Winsock UDP application that was expecting another UDP response from the client. Being informed, via receipt of the WSAECONNRESET error message, that the client has closed the UDP connection and will not be sending any further responses would enable the Winsock UDP application to carry on if it was adequately prepared for this eventuality.

However, this would not be a good thing for a Winsock UDP application that is not expecting a response from the client. I don't believe that FMS 3 (and possibly some later versions of FMS as well) is programmed to expect UDP responses from the client. The network traces suggest that the client actually fires off its two UDP packets right off the bat without waiting for any response from the FMS. In other words, the sending of the second UDP packet from the client is not contingent on receiving a response from FMS to the first client UDP packet. This is evidenced by what is seen in the traces after the problem occurs (i.e., after the host disappears): two UDP packets are seen arriving from each client who is trying to connect, but no response is seen going back from the FMS to the client. This suggests that FMS is programmed to respond to each UDP request received from a client but is not expecting a response from the client in return--the client has already sent all of the UDP packets that it is going to send.

When the client returns an ICMP port unreachable message to the server, the winsock layer on post-NT servers thinks that this is something that would be useful for the Winsock UDP application to know, and consequently captures this as a WSAECONNRESET error message and forwards it to the Winsock UDP application. However, FMS is not programmed to expect or handle this error in this context, and consequently the UDP portion of the FMS application hangs upon receipt of this error. Restarting the FMS presumably clears out the WSAECONNRESET error message.

Microsoft must have realized, or been informed, that this new feature was causing a problem for certain Winsock UDP applications because it issued a fix as documented in KnowledgeBase article # 263823 entitled "WinSock Recvfrom() Now Returns WSAECONNRESET Instead of Blocking or Timing Out." The intent of this fix was to provide WinSock UDP applications with a technique for obtaining the original Windows NT behaviour when an ICMP port unreachable message is received. To get this technique to work, it was necessary to rewrite the WinSock UDP application specifically for Windows 2000. By the time this fix was issued (the Last Review date is 2003/09/11), I suspect that some versions of FMS, including version 3, were no longer supported by FileMaker and that consequently, rewriting these versions of FMS to incorporate this fix was just not an option.

So this potentially explains what is happening at the server end of things, but what is happening at the client end that causes the ICMP port unreachable message to be generated in the first place? Next time, I'll discuss a theory for this.