rdebath

The 32 base32 characters only come to 160 bits of entropy so no, they don't fill the AES256 keyspace. But IMO they're big enough, the only reason that I don't think 128 bits is large enough is that it may be possible to engineer an birthday attack against BTSync because there are no user (share) names. BTW: It only accepts the base64 set so 48 characters is "only" 288 bits not 384. It might be that the info hash is 160 bits, in that case using a 256 bit key would mean that there are 79228162514264337593543950336 different passwords possible for each info hash. This is useful because it removes the any possible utility of a birthday attack completely in two different ways.

The main problem with confusing BTSync into allowing you to have subshares is the *.!sync file. You'll end up with the same file either being seen under multiple names or by multiple copies of BTSync. This will cause corruption. You can share space with aufs but you can't let either multiple copies of BTsync write to the same area nor can you let one copy see the same writeable area under different names. BTW: This means that as it stands this wouldn't work if BTSync followed symlinks either.

Most people don't seem to have noticed that you can enter a secret using the Base64 characters plus space (as long as there are 42 characters not including spaces) so the phrase "The quick brown fox jumps over the lazy dog" is actually a valid secret. My question is what's actually done with this secret? And how is it different from the handling of the 160bit secret? For example, you can enter a secret of significantly more than 256 bits with this; but AES256 will only use 256 bits. Does it use SHA256 to make the real secret? Does it do the same with the 160bit secret?

This idea will decrease the security of the share, because there are now multiple passwords that will allow someone to connect. Each "UUID" is a freshly generated random password. In fact if it's a standard UUID it's only 128 bits long compared to 160 for a BTSync password AND if generated by traditional means a UUID is likely to be guessable because it often relies on ethernet adaptor IDs and the time for large portions of it's uniqueness. If you want individual control of who is able to connect you have to use a certificate style scheme so everybody can authenticate peers trying to connect to them without knowing all the passwords or having to depend on a central authentication agent. Even then distribution of the certificate revocation list is a significant problem.

Re: the "idle" bandwidth; I agree it's been raised with them that they need no more than about 7 Bytes/second to keep the link open. As it appear to have got stuck I'm not sure I'd believe the stats on the front page; does Windows explorer agree ? (Remember to exclude .SyncTrash) Can you compare the two shares completely; eg: use something like http://www.md5summer.org to generate checksums for every file? Perhaps do it twice several hours apart to see if it's actually just going very very slowly. Then follow this: If you have SyncApp issue

