Strange connection to a wallet in China - 112.3.134.115

Support
1

For several days, my node spits errors about that wallet (112.3.134.115). There are a bunch of related entries, but this one error is coming every 10 minutes or so. I did reboot my node, but it is still clinging to that wallet / IP. Looking at the Connections tab in the UI, I have never seen that IP there. I also don’t have that error for any other IP, just this one. Anyone else noticed that, or rather this is just something that is coming from my wallet’s peers db. Here is the error:

2022-01-08T12:27:55.959 full_node full_node_server : ERROR Exception: Optional must be 0 or 1 <class 'ValueError'>, closing connection {'host': '112.3.134.115', 'port': 8449}. Traceback (most recent call last):

2

Don’t have that error. Could be someone running a wallet-only that has no local node to connect to and want to connect to yours. You can run wallet-only, never tried it and it seems a bit strange if it would use a node somewhere else to scan the blockchain for transactions.

1 Like
3

I believe I’ve seen that before, but just ignored it as it didn’t really impact me, and was just the their ip disconnecting.
Seemed to happen over and over for a while though with the same ip.

1 Like
4

Thank you guys!

I don’t have any chia ports open, so that is my node trying to connect to that IP. The only way to get that IP is through introducer.chia.net (at least for now). Maybe the reason that my node cannot connect to it is that it is running some really old chia version (that node/wallet).

It is happening like that for the past two-three weeks. I had a handful restarts during that time, and just this one persists. It kind of correlates with moving from v1.2.6 to v1.2.10/11, though.

Although, there is over 300 k nodes out there, so chances that @Bones also have seen it is kind of really remote. But, if that is related due to an old chia version, maybe no one can connect to it, thus somehow it managed to get to the top of the introducer.chia.net list.

Still, my take is that those type of errors (cannot connect to a peer, or abrupt disconnection) should be moved to DEBUG level, as having nodes not permitting to connect (got full right after talking to introducer), or disconnecting (e.g., chia shutdown, etc.) is really not a problem for a node, but rather a part of how p2p protocol works.

5

To be clear, when I said

I meant seeing the same ip in my logs repeatedly, not that identical ip. ( knew I should clarify that ).

But, that said, that ip does look familiar, and I did also add nodes from that same introducer page, so maybe it was that same ip.

1 Like
6

And then I did something pretty stupid… and got away with it;-)

Wanted to do a quick test to see if a wallet-only can sync from the network if in config.yaml wallet is not pointed to localhost but to some other ip. And it does, started syncing from the network, where normally it uses the local nodes blockchain. Slowly but it does. Next I decided to cut the network connection on the node I pointed that wallet-only to (my main rig), effectively locking myself out as it runs headless and I connect remote to it… No other option than pulling the plug while running. Might as well do some ubuntu updates after getting back in though ipmi and the started the chia client… Node and wallet synced again so I call myself mr. Lucky, pfffff :grin:

2 Likes
7

If you look at config.yaml, there are thee entries related to how wallet connects:

wallet:
  ...
  full_node_peer:
    host: localhost
    port: 8444
  introducer_peer:
    host: introducer.chia.net
    port: 8444
  port: 8449

The first (full_node_peer) is how your wallet is connecting to your full node. The second (introducer_peer), how your wallet is building up its connections and how other wallets know about your wallet. The third (“port: 8449”) tells how to connect to it, if anyone is interested (other wallets are using this port to connect to your wallet).

With that said, if you do not want to your wallet connecting to your full node, kill the first entry (full_node_peer). If you don’t want it connecting to any other nodes, kill the second entry (introducer_peer). And if you don’t want to have other nodes connecting to it, kill UPnP on your router (or potentially kill “enable_upnp: true” inthe full_node section). Maybe that is the simplest way to test.

Some time ago, we touched on how wallet is syncing, as we both assumed that it only/mainly syncs from the local node. However, looks like that is not the case, as otherwise wallet syncing should be really fast. I guess, someone pulled security card, and suppressed other approaches. I think that approach was used to eventually prevent blockchain db being poisoned. However, my understanding is that regardless of what blockchain db the full node has (poisoned or not), the wallet db will not be built if mnemonics / fingerprint is not provided, although I cannot say that I fully understand security issues around that.

With all that being said, I do not quite understand why wallets need to connect to each other, not just to full nodes.

UPDATE:
I have killed that introducer_peer section, and after restart, wallet was not able to start (there was no wallet process running). Also, missing the wallet service, the UI never made to the fingerprint / mnemonics screen - just produced a spinner with a thickness of 0.013 for a wallet missing error.

1 Like
8

I think a wallet only needs to connect to a full node, any full node.
Preferably the localhost one in which case it can sync from that wihout even needing network connectivity. Tried this on a VM by adding a fresh wallet to a synced client and cut the network connection. Wallet started syncing from zero and kept syncing, only taxing the disc with the blockchain db. Off course when it catches up it needs the network connection to stay synced, but then the full node does actually.

Changed the localhost in wallet section of config.yaml to the ip on my main full node, kept port at 8444.
The wallet (chia start wallet-only )shows up in the connections list of the full node with xxxxx/8449 as port numbers.
I 'm guessing it can connect to any full node on the network with 8444 opened for inbound connections.

1 Like
9

Let’s take a look at my wallet connections:

