rdebath

No information about anything except that. Technically the tracker/DHT/other peer discovery is used to setup the network of peers and get them talking to each other. It has no idea what they're going to talk about. In fact there is software out there that uses trackers to help setup VPN links between nodes so the tracker doesn't even have to know HOW the peers are going to talk to each other. As it happens there is one more piece of information that goes out to the trackers (and DHT possibly) that you might consider distinct. The INTERNAL lan IP address of the peer. This helps a lot if the are two peers on the same lan or connected via a VPN.

Put the same key into a your copy of BTSync too. If you can communicate with one of them the other is having problems. If you can communicate with both they'll bounce the file off you.

I don't know. You might turn debug logging on and see if any of those messages are what you mean. What would you expect from such a log entry anyway ... "File XXX was changed" is rather obvious. (And in the debug log)

Okay, please check my peer discovery post. Also read the Latest Sync Build: 1.1.15 post, especially the bit about earlier versions. Telnet uses TCP and BTSync uses UDP so it's quite reasonable for telnet to work and BTSync to fail. Logs from both machines are probably needed to help more.

Json is a very poor syntax for config files, you've probably missed a comma. I'd guess you code checker doesn't understand comments. We need to see the whole file to fix it. You can/should hide the keys.

Please look at the pinned threads. The Unofficial FAQ ... I can't connect to other devices - I think it's a Router/Firewall issue? If BitTorrent Sync is struggling to connect through your Router/Firewall, this post may be of use Also, if you're having trouble connecting to other devices over a VPN, try increasing the MTU size to at least 1500. To fix this you will need to turn on the debug log and post the logs (either here or by email) so others can help or you can report an issue. BTW: Your picture looks wrong I think you're mixing inbound and outbound, see this post

Well, yes. Nobody wants the modified time method it's just that it's easy. Even deletes are easy if you leave a zombie in your metadata file. From what I understand the 'rename the oldest copy' is the one that gives the best results in normal mirror application.

Can the machines "ping" each other? Are the machines connected by wifi? My Wifi router has an option called "AP Isolation" which stops the wireless PCs from talking to each other. Does it work if one is on wifi and the other on a wire ? You shouldn't need to change the default configuration for the PCs to find each other on a single LAN.

It's still a bug. The files in the new location have the wrong checksum and if the metadata gets regenerated for some reason it'll probably be rather random which version of the file ends up as the 'official' version.

Not at all AIUI, the --reverse filesystem is read only. But if the local filesystem is to be encrypted by encfs you should use encfs the right way up. PS: I should probably elaborate on the problem with writing to encfs--reverse; it's not a problem with encfs, it's working properly and you can write a correctly encrypted file to the filesystem. It's a problem with BTSync in that it doesn't have a way of dumping it's temp files into some proper temp directory. For example to use this with rsync you need to tell it to put it's temp files outside the encfs-reverse filesystem with the "-T" option. Other tools have similar options, but with BTSync your only option is to use BTSync on one copy and use another sync tool to put the data through encfs-reverse. This obviously means that BTSync takes a LOT of temp space and will probably cause filename too long errors at some point.

For consumer NAT boxes all that I know of will pass UDP and TCP connections correctly. The minimum timeout for UDP NAT punching is 30 seconds, though a few are over 300 seconds. Keepalive is the same minimum but more have higher timeouts. It appears that many work firewalls are configured to allow only web browsing and email (and that must be via the "excahnge server"). Usually a clear TCP channel can be poked through port 443 (labelled as https) which allows you to cover anything you like in a fake www wrapper. But no UDP ports are likely to be open. Occasionally UDP ports 123 and 53 will be clear, but frequently they will be put through application proxies. If you have an uncooperative firewall the correct solution is to get it fixed. If you have an uncooperative firewall admin you will have to punch the firewall (NOT the admin!) Tools suitable for punching through firewalls include Zebedee, OpenVPN, udptunnel and GVPE. The latter is especially good as it has several so called "darknet transports" that make it very difficult to block or even recognise.

BTSync's encryption is transport encryption not filesystem encryption. All nodes must know the key. To do an encrypted backup you might try encfs in --reverse mode.

I don't see what the problem is as they already implement a big chunk of the rsync algorithm when they transfer the metadata (.torrent) file. For torrent they have to generate a file with the hashes of chunks of the file and send it to the receiving node. For rsync they have to generate a file with pairs of hashes of chunks of the file and send it to the receiving node. For torrent they copy matching block aligned chunks from the old file to preseed the new file. For rsync they scan the old file looking for byte aligned chunks that match the little hashes (CRCs) from the metadata file, if the big hash also matches they copy the chunk to preseed the new file. The only other difference is that rsync normally uses smaller chunks; okay? Easy! PS: Don't use MD5 as the big hash as it's been broken for this use case.

