Noel Hibbard

Members
  • Content Count

    18
  • Joined

  • Last visited

About Noel Hibbard

  • Rank
    Member
  1. This worked for me on Win8.1x64. { "storage_path" : "c:/BTSync", "use_gui" : true, "webui" : { "listen" : "127.0.0.1:8888", "login" : "<someusername>", "password" : "<somepassword>", "api_key" : "<someAPIkey>" }}Then save this file in this path (path and filename are important): "%UserProfile%\AppData\Roaming\BitTorrent Sync\sync.conf" Then launch BTSync without any command line options.
  2. +1 To use this for business we would need this. So far I have used nils solution but it is only useful if the end user is totally ignorant and doesn't know about the hidden archive folder. You just have to hope they delete the folder thinking it is empty.
  3. Yes you are right, if you look at the data in my packets it should look something like this: d<RecordLength>:<Record><RecordLength>:<Record>e But you can see in my data the packets are truncated so it is something like: d4:test10:012345 When it should look something like: d4:test10:01234567890e I am capturing at the source which is odd, what could possibly be manipulating the packets before they leave the machine? For the other machines that I tested I was just capturing traffic from a remote machine. So hardware in between could have been a factor.
  4. I have duplicated this situation on three machines on the office LAN so far. I just tested it on my LAN at home and none of the machines have this (malformed packet) problem. How could the network cause BTSync to build malformed packets?
  5. I just did some closer examination of the broadcast traffic with Wireshark and I am seeing some malformed UDP packets. The length of the data on some of these packets doesn't match the payload header. Some of these multicast packets are truncated. Here is a snippet of a few good packets along with a few bad ones: https://dl.dropbox.c...k/Sample.pcapng Right now I have 4 shares. If I have "Search LAN" enabled on all of them I get packet loss and in Wireshark I see these truncated multicast packets. I have a filter set in Wireshark to ip.dst == 239.192.0.0 so I can easily see the stuff I am cons
  6. When you ask if I have any machines with two NICs I assume you mean machines running BTSync. If so, no. There are however a bunch of machines on the network with two NICs and possibly even both connected (WiFi and Ethernet) but none of those machines are running BTSync. At this point there is only one machine on this network running BTSync and that is my own. The only other place I have BTSync running is at the house on another subnet which is connected via IPSec. I shut down the IPSec tunnel which broke the peer that was running at the house but I figured it would recover and start routing ov
  7. That is a good idea. So I shutdown my tunnel and now that peer can't be reached (without the relay). When looking at the debug log I see these lines: [2013-08-28 12:47:30] Peer 7: 76.123.123.123:38820 003B8615EF1D57ED65734960A43EB8C9DA0D3222 [2013-08-28 12:47:30] Peer 7: local IP 10.18.1.1:49525 I masked my public IP in this log but you can see the port number on the public IP is different from the private. 49525 is the port that I have set for the listening port and is auto forwarded by UPnP on my router. I have no clue where port 38820 came from and how it expects people to communicate on t
  8. Okay... I think I am getting somewhere. As I said, packet loss is still happening even when syncing is paused (not to be confused with idle). So with syncing paused I decided to take a look at the traffic with Wireshark and I see that the only traffic going on now is broadcasts and what looks like some talk with trackers. So I then went into all my shares and disabled the "Search LAN" option. So now while syncing is paused I am only seeing traffic with trackers. The broadcast traffic stopped. After making that change I saw the packet loss go away. To be sure I left it for about 10mins (really
  9. I would love to see the creators of TuneShell and BTSync collaborate.
  10. I just tested the iOS client and it does this. I can sync with an entire music library and browse through the folders and click on the files I want it to download. If I no longer want that file on the phone I can swipe the file to delete it (Make sure you are using a read-only hash before deleting though). I would love to see something like this come to the other platforms.
  11. Another interesting note. The packet loss persists even when syncing is paused. It only stops if I remove all the shares or close BTSync.
  12. Yeah I understand ICMP isn't guaranteed, the thing is I will be doing something like remote controlling another machine where it is very obvious that packets are dropped because the whole screen freezes for a few seconds and then I look over at my second monitor to see PingPlotter showing a bunch of red. Then it recovers and my RDP session starts responding again. Some goes for websites. I click a link and it just sits. Or if I have a file transfer going (via HTTP) and it will just hang for a few secs and then resume. Shut down BTSync and all goes back to normal. I thought maybe it was related
  13. One thing I want to add to this. I am using PingPlotter from another machine on our network to monitor the packet loss on my machine. This packet loss is all local. This isn't a case of flooding all my outgoing bandwidth or anything like that.
  14. I don't have any problems transferring files. The problem is packet loss on my whole computer. BTSync works fine otherwise. This isn't the first machine I have experienced this on either. I was running it on a server that is running Server 2008 R2 x64 and it was doing the same thing. It would drop packets so bad you could hardly even connect to the machine via RDP. As soon as you would kill BTSync the machine would go back to normal. What is odd too is BTSync causes me to drop packets even when it is totally in sync and idle. BTSync isn't creating any CPU activity or disk activity either. I ha
  15. I have been having very bad packet loss on my machine the past 3 weeks and have tried everything under the sun to find the cause. New cable, different port on the switch, different NIC, firewall changes and on and on. I finally figured out what was causing the problem. BTSync! As soon as I close BTSync the loss goes away. Start it back up and I am back to lost packets. I am not talking about a packet here and there, I am talking about 60 - 70% loss. I am extremely excited to find the source but not be able to use BTSync anymore. Has anyone ever experienced this and if so, any ideas? This is on