Test Network Connection Between Remote and Instrument Computers » History » Revision 27
Revision 26 (Anchi Cheng, 10/07/2014 10:05 PM) → Revision 27/42 (Anchi Cheng, 10/17/2014 10:02 AM)
h1. Test Network Connection Between Remote and Instrument Computers By far the biggest installation problem comes from network connection is block at the microscope/camera computer from the remote computer where the main Leginon program is run. Here is a test to do before trying to start leginon operation at the remote computer. Leginon bulletin board has a thread that has "various problems and solutions":http://emg.nysbc.org/boards/6/topics/3 from users. h2. Start a Test Launcher on the Microscope Computer # scope> go to the location where Leginon is installed, generally <pre>C:\Python27\Lib\site-packages\Leginon\</pre> <pre>C:\Python25\Lib\site-packages\Leginon\</pre> # scope> double click on test1.py. You should see something like this: <pre>INFO localtransport server created at location {'instance': <localtransport.Server object at 0x40e614cc>} INFO tcptransport server created at location {'hostname': 'myscope', 'port': 49152} INFO <class 'event.SetManagerEvent'> binding added for destination myscope, method <function printData at 0x40e63c34> ACCEPTING CONNECTIONS AT: myscope:49152 hit enter to kill </pre> **If the line before last says ACCEPTING CONNECTIONS ...., you have an opened port on this host. # Write down the name of the hose, in this case "myscope", and the opened port, in this case "49152", and proceed to try to connect to that computer from the remote compute in the next step. h2. Attempt Connection from the Remote Computer # remote linux computer> go to the location where Leginon is installed, type the following to find the location: <pre>start-leginon.py -v</pre> # remote linux computer> start the 2nd test script with the host name of the microscope computer and its open port <pre> remote linux computer/Leginon>test2.py myscope 49152 </pre> You should see something like this: <pre> INFO localtransport server created at location {'instance': <localtransport.Server object at 0x2b08e0d43810>} INFO tcptransport server created at location {'hostname': 'myremote', 'port': 49152} ACCEPTING CONNECTIONS AT: myremote:49152 INFO <class 'event.NodeAvailableEvent'> binding added for destination myremote, method <function printData at 0x2b08e0d51c80> CONNECTING TO: myscope:49154 WARNING localtransport client add failed INFO tcptransport client added INFO server location set to to {'TCP transport': {'hostname': 'myscope', 'port': 49154}} hit enter to kill INFO handling threaded INFO inserted in queue (class NodeAvailableEvent) INFO <class 'event.NodeAvailableEvent'> handling destination defcon1, method <function printData at 0x2b08e0d51c80> REMOTE CLIENT RESPONDED: myscope:49154 </pre> If you get the last line "REMOTE CLIENT RESPONDED" with correct hostname and port, the connection is fine. You can go to next section to test Leginon run on the remote computer. You can ignore the following error message print out in test1.py on the microscope PC when you exit it. <pre> tcptransport.TransportError: No route to host </pre> h2. Problem solving tips * See Leginon bulletin board thread on "network problem, Leginon not seeing tecnai host":http://emg.nysbc.org/boards/6/topics/3 h2. Most likely reason for the failure of the test: FIREWALL * The easiest solution is have the involving computers inside the same firewall. * Alternatively, you can # add python to firewall application exception OR # open [[Ports_used_by_Leginon|specific ports for Leginon system]] The latter is described in the Leginon bulletin board thread on "network problem, Leginon not seeing tecnai host":http://emg.nysbc.org/boards/6/topics/3 h2. Another possible reason for the failure of the test: hostname-ip address mismatch For leginon to communicate through socket, it needs to know the hostname of itself and the other computer it is connected to in both ways. The hostname also need to map properly to the IP address the partner understand as. If you are on a dynamically assigned domain name system (DNS), this should all be taken care of. However, since the local hosts HOST file overwrites the DNS assignment, you should check if you have a mismatch if you do have problem. requirement You should therefore check if you have [[add host|added hosts]] to the right files on both sides of the connection. To confirm what python thinks the hosname is on its own computer, is, run the following in python command line: <pre> import socket socket.gethostname() </pre> You can also get the IP address with this python command after importing socket like above <pre> socket.gethostbyname(socket.gethostname()) </pre> You should also check what one computer think the another's ip address is through socket connection once you know the hostname for the other computer <pre> socket.gethostbyname('hostname_of_the_other_computer') </pre> ______ [[Test Leginon on the Computer Controlling the Microscope|< Test Leginon on the Computer Controlling the Microscope]] | [[Run Leginon Client on the Instrument Computers|Run Leginon Client on the Instrument Computers >]] ______