|Type      IP       |Ports       NodeID      Last Connect      MiB Up|Dwn|
|FARMER    127.0.0.1|59997/8447  1be64b23... Jan 08 16:59:24      0.3|0.0|
|WALLET    127.0.0.1|60060/8449  8ea96b28... Jan 09 00:30:21      5.9|0.0|
|FULL_NODE 1.1.1.1.1|8444/8444   35763e1a... Jan 09 00:30:21      1.8|11.6|
|FULL_NODE 2.2.2.2.2|8444/8444   7802cb5e... Jan 09 00:30:21      2.1|16.4|
|WALLET    3        |58117/8449  046f0f5a... Jan 08 17:18:57      0.1|0.0|
|WALLET    4        |51032/8449  9159204d... Jan 09 00:26:53     59.4|0.0|
|WALLET    5        |18756/8449  93879614... Jan 08 20:32:49      0.0|0.0|
|WALLET    6        |25949/8449  98e24e37... Jan 09 00:29:39      0.1|0.0|
|WALLET    7        |56827/8449  e6b28b52... Jan 09 00:30:13      0.1|0.0|

As you can notice, in the local connections (node to wallet/farmer), the first port is random, and the second reflects open port specified for a given process in config.yaml. The reason that the first port is random, is that TCP/IP connection is originating from the node, and it is local, so it really doesn’t matter, what the node will use.

If we will use that as a guidance (which port is local, and which remote), we can assume that node-to-node connections are on both sides 8444, as on one hand our node want to be connected on that one, but it is also the port that the other nodes are opening, so on both ends (for convenience) we see the same port. (My understanding is that there is no need for such symmetry for TCP part, only for UDP, but whether random or the same it works the same way for TCP part.)

On the other hand, for all wallets, the originating port is random (and based on the local connection) it is the outgoing port for our node. On the other hand, the destination port is 8449, what is the advertised open port for wallet (in config.yaml). So, that port needs to be UPnP opened to allow such connection.

That supports your statement, that wallets only need connections to nodes; however, nodes originate those connections (as that output suggests). Although, I am not sure, whether those listed connections are also covering the wallet’s own connections, and/or there are any outbound originated ones on the wallet side.

I am a bit lost at this one. You have there xxxxx/8449 pair, that means to me that you got that output from the full node side, not really wallet, as port 8449 is there. Are you saying that you see such connection on the wallet side?

10

So I’m running a wallet-only on 192.168.2.13, with config.yaml’s wallet section full_node_peer changed from localhost to 192.168.2.100 (port left untouched at 8444).

On 192.168.2.13 iptraf monitoring shows a connection between 192.168.2.100:8444 and 192.168.2.13:49820

On 192.168.2.100 (my full node) however the connection is shown as

0xcdf83471a1e8f1..........        192.168.2.13          49820/8449     2.6/0     Wallet

So there seems to be some kind of knowlegde the incoming connection is a wallet, but it communicates over 8444 ?!? So maybe on the full node connections tab the …/844x does not really imply an ip port but rather is an expression of the (wallet) protocol used?

How did you get that output with the different WALLET x,y,z info?

1 Like
11

Yeah, we should have started looking at standard networking tools right away, not really trust what chia UI produces (at least, I assumed that what they produce is valid). That column heading is “Port” not really “some magic used to indicate whatever.” Also, the “Connection type” column already specifies “wallet,” so there is no need to specify the same thing in two places. So, I don’t really know why that 8449 is there. (Based on chia’s UI, I initially thought that somehow chia is maybe reflecting router ports, not local ones.)

I have compared netstat output with that from chia, and yanked out a couple of connections to peers and wallets for comparison (all other connections look the same):

netstat -abnq -p TCP
chia show -c

  TCP    192.168.20.145:60021   178.39.186.189:8444    ESTABLISHED	netstat
FULL_NODE                       178.39.186.189         8444/8444	chia
  TCP    192.168.20.145:60065   84.182.234.60:8444     ESTABLISHED	netstat
FULL_NODE                       84.182.234.60          8444/8444	chia

  TCP    192.168.20.145:8444    70.186.231.82:58117    ESTABLISHED	netstat
WALLET                          70.186.231.82          58117/8449	chia
  TCP    192.168.20.145:8444    112.229.254.23:51032   ESTABLISHED	netstat
WALLET                          112.229.254.23         51032/8449	chia

// my wallet connections - only local
  TCP    127.0.0.1:9256         0.0.0.0:0              LISTENING
  TCP    127.0.0.1:59990        127.0.0.1:59991        ESTABLISHED
  TCP    127.0.0.1:59991        127.0.0.1:59990        ESTABLISHED
  TCP    127.0.0.1:60060        127.0.0.1:8444         ESTABLISHED
 [start_wallet.exe]

Somehow chia states that port 8449 (one specified for wallet in config.yaml) is being used, but netstat is rather contradicting it (as well as iptraf you used). There is no single line produced by netstat that would have that port.

On the other hand, my wallet has port 9256 open to the world, but it doesn’t look like it is being used, instead my wallet connects to my full node via port 8444. ​I would put my money on netstat, in this case.

For all my full node peers, netstat shows a random high local port (standard), and 8444 remote port. That just confirms that the only connections that I have are outbound.

However, all wallets have random/high remote port (their ports), and local port 8444 (my node’s port). That would imply that all those wallets initiated their connection. (I need to check again, whether my router permits UPnP opening of port 8444, as I think this is the only way to get it working.)

The strange part is that my wallet is only connecting locally to itself on ports 59990/1, and locally to port 8444 (to my full node). However, it doesn’t try to connect to any outside node (so why those other wallets are making remote connections?).

By the way, I limited netstat to TCP only, but checked that UDP doesn’t have anything chia related.

12

Thanks, things are getting clearer bit by bit;-) Just noticed a blog on chia.net about v1.3 and the new wallet in it. An improvement I think, but we’ll have to see how it holds up in practice.
https://www.chia.net/2022/01/10/understanding-the-changes-in-the-new-light-wallet.en.html