alastria/alastria-node

Nuevo nodo regular no sincroniza

vperaltac opened this issue · 12 comments

Hace 5 días di de alta el siguiente nodo en la red de Alastria: REG_mydassbc-ugr_T_10_16_00

He esperado más de 72 horas para que los nodos validadores lo añadieran a su lista de nodos pero sigue sin sincronizar.

A continuación incluyo la información que soléis pedir cuando existen problemas de este tipo:

> admin.nodeInfo
{
  enode: "enode://2faa05e9069167f8749c86f76894d7cb060644203984677c0808dd744c9c5b5923e1bda481bf6e578f84b8e3947dc06bdc66a248a3b5942491e001c482b50e0b@127.0.0.1:21000?discport=0",
  enr: "0xf894b84002f3747c4e989e73ac4450282635449bea29d44d8387b289db5a5b3624e771ca65a47a3216cd11798b5abfdc556ab662d48035f3b49e75ab78d0b8db4a1feae20183636170cbca88697374616e62756c40826964827634826970847f00000189736563703235366b31a1032faa05e9069167f8749c86f76894d7cb060644203984677c0808dd744c9c5b5983746370825208",
  id: "ca96f1905d860dd4b56cd4218ec8969eacd76732f7a0574d45e6d6d02e7dbc81",
  ip: "127.0.0.1",
  listenAddr: "[::]:21000",
  name: "Geth/REG_mydassbc-ugr_T_10_16_00/v1.8.18-stable(quorum-v2.2.3-0.Alastria_EthNetstats_IBFT)/linux-amd64/go1.9.5",
  ports: {
    discovery: 0,
    listener: 21000
  },
  protocols: {
    istanbul: {
      config: {
        byzantiumBlock: 0,
        chainId: 83584648538,
        eip150Block: 0,
        eip150Hash: "0x0000000000000000000000000000000000000000000000000000000000000000",
        eip155Block: 0,
        eip158Block: 0,
        homesteadBlock: 0,
        isQuorum: true,
        istanbul: {...},
        txnSizeLimit: 64
      },
      difficulty: 1,
      genesis: "0x77a8c93fdee76dcbe099afcda0ee6b2856a0fbebc30fd6bee45ca1a555dd474c",
      head: "0x77a8c93fdee76dcbe099afcda0ee6b2856a0fbebc30fd6bee45ca1a555dd474c",
      network: 83584648538
    }
  }
}
> admin.peers
[]
>
~/alastria/logs# tail quorum_20201001105920.log
WARN [10-24|10:14:02.042] Failed to decode stats server message    err="json: cannot unmarshal string into Go value of type map[string][]interface {}"
WARN [10-24|10:14:14.370] Full stats report failed                 err="write tcp 172.17.0.2:59556->185.180.8.152:80: use of closed network connection"
WARN [10-24|10:14:32.043] Failed to decode stats server message    err="json: cannot unmarshal string into Go value of type map[string][]interface {}"
WARN [10-24|10:14:44.639] Full stats report failed                 err="write tcp 172.17.0.2:59566->185.180.8.152:80: use of closed network connection"
WARN [10-24|10:15:02.043] Failed to decode stats server message    err="json: cannot unmarshal string into Go value of type map[string][]interface {}"
WARN [10-24|10:15:14.963] Full stats report failed                 err="write tcp 172.17.0.2:59586->185.180.8.152:80: use of closed network connection"
WARN [10-24|10:15:32.043] Failed to decode stats server message    err="json: cannot unmarshal string into Go value of type map[string][]interface {}"
WARN [10-24|10:15:45.227] Full stats report failed                 err="write tcp 172.17.0.2:59604->185.180.8.152:80: use of closed network connection"
WARN [10-24|10:16:02.043] Failed to decode stats server message    err="json: cannot unmarshal string into Go value of type map[string][]interface {}"
WARN [10-24|10:16:15.533] Full stats report failed                 err="write tcp 172.17.0.2:59624->185.180.8.152:80: use of closed network connection"

Hola! Parece que desde el punto de vista técnico está todo bien en tu lado. Voy a consultar desdel el punto de vista administrativo si podemos proceder a darte de alta como nodo. Te informo en este issue de la evolución. Un saludo!

Hola!

El nodo ya está permisionado, y debería estar sincronizando. Hemos visto que el tcp/21000 y udp/21000 está cerrados desde un par de máqunas. Comprueba que ambos están abiertos al menos, para los "boot-node" (dentro del repositorio verás un listado JSON con las IP de los mismos), aunque es bastante seguro abrirlos al 0.0.0.0: se trata del protocolo de whisper de Ethereum: el udp se usa para el descrubrimiento, mientras que el tcp se usa para el intercambio de datos.

Revisa el FW y comprueba con estos comandos la evolucion de la sincronización:

