Hot answers tagged

11

White peers are online and reachable and grey peers are offline. The longer period of time it has been since you last used your daemon, the more grey peers you are likely to see. White peers that fail to upgrade during a hard fork are (eventually) dropped from the network and become grey. People move and change VPS hosting providers, so peer status will ...


9

It's a two way connection, the IN refers to connections initiated by the peer, and OUT refers to connections initiated by your node, but communication is duplex. In that status command, the X+Y part is X OUT connections and Y in connections. You're connected to all of these nodes, the only difference is which side initiated the connection.


7

A node will connect to up to 8 peers by default (P2P_DEFAULT_CONNECTIONS_COUNT in src/cryptonote_config.h). I think there is no set limit of incoming connections, though if a lot of peers try to connect, you might end up hitting your open files quota. The more peers you are connected to, the more traffic you will have to propagate blocks and transactions. ...


4

There is no command to permanently ban, but you can set a lengthy ban time using the daemon command ban <IP> [<seconds>], or using the RPC method set_bans. So if you set the seconds parameter to 4294967295, that will ban for just over 136 years.


4

Pretty sure that's how it works. You can also use the command "status" and you'll see at the end of the line a number like "8+1" this shows the number of nodes you are connected to, and after the + shows the number of nodes you are serving.


3

You can set the number of your daemon outgoing peers (ie, peers it connects to) with the command line parameter --out-peers. The default is 8. For having incoming peers, you need to open up your firewall for your daemon's p2p port (typically 18080). I think you cannot limit the number of incoming connections. For limiting the traffic for all of these ...


3

As a partial answer, here is a list of reverse DNS lookups followed by their respective WHOIS owners: 107.152.130.98 > monero.cc > Riccardo Spagni 212.83.175.67 > poneytelecom.eu > Unknown 5.9.100.248 > your-server.de > Martin Hetzner 163.172.182.165 > scaleway.com > Unknown 161.67.132.39 > Unknown 198.74.231.92 > Unknown 195.154.123.123 > poneytelecom.eu > ...


3

I was suffering from something similar yesterday. When I turned my OS X firewall off, I got the incoming connections back. When I turned it back on, I got 0 incoming connections again. To fix it, I ended up forcing port 18080 open using this guide. Scroll down to the 10th comment if you need help using Vim (I did). I turned the firewall back on and I got ...


3

... --add-peer node.supportxmr.com:18081 --add-peer arg is the correct parameter, however, by the peers you are trying to add it's clear you are using the other peers RPC interface, not their p2p interface. The p2p port is 18080. --add-peer arg is for adding p2p peers. Also, But after requesting get_connections to rpc node ... You can check which ...


3

Since those peers are hardcoded into the Monero software, could a malicious ISP intercept initial communications by redirecting traffic to those peers? Sure, to another valid Monero node. Traffic NAT'ing happens all the time. Would this be detectable? I don't see anything in the codebase that reaches out to STUN, etc. to determine its outside IP (and ...


2

I figured out what my issue was. I checked my ufw rules, and there was no rule for allowing port 18080. After allowing that port and reopening monerod (not sure if that was necessary), I'm quickly up to 7+44. (@TFI_Charmers, thanks for the push to double check the firewall.) I don't know why ufw allowed it previously, with no rule, but it must have. ...


2

This does not try all entries in the set, it picks one entry in that set.


2

You are referring to seed nodes. These are the set of hardcoded peers a fresh user will first request other peers from and is a common problem for all P2P networks - how to discover other peers on first usage. Whilst these are coded in as a convenience, once you have found other peers, your node remembers its last known peers and is constantly looking for ...


2

1) Not that I know of. 2) & 3) One way would be to make use of the built-in monerod commands and a little scripting. E.g. monerod bans | awk 'NR>2 {print $1}' > bans.txt Gets a list of any currently banned IPs. After you have restarted monerod, you could then: cat bans.txt | while read ip; do monerod ban "$ip"; done Which will re-ban them all....


2

Theoretically if no node accepted incoming connections then the network would be limited to transactions originating from any of the aforementioned nodes. The network would survive as miners would still process those transactions. The biggest effect would come in the loss of third party services that require a remote node to operate (for example some light ...


1

This file contains the list of peers the node knows about, along with the time they were last seen. Deleting it clears that memory, and the node will have to rely on seed nodes to get a new list of peers. Keeping this file means that you don't have to rely on the seed nodes to be able to connect to the Monero network, as you already know of a large number ...


1

We can't tell without more information. If you'd left monerod not running for a long time, it's plausible that it'll try to contact nodes which were running, but are not (either they're now down, or they were on dynamic IPs which changed since, etc). It is also possible that peers banned your node. This would normally only happen if your node is on a bad ...


Only top voted, non community-wiki answers of a minimum length are eligible