• 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 custom location, which could then be encrypted.
  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 settings and hardware. Is there anything that can be done at the BTSync level here?
  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 (say, around 5-6) is not propagated to the problematic network and every subsequent change in the filesystem of either computer goes unnoticed by the other one. This is really weird stuff. So I'm going to try and get ahold of a technician at my ISP and try to explain the problem to them to get them to change their MTU, but you can imagine the odds of success on this. Meanwhile, I'm wondering if this is not *also* a BTSync problem, i.e. how BTSync handles incoming packets? When they are fragmented due to weird MTUs? No other application has this issue.
  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 B ("server"). Network B: can sync TO all tested computers, but sees no changes made on other computers. "Sync to" means changes made on this computer are propagated "instantly" to other computers. Both use the same router (Fritz!Box 7390) BUT the one in network B has been modified somehow by the ISP and the VDSL connection is a permanent one - i.e. no interruption and no IP change. My suspicion is that all lines from our area are grouped (masquaraded) somehow, but then, I have a DynDNS account set up pointing to that router and it works fine, VNC ports are forwarded fine, BitTorrent works fine, etc. I'm really at a loss here. The kicker: even IF the ISP was somehow filtering some traffic, the two routers have a permanent IPSec connection between them, that is, network A and B appear to all computers in it to be two related subnets. So all BTSync traffic is encapsulated in encrypted IPsec packets. But sync to network B doesn't work regardless of whether IPSec is activated. Even better: If I set up a synced folder between network A and B and add some files to it on A; like I said, B will not notice (it doesn't even show up in the History on "B"). But if I let it sit long enough, somehow B will "notice" and sync some files, but not others, then somehow notice the others, set up transfers with 0kb/s which work when I enable TCP for LAN. Then I add some more files on A, and again B doesn't notice. I have absolutely NO clue what's going on. I had the router on B dump out Wireshark captures, and they show the packets arriving fine, so the ISP apparently isn't filtering. Here are the logs: sync_atlas_1.log and sync_server_1.log are from a test where I added files on network B ("server"), and they were immediately sent to atlas, as seen in the logs. sync_atlas_2.log and sync_server_2.log are from a test where I added files on network A ("atlas"), and network B did not notice until later (around 10:33 in the log, twenty minute after logging started and the files were added), sent SOME of the files and the remainer only (not on the logs) when I enabled LAN TCP.
  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 clients propagate changes, initiate transfers, but the transfers only work one way; the other way around, the transfer just sits there in the Transfers tab with 0.0kb/s speeds. Third test: Got my sister to install on her computer (yet another network). Sync works fine between hers and mine, she can sync fine with the network containing atlas, but I get nothing from atlas. In summary: Three networks (atlas, boreas, other). Atlas & Boreas configured with NAT forwarding and disabled firewalls, other network as-is. Boreas->Atlas, Boreas->Other, Other->Boreas and Other->Atlas work fine. Atlas->Boreas doesn't. I have sent all this (and the log files) in an email to
  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 threads (one with the exact same routers), but no replies. Thanks and regards, TheEastWind