Can't detect valid external address - unable to start MN

Curacao

New Member
Feb 23, 2017
16
3
3
29
Dear Community,

I've come here to find help with our masternode. Ever since the release of 0.12 we're unable to start our masternode. We've done a complete reinstall and used the previous dash.conf file. However we are unable start the MN. The error we're getting is:
Not capable masternode: Can't detect valid external address. Please consider using the externalip configuration option if problem persists. Make sure to use IPv4 address only

Our conf file looks as follows:
pcuser=REMOVED
rpcpassword=REMOVED
rpcallowip=127.0.0.1
listen=1
server=1
daemon=1
logtimestamps=1
maxconnections=256
masternode=1
externalip=190.RE.MO.VED
masternodeprivkey=REMOVED

We have not changed anything in our network setup. Basically it's running on a host behind our router/firewall which has port TCP 9999 forwarded to this host. This worked fine previously.

Kindly please advice us how to proceed.

Regards,
 

dashren

New Member
Aug 26, 2015
16
16
3
Try format maternode.conf as the clue inside the file on local node.
let dash.conf empty.Active the node from "masternode" menu on main page.
 

oaxaca

Well-known Member
Foundation Member
Jul 8, 2014
573
832
263
Does the line in your dash.conf look like

externalip=190.RE.MO.VED

or

externalip=190.RE.MO.VED:9999
 

Curacao

New Member
Feb 23, 2017
16
3
3
29
To answer oaxaca:
Without the port number, thus for example:
externalip=190.1.2.3

I'm going to re-try with the latest release now, I will try to get some relevant debug output.
 

lynx

Active Member
Dec 11, 2015
364
250
133
To answer oaxaca:
Without the port number, thus for example:
externalip=190.1.2.3
There is your problem, the port number needs to be there. For example:
externalip=190.1.2.3:9999
 

TanteStefana

Grizzled Member
Foundation Member
Mar 9, 2014
2,871
1,863
1,283
The dash.conf file is for the remote / server side (the computer that stays on with a running dashd node) But the local, funded wallet needs the masternode.conf file. Do you have it set up this way? Make sure you're following a current tutorial, like the ones on the Dash wiki (posted by tungfa)
 

Curacao

New Member
Feb 23, 2017
16
3
3
29
Hi All,

Over the weekend we've tried it various ways, including with and without the externalip option, also with and without port. The remote wallet (with the 1000 dash) uses the masternode.conf as described in the documentation, and is started with "start masternode alias mn1" (if I remember correctly). We get a "success" message, and the masternode is trigered and quickly fails as it somehow can't detect and/or connect to the it's external IP. See debugging output:

2017-03-03 23:13:55 AcceptConnection -- masternode is not synced yet, skipping inbound connection attempt
2017-03-03 23:13:55 CMasternodeBroadcast::Update -- Got UPDATED Masternode entry: addr=190.1.2.3:9999
2017-03-03 23:13:55 CActiveMasternode::ManageStateInitial -- Checking inbound connection to '190.1.2.3:9999'
2017-03-03 23:14:00 CActiveMasternode::ManageStateInitial -- NOT_CAPABLE: Could not connect to 190.1.2.3:9999
 
Last edited by a moderator:

lynx

Active Member
Dec 11, 2015
364
250
133
What about the output from

dash-cli mnsync status

on the MN?
 

Curacao

New Member
Feb 23, 2017
16
3
3
29
Here you go:

$ dash-cli mnsync status
{
"AssetID": 999,
"AssetName": "MASTERNODE_SYNC_FINISHED",
"Attempt": 0,
"IsBlockchainSynced": true,
"IsMasternodeListSynced": true,
"IsWinnersListSynced": true,
"IsSynced": true,
"IsFailed": false
}
 

lynx

Active Member
Dec 11, 2015
364
250
133
Everything seems to be in working order. Dash Ninja even reports your port to be open, I don't know what could be the problem. Why don't you give it another try?

@UdjinM6
 

Curacao

New Member
Feb 23, 2017
16
3
3
29
Wallet says successfull, mn says:

$ dash-cli masternode status
{
"vin": "CTxIn(COutPoint(0000000000000000000000000000000000000000000000000000000000000000, 4294967295), coinbase )",
"service": "190.1.2.3:9999",
"status": "Not capable masternode: Could not connect to 190.1.2.3:9999"
}
 
Last edited by a moderator:

lynx

Active Member
Dec 11, 2015
364
250
133
Hum... now it's reporting watchdog expired. Are you running sentinel? Does it give out any errors? Is it called successfully every minute on cron?

watchdog.png


Edit: Added image
 
Last edited:

Curacao

New Member
Feb 23, 2017
16
3
3
29
Hi Lynx,

It runs every minute through cron, and outputs:

"Invalid Masternode Status, cannot continue."
 

lynx

Active Member
Dec 11, 2015
364
250
133
I can't help any further. I would upgrade to 0.12.1.3, upgrade sentinel, and retry everything again, maybe even send the Dash to a new address and regenerate the MN private key. If it doesn't work, e-mail [email protected] with relevant debug logs and diagnostics.
 

