@Kara: Did you notice that the second time you showed up for the session that you didn't have the problem? That's what is really strange it's like once you can see the game you can see it the rest of the day. Probably hasn't been noticed in FS2 since the host usually restarts the server after just about every game. I'm wondering if it has to do with the machines having 2 IP addresses. I know Taylor worked on that for 3.6.10.
As karajorma said, it is likely a NAT issue. There is no point in restating that really, but I have some to add to it. I recently found a bug in the server code that would make it not be able to properly distinguish between multiple games running from the same place (same IP, as far as the server is concerned if you are dealing with NAT). It's quite possible that this is the heart of the problem you are seeing. I have fixed this by doing two things: 1) I added a disconnect packet so that when a host game ends it will send a disconnect right then and you won't be left with host games being there until timeout or just remaining stale, and 2) game listings are now maintained with identification based on IP
and port number. #2 is going to be the big one here, since now you should be able to successfully run multiple games from the same IP, but on different ports (the -port cmdline option), and both the client and server sides will be able to keep track of it all properly.
Right now those changes (plus a bunch more) are currently just in testing, and usable only with the 0306 Xt build, on a separate server daemon. I had planned on replacing the existing v.2 daemon (for 3.6.10) with the newer version over the weekend, but I couldn't get all of the code worked out in time. The IP/port fix should be hitting the v.1 daemon as well, but the disconnect packet obviously will not. Both the v.1 and v.2 daemons should be replaced with their newer counterparts this coming weekend, so you can test it all out at that point and see if you can still replicate the problem.
Turey has the code for a partial solution for this problem. With luck it will be in 3.6.10.
I've been trying to integrate that code in, but it actually needed a rewrite. That little bit of code actually managed to contain every single bug that the original FS2NetD code had both client and server side. It was quite amusing.
But anyway, during the restructure of that code I got a "WTF?" feeling about it, and after re-checking the RFC to be sure, I'm sure that it wouldn't have actually worked. It was basically correct in theory but had several flaws which would have prevented it from ever working properly. Fixing that calls for a slight redesign though, so I'm trying to work out how to go about that and still have it work together with FS2NetD as it is designed.
It is still slated for 3.6.10 though. I'll get the issues worked out and have it in working builds within the next week or two.