• Content Count

  • Joined

  • Last visited

About TheEastWind

  • Rank
  1. In reference to this earlier entry of mine: I have tested setting the MTU to the lower value (the one set for the VDSL line by my ISP) on all machines and, lo and behold, everything works like a charm. So this is definitely a problem with BTSync's handling of MTU fragmentation on the UDP protocol. Will anything be done about this?
  2. Cool, thanks! My bad, I should have expanded on this; when I first started looking into the possibility of encrypted my system drive, I found a number of sources online which stated that TrueCrypt'ing SSDs had some detrimental effects when it came to wear.
  3. Please add an option to store the configuration files in a custom folder. The fact that settings - and thus the secrets! - are stored in %APPDATA% (on Windows) is a huge security problem. My laptop has an SSD and thus I can't encrypt the system folder with TrueCrypt. For similar reason, my home-built NAS system has a non-encrypted system drive. If someone were to get their hands on those systems (however unlikely), they would not get data straight away - all data drives are TrueCrypt'ed - but they would get my secrets. This could be solved by allowing users to move the settings folder to a cus
  4. Not being familiar with the BitTorrent protocol per se, is there a compelling reason why UDP is used for non-data transmissions? I'd be very interested in whether this is a UDP-specific problem. Nonetheless, it would appear you are correct. For the record, after some *more* tinkering, I found out my router connects via "routed bridge encapsulation" - the VDSL line here is part of a pilot project in a small village, so I assume the VDSL line is simply the link and everything else is handled by common ethernet standards, since the router IP is obtained via DHCP.
  5. Making BTSync use TCP packets for LAN did not help, I believe this is because, for status messages, it still uses UDP (as seen in Wireshark). So it would appear BTSync cannot handle UDP fragmentation well. In no way am I an expert or even knowledgeable about networking specifics so I have no idea what could be done here. It's not even clear to me on what level the fragmentation occurs or where there might be some possible influence over fragmentation. But this seems like a problem - there will probably be more people with little influence over their MTUs and no influence over the networking se
  6. After some very extensive tinkering, I believe this might be an MTU problem. I managed to find out how that the problematic router (B ) connects to the internet via bridging with an MTU of 1300. Why they have set this weird value, I have no idea. This idea is supported by the fact that syncing very small files or very few files works - if I just add one or two files to a synced folder and they are small, syncing works. Addition of a big file on the non-problematic network is propagated to the problematic network, but the transfer is very, very slow (around 0,1 kb/s). Addition of many files (sa
  7. I posted a month or so ago about an issue I had where syncing to a specific network didn't work. Since then I have isolated the problem as depending on just that network, but I'm really at a loss here. Here's the scenario: Syncing TO the network where "server" (family's central backup server, I live in another city) is does NOT work. It works between all other computers I can get my hands on, even with my university computer that's behind a huge firewall, sitting in a huge university network, etc. Topology: Network A: can sync to and from all tested computers, with the exception of TO network
  8. Fixed it: slightly embarrassed about this, but settings "lan_use_tcp" to true fixed it. I have to admit I never even thought this might be the issues as I couldn't see any reason for TCP to pass through the NAT/firewall, but not UDP.
  9. Sorry for the delay. My MTU is 1500 anyway. Both connections are extremely stable VDSL2 connections with not troubles outside of this whatsoever. I have disabled the VPN connection, disabled both Windows firewalls, to no avail. I double-checked the NAT port forwarding, tried out ĀµTorrent on both computers, using the same ports, which works fine. Interestingly, after some messing around, I found out that the sync works one way - but not the other. That is, files from one network (machine called boreas) are being synched to the other (machine called atlas), but not the other way around. Both cli
  10. Hi everyone, I'm getting very slow speeds over a VPN set up between two routers (2x Fritz!Box 7390). The routers set up a VPN between them so I get the subnets 192.168.0.x and 192.168.1.x. I have set up appropriate NAT holes, even though for the VPN that shouldn't matter I'm getting speeds in the 2 kb/s range, sometimes changes aren't even propagated to other clients. As far as I can tell from the official documentation, the VPN uses IPSec/IKE with AES encryption. I have no real influence on any parameters of the VPN connection. All other applications work fine over VPN. I've seen two similar