I am using Chia version 1.3.5 and up to a week ago I was getting a full set of Peer connections. Port 8444 is open. There were the usual 8444/8444 entries and a whole bunch of xxxxx/8444.
I have upgraded my internet connection and now have a new static IP address. I still have the 8444/8444 entries but only one or two of the xxxxx/8444 and these seem to come and go. The port is still open.
1: Does the IP address change screw things up?
2: Does it matter anyway?
3: Will it eventually sort itself out?
4: I have tried adding the introducer node into the list but debatable as to whether or not this make a difference.
5: Seem to be getting a lot of Wallet entries in the list instead of Full Node. Is this relevant to anything?
If wallets can connect, it implies that peers also should be able (both use the same port, the same protocol). So, give it some time (a day or so) to calm down.
The Wallet connections are all xxxxx/8449, so using a different port.
Is that a clue?
And just noticed that in the config.yaml file, enable_upnp is set to true. This has never been changed, but could it now be causing a problem. I will try changing it to see if it makes any difference. upnp is turned off in the router.
It has now been in this state since the IP address change which was a week ago.
That’s just chia UI that is kind of worthless in this respect to that column (you would need to use netstat instead).
Basically, you have five types of connections:
- peers connecting to your full node via port 8444
- your full node connecting to other peers via port 8444
- your wallet connecting to your full node via port 8444
- your wallet connecting to external full nodes via port 8444
- other wallets connecting to your full node via port 8444
The outbound ports are random for all those connections.as such there are no 8444/8444 connections.
I am not sure what takes precedence in the code, but UPnP is basically the same as manually port forwarding external port 8444 to your box local port 8444. So, it is kind of redundant to have both of them. However, if it worked with the previous IP, all that routing has no clue about that IP change, and works as before, so all should be good.
If you kill port forwarding on your router, and disable UPnP, your port 8444 will be closed, and you should not see external wallets anymore (#5 above). Also, #1 will not be possible. However, your full node will still be making connections, and #2 looks in UI exactly the same way as #1, and there is no difference in functionality (from node’s point of view). Although, the max number of connections for inbound peers by default is 80, where for outbound is just 8 (or at least that used to be 8). If you kill both port-forwarding and UPnP, it is best to increase the max outbound peer number (to the value that your node tolerates).
The LAN part is oblivious to WAN part, so IP changes should not affect anything (as long as you operate on port level). Although, the introducer may have some lag, but that should not be too long (say hours max, if not just short minutes - although not seeing the code it is hard to be sure).
Although, you may want to reboot your router to eventually flush it (what I assume you have done already when changing the external IP part).
If in doubt. You can kill your port forwarding, and disable UPnP. This should make your node to settle on those 8 outbound ports. Once you see it stabilize (it is a slower process (a day or so), as not all nodes have open ports), you can bump the number of outbound connections to 20 or so, and check how your node will respond (another day). Once you see it hitting 20 connections, you can either port forward 8444, or enable UPnP, and that should quickly bring external wallets and the number of peers should go over 20 (if you increased it).
Your node will be working perfectly fine with all those settings, as opening port 8444 is optional, although highly recommended (for the health of network, not the health of your node).
1 Like
Thank you for all the information. Funily enough, about half an hour after my previous reply I won a block. So that at least shows everything is working as it should.
1 Like
So in summary what is the best set up for upnp and forwarding?
There is really no “best setup” as it really has to reflect what you have, what are your priorities. The first two criteria are what is good / enough for your node, vs. what is needed for the network.
For the health of your node, you don’t need neither port 8444 forwarded, nor UPnP enabled, as your node will be happy as a clam making outbound peer connections. Depending on your node capabilities, you may specify what is the upper limit for all connections (whether in- or out-band). Bear in mind, that this needs to adjust to handle dust storms.
When you consider the health of the network, having that port open is a must (if all nodes will close that port, there is no more network).
However, this is where things get interesting. From farmer’s perspective, the only thing that matters is the health of the harvester and farmer, as those two components are dealing with earning pool rewards (if pooling), and winning the blocks. So, the blockchain is just a tool, and how it works, really doesn’t matter. On the other hand, from Chia’s business side, the health of the network is the most important, not really farmers winning or even being healthy (if there is enough mass in the network, it can tolerate a big amount of crippled nodes - e.g., all those glory statement how well the network survived those first dust storms, when about 50% of nodes were knocked off).
As JM stated in his last video, 'farming is a competitive thing" so to extend his statement, the farmer should optimize not just for how disks are being run, but also how to minimize full node requirements. This basically says that to be competitive, the best setup would be one that doesn’t require the full node at all - e.g., something like Flex Farmer. Actually, looking deeper into this, Chia claims that “small farmers can utilize their overprovisioned hard drive space.” Such no full-node setup is really what could/would enable such small farms, although it doesn’t directly contribute to the network (indirectly, the more people are involved, the stronger the ecosystem is - what is basically lost in all those discussions). unfortunately, this model breaks the incentive model that Ciha put in place (no incentive for running a full node).
So, going past all of that, I would really start with both port-forward and UPnP disabled, and number of outbound peers increased to 20-40 or so (more than good enough to successfully run a farm).
If that would work well, I would check with your router, whether UPnP is already enabled on it. If it is (by default it is on all commercial routers), and you don’t want to deal with DHCP settings, etc., I would enable UPnp. This way, you don’t need to worry about that port if anything changes inside of your LAN (e.g., you change the full node box). On the other hand, if you don’t have UPnP enabled, or you don’t want to have it enabled, than port-forwarding is the only option to make that port open. When you will be doing these changes, you may also specify what is the inbound max for connections (will depend on what CPU / media for your bc db are).
If you have more than one full node on the network, than you will not be able to port-forward to two boxes, as the router has no clue what goes where. My understanding is that the UPnP will also not work. So, the only solution is to make all but one full nodes to be outbound only.
1 Like
Thank you for your detailed and very useful explanation. I see that disabling upnp and port forwarding is a better way. So I think I should edit upnp to false in config file. Other than that do you advice some other changes in config file (other than increasing outbound connections to 20-40) ? Thanks again.
You welcome.
The fact that port 8444 is not open is maybe not the most optimal from the network point of view; however, increasing those outbound ports also contributes to network health. So, let it run with whatever you have right now, and if the full node is really bored, bump it up by 10 or so. Just remember to check on the CPU usage / node seeing “bad” peers during the next dust storm, as that is really when the rubber meets the road. This is part of a standard network handling, but chia fails here as well.
I guess, the only other setting that I am concerned about in config.yaml is how often drives / folders are being scanned. The old setting was just one liner, and it was checked every time a new scan got triggered. The new setting was introduced long time ago, but unless config was either regenerated or that change was brought in manually, it is missing. From my point of view, if you are not plotting, there is no point to scan those folders every 2 minutes. So, I would increase that value to several hours / once per day. If needed, it can be triggered manually, so no problem to extend that timeout.
As far as your other concern (that receiving address) the behavior you explained there is correct (not saving it). As it was explained by others, every time you want to make an outgoing transaction, you should be using a new address. If you want someone to xfr XCH to you, also generate a new one. Whatever you used before, you should consider spent, and not worry about those - forget those. On the other hand, you may want to save somewhere your receiving address that you are using for your pool and .25 rewards, just to maintain some sanity. Of course, you can change those from time to time as well, but keep them saved, so you know that your setup was not messed up with. If you need to do some accounting, the best way is to go directly after your wallet, as that is the only place that understands all those spent addresses, or rather what came in and went out. All the bc explorers out there, unfortunately (or maybe fortunately) can trace only one such address at a time.
1 Like
Jacek, I made all the edits you told me and a few hours later I found a block!!! How to explain this I dont know. Winning after 80 days (estimate:19).
Thank you so much. Now I am sure that I have a good setup. 
1 Like
Happy to see you breaking your dry spell.
Don’t know what you had before, but it just shows how luck works. Hopefully, the rest of us stuck at about 5x will break it soon.