rdebath
-
Posts
289 -
Joined
-
Last visited
-
Days Won
6
Posts posted by rdebath
-
-
Least open ports for you are using ONLY the tracker and the relay.
Open your UDP port, your host to the tracker and relay IPs port 3000.
Allow solicited replies from same.
Nothing else. This will probably be slow and the peers will still attempt (and fail) to make direct connections.
It's better if you configure UDP to be just like TCP normally is, ie: allow all solicited replies.
RE: TCP ...
Posted 12 May 2013 - 07:09 AM
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.
- 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)
-
- Block TCP at the firewall it's only useful for local peers.
- You don't need to allow packets to port 3000 on your machines; the tracker and relay are on port 3000.
- Turn off DHT, you are not giving it sufficient access to do anything useful.
- Make sure that peers behind the same firewall have different ports.
- Don't run it as root.
Otherwise, if you want to completely lock down the firewall, it's a case of choosing which peer discovery option you want to use, allowing the connections for that method and disabling the others.
BTW: 'Ingress' and 'Egress' are vague terms that mean something to your specific firewall vendor/script etc. Your log messages are obviously "iptables" messages but these words don't mean anything for iptables.
PS: Iptables connection tracking will be kept alive by BTSync's chatter, if you make significant changes you may have to turn off ALL peers for at least 4 minutes to allow the tracking to clean up. (Or add NOTRACK rules to the raw table)
- Block TCP at the firewall it's only useful for local peers.
-
Sorry, I meant change one of them (user or password) by one character.
-
I guess you're using DHT. The remote for DHT is whatever some random person on the internet configured.
Locally BTSync opens ports 3838 for local multicast, your configured port on UDP for internet connectivity and your configured port on TCP for local connectivity. Additionally, if configured, it opens the http(s) port for the web GUI.
Minimum, firewall requirements are here. (as noted in the unofficial FAQ) Maximum firewall requirements are basically the configured UDP port open for unsolicited packets from any address and any port over 1024.
-
I would really love to have see btsync use IPv6.
Some of the locations my computers are located provide native routed IPv6 addresses for each computer but only a single NAT IPv4 address against the internet. Often the IPv4 NAT connection does not allow UPNP, so relaying is required. Having IPv6 would be really nice.
IPv6 would be good, but NAT (without UPnP) does NOT mean that relaying is required.
If ONE side has UPnP or a mapped port a direct connection will be possible (if any is).
If BOTH sides have "good NAT" a double NAT punch is possible and a direct connection will be made.
Ciscos (usually?) have bad NAT that scrambles the port numbers.
-
For all intensive purposes your OS would see the Synced folder as if it was a local actual folder but it would actually be empty and showing the contents of a remote folder.
BTSync is NOT a network file system. It's a tool for copying files between machines.
You OS already has network file systems suitable for your use case, however, it is likely that your internet connection is too cheap for the performance that you want to see.
Note: you may get better performance if you use an ISCSI drive with aggressive local caching, but that will only allow a single machine to access the drive.
-
So my current wish: Different setting profiles based on "whatever Windows uses".
Windows uses the ip address, netmask and default route to choose one of three profiles (public, private and domain)
You can add a rule to the Windows firewall to block BTSync when you're on a 'public' network already.
Possibly something in the installer to add these rules automatically would be nice.
-
Before about 1.1.12 the DHT module was not turned off when the flag was turned off on all the shares. It would still respond to external DHT requests but would not initiate a connection to DHT. This has changed.
There are plenty of AV solutions that run on MAC and Linux.
They have 99.999% Windows signatures.
There are maybe six Mac signatures, half of them are variants, none of them are real viruses, just trojans.
From what I can tell the last time the Mac signatures were updated was in May 2011, that extra signature was described as a "bumper crop" by Intego.
BUT "phishing" is any-platform, some AV traps this stuff as well and calls it a virus to inflate the stats; most people call it spam.
-
apt-get only works as root.
If you want to install it as a user I'd say get the bare executable direct from Bittorrent (here) and start it with an "@reboot" line in the user's personal crontab.
-
As it's a network server it's not the best idea to run btsync as root. It doesn't use anything that requires root access.
Specifically, BTSync does not (as yet) understand users so will create all files as the user that it's run, it cannot change the user ID.
So you need to run BTSync as the user & group that you want the files to have. (Don't forget to set your umask too).
-
Ignore the glibc23 version unless the normal version gives you errors about "GLIBC_2.4 not found".
Current glibc versions are around 2.11 IIRC.
It's possible for the x64 and i386 versions to run on machines that are officially each other.
I'm running the x64 version on a machine that's mostly i386; I can do this because my kernel is x64 and I have a few x64 libraries.
Normally the other way round is even easier.
Likewise on Windows. All 64 bit versions of windows have a full set of standard 32bit exe's & libraries; including XP64sp2 which has the executables libraries from XP32sp3 (or later) so only the 32 bit version has been released.
NB: If you upgrade to 1.1.22 you'll have to upgrade all peers from 1.0.134 because the versions are completely incompatible.
-
The BTSync exe will be shutdown with "kill -15". This is the normal method of stopping btsync so it will be fine.
A poweroff without shutting down is never a good idea, however, 1.1.X versions should be more resilient against this because they're using a database to store their metadata. Versions 1.0.x and earlier are more likely to lose information about the current state of the sync because they only save (all of) their metadata every few minutes.
-
It should merge the two directories without complaint.
If unison hasn't been syncing timestamps it'll do those and probably create a lot of copies in the .SyncTrash directory.
As it's Alpha software it may, possibly, eat the lot. If you're using a version before 1.0.130 it can eat the whole machine.
-
The version 1.0.134 is the version on the main servers and the version on the 'do I have the most recent version' check.
That version is incompatible with the version 1.1.22 available in this forum. Even if you remove the initial "A" from a 1.1.22 generated 160 bit secret they won't talk to each other.
As this is Alpha software it's a poor idea to mix versions as there are likely to be significant changes between versions. Between 1.0.134 and 1.1.22 there are a lot of very significant changes.
Please remember "Alpha Software" means "It will break and it will eat your babies (pictures)".
-
It's on the default port with the default login and default password ... you sure your browser hasn't remembered the password/cookie.
-
Nice config file; works perfectly.
-
I think this is okay, if you'll count the characters you'll see there's actually 33 of them, that's one more than in V1.1.15.
I suspect the first character is now a 'secret type' code, like the 'R' on the 33 character read only secrets.
-
You have the HTTP port and the BTSync data port as the same number.
This is not allowed because the BTSync data port is open on TCP and is even used sometimes.
change this: "listening_port" : 8888,
to this: "listening_port" : 3000,
-
@rdebath
Thanks I will try your idea out. What do you mean by "... they'll bounce the file off you"
If they cannot talk to each other, but both of them can talk to you all the files in the share will be sync'd. BUT all the data will have to be passed through your peer.
Hi,
With the example of this post (BTSync port = 20001 and peer port = 20002), what is the firewall configuration if I want to use BTSync with known peers and direct connections only?
20001 to 20002 and 20002 to 20001 only?
If both peers know each other and both firewalls are well behaved only outbound connections have to be opened on both firewalls. The 'inbound' half will be covered by the "NAT punching". If it's not possible for both peers to be completely predictable then at least one of them must be able to accept an incoming connection on it's port.
And yes, the only connection needed is UDP hosta:20001 <-> hostb:20002.
-
In case someone else searches for this you could setup a tunnel with your ssh connection. Get ssh to tunnel your localhost port 8888 to port 8888 on the remote machine.
$ ssh -L 8888:127.0.0.1:8888 remoteserver
then in another xterm
$ firefox http://localhost:8888
-
I have clicked the wrong systray logo a couple of times now ...
-
They shouldn't be able to point at the same folder; looks like the developers missed a trick with their '.SyncID' file.
But they can't stop you installing it twice. All they can do is make it even more annoying to do the use cases that actually require two installs.
-
Just try it. It should just work. BTSync uses NAT punching for firewalls that aren't "subservient" to it.
Only if the firewall is actively uncooperative, for example blocking all UDP traffic or scrambling port numbers, do you need to start opening UDP ports. (Special 'tricks' might need it too)
-
If you put in the correct IP:port for known hosts and your firewalls allow you to connect you should get lines like this ...
[20130528 20:31:12] Got ping (broadcast: 0) from peer 59.13.171.20:27126 (70461140ED1FEA223F85CE0260B0BBB64E95015D) for share 0FDBBAC4843BCD58A454D2803859501BA27AE32B
BTW: The share id is safe to post as it's the CLIP160(SHA2256(CLIP160(SHA2256(Secret))).
If you don't want to post any logs here try reading the other sticky threads ie: If you have SyncApp issue
)
Please add the following:
in Sync General Discussion
Posted
Re a 'native' client, I would much prefer the other versions run as services/daemons or whatever and the web client becomes the normal client.
A 'web connected' "native client" might be nice for people who insist on features like a systray icon.But it should not be limited to connecting to the service on this computer. It should also be able to provide the same features when connected to a service running on a NAS box without the service even being installed on 'this machine'.
PS: Obviously, if a "native client" is connecting to a service on this machine it has the ability (if not the security authority) to read the service configuration and connect without asking the user for a password.