Okay, firstly for your URI syntax. The double slash is not needed if only a path is required ie: btsync:ABCDEFGHIJKLMNOPQRSTUVWXYZ234567 If you want to specify one or more of a host, port, user and password you need the slashes: btsync://user:password@tracker.org:3000/ABCDEFGHIJKLMNOPQRSTUVWXYZ234567 or perhaps a special for dht. btsync://dht.zz/ABCDEFGHIJKLMNOPQRSTUVWXYZ234567 OTOH query strings work fine. btsync:ABCDEFGHIJKLMNOPQRSTUVWXYZ234567?peer=192.168.0.1:33333 btsync:ABCDEFGHIJKLMNOPQRSTUVWXYZ234567?tracker=&dht=1 As for losing the tracker, well, actually you can't. You need somewhere to call right at the beginning at a fixed address or DNS name to get you started, to "join the swarm". But, peer exchange is on the wishlist; this will in effect make every peer into a tracker.

Well, damn. I usually get a few weeks to a month or three between the times the connection gets reset. Are you really saying that the Germans are that inefficient ! . . .

Your ISP should not be giving you a new IP address every day. Does your public IP actually change each day? ... http://whatismyip.org/

If it is actually i486 and not i686 it may be incompatible with the floating point instructions generated by the compiler. If the distribution that BTSync was compiled on has distinct i386 and i686 binary architectures the C compiler for the i686 distribution will generate code using sse instructions that is incompatible with the i486 by default. Unfortunately, I can't test this as I only have machines with sse and sse2 instructions baked in. You might do a "cat /proc/cpuinfo" to see if this guess has any chance of being right.

My first assumption would be that you've mistyped (miscopied) the RO secret as this part is working fine for most people and only has minor issues for the rest. Otherwise try this http://forum.bittorrent.com/topic/12658-if-you-have-syncapp-issue/

Missing libraries or wrong version. They will need more information ... eg: run the commands: uname -a file ./btsync ldd ./btsync ls -l /lib/libc.*

It's far more likely that you will be the only person to win an accumlator lottery using your mother's birthday from a ticket that you found in a cookie jar on your birthday then going home to find your house has been burnt to the ground after being struck by lightning, blown up in a gas explosion and demolished by two semis driving through it! Then meet a guy named Phil who used to have only one head.

SyncIgnore really doesn't work. If you want to get something useful out of them you must make sure all the syncIgnore files are identical. You will probably have to remove and recreate the share (on all machines at the same time) to ensure that the ignored files are not in BTSync's metadata on any machine. The deleting of ignored files is considered a bug, in both directions.

Old thread. It now means that BTSync is trying to connect to a share that it's impossible for it to connect to. Specifically, the protocol has changed between V1.0.* and V1.1.* so that they cannot share with each other. They still try to connect but it will never succeed. It used to be that you would get this message for a little while after deleting a share, until the other peers realised that you didn't have it any more.

Um, zero is NOT a "bad time". A time_t is normally a signed int on a 64 bit system. It is also usually signed on a 32bit system but it can also (becoming less rare) be a signed 64bit int on a 32bit system. # uname -mrso Linux 2.6.32-5-amd64 x86_64 GNU/Linux # date -d '23 jan 1966' +%s -124329600 # date -d '23 jan 2066' +%s 3031430400 # date -d '23 jan 1801' +%s -5331225525 # date -d '23 jan 2266' +%s 9342777600 # TZ=UTC date -d '1 jan 1970' +%s 0 # TZ=UTC date -d 1970-01-01+2147483648sec Tue Jan 19 03:14:08 UTC 2038 #

It's initially back on the tidyness issue, it helps make the application more stable and means that debugging is easier in that if the settings are such that if the two peers won't be able to communicate they can't even see each other. That way I know that if they are trying (and failing) to communicate then it's a network (NAT) problem if they're not even trying it's a setup problem. To illustrate there is a setup issue like this in OpenVPN in that if you use the 'comp-lzo' option on only one side it looks like the ends should be talking to each other; one end will believe the connection is working and the other end doesn't. This looks like a stupid firewall issue until several hours later you realise that it's a "minor config difference" !!! To put it bluntly, "why should the ****! ****! ****! application try to make a connection that it knows is going to fail?" But, it is also a (minor) security issue in that it can potentially hide an attack. If you know you have a wrongly setup node it would be quite reasonable to see continual "failed attacks" in the application. Even if you don't think you have a misconfigured node it actually becomes a more reasonable diagnosis than someone is trying to attack the peer. You lose part of the ability to monitor the security because something that should never happen (a connection with the wrong key) becomes a common, dumb, problem. Use of different encryption & MAC algorithms is just the normal security stuff. If an attacker doesn't even know which algorithm you're using they either have more work to do (to find out) or they have to attack all algorithms are the same time. What's more the OpenSSL library can be upgraded and if the new version supports SSH3 then so can BTSync, immediately, without any extra updates.

However, this is an artificial limitation because all the shares are managed by one instance of BTSync and it's (currently) unable to cope with a file/directory belonging to two different shares. To do this you have to have two instances of BTSync running, one for the overall share and one for all the "little" shares. On Windows this has to be done by putting the two copies of BTSync into separate sessions; say by using "Fast user switching". BUT, beware of using this technique with overlapping writeable shares; the *.!sync files from multiple BTSync daemons will collide and could cause files to be lost or corrupted. This is one of the reasons I think *!sync files are a bad idea. The worst one though is fragmentation, the *!sync files are usually very very fragmented (because they're created from random pieces) and should be copied to the final location to reduce or even remove this fragmentation.