Connection failures.
These have been the bane of many a project, not just Open Cobalt, however it affects us too. I worked through some just today with Kenneth to determine if two Cobalt instances couldn't connect together, or it was just firewalls playing stupid. In the description below, anything in this sort of text should not be typed, but symbolises a prompt for information. Entries like <this> symbolise a single named key to hit on the keyboard, like the <Enter> key. Please, don't type the seven separate characters < e n t e r >. You'd be surprised how many people have done just that. These instructions may duplicate information already out there. When checking firewalls, remember to check your local computer for any running firewalls. Machines booting Windows have a firewall in place by default, and Microsoft recommends strongly against disabling it. Linux machines typically use an iptables-based firewall, if one was ever installed. I can't say what Mac OS X machines use, as I don't have any Mac OS X experience. A simple set of instructions to configure the Windows or Mac OS X firewall are mentioned in the Troubleshooting Cobalt document elsewhere. In addition, check whatever device you're connected to the Internet with; for home users this is often some sort of modem or router device, usually with its own firewall. Business users wanting to run Open Cobalt on the business network should talk to their technical/network support about tcp traffic on port 6900. If you are the technical support, then you should know what I mean. Other ports used by Open Cobalt are described in the Network Usage document. To test the connection between two computers on the port that Open Cobalt would normally communicate on, take:
First test
type in some text here<Enter>
type in some text here
type in some text here Here is some text in return<Enter>
Now, reverse the test machines, this time the host becomes the client, and the client becomes the host. You can hit <Control>C on each end to quit both netcat programs so you can start the test again. Second test
type in some text here<Enter>
type in some text here
type in some text here Here is some text in return<Enter>
And that's roughly what we did. Now what to do if you don't see all/any lines of text. First test results - needs fine tuningIf harry sees no lines of text, then percy probably won't see any reply lines either. It's actually pretty hard to judge whose firewall to look at unless you have multiple places you can connect from. If connections from anywhere fail to reach percy:6900, then check percy's firewall. If connections from harry don't reach percy, but connections from elsewhere (for example, from bootes) do, then check harry's firewall for outgoing connections to anywhere:6900 (or at least percy:6900). Connections are different to replies, as they're establishment of a link between two computers, whereas replies are continuances of an existing conversation between computers. For you techie types who've memorised the TCP stack, we're talking about the SYN portion of the setting up, not the SYN/ACK or ACK stages. If harry sees lines, but percy doesn't see any lines in return, then harry needs to check outgoing reply traffic on port 6900, and percy needs to check incoming reply traffic on the same port. Again, this can be further refined if bootes can connect to percy:6900, in which case, check harry's firewall. If bootes cannot connect either, then check percy's firewall. If both harry and percy see each other's lines, then we can establish that harry's firewall is probably set up correctly. Second test results - needs rewriteIf percy sees no lines, then it's likely that harry's firewall isn't set up to allow outgoing connections on port 6900, or it's likely that percy's firewall isn't set up to allow incoming connections from anywhere:6900 (or at least, from harry:6900). This rather depends upon the results of the first test, because if that test failed, then both sets of firewalls need configuring. If the first test succeeds and the second test doesn't, then the setting up of each firewall differs from the previous case. In this case, harry needs to check their firewall for outgoing connections from harry:6900 to anywhere:6900. If percy sees lines but harry doesn't see any lines in reply, then percy needs to check reply traffic from percy:6900 to anywhere:6900. If both harry and percy see lines after both tests, then all firewalls are set up correctly for Open Cobalt connections. Congratulations.
|
Documentation > Developer Resources >