Not ready, check your connection [Centos] with temp solution
I am using Centos and trying to install teamviewer 12 on it. Then I arrive at the "infamous" problem of "not read, check your connection". I have tried many times of installing and have tracked the problem on various forums. I finally arrive at a conclusion that the problem may be a bug in the daemon installation, which has not been mention in any thread on web.
This problem suddently remind me of a very similar problem of TV about 6-7 years ago (yes I am a long time user of TV). That time, I try to set it up on a Ubuntu, and eventually cannot find any solution until I fall back to TV7. Any high version at that time shows "not ready". I am so surprised that this problem can linger for that long in the product. I believe the TV support team can figure the precise coding problem within and update it. This is why I post what I have learnt here.
For those who want a quick workaround, please look at the temporary solution at the end of this passage. It does work for me, at least, without setting anything DNS or network or routing. I never saw any solution like this in many forums, and I hope it can help those who are frustrated. Good luck!
My observations:-
-- if you install the rpm, it shall install the daemon. Then you either get "Not ready" or "LAN only", depends on your settings in options.
-- if you install the tarball, it is possible to run as stand alone. You shall notice that the TV12 works and can reach out to internet. I suppose it can be connected from partner, just that you cannot set a password for unmanned access (it states you cannot because it is not perminently installed). If you install and setup the tarball with daemon, then the Not Ready problem come back.
My experiments:
-- from some forums, I saw many threads saying the TV cannot resolve and connect to the TV server. From what I see when I check what ports the TV programs is holding, thats true. Comparing the network port list for the two cases, we can see the difference.
In the "rpm" case, teamview holds only port 5940 and daemon holds 5939. later I find that 5939 is hold by a dead daemon, i.e. it is still there even after stopping the service. So I kill it.
In the "tarball" and standalone case, teamview holds ports 5940, 5941, 5938, and several others data ports.
I suppose the 5940 is for the wine component in both cases. 5941 should be also for similar purpose, but in the "rpm" case it fails.
Then I tried to look at the connection process, what the two TV cases did. The "tarball" tried to connect to ping3 TV server. But "rpm" case immediately giveup and no trace of ping3 can be seen. I tried to put ping3's ip into hosts file. It didnt work. So i suspects the daemon is using a special way to resolve hostname.
When I play with daemon enable and disable, I notice there are some scripts in /opt/teamviewer/tv_bin/script/ . So I read into some of them and notice that tv-delayed-start.sh has some network checking routine.
But I fail to decipher what is the problem there. No clues. But it certainly look like the teamviewerd is not behaving properly when it tries to connect to master or ping3. I hope the support team in TV can figure it out.
My temporary solution:
-- Install the tarball without daemon
-- Run teamviewer and mark down the ID and pass
-- In the options, setup so that this pass is very secure and does not change across time.
-- Access from elsewhere to the Centos/Linux PC using this info.
note: Although you cannot add the PC into your computer list, you can keep on accessing it successfully. Just that you cannot reboot your PC.
