Topic: Monero Support - page 23. (Read 82975 times)

Thanks. My router and firewall has been opened, but I still get this error when running bitmonerod:


What could I be missing? bitmonerod was compiled from the current Github source.

18080

but your router might already be forwarding due to upnp magic.. some plug and play thing. But manually setting it never hurt anyone.

also be sure to open that up in your firewall.

windows, make your way to windows firewall

ubuntu,

sudo ufw allow 18080

Which ports if any do I need to forward on my router to a machine running a monero node?

It will unlock its self u just need to wait.

Did you try the --no-igd option


That's --no-igd in Monero.

Most coins use miniupnp for their UPNP sitff, local internet providers have never yet provided me a modem it works with. But then again I have also tried downloading other PNP programs to examine the modems and still never found any of the local providers modems to work.

Maybe your modem is even worse, and is being acticely screwed up by the UPNP attempts.

Most coins you can compile them with USE_UPNP= to totally leave out the UPNP support when compiling.

If the UPNP support is compiled in, usually there is a way to turn it off at runtime.

If you have not tried running it with no UPNP it is probably at least worth trying.

Basically the program tries to use plug and play of some kind to talk to the modem, assuming it understands some kind of plug and play protocol (which also you can usually enable and disable in the mode itself), it tries to ask the modem to open an incoming port for it.

If you want an incoming port you can set it up manually in the router, provided you also have the router assign the machine a known IP address instead of a random one, so you know which IP to route the port to.

-MarkM-

For kicks, can you try seeding a popular linux distro for an hour and see if that causes you any problems? http://linuxtracker.org/ - kali-linux-2.0-amd64.iso is a good example with hundreds of leechers.

I really find it hard to believe that your equipment is healthy given what you describe.

I don't see how the modem can be busted. It works totally fine otherwise, right up to the moment I start up bitmonerod. Nothing else has caused me problems like this. (Including syncing blockchains from other cryptos) But I am struggling to understand how this can be happening, Its very odd for sure.

edit: I tried recompiling with latest code but no difference.. Surprised I'm the only one to discover this problem. Anyway ,  maybe i'll investigate some lightweight clients or something but I'm not going to go any further trying to get the daemon to run. 

This seems like a very explicit, defined, tangible and surmountable code flaw with (apparently) an obvious increase in user experience satisfaction - a faster syncd blockchain. Hrm, I wonder if Dr. Moo is interested....

Clearly your modem is busted. There is no way that running a program, whatever program that happens to be, should cause your modem to crash. You can try --no-igd if you haven't already though. Maybe your modem has a bug in its UPnP.

Appreciate all the help but still no joy for me I'm sorry to say, modem still crashing ..

Everytime I start up bitmonerod the modem crashes and even fails to restart, crashing again repeatedly. I found that ff I start the daemon, then physically unplug the modem, wait a few seconds then plug it in again then the daemon seems to start synching after first showing lots of exception messages in red font while waiting for modem to come back online. which is the only way I can manage to get it kicked off.

After doing above method when it started synching I did print_cn and found a list of connected hosts which seemed to look good, there were about a dozen of them I think.

So I then tried starting bitmonerod with the exclusive node option as described above picking one of the IP:port in the list but same thing happens, modem crash straight away even with just the one host connected.

I repeated the exlusive node with a few different IPs but that made no difference, still crash straight away.

Makes me think the problem is not being overloaded with too many connections but something else. Perhaps I should grab code and re-compile again ? could there have been another bug in the version I lifted?

I just had to sync a node that was offline for a long time so I'll summarize how I optimized the process. None of this is necessary, but this method is efficient and safe:

1. Choose a node that is reliable and has good bandwidth. How you do this is up to you, trial and error if nothing else. You can start the node, look in the print_cn list, and then kill it to get some candidates for example.

2. Start daemon with --add-exclusive-node [IP:port] --p2p-bind-ip 127.0.0.1

