Modem keeps rebooting -- even with reduced Swarm settings

Help Kubo
1

I’m one of those people who has an, let’s say, IPFS-incompatible modem. After a while, even if I change my Swarm settings to the bare minimum (I think) and apply all the things mentioned in the different GitHub issues.

It’s a bit frustrating because I really want to use IPFS via my own node. I’m also a bit puzzled why this happens because I can run BitTorrent and Bitcoin without having to limit anything.

So is there anything else that I can do, or try out to debug the issue?

My current routing and swarm settings are:

  "Routing": {
    "Type": "dhtclient"
  },
  "Swarm": {
    "AddrFilters": null,
    "ConnMgr": {
      "GracePeriod": "30s",
      "HighWater": 64,
      "LowWater": 32,
      "Type": "basic"
    },
    "DisableBandwidthMetrics": false,
    "DisableNatPortMap": true,
    "DisableRelay": false,
    "EnableAutoNATService": false,
    "EnableAutoRelay": false,
    "EnableRelayHop": false
  }
2

Tried disabling MDNS ? That would be a wild shot though.

Would it be possible for you to compile a custom go-ipfs reducing https://github.com/libp2p/go-libp2p-swarm/blob/master/swarm_dial.go#L62 (ConcurrentDials) ? Perhaps the problem is that too many dials are happening at once, rather than having too many connections open…

3

Thanks for the reply!

I will try both your suggestions. I’m already set up to compile Go, so that’s no problem :slight_smile:

I’ll report back soon, because it usually doesn’t take long before my modem start to reboot.

4

Can you share your router model?

5

I have a Ubee EVW321B.

Well, I thought I would have some quick results. But whatever I do I’m not getting it to reboot now, even with “dht” routing and higher connection numbers.

Edit: Ha, just as I send this message it rebooted. But that’s good, so I can try out your suggestions again.

I know the problem wasn’t incidental. I’ve been trying to use IPFS for over a year and it was always there. So I will have to wait until it starts again and then try the new settings.

Maybe it has to do with the rate of new connections, like you said, and that it happens to create fewer ones in short succession today.

6

You may also add your local network to Swarm/AddrFilters like:

  "Swarm": {
    "AddrFilters": [
      "/ip4/10.0.0.0/ipcidr/8",
      "/ip4/100.64.0.0/ipcidr/10",
      "/ip4/169.254.0.0/ipcidr/16",
      "/ip4/172.16.0.0/ipcidr/12",
      "/ip4/192.0.0.0/ipcidr/24",
      "/ip4/192.0.0.0/ipcidr/29",
      "/ip4/192.0.0.8/ipcidr/32",
      "/ip4/192.0.0.170/ipcidr/32",
      "/ip4/192.0.0.171/ipcidr/32",
      "/ip4/192.0.2.0/ipcidr/24",
      "/ip4/192.168.0.0/ipcidr/16",
      "/ip4/198.18.0.0/ipcidr/15",
      "/ip4/198.51.100.0/ipcidr/24",
      "/ip4/203.0.113.0/ipcidr/24",
      "/ip4/240.0.0.0/ipcidr/4",
      "/ip6/100::/ipcidr/64",
      "/ip6/2001:2::/ipcidr/48",
      "/ip6/2001:db8::/ipcidr/32",
      "/ip6/fc00::/ipcidr/7",
      "/ip6/fe80::/ipcidr/10"
    ],

and see what happens. This would prevent your peer from trying to dial addresses in your LAN (which it does randomly).

Good luck!

7

Quick update:

Disabling MDNS is making things much better. The problem isn’t solved, but a reboot “only” happens two times a day or (or more, but I don’t notice it).

Because MDNS is related to peer discovery, it could mean that hector’s theory is right: it’s not the number of active connections that is causing problems but the number of dials at the same time.

I will now lower the ConcurrentFdDials setting and see if the problem disappears completely.

8

This is usefull information. There could even be a IPFS build: Router-Friendly Edition (:tm:) shipped with the right settings :ok_hand: :slight_smile:

9

Disabling MDNS is making things much better…

Hmm I can’t imagine why a router would end up rebooting from handling a broadcast every 10 seconds. But good to hear. mdns however should not really cause more dials, as it is only more discovery on the LAN (or should be).

10

Then this there might be a placebo effect going on. But I didn’t have any reboots yesterday, as far as I can tell.

I wonder if it happens more often when go-ipfs just started (say in the first hour or so), when it’s (presumably) making the most connections.

I will try to measure it more actively, by doing an automated ping every 30 seconds or so and counting the number of failures over time.

11

ipfs dht findprovs <Qm_some_unexistent_hash> will trigger dht walks. Say you launch a few of those continuously, you might artificially increase the number of concurrent dials and then see if the router gives up.

12

I will try it.

Thanks for all the help so far :slight_smile:

13

Turning MDNS off is doing something.

I logged internet outages (i.e. reboots) now and with the setting turned on I got multiple per hour. With MDNS turned off I get none.

In both cases I was trying to get a file that is temporarily unavailable, and running ipfs dht findprovs in a loop.

So, I’m happy the reboot issue is finally resolved for me. The question that remains, of course, is: why does this work?

14

Honestly, I checked the MDNS code and it just makes a broadcast per interval and handles any responses. There is nothing flooding MDNS from the IPFS side… I would be interesting to have a look into wireshark to see if something is going on on your network.

Maybe is some other device screwing things up somehow indirectly triggered by IPFS, or the router is simply horribly buggy.

15

I can check. Should I then be looking for any multicast packets?

16

Yeah, or otherwise I would just look in general to see if there’s something fishy…