2

I have the dogecoin daemon running successfully on Ubuntu, started with this command:

dogecoind -daemon

It's listening on port 22556, as verified by netstat.

I can also pass commands to it directly via the Ubuntu terminal, like so:

dogecoind getinfo

However, passing RPC requests to it through HTTP does not work. The daemon doesn't refuse the connection (and I can verify that it does refuse the connection if I use a port other than 22556); instead, the connection hangs, with no data being sent to the client making the HTTP request. Directly connecting to

http://a:b@127.0.0.1:22556/

makes the web browser sit and wait for data. Similarly, making an RPC request via a PHP script, and then accessing that script in a browser, makes the browser wait for 30 second before PHP spits out an error stating that the maximum execution time of 30 seconds was exceeded.

I have my ~/.dogecoin/dogecoin.conf file as such:

server=1
rpcuser=a
rpcpassword=b

(I know the username and password I typed there are insecure; those are temporary until I can at least make a connection.)

I've tried adding the line 

rpcallowip=127.0.0.1

to the end of the config file, but that didn't change the behavior at all.

What am I doing wrong -- why isn't my Dogecoin daemon accepting RPC requests (or any from-an-actual-browser HTTP requests, for that matter)?

edit: Also, I can verify that the daemon is caught up with the blockchain.

Improve this question
2
  • 1
    rpcallowiip=0.0.0.0 That is an unsafe configuration if you are listening on a public ip address space. The address map 0.0.0.0 is shorthand for allow connections from all hosts. If you are running in a NAT environment you may be ok for the time being as long as you arent' sharing the network with any unknown hosts. (ie a dorm room network) Casey
    – user11445
    Dec 26, 2013 at 18:56
  • @unklStewy: Ah, thanks for pointing that out. I'll be sure to change it before going to production.
    – Josh1billion
    Dec 31, 2013 at 19:50

1 Answer 1

Reset to default
1

Figured it out. It had to do with adding rpcallowip lines to the config file. Adding these three lines solved it:

rpcallowip=127.0.0.1
rpcallowip=192.168.1.*
rpcallowip=0.0.0.0

The last line is what eventually allowed it to work. I'm not sure why, but netstat said it was listening on 0.0.0.0:22556, so adding 0.0.0.0 to the rpcallowip list solved it.

Improve this answer
2
  • 1
    That's because 0.0.0.0 in network speak essentially means "all IP's". So you've basically allowed all IP's to connect to your RPC server.
    – taco
    Jan 27, 2014 at 2:19
  • Thanks for the information. I've since removed it to make sure that vulnerability doesn't exist. As far as the actual fix, I'm not sure what the issue was. Running a new installation on a different server, I haven't experienced the same issue that I originally posted about.
    – Josh1billion
    Apr 30, 2014 at 22:12

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.