When bitcoin-qt is syncing the blockchain, eventually the wireless will stop taking new http (or IMCP) requests. open connections still transmit data fine and DNS lookups resolve. Exiting the bitcoin client causes the wireless to resume working after about a minute or two.

I've been in contact with the open-mesh support team for quite some time about seemingly random wireless dropouts but the discovery that starting the bitcoin client dependably reproduces the problem for me gives me a technical path to target.

So a couple questions...

Has anyone ever seen anything similar happen when starting bitcoin on your network?

What might bitcoin be doing during the blockchain download that could cause something like this to happen? I know there are 8 connections and some downloading going on, but it can't be any more of a bandwidth hog than a big youtube or movie which both download fine without causing the network brownout.

As far as I know, network devices can handle certain number of connections at any one time. Bitcoin is based on a P2P protocol and as a result it opens many connections to different networks. That could cause the routers to slow down or even reboot if they can't handle that number of connections. Maybe that is your problem. The only solution I see, is to limit the number of connection that bitcoin-qt tries to open, but I don't know if this can be done or how.

When bitcoin-qt is syncing the blockchain, eventually the wireless will stop taking new http (or IMCP) requests. open connections still transmit data fine and DNS lookups resolve. Exiting the bitcoin client causes the wireless to resume working after about a minute or two....Has anyone ever seen anything similar happen when starting bitcoin on your network?

I have no idea, but couldn't it just be that the machine you're using is not handling the load?I mean, bitcoin-qt does a lot of disk IO during blockchain synchronization. Maybe your OS ends up doing lots of swap too and it stops accepting new TCP connections because it is not managing to handle it? I don't know, just trying to guess.Maybe the best way to test would be using a SDD. Or with the blockchain in a different disk than the rest of your system, including swap.

I have no idea, but couldn't it just be that the machine you're using is not handling the load?I mean, bitcoin-qt does a lot of disk IO during blockchain synchronization. Maybe your OS ends up doing lots of swap too and it stops accepting new TCP connections because it is not managing to handle it? I don't know, just trying to guess.Maybe the best way to test would be using a SDD. Or with the blockchain in a different disk than the rest of your system, including swap.

I'm on a Core i7 with dual SSD's and 24GB of RAM.

But I don't think that would be it anyway. When it goes down, the entire mesh network goes down. I am connected to the Mesh Gateway router so I think I'm taking that down with Bitcoin. When that does down, none of the other mesh routers can talk to the gateway.

At the same time, a computer connected to the dsl directly pings out fine.