Cardinal-Cryptography / Cardinal-Cryptography/aleph-node-issues

aleph-node logs failed connections to a bootnode that is *not* on the BOOT_NODES list

Offen
#4 9 Kommentare 0 Reaktionen 0 zugewiesene Personen Auf GitHub ansehen
Vorherrschende Sprache
Keine Sprachdaten
Sterne
2
Forks
0
PR-Merge-Kennzahlen
Keine gemergten PRs in 30 T.

Beschreibung

### Did you read the documentation and guides?

- [X] I have inspected the documentation.

### Is there an existing issue?

- [X] I have searched the existing issues.

### Description of the problem

my testnet node 1 (QNODE-TEST) started logging some events yesterday (Apr-2-2023), starting at 2023-04-02 13:13:07 PDT. Events continued until the node was restarted at 2023-04-02 14:06:08 PDT. a pair of the same event was logged every 5s or so:

`2023-04-02 13:13:07 💔 The bootnode you want to connect to at `/ip4/84.245.33.122/tcp/30333/p2p/12D3KooWRkGLz4YbVmrsWK75VjFTs8NvaBu42xhAmQaP4KeJpw1L` provided a different peer ID `12D3KooWJgniH6kTFxLAZUVaP2nE7ohrMVjFMXBbbyph1uGYFDL6` than the one you expect `12D3KooWRkGLz4YbVmrsWK75VjFTs8NvaBu42xhAmQaP4KeJpw1L`

I posted about this on the discord testnet-validator-general channel: https://discord.com/channels/775720634848116807/1050508965647233055/1092203956324814848

Another validator (Bart | StakeSafe) confirmed that the IP address logged (84.245.33.122) belonged to his ISP (Cambrium IT Services BV). All of the AZF bootnodes seem to be hosted on Amazon, so there was a mismatch of sort

the connection attempted was using one of my "regular" peers IP address along with a peer_id belonging to an actual AZF bootnode (the first on the bootnode list): _bootnode-eu-central-1-0.test.azero.dev_

_bootnode-eu-central-1-0.test.azero.dev_ resolved to the correct IP address (18.184.79.200) on the same testnet machine
the problem persisted until i restarted aleph-node. after restarting, the issue disappeared

### Information on your setup.

testnet validator ✌️ version 0.10.1-9c6a46952d3 (built from source)
node name: QNODE-TEST
peer_id: 12D3KooWMW86EoNYwBar6e5Gcnmaa13N6JsnzYVPPVGsmvjUddWt
OS: ubuntu 22.04.02
hardware: VM on ESXi hypervisor, AMD AMD EPYC 7302 (8c/16t dedicated), 64GB ECC RAM, 1×100 GB SSD, 1×1.92 TB SSD NVMe, 1G connectivity, business fibre (static IP)
IP address: 206.116.52.219

### Steps to reproduce

not sure how to reproduce

[backup-aleph-node-testnet-2023-04-02T1406.zip](https://github.com/Cardinal-Cryptography/aleph-node-issues/files/11140221/backup-aleph-node-testnet-2023-04-02T1406.zip)

### Did you attach relevant logs?

- [X] I have attached logs (if relevant).

Beitragsleitfaden

Für dieses Repository ist kein Beitragsleitfaden indexiert

Rechercherichtung

Es werden keine Quelldateien oder Tests genannt. Beginne mit der Prüfung des angehängten Log-Archivs und der BOOT_NODES-Konfiguration und verfolge anschließend, wie die gemeldete IP-Adresse und die Peer-IDs ausgewählt und aufgelöst wurden. Die Aufgabe ist abgeschlossen, wenn festgestellt wurde, warum eine Adresse, die kein Bootnode ist, angesprochen wurde, und eine reproduzierbare Prüfung oder ein Test hinzugefügt wurde, der die inkorrekte Verbindung verhindert.

Vom Indexierungsmodell aus dem Issue-Text verfasst.

Bewertung

Bereich
networking
Issue-Typ
Bug
Schwierigkeit
4/5
Geschätzter Aufwand
3-5 Tage
Aktivitätsstatus
Veraltet
Klarheit
Muss geklärt werden
Anfängerfreundlichkeit
25/100

Neue Issues direkt in Ihr Postfach

Eine kurze Übersicht über anfängerfreundliche GitHub-Issues.