UdjinM6

Official Dash Dev
Core Developer
Dash Core Team
May 20, 2014
3,639
3,537
1,183
I believe it's smth about the way router is configured i.e. it probably cuts connections from inside to its own outside address. I think you need to specify this route explicitly in router config to make it work.
 

Curacao

New Member
Feb 23, 2017
16
3
3
29
Hi UdjinM6,

I thought so too, but I've made sure port TCP/9999 forwards on both the internal and external interface. In my firewall I can actually see the count of "internal" connections that have been forwarded back to the node. Again, this worked fine before 0.12.1.
 

UdjinM6

Official Dash Dev
Core Developer
Dash Core Team
May 20, 2014
3,639
3,537
1,183
I'm not sure why tbh, I can't reproduce this...
Do you have UPnP enabled on your router? If so, try -upnp flag (or upnp=1 in dash.conf).
 

Curacao

New Member
Feb 23, 2017
16
3
3
29
Hi Udjin,

So I think there are some DNAT issues here to blame, apparently packets aren't recognized by the MN host, probably because the source IP is itself:
MN --> Router [DNAT Back to MN] --> MN

I've implemented a quick and dirty fix by adding our external IP to the host as a virtual additional IP:
inet 190.4.184.180/31 brd 255.255.255.255

This appears to be working as of now.
 
  • Like
Reactions: UdjinM6

UdjinM6

Official Dash Dev
Core Developer
Dash Core Team
May 20, 2014
3,639
3,537
1,183
Hi Udjin,

So I think there are some DNAT issues here to blame, apparently packets aren't recognized by the MN host, probably because the source IP is itself:
MN --> Router [DNAT Back to MN] --> MN

I've implemented a quick and dirty fix by adding our external IP to the host as a virtual additional IP:
inet 190.4.184.180/31 brd 255.255.255.255

This appears to be working as of now.
Thank you for the provided solution!
 

Curacao

New Member
Feb 23, 2017
16
3
3
29
Hi Devs,

I've given this some thought:
I have some concerns as to how dashcore currently checks it's external IP and availability through this address at the moment. This works fine for (master)nodes directly on the internet (say VPS'es), however for nodes behind routers (with NAT) this is an issue according to my findings. I can't think of an fix other than the dirty fix I mentioned above.
If Dash truly wants to be decentralized people should be able to run nodes in their SOHO environment, thus the software should be able to recognize it's external IP and somehow (if necessary) check it's availability through that externalip:port. I believe my set-up isn't common at this time, but I think the software should be able to run in such set-ups as mine.

Feedback appreciated.
 

UdjinM6

Official Dash Dev
Core Developer
Dash Core Team
May 20, 2014
3,639
3,537
1,183
Hi Devs,

I've given this some thought:
I have some concerns as to how dashcore currently checks it's external IP and availability through this address at the moment. This works fine for (master)nodes directly on the internet (say VPS'es), however for nodes behind routers (with NAT) this is an issue according to my findings. I can't think of an fix other than the dirty fix I mentioned above.
If Dash truly wants to be decentralized people should be able to run nodes in their SOHO environment, thus the software should be able to recognize it's external IP and somehow (if necessary) check it's availability through that externalip:port. I believe my set-up isn't common at this time, but I think the software should be able to run in such set-ups as mine.

Feedback appreciated.
Well, it's already able to recognize its external IP from other peers or from settings, that is not a problem. The problem is connectivity - it no longer connects to whatever self address is, it connects to exact external (and only external) IP now. Given the fact that it's possible to setup a mn with the fix you provided, I think it's actually ok. This kind of initial connectivity check is not a perfect indicator of masternode capability to provide services anyway, we are going to move to a much more sophisticated model in Evolution which will account actual service requests served by each mn and determine its status based on that (or at least that is how we try to design it now). Consider this current low level verifications as a band-aid until we have a better model in place (the one I just described).
 
  • Like
Reactions: Curacao

Newar

New Member
Oct 2, 2015
16
4
3
After looking at several "things", I got a feeling that I have the exact same issue.

Could you please elaborate a bit on:
[...]
I've implemented a quick and dirty fix by adding our external IP to the host as a virtual additional IP:
inet 190.4.184.180/31 brd 255.255.255.255
[...]
How do you do that?
 

Newar

New Member
Oct 2, 2015
16
4
3
Searching for inet 190.4.184.180/31 brd 255.255.255.255, Google revealed this thread: https://arstechnica.com/civis/viewtopic.php?t=149666 . If I understood it correctly, it recommends against this method. However, another method was offered:
Code:
iptables -t nat -A OUTPUT -s XXX.XXX.XXX.XXX -d YYY.YYY.YYY.YYY -j DNAT --to-destination 127.0.0.1
where XXX is the internal IP of the PC and YYY is the external IP. This worked for me.
 
  • Like
Reactions: UdjinM6 and Curacao