Tim Radbourne

  • Posts

  • Joined

  • Last visited

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

Tim Radbourne's Achievements


Member (2/3)

  1. I would agree that the GF is not blocking needed ports. As long as you are syncing large files, the speed will approach wire line speed. The overhead for processing files will slow small file transfers way down. I blamed some of the issues on the GF, but in reality it was not the root cause. Bugs in the Sync software resulting in it dropping the connection intermittently. These appear to be fixed in the version of 2.3 that they created for me, and possibly these fixes are included in the newly released ver 2.4
  2. I have run some test versions of BT Sync docker software (2.3.10058) that have managed to remain connected for weeks without issue. I now declare it stable. Remaining issues are my 2/100 line speed in China and jumping the Great Firewall.
  3. Yes, correct, a direct connection to the USA is possible. China IP keeps changing. Suddenly, It has lost connection again, so these logs should be useful. Sending them now. I have logs going back to 08/02 (500mb) on the China side, but only to 08/06 (800mb) on the USA side. Sync seems to be cleaning up the logs when they get overly big. Your support page is having problems receiving the log files. Sent 4 logs, China / USA logs from today China / USA logs from Aug 6, the oldest Sync log files that have not rotated.
  4. While I have had no disconnects, suddenly the peers online jumped to 2 of 2 (there is only one peer on either end and it always showed 1 of 1 before) and Sync stopped syncing for over a week. There was 25G / 800 files to sync but it acted like it was fully synced. Rebooting, stopping and restarting the Sync docker service did nothing to fix this. Suddenly today, long after I had given up on getting this fixed, I had to rebooted the USA server for another reason. Sync refused to connect until I stopped are restarted the Sync docker service in China. Now suddenly it is showing 1 of 2 peers online, and it is syncing again. Logs are available...
  5. I have been using a test build (2.3.1049 - 57) of Sync for several days now, and so far I have not seen any disconnects.
  6. I have not found a way to use one of the dynamic host services in China yet. They are blocked. Were you meaning like duckdns? That is what the USA computer is using today, so we have predefined hosts on one side of the connection.
  7. Both ends are still logging, I have sent updated logs that should include the reconnect time period.
  8. I see sync is running again. Did you poke it somehow? Or did it fix itself?
  9. Logs sent.... I am running Sync 2.3.7 Docker under Linux on both ends. Upgrading to 2.3.8 is not yet flushing through to http://lime-technology.com/forum/index.php?topic=40654.0
  10. The China side is confusing because China Telecom is using IPV4 with CG-NAT. CG-NAT is what creates the double NAT problem. Skype, WhatsApp and Teamviewer seem to be able to penetrate this, as does your Sync with some success, but it is not good. IPV6 is not available at this location yet. On the USA side we have Google Fiber. I have another ISP I can try on the USA side if needed. We control this via dynamic dns, but our GF ip seems to be static, so we could use our GF IP address instead. The China Sync client has predefined hosts set up like: mydomain.duckdns.org:5555 On the GF network box (router) the port 5555 is port forwarded to the local ip of the Sync client for both UDP and TCP. In China, the dd-wrt router also has port 5555 forwarded to the local ip of the sync client both UDP and TCP. The China side has port 3838 forwarded, but I don't think this is needed. Maybe I should delete this? 2.3.7 on both ends using Docker. My screen on both ends just shows offline right now. Once we reconnect, I can check this. This setup has moved 150 GB over the course of a month, about 1/2 USA->China, and about 1/2 China->USA. I have had to struggle and get it reconnected several times. Now it is disconnected again. I would like fix it so it will stay connected, but I will not mess with anything until you get the chance to troubleshoot what you need. I will try any suggestion you may have.
  11. Thanks RomanZ for your help. The speed fluctuates dramatically from sitting at 0 for a period of time then jumping to a normal speed of 30-60kb/sec then without warning it will suddenly increase for a short period of time to an abnormal speed of 500kb/sec. I have never seen it exceed 1000kb/sec. Average sync speed seems to be in the 30-60 kb/sec into China and 60-120 kb/sec out of China. How do I check if the connection is direct or via relay? Under preferences, we have use relay server checked, use tracker server checked, search lan unchecked, and use predefined hosts checked on the China server. The USA server is the same except that the predefined hosts is not checked as the CG-NAT in China keeps the China IP changing very often. Dynamic DNS services don't work in China, otherwise I would set it up as predefined on both sides. The connection is GF in KC to a China Telecommunications link in South China with a speed of 100mbit down and 2mbit up. GF is gbit both ways with a dynamic dns and the link in S China is CG-NAT. The router in china is using dd-wrt and shows an external ip of 100.64.160.xxx This IP changes every 48 hours, but the real external IP as reported by http://ipecho.net/plain is more likely to be 219.130.73.xxx Sync seems to be able to get through this double NAT, except when it can't. Every few days, I see that sync has stopped and shows peers online "0 of 1" This is the same at both ends as I can use teamviewer to access the other end as well. Messing around and deleting the predefined hosts and recreating them sometimes will fix the connection. Other times it requires a Docker restart or a complete reboot. Since it has stopped again right now, I will not fool with it in case you want some diagnositics. I would like to get this to a stable point where I can just let it go.... and it won't burp or throw up all over me... Thanks
  12. Through the peer list I can see the first 100 files waiting to transfer, but another 2200 files are not shown. Is there any way to get the complete list? The "Size column" is not showing on my Sync Docker screen. Should it be visible on the Linux Docker version? I understand your progress bar now, thanks.
  13. Is there any way to see a detailed list of the unsynced content at any point? I would like to see a sync status as well as a list of files that have not yet synced. The current Status line on each Sync folder attempts to show a summary status, but first it is not accurate (right now for one of my folders it shows (1% complete 6kb/sec remaining time 3 months), when in fact I know that the folder is about 70% replicated. (40gb of 70gb or 3045 of 7134 files synced) I have to do this check manually, as I cannot trust the status indicator. Yesterday it was showing 40% replicated, (better but still wrong).
  14. I can report that Sync is proceeding slowly between USA and China. The biggest issue seems to be that there is a double NAT in place due to CG-NAT (carrier grade network address translation) or Large Scale NAT. This results in difficulty for software to get through the firewall. Skype and Sync seem to use similar methods to break through. The results are that it works, sort of..... It appears that the only real solution is a directly accessible IP address on both ends of the transaction. Today, only one end has this due to China running out of real IP addresses. The solution is IPV6 which is being implemented slowly. I wonder how badly Sync performs when both ends are behind CG-NAT
  15. After 4 days, the folders are now synced up, except that the some test files I created in the source folder never arrived in the destination folder. The Source folder shows these files being added during the sync The destination shows the sync finishing, but these files never arrived. How can we track where the problem might be??