After a period, stops accepting new connections (when using IP tables)

[pfrazee]

I have a linode server which is running dat right now. When I first run it, it works as expected. After some time period (>5 minutes, not sure how much) it stops working. The CLI continues to display:

Downloading in data

Share Link: 6d12454b46d77ff4af801c7e40ee8f48595cdb62e147814e9952d8d356590567
The Share Link is secret and only those you share it with will be able to get the files

[=============================>] Downloaded 53 items (639.19 kB/645.34 kB)

Waiting for connections. 

So nothing appears to be wrong.

[pfrazee]

@mafintosh Replying to beakerbrowser/beaker#44 (comment) here

I'm seeing some indications that it will occur in Beaker, if it's been left open for a while. It may be important that the dat sit idle (meaning, no network activity at all).

I'll double check my tests

[mafintosh]

okay, great. let me know. would very much like to get this fixed if it is indeed a problem.

[pfrazee]

yeah, same. I consider it a blocker in Beaker

[pfrazee]

I wonder if mappum/electron-webrtc#50 could be related? This is an error I get after a period of inactivity, and it only occurs when electron-webrtc is fed into hyperdrive-archive-swarm. It could be a bug in the dat code, which is only made apparent by wrtc

[mafintosh]

Ah. I havent tested using webrtc. Will give it a spin
On Tue, 2 Aug 2016 at 17:48, Paul Frazee notifications@github.com wrote:

I wonder if mappum/electron-webrtc#50
mappum/electron-webrtc#50 could be related?
This is an error I get after a period of inactivity, and it only occurs
when electron-webrtc is fed into hyperdrive-archive-swarm. It could be a
bug in the dat code, which is only made apparent by wrtc

—
You are receiving this because you were mentioned.

Reply to this email directly, view it on GitHub
#503 (comment), or mute
the thread
https://github.com/notifications/unsubscribe-auth/AAW_VcD_O3_o5WxtgzutALTkDV2lDnPWks5qb2bNgaJpZM4JaBkD
.

[pfrazee]

I just triple checked using only dat CLI. It doesnt seem to be dependent on webrtc, though maybe my linked webrtc bug is emitting information related to this bug

[joehand]

I wasn't able to reproduce with local CLI or with the @pfrazee's cloud Dat. @pfrazee thinks maybe it is an issue with his local machine, so holding on his investigation.

[pfrazee]

I double checked my software settings and tried on two different networks. Im still getting the same results. This is on latest dat (11.1.2). My cloud machine is node 5.4.1, and my laptop is node 6.2.1.

[pfrazee]

I disabled iptables on my cloud server, and things started working right away. Here's a dump of the rules I was using:

# Generated by iptables-save v1.4.21 on Tue Aug  2 20:15:21 2016
*security
:INPUT ACCEPT [22564796:11462308678]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [23681133:12299842918]
COMMIT
# Completed on Tue Aug  2 20:15:21 2016
# Generated by iptables-save v1.4.21 on Tue Aug  2 20:15:21 2016
*raw
:PREROUTING ACCEPT [23384816:11542433711]
:OUTPUT ACCEPT [23681133:12299842918]
COMMIT
# Completed on Tue Aug  2 20:15:21 2016
# Generated by iptables-save v1.4.21 on Tue Aug  2 20:15:21 2016
*nat
:PREROUTING ACCEPT [103316:7004032]
:INPUT ACCEPT [61406:3732456]
:OUTPUT ACCEPT [261775:16651306]
:POSTROUTING ACCEPT [261775:16651306]
COMMIT
# Completed on Tue Aug  2 20:15:21 2016
# Generated by iptables-save v1.4.21 on Tue Aug  2 20:15:21 2016
*mangle
:PREROUTING ACCEPT [23384817:11542435211]
:INPUT ACCEPT [23384805:11542431035]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [23681133:12299842918]
:POSTROUTING ACCEPT [24455800:12376530535]
COMMIT
# Completed on Tue Aug  2 20:15:21 2016
# Generated by iptables-save v1.4.21 on Tue Aug  2 20:15:21 2016
*filter
:INPUT ACCEPT [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
:f2b-sshd - [0:0]
-A INPUT -p tcp -m multiport --dports 22 -j f2b-sshd
-A INPUT -i lo -j ACCEPT
-A INPUT -d 127.0.0.0/8 -j REJECT --reject-with icmp-port-unreachable
-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
-A INPUT -p tcp -m tcp --dport 80 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 443 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 8008 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 1025 -j ACCEPT
-A INPUT -p tcp -m state --state NEW -m tcp --dport 22 -j ACCEPT
-A INPUT -p icmp -m icmp --icmp-type 8 -j ACCEPT
-A INPUT -m limit --limit 5/min -j LOG --log-prefix "iptables denied: " --log-level 7
A INPUT -j DROP
-A FORWARD -j DROP
-A OUTPUT -j ACCEPT
-A f2b-sshd -j RETURN
COMMIT
# Completed on Tue Aug  2 20:15:21 2016

@mafintosh if you want, I can test out some variations on these rules

[okdistribute]

@maxogden @joehand this might be a great addition to a 'troubleshooting' section of the dat readme

[okdistribute]

This issue still exists but we've left it as a troubleshooting tip to disable iptables. Moved to dat-ecosystem-archive/discovery-channel#8

[deed02392]

@pfrazee did you figure out what specific rules caused the problem, if it was indeed iptables?

[pfrazee]

@deed02392 probably the issue was that I wasn't listening on port 3282, which is used for discovery