BiglySoftware / BiglyBT

Feature-filled Bittorrent client based on the Azureus open source project
https://www.biglybt.com
GNU General Public License v2.0
1.59k stars 152 forks source link

LAN Peer finder isn't working #1933

Closed TheBestPessimist closed 10 months ago

TheBestPessimist commented 3 years ago

image

2 BBT clients:

LAN does not link those 2 clients, so i'm downloading the torrents via the internet.

As you can see from this picture, qBT has no issue finding LAN peers: image

I also have this error from torrent console, but idk if it's of any use:

[22:59:44.451] {plug} [StartStopRules] recalc seeding rank.  old/new=0/1000009994;  | Torrent: 'test torrent 1GB - 1'
[22:59:44.464] {plug} [StartStopRules] >> DL state=D;shareRatio=16;numW8tngorDLing=5;maxCDrs=999999;forced=N;actvDLs=6;maxDLs=0;ActDLing=N;globDwnRchd=Y;hgherQd=N;isCmplt=N;   | Torrent: 'test torrent 1GB - 1'
[22:59:44.464] {plug} [StartStopRules] NOT queuing: maxDownloads = 0;   | Torrent: 'test torrent 1GB - 1'
[22:59:44.464] {plug} [StartStopRules] << DL state=D;shareRatio=16;numW8tngorDLing=6;maxCDrs=999999;forced=N;actvDLs=6;hgherQd=N;ActDLing=N;    | Torrent: 'test torrent 1GB - 1'
[22:59:54.760] {stderr} DEBUG::Sun Dec 27 22:59:54 EET 2020::com.biglybt.net.udp.uc.impl.PRUDPPacketHandlerImpl::receiveLoop::764:
[22:59:54.761] {stderr}   java.net.SocketException: Network dropped connection on reset: no further information
    at java.base/sun.nio.ch.DatagramChannelImpl.receive0(Native Method)
    at java.base/sun.nio.ch.DatagramChannelImpl.receiveIntoNativeBuffer(DatagramChannelImpl.java:747)
    at java.base/sun.nio.ch.DatagramChannelImpl.receive(DatagramChannelImpl.java:725)
    at java.base/sun.nio.ch.DatagramChannelImpl.trustedBlockingReceive(DatagramChannelImpl.java:703)
    at java.base/sun.nio.ch.DatagramChannelImpl.blockingReceive(DatagramChannelImpl.java:630)
    at java.base/sun.nio.ch.DatagramSocketAdaptor.receive(DatagramSocketAdaptor.java:239)
    at java.base/java.net.DatagramSocket.receive(DatagramSocket.java:569)
    at com.biglybt.net.udp.uc.impl.PRUDPPacketHandlerImpl.receiveFromSocket(PRUDPPacketHandlerImpl.java:1785)
    at com.biglybt.net.udp.uc.impl.PRUDPPacketHandlerImpl.receiveLoop(PRUDPPacketHandlerImpl.java:688)
    at com.biglybt.net.udp.uc.impl.PRUDPPacketHandlerImpl$3.run(PRUDPPacketHandlerImpl.java:173)
    at com.biglybt.core.util.AEThread2$threadWrapper.run(AEThread2.java:317)
[22:59:54.762] {stderr} 
[22:59:56.962] {stderr} DEBUG::Sun Dec 27 22:59:56 EET 2020::com.biglybt.net.udp.uc.impl.PRUDPPacketHandlerImpl::receiveLoop::764:
[22:59:56.963] {stderr}   java.net.SocketException: Network dropped connection on reset: no further information
    at java.base/sun.nio.ch.DatagramChannelImpl.receive0(Native Method)
    at java.base/sun.nio.ch.DatagramChannelImpl.receiveIntoNativeBuffer(DatagramChannelImpl.java:747)
    at java.base/sun.nio.ch.DatagramChannelImpl.receive(DatagramChannelImpl.java:725)
    at java.base/sun.nio.ch.DatagramChannelImpl.trustedBlockingReceive(DatagramChannelImpl.java:703)
    at java.base/sun.nio.ch.DatagramChannelImpl.blockingReceive(DatagramChannelImpl.java:630)
    at java.base/sun.nio.ch.DatagramSocketAdaptor.receive(DatagramSocketAdaptor.java:239)
    at java.base/java.net.DatagramSocket.receive(DatagramSocket.java:569)
    at com.biglybt.net.udp.uc.impl.PRUDPPacketHandlerImpl.receiveFromSocket(PRUDPPacketHandlerImpl.java:1785)
    at com.biglybt.net.udp.uc.impl.PRUDPPacketHandlerImpl.receiveLoop(PRUDPPacketHandlerImpl.java:688)
    at com.biglybt.net.udp.uc.impl.PRUDPPacketHandlerImpl$3.run(PRUDPPacketHandlerImpl.java:173)
    at com.biglybt.core.util.AEThread2$threadWrapper.run(AEThread2.java:317)