geth --exec "eth.blockNumber" attach /root/alastria/data/geth.ipc
geth --exec "admin.peers" attach /root/alastria/data/geth.ipc
geth --exec "eth.syncing" attach /root/alastria/data/geth.ipc```

Parece que el nodo sigue sin sincronizar.

El puerto 21000 está abierto desde ufw tanto en tcp cómo en udp. Añado la lista de los puertos abiertos para el nodo:

$ sudo ufw status
Status: active

To                         Action      From
--                         ------      ----
80/tcp                     ALLOW       Anywhere
443/tcp                    ALLOW       Anywhere
53                         ALLOW       Anywhere
21000                      ALLOW       Anywhere
9000/tcp                   ALLOW       Anywhere
8086/tcp                   ALLOW       Anywhere
8443/tcp                   ALLOW       Anywhere
80/tcp (v6)                ALLOW       Anywhere (v6)
443/tcp (v6)               ALLOW       Anywhere (v6)
53 (v6)                    ALLOW       Anywhere (v6)
21000 (v6)                 ALLOW       Anywhere (v6)
9000/tcp (v6)              ALLOW       Anywhere (v6)
8086/tcp (v6)              ALLOW       Anywhere (v6)
8443/tcp (v6)              ALLOW       Anywhere (v6)

Con respecto a los comandos para seguir la evolución de la sincronización, devuelven lo siguiente:

$:~/alastria-node# geth --exec "eth.blockNumber" attach /root/alastria/data/geth.ipc
0
$:~/alastria-node# geth --exec "admin.peers" attach /root/alastria/data/geth.ipc
[]
$:~/alastria-node# geth --exec "eth.syncing" attach /root/alastria/data/geth.ipc
false

Puedes comprobar tu IP con un "curl ifconfig.me" o "curl ifconfig.co"?

Tenemos registrado 150.214.205.121, y no responde geth:

telnet 150.214.205.121 21000
Trying 150.214.205.121...
telnet: Unable to connect to remote host: Connection timed out

Buenas @vperaltac , dispones de algún otro FW perimetral?, como dice @alejandroalffer se observa el 21000 cerrado. A parte de esto, y para ver de mejor forma lo que pueda estar ocurriendo,, ¿Tendrías disponibilidad mañana?. De esta forma, podríamos hacer un Teams y ver lo que sucede. Estoy intentando hacer un telnet a la dirección pública que habéis escrito en el fichero regular-nodes.json y ni el puerto 21000, ni el 80. Gracias

curl ifconfig.me
150.214.205.121
curl ifconfig.co
150.214.205.121

Probablemente se trate de algún conflicto con la red de la universidad. Ya que para muchas tareas es necesario acceder desde su VPN (ssh incluido).
Voy a comentarlo con personal de la universidad mañana y veremos si se trata de eso. Actualizaré en este issue cuando tenga noticias.

Muchas gracias por la rápida ayuda!

Buenos días @vperaltac, @alejandroalffer , veo que el nodo ya está sincronizando. Actualmente va por el bloque 7 millones. ¿Habéis hecho algo?.

Gracias

Parece que el tcp sigue cerrado, al menos para mi host, pero el udp si está wide open:

ladmin@DESKTOP-UK0SQ8D:/mnt/c/Users/alejandro.alfonso$ nc -v 150.214.205.121 21000
nc: connect to 150.214.205.121 port 21000 (tcp) failed: Connection timed out
ladmin@DESKTOP-UK0SQ8D:/mnt/c/Users/alejandro.alfonso$ nc -v -u 150.214.205.121 21000
Connection to 150.214.205.121 21000 port [udp/*] succeeded!

Ayer notifiqué el problema a la universidad. Imagino que habrán modificado algo esta mañana.
Sigo a la espera de una respuesta.

Sincronizando está, si. Lo que es cierto es que como indica @alejandroalffer por udp si que hay respuesta, por tcp no. Por cierto, también he visto que tenéis cerrado el 22000, deberíais tenerlo abierto también. Saludos!!

Una pequeña puntualizacion sobre lo que comenta @cmoralesdiego: el tcp/22000 no es necesario para la sinconización del nodo. Se trata de un puerto http/rpc para aplicaciones que ofrece geth... y que en este caso si que hay que controlar el origen de peticiones: de hecho, el nginx que se instala es para hacer un filtro en "capa de aplicación" sobre los accesos a dicho puerto, aunque mi recomendación es hacerlo en la "capa de red", a través de un FW.

Geth tiene tres formas de acceso a la aplicacion:

  • a través de IPC: proceso local de sistema
  • a través de WebSockets.
  • a través de HTTP/RPC, que como menciona Carlos, normalmente se accede por tcp/22000

Con la documentación oficial de geth, https://geth.ethereum.org/docs/rpc/server, puedes ver y ajustar el comportamiento de cada uno de ellos (IP de esucha, CORS,...)

@vperaltac , cerramos el issue porque hemos visto que el nodo ha sincronizado correctamente. Gracias