It's a performance tweak only. When it's on the client will connect to other clients normally using UDP but when it has a lot of data to transfer (and it thinks it's peer is on the same lan) it'll attempt to open a TCP connection to the same IP and port number as it's peer's listening UDP port. With some network adaptors this connection will be offloaded, with others the TCP/IP network code is better optimised than BTSync's UDP data transfer. Most of the time it'll make little difference.

Okay, Windows 7 is really confusing the issue here. I've just done this on my sacrificial laptop. You will notice there are TWO "My Videos" folders in the C:\Users\TVision directory (Username is "TVision"). The one ringed in brown is the normal windows one, the one in black is one I just created. They are two distinct folders; the red rings is the standard windows one the orange rings is my new one. The standard windows one is actually name "C:\Users\TVision\Videos", you can prove this by trying to create a folder called "Videos" in that directory. Windows will say that the folder already contains "My Videos" (yes with the MY ) and do you want to merge. To top off the confusion there is also a symlink in the "My documents" folder (Actual name C:\Users\TVision\Documents ) which points the name "My Videos" at the physical folder C:\User\TVision\Videos. It has it's system bit set so you can't even see it unless you turn off the option "Hide Protected Operating System Files". All in all, if it wasn't that folder I'd believe a BTSync problem; that folder. Well, you're not the only person confused by it! From your description of your problem I would say that BTSync is not noticing the symlinks (JUNCTION POINTS in Microsoft speak) and is following them when it isn't searching for anything and ignoring them when it's scanning the filesystem. This bit may be a And some people want BTSync to follow symlinks ...

If Linux just says "Killed" that's probably the OOM killer. How big is your 'sync.dat' file ? (Possibly .sync/sync.dat) How much memory in the machine? This http://forum.bittorrent.com/topic/12658-if-you-have-syncapp-issue/ shows you how to turn on debug logging. NB: OOM = Out Of Memory

Oh yes. $ ln -s .. up $ It's much safer to include the actually required functionality directly in BTSync By that I mean have a configuration file that lists the overlays you want ... $ cat .Sync/overlay videos -> /disk/largearray/videos/notporn porn -> /disk/verylargearray project_a -> /home/staff/jenny/appleproject $ And have BTSync show the directories "videos", "porn", "project_a" even though they don't actually exist. After all, to make it safe, you're going to be doing that anyway and this way it's all local; no need to add it to the multi-peer finite state machine diagrams.

Instructions for turning the Linux log on: http://forum.bittorr...dpost&pid=35940 It gets very large very quickly.

Well, yes, shortly after a million files it'll run the 32bit versions out of memory (like the Windows version). It might even do it before it gets to a million files, if the directories are deep enough.

You mean like the fact that the folder "My Videos" doesn't exist? It's a fabrication of the Windows explorer; it doesn't even seem to be an NTFS Junction (aka Symlink) like "My Documents". The real storage behind "My Videos" is in the directory "C:\Users\Username\Videos" (Replace "C:" and "Username" as required).

It's the pinned topic at the top of this forum called "If you have a SyncApp Issue" ...

There isn't a limit on the number of files; though it gets very slow after one or two hundred thousand and starts to use a LOT of memory.

Okay, just for you I'll do it again and write down what I'm doing ... Two new PCs never had it installed before. Add rules on both firewall to direct a UDP port from outside to the PCs. Download vsn 1.0.132 to both PCs. Install to both PCs with different random keys, they don't WANT to talk to each other. Turn off UPnP; I don't need it. Configure the port numbers on both PCs. Turn off ALL ticks on the General tab for the share on both PCs. -- save Put a file in the share of PC No.1. Set the secrets on both PCs to LOVGDZGJXE7T6BUCEUFWZ6BTDN7OND6Y == base32(SHA1("password")) -- save Leave them for a while. ... ... PCs are NOT talking to each other. ... ... Still not talking. ... Add DNS hostname and port for the firewall of PC1 as a known host on PC2. Moments later the PCs see each other and up pops the message about a file transfer (it was a very small file). Add a couple of other files and did some movements; no problems. Then I removed the known host turned them off, got them not talking. Then did it the other way round. Notice in both cases I had the peers running but not talking then talking immediately I entered the host name. Plus I was running tcpdump on both firewalls. The website CanYouSeeMe(dot)org only checks for TCP ports not UDP I haven't found one that does UDP. But as you've forwarded both and BTSync opens both CanYouSeeMe will see it if you've done it right. But I'm going to leave mine running to see how well it follows when my IP changes.

The BTSync tracker is the same as a Bittorrent tracker, it does almost no work. For each combination of peer and share it stores: The hash for the share The IP address of the peer The port number of the peer The time to delete this record. Once two peers have been introduced to each other the tracker has nothing more to do. If the tracker goes down after the peers have linked up there's no problem. That DNS name resolves to three independent servers which will (probably) be sharing information. But, I expect, (deal killer if not!) there will be a configuration option to allow other trackers later on. As I said the real magic is the DHT mode where if you know or remember the location of any node in the network you can use it to find the rest of the network. I've tested the known hosts connection with Windows-7, it's working fine for me. I've tested it with only one side knowing the location of the other and that works too (depending on the firewall). Remember you have to open UDP ports not TCP ports and usually tell the BOTH clients the public IP addresses of the other so they can work together to poke holes through NAT or connection tracking. If the public IPs are dynamic you can use services like dyndns.org to get a constant dns name. If it's still not working you might need to raise a bug report.

Actually, I'd suggest some of the hacks below to make it work a bit more like a proper configuration file format (rather than whatever json is). So there's commas at the start of every line so you can c&p or comment out any line you like without breaking the format. The "shared_folders" sections are completely independent. so you just repeat the section if you have another share or comment out if you want to remove one. The webui bit is on a single line so it's easy to comment out with the "/*" at the end of the line to work around the problem that the webui turns itself off when there's a share in the file. There's not much I can do about the "line noise" like collection of special characters that are required though. Wishlist request: Use simple format that's nowhere near as easy to get wrong! { "device_name": "My Test Host" ,"listening_port" : 12345 ,"storage_path" : "/home/btsync/syncstate" ,"check_for_updates" : false ,"use_upnp" : false ,"download_limit" : 0 ,"upload_limit" : 0 // , "webui" : { "listen" : "0.0.0.0:8888", "login" : "admin", "password" : "Pa55w0rD" } /* ,"shared_folders" :[{ "secret" : "R27WAH4LQCGDFOGS7NLQYLQPXW5TRCW5" ,"dir" : "/home/btsync/cats" ,"use_relay_server" : false ,"use_tracker" : true ,"use_dht" : true ,"search_lan" : true ,"use_sync_trash" : true }] ,"shared_folders" :[{ "secret" : "OOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOO" ,"dir" : "/home/btsync/zero" ,"use_relay_server" : false ,"use_tracker" : true ,"use_dht" : true ,"search_lan" : true ,"use_sync_trash" : false }] // End of WEBUI comment */ // ,"lan_use_tcp" : true /* ,"shared_folders" :[{ "secret" : "AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA" ,"dir" : "/home/btsync/zero" ,"use_relay_server" : false ,"use_tracker" : true ,"use_dht" : true ,"search_lan" : true ,"use_sync_trash" : false }] */ }

Peer discovery: BTSync uses several methods of peer discovery. Known hosts: this is the simplest; you enter a Port number and an IPaddress or DNS hostname and BTSync attempts to contact this host (This should also work with dynamic DNS if you wish) Search lan: this sends out multicast packets to the local lan (and rarely some connected ones) on port 3838. If a client receives once of these it attempts a normal connection to that peer. Tracker: BTSync sends the info hash of the share (basically the hash of the secret) to t.usyncapp.com. That host keeps a list of the IP:port pairs that have contacted it with that hash and gives them out to everyone interested. DHT: (Distributed Hash Table) this is very similar in concept to a tracker, except the hashs are not stored on one central server but distributed across all the peers in all the swarms. There does need to be a starter peer (one of which I expect is hosted by bittorrent.com) but once started the network is self supporting. (This one is real magic ) use_lan_tcp is NOT use for peer discovery; it is a way of speeding up connections to peers that have already been contacted with UDP (like turning off lan_use_encryption). The relay server is NOT used for peer discovery; it's for working around stupidly obstructive NAT and firewall devices.

This is basically what DHT is, if BTSync doesn't query the known hosts as DHT nodes that'll be a bug.

It's not too difficult use_upnp, this is for firewall maintenance when turned on it attempts to tell the firewall that BTSync's random port will want incoming connections. Turn on to improve connection reliability. search_lan, this tells BTSync that it's allowed to send out UDP multicast packets from port 3838 to port 3838. These packets will only ever traverse nearby networks, probably just the local LAN. It is not required for these packets to go past any firewall. Only one side needs this turned on for it to work. use_dht, send BTSync's random port, IP and info hash to the DHT network. Any (public) peer may search for the info hash and receive your IP and random port. use_tracker, send BTSync's random port, IP and info hash to the hard coded tracker. Any (public) peer may search for the info hash and receive your IP and random port. use_relay, the peer is allowed to make indirect connections via central relay machines. Only needed if use_upnp and "NAT punching" fail. check_for_updates, allows BTSync to phone home to ask what versions are available. lan_use_tcp, make BTSync use TCP for main data transfer to peers that are designated as LAN. The classification appears to include peers seen using "search_lan" and peers specified in the known peers list. This is a performance enhancing option, it does not remove the need for UDP to successfully connect. The TCP connection uses the same server port number as the UDP random port, the source port is random. lan_encrypt_data, encryption is an expensive operation. This is used to turn off encryption for peers that are classified as lan. I am uncertain if this is the same classification as "lan_use_tcp", but assuming it is data will NOT be encrypted to known hosts if this is turned off. use_known_hosts, known_hosts, these are a list of known hosts BTSync will attempt to connect to these even without any other peer discovery turned on. A UDP connection must be established to allow data transfer. This may require BOTH ends to be configured with the other to provide NAT punching. The "info hash" is an identifier for the share, it is related to the secret but cannot be used to discover the secret. Peer exchange; BTSync do not share information about known peers. If a peer cannot be discovered by any of the above methods a connection will not be initiated to it. So to create a pure star network turn off all the discovery options except for known peers and hard code the server IP:port in the clients. The server must be able to accept unsolicited UDP packets from anywhere, the use_upnp option may help with that, if not the random UDP port will have to be forwarded on the server's firewall. Turning all these off turns off all network access except for occasional DNS lookups for t.usyncapp.com. and r.usyncapp.com.. PS: I haven't checked but basic security rules would suggest that the relay will have to be "NAT punched", ie both ends will need to tell the relay that the connection is acceptable before any packets will flow. This means that it'll only work well with the tracker or perhaps the DHT.

And a star is just a mesh where some of the links are unused.If the file happens to be created on the server with very fast uplinks none of the other nodes will send anything to each other; BTSync WILL act like a star network. This is the advantage of Bram's bittorrent protocol it adapts to what it knows about the peers. What I (and I suspect now greenone83) am now proposing is to help the protocol by giving it the very important piece of information that it would be a really, really good idea for the big fast reliable node (with a cheap upstream) at IP:Port to have a copy of the file. This doesn't change how the rest of the network works. This doesn't impact the performance UNLESS that node has a worse upstream than you. It just changes the choice of which node to send the next piece to. If the node is busy a piece would be sent elsewhere, but considering the asymmetrical nature of ADSL lines this is quite unlikely.

No, Harold, you don't understand the maths here. The performance of bittorrent is not because any node can send to any other node. The same performance can be gotten in a centrally controlled scheme where Node A sends data to Node B who sends it to Node C who sends it ... and so forth. The important point is the 'chunking' or pipelining of the file transfer where Node B starts sending data to Node C as soon as it has any data. It does not wait for Node A to finish sending all the data before it starts sending to the next node. The multi-point processing is still very important, because it's the way that bittorrent is able to "simulate" this strict "bucket brigade" of data transfer with a random and sometimes uncooperative collection of heterogeneous peers. This also explains why "super-seeding" is beneficial when starting up a swarm; for most swarms, when there is only one seeder, the upload speed of that seeder is the limiting factor on how fast the data can get into the rest of the peers. If the initial seeder makes sure they only send each block into the swarm once they are acting much more like "Node A" in the perfect scenario above. The problem with "super-seeding" is that some peers are unreliable and will lose blocks that are sent to them. They not only lose the blocks for themselves but also for the rest of the swarm. OTOH if the initial peer can "super-seed" to a high performance "server" that server will be able to send out more than one copy of every block it receives. This improves reliability and may improve speed if some of the other peers have a poor upload performance. But, your last paragraph is right on the money. There is no benefit to downloading from a central server, unless, of course, that's where the next block is. PS: I've actually done that pipelined scheme before by running a pair of "netcat" commands and a "tee" command on each peer. You need a good switch, but when it works it's very very quick. UDPcast is just as quick though, and will work with a hub.

He didn't say, but, IIRC, *.95 to *.116 lost all the shares due to the change in the way secrets were handled. But we keep coming back to "ALPHA SOFTWARE". To me this means you should completely remove the old version before installing the new version. Unless you happen to be testing auto update, of course. BTW: BTSync is nice in that way; so far it uninstalls very cleanly. BTW2: I have, of course, tried updating in place without clearing out things. It seems to mostly work but you're likely to have old (lets say) "rubbish" in your sync.dat file, left over from old bugs, and this "rubbish" can't always be clean out by the new version.

Actually, greenone83 isn't completely wrong. BTSync is based on a bittorrent engine, if it works perfectly a newly created file on one peer will be sent one piece at a time to another peer. This peer will send each piece on to the next peer as it's received, and so forth. This means the total time to send the file is the time it takes the seeder to upload the file plus the time it takes every other peer to upload the last piece to it's next peer. This is a lot faster than uploading the file to a traditional server then waiting for every peer to download it using the server's bandwidth. BUT, the initial seeder isn't perfect. It may upload a piece more than once. To prevent this a mode where one of the peers is the designated seeder would improve speed. Ie if the designated seeder doesn't have a full copy of a file, and you do, you should only send pieces to that peer. If you're a leecher you work as normal, passing pieces to anyone who wants it. If you're the designated seeder, again you work in the normal bittorrent fashion (except perhaps, you're a bit more trusting and never blacklist a peer). The difference would often be small, but if some of the peers are unstable it could make a huge improvement. PS: There are of course, 101 other reasons that one particular known peer must have a copy ... it's the only one that always turned on ... it's the one with the tape drive ... it's the office ... etc etc.

Yup, Here's the start of a file, slightly pretty printed... ".fileguard" = C8AA8024DA5F69AB2EE3EDC129848F892EB0A424 version = "1.0.130" device = BTSync folders = ( { path = "/home/btsync/data/cats" secret = R27WAH4LQCGDFOGS7NLQYLQPXW5TRCW5 delete_to_trash = 1 use_dht = 1 use_lan_broadcast = 0 use_relay = 0 use_tracker = 1 use_known_hosts = 0 known_hosts = ( ) peers = ( { Like I said, it's a bonehead mistake. ps: Doh!