[22:59:56.963] {stderr} 
[23:00:07.484] {tracker} Tracker Announcer is sending an update Request;    | Torrent: 'test torrent 1GB - 1'
[23:00:07.484] {tracker} Tracker Announcer is Requesting: http://192.168.87.69:16969/announce?info_hash=%F5p%17%B3U%0B%DCX%96Kxi%F2M%17%5D%CB%A5%A2%9E&peer_id=-BI2601-kZyDDorYCSee&requirecrypto=1&port=34374&azudp=34374&uploaded=0&downloaded=0&left=795742376&corrupt=0&numwant=100&no_peer_id=1&compact=1&ip=192.168.87.69&key=ISAq262L&azver=3;   | Torrent: 'test torrent 1GB - 1'
[23:00:07.484] {tracker}     HTTP: url adjusted to http://127.0.0.1:16969/announce?info_hash=%F5p%17%B3U%0B%DCX%96Kxi%F2M%17%5D%CB%A5%A2%9E&peer_id=-BI2601-kZyDDorYCSee&requirecrypto=1&port=34374&azudp=34374&uploaded=0&downloaded=0&left=795742376&corrupt=0&numwant=100&no_peer_id=1&compact=1&ip=192.168.87.69&key=ISAq262L&azver=3;  | Torrent: 'test torrent 1GB - 1'
[23:00:07.486] {tracker} Tracker Announcer [http://192.168.87.69:16969/announce] has received : d9:azcompacti2e8:completei0e10:downloadedi0e10:incompletei1e8:intervali120e12:min intervali120e5:peerslee;  | Torrent: 'test torrent 1GB - 1'
[23:00:07.486] {tracker} Received from announce: 'interval' = 120; 'min interval' = 120;    | Torrent: 'test torrent 1GB - 1'
[23:00:07.486] {tracker} ANNOUNCE SCRAPE1: seeds=0 peers=1;     | Torrent: 'test torrent 1GB - 1'
[23:00:07.486] {tracker} ANNOUNCE CompactPeers2: num=0;     | Torrent: 'test torrent 1GB - 1'
[23:00:07.486] {plug} [StartStopRules] somethingChanged: new scrapeResult S:0;P:1;  | Torrent: 'test torrent 1GB - 1'
[23:00:07.486] {tracker} Next tracker announce (unadjusted) will be in 110s;    | Torrent: 'test torrent 1GB - 1'
[23:00:07.486] {tracker} MIN INTERVAL CALC: override, perc = 50: 55;    | Torrent: 'test torrent 1GB - 1'
[23:00:07.486] {tracker} MIN INTERVAL CALC: min_interval=120, interval=110, orig=110, new=61, added=1, perc=2.0;    | Torrent: 'test torrent 1GB - 1'
[23:00:07.486] {tracker} Next tracker announce (adjusted) will be in 61s;   | Torrent: 'test torrent 1GB - 1'
[23:00:08.473] {plug} [StartStopRules] recalc seeding rank.  old/new=1000009994/1000009994;     | Torrent: 'test torrent 1GB - 1'
[23:00:08.475] {plug} [StartStopRules] >> DL state=D;shareRatio=16;numW8tngorDLing=5;maxCDrs=999999;forced=N;actvDLs=6;maxDLs=0;ActDLing=N;globDwnRchd=Y;hgherQd=N;isCmplt=N;   | Torrent: 'test torrent 1GB - 1'
[23:00:08.475] {plug} [StartStopRules] NOT queuing: maxDownloads = 0;   | Torrent: 'test torrent 1GB - 1'
[23:00:08.475] {plug} [StartStopRules] << DL state=D;shareRatio=16;numW8tngorDLing=6;maxCDrs=999999;forced=N;actvDLs=6;hgherQd=N;ActDLing=N;    | Torrent: 'test torrent 1GB - 1'
[23:00:09.795] {stderr} DEBUG::Sun Dec 27 23:00:09 EET 2020::com.biglybt.net.udp.uc.impl.PRUDPPacketHandlerImpl::receiveLoop::764:
[23:00:09.796] {stderr}   java.net.SocketException: Network dropped connection on reset: no further information
    at java.base/sun.nio.ch.DatagramChannelImpl.receive0(Native Method)
    at java.base/sun.nio.ch.DatagramChannelImpl.receiveIntoNativeBuffer(DatagramChannelImpl.java:747)
    at java.base/sun.nio.ch.DatagramChannelImpl.receive(DatagramChannelImpl.java:725)
    at java.base/sun.nio.ch.DatagramChannelImpl.trustedBlockingReceive(DatagramChannelImpl.java:703)
    at java.base/sun.nio.ch.DatagramChannelImpl.blockingReceive(DatagramChannelImpl.java:630)
    at java.base/sun.nio.ch.DatagramSocketAdaptor.receive(DatagramSocketAdaptor.java:239)
    at java.base/java.net.DatagramSocket.receive(DatagramSocket.java:569)
    at com.biglybt.net.udp.uc.impl.PRUDPPacketHandlerImpl.receiveFromSocket(PRUDPPacketHandlerImpl.java:1785)
    at com.biglybt.net.udp.uc.impl.PRUDPPacketHandlerImpl.receiveLoop(PRUDPPacketHandlerImpl.java:688)
    at com.biglybt.net.udp.uc.impl.PRUDPPacketHandlerImpl$3.run(PRUDPPacketHandlerImpl.java:173)
    at com.biglybt.core.util.AEThread2$threadWrapper.run(AEThread2.java:317)
[23:00:09.796] {stderr} 
[23:00:13.252] {stderr} DEBUG::Sun Dec 27 23:00:13 EET 2020::com.biglybt.net.udp.uc.impl.PRUDPPacketHandlerImpl::receiveLoop::764:
[23:00:13.252] {stderr}   java.net.SocketException: Network dropped connection on reset: no further information
    at java.base/sun.nio.ch.DatagramChannelImpl.receive0(Native Method)
    at java.base/sun.nio.ch.DatagramChannelImpl.receiveIntoNativeBuffer(DatagramChannelImpl.java:747)
    at java.base/sun.nio.ch.DatagramChannelImpl.receive(DatagramChannelImpl.java:725)
    at java.base/sun.nio.ch.DatagramChannelImpl.trustedBlockingReceive(DatagramChannelImpl.java:703)
    at java.base/sun.nio.ch.DatagramChannelImpl.blockingReceive(DatagramChannelImpl.java:630)
    at java.base/sun.nio.ch.DatagramSocketAdaptor.receive(DatagramSocketAdaptor.java:239)
    at java.base/java.net.DatagramSocket.receive(DatagramSocket.java:569)
    at com.biglybt.net.udp.uc.impl.PRUDPPacketHandlerImpl.receiveFromSocket(PRUDPPacketHandlerImpl.java:1785)
    at com.biglybt.net.udp.uc.impl.PRUDPPacketHandlerImpl.receiveLoop(PRUDPPacketHandlerImpl.java:688)
    at com.biglybt.net.udp.uc.impl.PRUDPPacketHandlerImpl$3.run(PRUDPPacketHandlerImpl.java:173)
    at com.biglybt.core.util.AEThread2$threadWrapper.run(AEThread2.java:317)
[23:00:13.252] {stderr} 
[23:00:17.496] {plug} [StartStopRules] >> DL state=D;shareRatio=16;numW8tngorDLing=5;maxCDrs=999999;forced=N;actvDLs=6;maxDLs=0;ActDLing=N;globDwnRchd=Y;hgherQd=N;isCmplt=N;   | Torrent: 'test torrent 1GB - 1'
[23:00:17.496] {plug} [StartStopRules] NOT queuing: maxDownloads = 0;   | Torrent: 'test torrent 1GB - 1'
[23:00:17.496] {plug} [StartStopRules] << DL state=D;shareRatio=16;numW8tngorDLing=6;maxCDrs=999999;forced=N;actvDLs=6;hgherQd=N;ActDLing=N;    | Torrent: 'test torrent 1GB - 1'
[23:00:18.975] {plug} [StartStopRules] >> DL state=D;shareRatio=16;numW8tngorDLing=5;maxCDrs=999999;forced=N;actvDLs=6;maxDLs=0;ActDLing=N;globDwnRchd=Y;hgherQd=N;isCmplt=N;   | Torrent: 'test torrent 1GB - 1'
[23:00:18.975] {plug} [StartStopRules] NOT queuing: maxDownloads = 0;   | Torrent: 'test torrent 1GB - 1'
[23:00:18.975] {plug} [StartStopRules] << DL state=D;shareRatio=16;numW8tngorDLing=6;maxCDrs=999999;forced=N;actvDLs=6;hgherQd=N;ActDLing=N;    | Torrent: 'test torrent 1GB - 1'
[23:00:20.493] {plug} [StartStopRules] >> DL state=D;shareRatio=16;numW8tngorDLing=5;maxCDrs=999999;forced=N;actvDLs=6;maxDLs=0;ActDLing=N;globDwnRchd=Y;hgherQd=N;isCmplt=N;   | Torrent: 'test torrent 1GB - 1'
[23:00:20.493] {plug} [StartStopRules] NOT queuing: maxDownloads = 0;   | Torrent: 'test torrent 1GB - 1'
[23:00:20.493] {plug} [StartStopRules] << DL state=D;shareRatio=16;numW8tngorDLing=6;maxCDrs=999999;forced=N;actvDLs=6;hgherQd=N;ActDLing=N;    | Torrent: 'test torrent 1GB - 1'
[23:00:21.986] {plug} [StartStopRules] >> DL state=D;shareRatio=16;numW8tngorDLing=5;maxCDrs=999999;forced=N;actvDLs=6;maxDLs=0;ActDLing=N;globDwnRchd=Y;hgherQd=N;isCmplt=N;   | Torrent: 'test torrent 1GB - 1'
[23:00:21.986] {plug} [StartStopRules] NOT queuing: maxDownloads = 0;   | Torrent: 'test torrent 1GB - 1'
[23:00:21.986] {plug} [StartStopRules] << DL state=D;shareRatio=16;numW8tngorDLing=6;maxCDrs=999999;forced=N;actvDLs=6;hgherQd=N;ActDLing=N;    | Torrent: 'test torrent 1GB - 1'
parg commented 3 years ago

What does the LAN Peer Finder log show? Tools->Plugins->Log Views

TheBestPessimist commented 3 years ago

Source: qBT (server) -> BBT (laptop):

All it has are lines for each of my torrents, similar to this one:

[13:21:22] Tracking test torrent 1GB - 2
TheBestPessimist commented 3 years ago

Maybe this extra info helps:

This looks to me as if we cannot find the BBT LAN source, however BBT LAN client finds a qBT LAN source

parg commented 3 years ago

There are two different (incompatible) LAN discovery protocols - Azureus/Vuze/BiglyBT clients use their own multicast group and discovery protocol. Requires the peers to be on the same LAN segment. If you don't see any lines of the form

 Found: id=63C7AE15...,ap=az_5.7.5.1_CVS,int=192.168.1.4,ext=81.155.203.210,tcp=63903,udp=63903,udp2=63903,props=null

then multicast isn't working.

TheBestPessimist commented 3 years ago

Maybe the info on the plugin page should mention about multicast.

Anyway, another message that i got in the same window log is the following, this happened after i restarted my router:

[14:23:01] Changed: id=AB97713E...,ap=az_2.6.0.1_B05,int=0.0.0.0,ext=86.125.246.102,tcp=34375,udp=34375,udp2=34375,props=null

However, i still dont have a message that you have

parg commented 3 years ago

that 0.0.0.0 isn't good...

parg commented 3 years ago

The first time another BiglyBT instance is found you get a 'Found' line - when it is 're-discovered' you get a 'Changed' line. So there must have been a previous 'Found' that has scrolled out of the log (well, that's my guess, unless those details correspond to your local instance - check the port number)

fritzgert commented 3 years ago

Hi, i try it in english.

Years ago i was using the local peer function in the pre bigly clients. Some days ago i startet to use it again, but cant get it working. After reading and searching a lot iam not a step closer (iam not so deep in that stuff)

I have a raspberry pi 4 with qbittorrent (i already found out, that the protocol is incompatible to that from bigly), but the pi isnt important (maybe i try to install bigly after the next pi newinstall, if its not so difficult). Since i dont let the pc running at night or when iam not at home, i want at least let the laptop online at night. So it can sync the pieces found at night to my pc the next day. The torrents for that are sometimes very old or going very fast down to under 10 seeds. The speed from them is the other issue, its slow because they seed a lot old torrents i guess.

I managed to let both biglys fiend eachother and even connect local , but they dont start the transfer over LAN, when i deactivated peer exchange, dht ect. With all on, they behave like normal internet clients to eachother and are transfering like all other clients. I made a testtorrent without dht ect, only local is active and they find eachother again, but wont start the transfer too...

My VPN is AirVPN with port-forwarding, both systems are on a seperate device recognized by the vpn service and all with the nonlocalnetwork stuff is working very good. Both systems see when the other is to shutdown in the "local clients detected" or is back online again. They see it within seconds. So i guess my problem is somewhere else.

Both systems are bind to interface with the wintun driver. PC: "net8" and laptop "net6". here i think i have to add something. In the Lan peer finder addon: at the moment i left the network part empty, already tried it with 192.168.. or 192.168.0.* (192.168.0.1 is router). So i filled "exspecially these sources" at the pc with "192.168.0.31" and on the laptop "192.168.0.43". Also i had the combination with the Pi before like "192.168.0.31;192.168.0.117" as i didnt know, that bigly and qbittorrent have different local peer plugins.

AirVPN with portforwarding, for emule with high ID too, all fine. Windows network working with active vpn too, manual filetransfer, printing ect is all possible. Plugins that could be relatet with that: -friends (i can chat with both systems to eachother^^ boosting active and both systems added as friends) -I2P Helper (I2P is active too) -µtp deactivated -VPN Helper

i activated and deactivated so much and restartet the program after that with no result. In the VPN forum someone aggreed to my guess, that the bind to interface function is the problem (as its doing what it should do^^). the options in the local peer finder i understand them as a manual override. is that correct? both systems are seeing eachother so until a certian point it works and it should be possible in my thouhgts, but the last step is missing. is that correct too?

Do i have to add something in the field from "bind to interface" ? this IP stuff with the [ ] ect is to much for me^^

parg commented 3 years ago

Do the logs show the two BiglyBTs finding each other?

The log should also show that they have torrent(s) in common.

If you have bound BiglyBT to an interface (under Connection->Advanced Network Settings) then all peer-to-peer connections will be sent via that network interface, regardless of whether they are detected as 'LAN local'. Unless your VPN itself has some smart routing for local addresses then the connections will fail.

Assuming that you have VPN bindings set for both BiglyBTs, try removing them and running your test torrent.

parg commented 3 years ago

For example you should see something like

[18:10:03] Tracked: id=33CB288C...,ap=az_2.6.0.1_B47,int=192.168.1.5,ext=aa.bb.cc.dd,tcp=1234,udp=1234,udp2=1234,props=null: MyTestTorrent, seed = false
[18:10:03]     MyTestTorrent: Injecting peer 192.168.1.5:1234/1234

It would be possible I think to add an option to ignore bindings for addresses that are considered LAN local that might fix things.

fritzgert commented 3 years ago

Hi, thank you for your help.

i deleted the friends and deactivated the plugin friends + restart.

log from lan-peer-finder on pc.

[20:51:50] Added peer '192.168.0.117' [20:51:50] Added peer '192.168.0.31' [20:51:51] Tracking CinematicMod2013_1.2_full [20:51:51] Found: id=6503A4C8...,ap=az_2.6.0.0,int=10.17.146.249,ext=195.206.xxx.xxx,tcp=3092,udp=55987,udp2=55987,props=null [20:51:51] Tracking HotA_1.6.1_setup.exe [20:52:33] Tracked: id=6503A4C8...,ap=az_2.6.0.0,int=10.17.146.249,ext=195.206.xxx.xxx,tcp=3092,udp=55987,udp2=55987,props=null: HotA_1.6.1_setup.exe, seed = false [20:52:33] HotA_1.6.1_setup.exe: Injecting peer 10.17.146.249:3092/55987 [20:52:37] Tracked: id=6503A4C8...,ap=az_2.6.0.0,int=10.17.146.249,ext=195.206.xxx.xxx,tcp=3092,udp=55987,udp2=55987,props=null: CinematicMod2013_1.2_full, seed = true

The ext is the correct IP from the laptop connection, and the log from the laptop shows the correct from the pc. The network IPs within the vpn datacenters are correct too. So if the local peer finder wouldnt work, why could the biglys see eachother within my network at home? They know that the .31 is the 10.17.146.249 with the ext 195.206.xxx.xxx Very interesting.

My pc is connected over sweden and the laptop over switzerland. Complete different datacenters.

I seed the fanmod CinematicMod2013_1.2_full on both systems with all dht, trackers ect The gameupdate HotA_1.6.1_setup.exe is seeding on pc and 0% on the laptop. the .torrent was created without dht and trackerinformation, peer exchange was deactivated too. I2P says there are 2 leecher, which should be 1 seed and 1 leecher. the torrent was created with a random file by myself for the test only.

LAN says "1 local source detected" but peers, seeds, leecher are 0. Somewhere its still blocked.

fritzgert commented 3 years ago

yeah, youre right. My amateur assumption was, that the options in the local peer finder were some sort of override for the binding to interface. so if the client know, that i want the 2 specific ips in the local network at home excluded from the blocking, so they can sync the pieces. Were at that point, that they know exactly, that the other one is there ect, but the dont do the next step and start the transfer.

Hope i can discribe it, not easy in english with this specific stuff^^

parg commented 3 years ago

The LAN Peer Finder works by using Multicast UDP - this isn't routed through the VPN but over your local network. However, the addresses that are communicated via UDP are the VPN local endpoints (e.g. 10.17.146.249)

So when the BiglyBTs attempt to connect to each other using this information they use the (unrouteable) 10.17.146.249 (in this example).

I can change things so that your local routeable IP is also used (192.168.whatever) but the problem will be that BiglyBT is only listening on 10.17.146.249 (as you bound BiglyBT to that) and the connection will fail.

If one BiglyBT was on a VPN and the other not then this fix would make things work. However with them both bound to a VPN neither will be able to connect to the other.

A further option could be added to allow BiglyBT to bind the incoming connections to the wildcard address while forcing outgoing connections through the VPN I suppose.

fritzgert commented 3 years ago

Thank you for that explanation. I still cant understand why they then even know, that they are both in the same local physical network, but are only allowed to use the vpn connection. Heavy stuff for me. I think i will then use the friend plugin and add them as friends to eachother again.

My problem seem to be a very rare^^ Ok, big thank you for your reply. I was very happy to see BiglyBT after a long downtime from BitTyrant. The time with Vuze was short for me, didnt like it at all, used µtorrent mainly as emergency, and a lot of other clients. Azureus was my favorite from my torrent time and then the good successors. Best uploadbehavior in my opinion with a lot of extras and details to see. So now iam a Bigly user for some years.

parg commented 3 years ago

I'll see if I can get things working and get back to you with something to test :)

fritzgert commented 3 years ago

If i could help with my setup, that would be cool to get it working. I still find it funny, that as soon as i restart the program on the laptop, the counter on the pc with "1 local clients detected" goes to 0 and up to 1 as soon as the client on the laptop is running again^^ they definetly see eachother somehow next to the vpn. They just cant bypass the transfer.

Iam curios now :D Good night, iam from germany, so its getting late for me.

parg commented 3 years ago

Beta B48 has two new options that you will need to configure to get things working in both your BiglyBTs (hopefully!). They are under Connection->Advanced Network Settings

1) Additional bind addresses for incoming connections

Put in whatever your PC's LAN address is (192.168.x.y) or use the network interface name, e.g. eth3.

This will allow BiglyBT to accept incoming connections from your LAN, not just from the VPN.

2) Ignore bindings for outgoing connections to LAN addresses

