bitmagnet-io
running the app (docker version) floods router dns server with dns request of IPs (not domains)
- [ x] I have checked the existing issues to avoid duplicates
- [x ] I have redacted any info hashes and content metadata from any logs or screenshots attached to this issue
I used the sample docker to use this app. when I run this docker app my dnscrypt throws errors about
daemon.warn dnsmasq[1]: Maximum number of concurrent DNS queries reached (max: 150)
daemon.err dnscrypt-proxy[ [WARNING] Too many incoming connections
it seems that this app floods the router dns server with dns request about IPs of IPs (instead of domains)
192.168.1.101/52376 query[PTR] 146.214.167.91.in-addr.arpa from 192.168.1.101
192.168.1.101/52376 forwarded 146.214.167.91.in-addr.arpa to 192.168.1.1#55
192.168.1.101/61512 query[PTR] 53.194.97.177.in-addr.arpa from 192.168.1.101
192.168.1.101/61512 forwarded 53.194.97.177.in-addr.arpa to 192.168.1.1#55
192.168.1.101/55319 query[PTR] 166.248.102.183.in-addr.arpa from 192.168.1.101
192.168.1.101/55319 forwarded 166.248.102.183.in-addr.arpa to 192.168.1.1#55
192.168.1.101/57711 query[PTR] 149.174.162.178.in-addr.arpa from 192.168.1.101
192.168.1.101/57711 forwarded 149.174.162.178.in-addr.arpa to 192.168.1.1#55
192.168.1.101/64067 query[PTR] 196.41.104.223.in-addr.arpa from 192.168.1.101
192.168.1.101/64067 forwarded 196.41.104.223.in-addr.arpa to 192.168.1.1#55
192.168.1.101/63038 query[PTR] 119.160.99.113.in-addr.arpa from 192.168.1.101
192.168.1.101/63038 forwarded 119.160.99.113.in-addr.arpa to 192.168.1.1#55
192.168.1.101/61814 query[PTR] 37.234.162.112.in-addr.arpa from 192.168.1.101
192.168.1.101/61814 forwarded 37.234.162.112.in-addr.arpa to 192.168.1.1#55
192.168.1.101/51985 query[PTR] 244.40.92.153.in-addr.arpa from 192.168.1.101
192.168.1.101/51985 forwarded 244.40.92.153.in-addr.arpa to 192.168.1.1#55
192.168.1.101/56061 query[PTR] 252.30.227.5.in-addr.arpa from 192.168.1.101
192.168.1.101/56061 forwarded 252.30.227.5.in-addr.arpa to 192.168.1.1#55
192.168.1.101/64486 query[PTR] 206.8.189.117.in-addr.arpa from 192.168.1.101
192.168.1.101/64486 forwarded 206.8.189.117.in-addr.arpa to 192.168.1.1#55
192.168.1.101/49290 query[PTR] 230.93.68.208.in-addr.arpa from 192.168.1.101
192.168.1.101/49290 forwarded 230.93.68.208.in-addr.arpa to 192.168.1.1#55
192.168.1.101/62256 query[PTR] 29.157.159.185.in-addr.arpa from 192.168.1.101
192.168.1.101/62256 forwarded 29.157.159.185.in-addr.arpa to 192.168.1.1#55
192.168.1.101/60732 query[PTR] 184.174.162.178.in-addr.arpa from 192.168.1.101
192.168.1.101/60732 forwarded 184.174.162.178.in-addr.arpa to 192.168.1.1#55
192.168.1.101/49173 query[PTR] 107.130.66.178.in-addr.arpa from 192.168.1.101
192.168.1.101/49173 forwarded 107.130.66.178.in-addr.arpa to 192.168.1.1#55
192.168.1.101/53000 query[PTR] 219.132.187.188.in-addr.arpa from 192.168.1.101
192.168.1.101/53000 forwarded 219.132.187.188.in-addr.arpa to 192.168.1.1#55
192.168.1.101/59901 query[PTR] 82.54.62.92.in-addr.arpa from 192.168.1.101
192.168.1.101/59901 forwarded 82.54.62.92.in-addr.arpa to 192.168.1.1#55
192.168.1.101/57042 query[PTR] 145.173.233.193.in-addr.arpa from 192.168.1.101
192.168.1.101/57042 forwarded 145.173.233.193.in-addr.arpa to 192.168.1.1#55
192.168.1.101/49696 query[PTR] 189.10.239.120.in-addr.arpa from 192.168.1.101
192.168.1.101/49696 forwarded 189.10.239.120.in-addr.arpa to 192.168.1.1#55
192.168.1.101/50442 query[PTR] 9.153.94.113.in-addr.arpa from 192.168.1.101
and this flood of equerries causes the dns-server to refuse serving dns answers.
- Bitmagnet version:
[latest docker version] - OS and version:
[archlinux]
This happens without Docker as well. A flood of DNS requests for the bootstrap nodes also occurs, which seems horribly wrong.
This happens without Docker as well. A flood of DNS requests for the bootstrap nodes also occurs, which seems horribly wrong.
I wanted to specify so that if the bug was only present in docker then the dev(s) could narrow it down. but your report helps too so. thanks for confirming it.
I still don't understand the flooding even for non dns requests, but this is for requesting IPs of IPs (instead of domains) so it has to be a bug.
This issue brought my home network to its knees, and it took me far too long to trace it back to Bitmagnet. Reducing the DHT_CRAWLER_SCALING_FACTOR does little to nothing to fix it.
I also could swear this only started about a week ago (around the time this issue was opened) - at least I didn't notice it earlier. But, as far as I can tell, there hasn't been a new docker release in over two months?
Is there another trigger or threshold that could have exacerbated this bug?
I'm running the docker container as well.
This issue brought my home network to its knees, and it took me far too long to trace it back to Bitmagnet. Reducing the DHT_CRAWLER_SCALING_FACTOR does little to nothing to fix it.
I also could swear this only started about a week ago (around the time this issue was opened) - at least I didn't notice it earlier. But, as far as I can tell, there hasn't been a new docker release in over two months?
Is there another trigger or threshold that could have exacerbated this bug?
I'm running the docker container as well.
maybe I cursed it?
by the way, a similar issue was present with magnetico (the other dht crawler) but that one was managed by something like that DHT_CRAWLER_SCALING_FACTOR.
this issue is present at the start and it seems to go away after a while. not a small amount of time but I didn't check to reproduce the time it takes to go away cause it makes my dns server give empty answer for whole network
Are you by any chance using an OpenWRT router? This sounds like it might be a duplicate of https://github.com/bitmagnet-io/bitmagnet/issues/299
Routing Bitmagnet through a VPN might help in this case.
The Bitmagnet code is not making any DNS queries directly (with the exception of the bootstrap nodes), it's just using the standard networking libraries.
Are you by any chance using an OpenWRT router? This sounds like it might be a duplicate of #299
Routing Bitmagnet through a VPN might help in this case.
The Bitmagnet code is not making any DNS queries directly (with the exception of the bootstrap nodes), it's just using the standard networking libraries.
I am using openwrt but my issue is not the same as that one.
mine is exactly because of dns requests that make both dnscypt and dnsmasq go:
daemon.warn dnsmasq[1]: Maximum number of concurrent DNS queries reached (max: 150)
daemon.err dnscrypt-proxy[ [WARNING] Too many incoming connections
if I have a download running before running bitmagnet , that still has its own bandwidth because it already has the dns-ip it needed.
so to repeat, my issue is not network coming to a standstill because of weak cpu in router. network works. my issue is that this app floods the dns server with ip request that are actually IPs instead of domains.
I have put the dns request at the top as you can see.
it is not asking for IPs of bootstraps.
it is doing this:
query[PTR] 166.248.102.183.in-addr.arpa from 192.168.1.101
so it is asking the dns server what is IP of domain 166.248.102.183.in-addr.arpa
asking for IP for an IP is incorrect but that is one issue. flooding dns server causes this bug.
my issue is that this app floods the dns server with ip request that are actually IPs instead of domains.
There simply isn't any code in Bitmagnet that does this. I suspect it's a software (not hardware) issue with OpenWRT routers. Many OpenWRT users have already raised issues both here and on Discord. The best workaround that's been found is running Bitmagnet through a VPN. I don't have an OpenWRT router to test with myself but you might be able to get help from other users on Discord: https://discord.gg/6mFNszX8qM
my issue is that this app floods the dns server with ip request that are actually IPs instead of domains.
There simply isn't any code in Bitmagnet that does this. I suspect it's a software (not hardware) issue with OpenWRT routers. Many OpenWRT users have already raised issues both here and on Discord. The best workaround that's been found is running Bitmagnet through a VPN. I don't have an OpenWRT router to test with myself but you might be able to get help from other users on Discord: https://discord.gg/6mFNszX8qM
I think I found out some more info. the chaining of dnscrypt and dnsmasq causes this. maybe it somehow creates a loop. I make dnsmasq the only server in dns chain and it fixed this issue.
so I will close this and see what causes it.
but I didn't see this loop before with any other apps.
weird I reverted my "fix" and the issue is no longer there. so my fixing didnt fix it. it was fixed before somehow. so it seems the issue was not the openwrt issue.
update: I again got this bug. running the app floods my dns server.
I even disabled dnscrypt.
Please note I have similar network degradation while using Synology routers, I could pinpoint the issue back to Bitmagnet but still unclear what's producing the network overload. It's happening with v0.9.5, however I could eventually managed to make it work with latest v0.10.0-beta5 through gluetun, will keep posted.
i have same issue while using Fritz box router tried DHT_CRAWLER_SCALING_FACTOR 5 not helping
it seems that this app floods the router dns server with dns request about IPs of IPs (instead of domains)
It is not trying to resolve an IP from an IP. It is trying to resolve a name from an IP.
You can see clearly it is a PTR request.
https://www.cloudflare.com/learning/dns/dns-records/dns-ptr-record/
Also there would be nothing in base OpenWrt causing countless PTR record lookups. There would need to be some very strange configurations or perhaps some type of package installed like IDS/IPS/EDR that might perform PTR lookups as part of inspecting traffic.
I don't know what your level of networking expertise is but if you pulled down the latest stable or nightly build of OpenWrt rather than one you've built, customized or installed packages on, isolated bitmagnet to a specific IP address that nothing else is using and you're still seeing PTR requests coming from that IP the only conclusion that could be drawn would be that bitmagnet is indeed the source of the PTR lookups. Be sure to select the option to wipe your settings when flashing the firmware via GUI to clear out any current configurations. You may need to run 'firstboot -y && reboot' from command line to ensure you're factory wiped.
right now I am not using bitmagnet because I have bad internet (non-fiber in iran has low upload speed) so running bitmagnet makes my network too slow.
but I think when that issue happened it was not any other app running that causes that.
right now when I try bitmangnet I dont get the issue but that also was the case when the bug happened intermittently.
Just chiming in with my mikrotik so maybe this will help you to right direction
bitmagnet apprx. consumes 3-4Mbps of bandwith. related to above problem I see 3000+ connections made from bitmagnet machine:port to outside ip addresses (udp+tcp combined).
I have my recursive dns server on the same machine but I dont see any DNS requests being made(servers default gateway is router and router's main DNS address is directed to server.)
Lots of connections in a state of SACFs (seen reply / assured / confirmed / fasttrack / srcnat)
Can confirm that its still happening in v. 0.10.0 It hangs the network DNS (couldnt investigate what type and what amount of requests, since I cant apt-get anything, because my routers DNS is not functioning properly)
