Trouble getting the example menu to work

[wtfork]

I've been poking through the examples a little to get a feel for things. To play around with mobile-to-desktop networking I baked a build with all the example scenes (starting with the menu) to my iPhone. It loads fine and it also detects the version running in the Unity editor, but when I try to connect it seems to time out and then my app freezes up with a SIGUSR1 error, which is a new one on me (xcode screenshot attached). Has anyone run into this sort of thing before?

[ArenMook]

When connecting, it first attempts to connect via an external IP address, then 3 seconds later when that's unsuccessful -- via a local IP address. Is your device actually connected to wifi, do you have stripping enabled, and what version of TNet are you using?

[wtfork]

Wifi: both desktop and iPhone
Stripping: Disabled
TNET: 1.6.8

When I deploy it to the desktop and run the Editor and Standalone side by side, I don't get a crash but I do get a The object was used after being disposed error, if that's any help.

[ArenMook]

Hmm... so does it only happen outside of the editor? Does it happen in the server or client? You can run the server separately by extracting the contents of the ZIP file. Server's project and source files are in there as well.

[wtfork]

I can't get any builds (editor, standalone, iOS) to work together. The goal is to establish a direct network connection between a mobile device and a desktop (with Unity spawning a server instance internally) so I'm reluctant to rely on a standalone server. Plus it's clearly mostly working since I can see the server on the would-be client devices.... I just can't connect to it. I'll try a global re-import/rebuild, see if that helps. Edit: it did not.

[wtfork]

OK, If I sequester my desktop from the wireless network and run the editor and the demo simultaneously it works... which makes me think it's a Loopback issue. I know a few other people have had issues with address loopback, but in other posts you've implied that the second connection stage (internal addresses) should work in situations without loopback. Since I'm looking at a LAN-only application, any advice on forcing an internal, non-loopback based connection?

Edit: I can resolve the problem by swapping out tcpEndPoint for mFallback in TcpProtocol.cs... so it looks like the fallback mechanism must be failing somehow, since it doesn't seem to be firing on its own (and otherwise seems to work). I'll poke around a bit to see if the issue with fallback has to do with the thread not spawning correctly, or something to do with the sockets not opening correctly...