Enable this.

This will allow BiglyBT to connect to addresses on your LAN rather than trying to use the VPN to connect to them.

fritzgert commented 3 years ago

Hi, that was fast.

I try it at the moment, but i get the error in status "paused binding missing" My PC: I set additonal bind address... to "eth3" (thats my normal 192.168.0.43 for the pc" checked the "ignore bindings for...."

Is there a problem with the following seeteings from previous version? "check bind ip addresses..." active "force ip-bindings, even no interfaces..."

then under die lan-peer-finder plugin both boxes checked first field empty at the moment, tried 192.168.. before too second field 192.168.0.31 (thats the laptop)

On my laptop same settings with the changed interface and ips.

Also restartet both programs every time.

parg commented 3 years ago

You added 'eth3' to the new config setting called 'additional bind addresses for incoming connections', NOT the existing 'bind to local IP or interface' setting?

Also, in the area that lists the network interfaces in the system I assume that 'eth3' is showing up there with 192.168.0.43 listed as an addresses attached to that interface?

fritzgert commented 3 years ago

yes, i tried eth3 in the new field which is listet as 192.168.0.43. i also tried the ip instead of the eth3. maybe i have something else not right.

Unbenannt Unbenannt1 Unbenannt2

parg commented 3 years ago

Ah, I wonder if you are successfully establishing a LAN connection but some other code is detecting the connection and treating it as an error...

Try experimenting by unchecking the 'force bindings even if no interface' and see if that gets things working.

parg commented 3 years ago

I managed to reproduce what you're seeing - tell me if unchecking the 'force bindings' option fixes things for you and I'll assume that we're both seeing the same thing!

fritzgert commented 3 years ago

Sadly nothing changed. I tried to test if the lan peer still works without the whole vpn stuff, but i cant get it runnung anymore^^ Now iam back setting it with the VPNs. The PC can see the bigly on the laptop start or closing and the other way around too. I have complete deactivated my windows firewall. i dont use other antivirus oder firewall software.

Do i have to fill 192.168.. in the first field of the lan peer finder setting? i still think that something on my end is wrong...

parg commented 3 years ago

You don't have to fill in anything in the LAN Peer Finder plugin, the defaults should be fine (two boxes checked, no explicit addresses)

Try B49

fritzgert commented 3 years ago

Still not. What i can verify is, that i have to fill the ip from the other system in the second field of the lan peer finder plugin.

now i see this, but they cant start the transfer. they even exchange some kilobytes.

Unbenannt4

parg commented 3 years ago

Is the connection using a LAN address now?

parg commented 3 years ago

And does the log view for the Lan Peer Finder show peer IPs being 'injected' ?

fritzgert commented 3 years ago

[18:04:07] Added peer '192.168.0.31' [18:04:10] Found: id=6503A4C8...,ap=az_2.6.0.1_B49,int=10.17.146.249;192.168.0.31,ext=195.206.xxx.xxx,tcp=3092,udp=55987,udp2=55987,props=null [18:04:10] Tracking CinematicMod2013_1.2_full [18:04:10] Tracking core_BiglyBT2601-B49-signed.jar [18:04:11] Tracking HotA_1.6.1_setup.exe [18:05:18] Lost: id=6503A4C8...,ap=az_2.6.0.1_B49,int=10.17.146.249;192.168.0.31,ext=195.206.xxx.xxx,tcp=3092,udp=55987,udp2=55987,props=null [18:06:17] Found: id=6503A4C8...,ap=az_2.6.0.1_B49,int=10.17.146.249;192.168.0.31,ext=195.206.xxx.xxx,tcp=3092,udp=55987,udp2=55987,props=null [18:06:26] Tracked: id=6503A4C8...,ap=az_2.6.0.1_B49,int=10.17.146.249;192.168.0.31,ext=195.206.xxx.xxx,tcp=3092,udp=55987,udp2=55987,props=null: HotA_1.6.1_setup.exe, seed = false [18:06:26] HotA_1.6.1_setup.exe: Injecting peer 10.17.146.249:3092/55987 [18:06:26] HotA_1.6.1_setup.exe: Injecting peer 192.168.0.31:3092/55987 [18:06:36] Tracked: id=6503A4C8...,ap=az_2.6.0.1_B49,int=10.17.146.249;192.168.0.31,ext=195.206.xxx.xxx,tcp=3092,udp=55987,udp2=55987,props=null: CinematicMod2013_1.2_full, seed = true

on the pc i have now the problem that i have to force start the torrent. on the laptop they starting normally. all settings are the same (except the network related of course).

I would say, that they dont use the local ips with the 43 and 31... but theres a dot on my screenshot at the "LAN" . i assume, that i have something here, what blocks or we dont have that in mind.

edit: just noticed that the pc isnt recognized as a seed by the laptop, instead hes at 99,5% of the file, which isnt correct

parg commented 3 years ago

If you have a seed with no peers then by default it will go into a 'queued' state - perhaps that is what you are seeing?

So whatever computer the above trace is from is attempting to connect to the other one via 192.168.0.31:3092

Is that the right address to use to connect to BiglyBT on the other computer?

And you're saying that that connection never succeeds? What if you go to the Peers tab for the download, right-click and select the 'add peers...' option and then enter 192.168.0.31:3092 ?

Does that connect?

fritzgert commented 3 years ago

Now i get errormessages on both systems. No, on both systems neither. on top i get this now in the right corner as an error:

"Listen server socket on [the ipv6 from the eth3] does not appear to be accepting inbound connections [Permission denied: connect] Auto-repairing listen service...."

The "ignore bindings for outgoing connections to LAN addresses" is checked.

fritzgert commented 3 years ago

Thank you for your time and effort. This is really a long run^^

parg commented 3 years ago

Replace eth3 with the IPv4 local address in the 'additional service bind addresses' - see if that helps

parg commented 3 years ago

Of course I don't know what 'isolation level' your VPN gives you - obviously it is allowing UDP Multicast traffic to pass between your two BiglyBT processes over your LAN but is it possible that it is preventing TCP connections?

fritzgert commented 3 years ago

no. nothing different. i guess iam destroying my config :D now on the laptop same are queued too. strange. i reseted the windows firewall and allowed bigly for private and open network.

fritzgert commented 3 years ago

AirVPN has a software "eddie" where i can activate "allow LAN/private", so i can transfer data and print with the wlan printer without problem. i see all systems at home too. my laptop is via wlan, the Access Point to a switch, where my pc is connected. mybe i have to do more on the vpn portal.. i will check in some hours again. But iam very grateful for your help, you even did 2 beta versions.

parg commented 3 years ago

Keep at it! I have one VPN and it works fine with the VPN'd BiglyBT connecting to another 'open' machine, and the 'open' machine connecting to the VPN'd BiglyBT. So in theory things are working.

fritzgert commented 3 years ago

One idea: Could there be a problem with the port for the local peer finder plugin? i reada something with the port 49001. So only one client in my local network can use it or both the same time? would it help to give one client a different and how would i do that?

parg commented 3 years ago

nope, that shouldn't be relevant

What happens if you manually add the remote peer like I said?

fritzgert commented 3 years ago

ah sorry, forgot to put that in the answer yesterday. It didnt help. I try it later with the new beta version again and give you the errormessage or the behaviour. I will go through all options again to verify them.

fritzgert commented 3 years ago

ok there was a transfer over lan, but i cant recreate it. dont know what caused it. does the manual "add peer" is saved for a longer time? as i added it, nothing happened, there were over 5 minutes delays until the transfer startet.

i have to see it myself for the details, noticed it, as it was 98% complete. but good news, it can work^^

fritzgert commented 3 years ago

Now its working with manual "add peer", i can even get the raspberry pi with qbittorrent added. All 3 systems are able to download and upload to eachother over the lan connection.

I think the following points are important: the second field in the lan peer finder plugin "exspecially these sources" has to accept the port with ip, instead ip only. 192.168.0.31;192.168.0.117 isnt enough, 192.168.0.31:3092;192.168.0.117:8999 should be possible. at the moment i think the programm doesent accept this. even when theres no errormessage.

The lan peer finder plugin has also to add the ip with the port at start and in the injectprocess too. i have to add 192.168.0.31:3092 to get it startet. maybe until now the system see the clients on the systems, but lack permission or information about the port.

The new field in connection ->advanced "addional bind addresses for incoming connection" needs at the moment the IP, the interface for example eth3 or wlan1 doesnt work and result in the errormessage some posts before ""Listen server socket on [the ipv6 from the eth3] does not appear to be accepting inbound connections [Permission denied: connect] Auto-repairing listen service....""

I hope this observation can help you to get it possible for automatic adding and injecting the peers.

Some extra: I deactivated the friend plugin, because i have the feeling, that the plugin tries to connect and is blocking the "add peer" process by me sometimes. maybe theres a add peer limit per for some seconds^^ i can see the client details of the torrent the other peers. there are the connections which are apearing and going, and i think, i can only add a peer manuially in the moment, weres no other function is trying to add the same ip. I will delete the friendconnection between both systems.

And i see the intern IP from the vpn datacenter in the peers from the other client too. So my client on the pc knows exactly that the local ip of the laptop and the intern ip of the vpn on the laptop, are from the same client on that device. is that part of the udp multicast you mentioned before? i think you said somewhere before, that we cant use that.

parg commented 3 years ago

The port isn't relevant to the LAN Peer Finder plugin - that plugin categorises IP addresses as LAN local.

The key question I have is "do you see the LAN Peer Finder plugin injecting the correct IP:port in the log file" (Tools->Plugins->Log Views->LAN Peer Finder)

If the plugin is working correctly then you should see it attempting to inject two peers (most likely) - the first one will be the "internal VPN IP Address:Port" and the second the "LAN IP Address:Port" (the same as you are manually injecting to get things working).

The "internal VPN IP" won't work as it isn't a routable address on your LAN but that doesn't matter, the second peer is the one that should work.

fritzgert commented 3 years ago

[16:08:50] Added peer '192.168.0.31' [16:08:50] Added peer '192.168.0.117' [16:08:53] Tracking HotA_1.6.1_setup.exe [16:08:54] Found: id=6503A4C8...,ap=az_2.6.0.1_B51,int=10.17.146.249;192.168.0.31,ext=195.206.xxx.xxx,tcp=3092,udp=55987,udp2=55987,props=null [16:21:55] Tracked: id=6503A4C8...,ap=az_2.6.0.1_B51,int=10.17.146.249;192.168.0.31,ext=195.206.xxx.xxx,tcp=3092,udp=55987,udp2=55987,props=null: HotA_1.6.1_setup.exe, seed = false [16:21:55] HotA_1.6.1_setup.exe: Injecting peer 10.17.146.249:3092/55987 [16:21:56] HotA_1.6.1_setup.exe: Injecting peer 192.168.0.31:3092/55987

ok, at the end its injecting with the port... but its not working even after hours. as soon as i "add peer" with "192.168.0.31:3092" , its starting.

i stopped the torrent. resetet the log. startet it and stopped again. this is the new:

[16:31:39] Tracked: id=6503A4C8...,ap=az_2.6.0.1_B51,int=10.17.146.249;192.168.0.31,ext=195.206.xxx.xxx,tcp=3092,udp=55987,udp2=55987,props=null: HotA_1.6.1_setup.exe, seed = false [16:31:39] HotA_1.6.1_setup.exe: Injecting peer 10.17.146.249:3092/55987 [16:31:39] HotA_1.6.1_setup.exe: Injecting peer 192.168.0.31:3092/55987

PS: i discovered that the intern vpn IP changes after some days, even when using the service. thought until now that this happens only when i dont use it a week. but bigly get it right, because iam unsing the bind to interface.

parg commented 3 years ago

The only difference I think between you manually injecting the peer and the plugin doing it is that the plugin assumes (for whatever reason) that the crypto level is 'none'

As far as I can remember crypto is supposed to be ignored for LAN connections, however, have you changed the setting under Connection->Transport Encryption from the default of 'none' ?

fritzgert commented 3 years ago

Thanks for that new approach. I deactivated the encryption complete and restartet on both systems, doesent help^^

parg commented 3 years ago

That UDP port (55987) is what you have configured I assume? By default it is the same as the TCP listen port.

parg commented 3 years ago

hmmm, hang on, is it a private torrent? Given that you can manually inject peers that means it isn't but just wanted to check.

parg commented 3 years ago

The 'plugin peer source' does need to be enabled though, don't supposed you've messed with the defaults for that?

parg commented 3 years ago

Check the debug_1.log/debug_2.log files in %appdata%\logs

fritzgert commented 3 years ago

-yes, that UDP was set by me. i changed it to the same number like TCP. -its not a private torrent. just no tracker and no DHT. -plugins, incoming connections and peers can add sources are allowed and active. -i dont have a plugin"peer source" , do you mean the options for "origin of sources" ? -in these logs, what should i search for? (Sorry, its too much for me) -µtp and friend plugin are deactivated

at the moment, i have deleted the ips in in the second field from the local peer finder plugin. But i insert/delete it, often to see, if the clients can see that. When IPs are filled in, its still so, that the PC see it immediately when the bigly restarts/shutdown on the laptop. the Laptop does it too when the PC is doing that.

The manual "add peer" results still in a successful transfer, even with no ips in the plugin local peer finder.