3. Wait for daemon report synced. You can use the print_cn and diff command to check status/progress or set_log 1 to see blocks being accepted. If you find blocks being accepted at a slow rate (or stopped) you may return to #1 and choose a different peer.

4. Exit daemon cleanly

5. If you have not had the daemon running previously (before steps #1-4), delete p2pstate.bin if it exists. If you have previously been running a daemon but were just offline for a while, you can leave p2pstate.bin alone.

6. Restart daemon with no connectivity options

7. Wait for daemon to report synced.

8. Check print_cn to ensure you have multiple connections (ideally 15 or more, including some incoming "INC" connections) and they are all in a normal state.

#1-4 will get you synced quickly but are not secure. #5-8 take very little time/bandwidth (under normal conditions where the original node was not broken or hostile) and ensure you are securely synced to the live network.

This complex procedure is only needed if you really want to optimize your syncing, especially if offline for a long time. Normally the default method will work fine for most people, and using the latest development versions from github it is extremely fast. The older release versions are not.

Background: The daemon doesn't do a very good job of receiving blocks from only one peer when syncing. There is code to do this, but it isn't entirely effective, so if you are connected to multiple nodes, you will often receive the same blocks from each of them, increasing bandwidth and paradoxically slowing down the syncing process. By connecting to one node during syncing you always eliminate the extra bandwidth from multiple copies and potentially reduce the slowdown, but the latter require that the peer node be able to keep up with your download speed.

In answer to question about router I'm not going through a separate router, (although the modem itself has a built in router).

Thanks for the suggestions will try a bit of troubleshooting later on when I get time.

Far safer to pick 2 or 3 at least so one broken node doesn't cause yours to end up unsynced. Starting with one is okay for troubleshooting though, but for actual use not recommended.

Also to limit total connections you need to block incoming connections on your firewall (software or hardware) since --add-exclusive-node only applies to outgoing.

1. as stated above, there are options for modify your bitmonerod to do less. If you're in windows, type bitmonerod.exe --help , it will print out a list of commands. If linux, ./bitmonerod --help , or the flag might be --h... either might work.

2. are you going through a router or straight through to the modem? I don't know why i think this will matter, but, details.

3. and this is the most important thing. You're monero are safe whether or not you are running the daemon. Running a daemon supports the network and allows you to create transactions.   


All you need to do is have the private keys to your monero account. You do not need to run the daemon to do this. In fact, you could run simplewallet without the daemon, create an address, and then send your exchange monero to this address without running the daemon. Granted, you wouldn't be able to verify that the monero is in your personal account, but if you copied the address correctly, it should be there.

So, you could run the daemon, verify that your monero are in your personal account, and then turn off everything forever. Your monero are still on the blockchain. If you copied your key files and loaded them on another computer, you would have access to your monero.

You could get your list of peers and pick one to connect to rather than allow for lots of connections by using --add-exclusive-node argument. If for nothing else, it could be helpful for troubleshooting.

What happens is when I start bitmonerod  my modem will randomly disconnect then automatically turn back on. The lights will go off and then slowly blink back until they are all on and then my connection is fine again. But this keeps repeating and usually happens when I first start too.

I've read online this sort of thing can be caused by some programs (e.g. BitTorrent, certain games and bitmonerod ) can open too many connections, overloading your modem, causing it to crash ?

Could it be my modem is getting overloaded with connections like that described? is there some config setting I can try lowering ?

Its a BT cable modem. Really offputting the way it keeps resetting. I don't really think to continue with it doing this.

Unfortunately starting to look like Monero not for me, yet at least.

I do have some monero but don't want to leave them on exhange is there some light wallet I can use where the monero are held on my machine but I dont' need to run the bitmonero daemon ?

I used bitmonerod with 4 different routers and there were no problems. Is there any chance you using a Belkin router? There are a lot of problems with any pear to pear program and most of the games with Belkin.

cable modem?

are you going through a router?

i haven't experienced this type of phenomenon.