Sally MacFarlane

So it's flaky if node B syncs too quickly, and is permitted check returns true on line 59 when we expect false. And also flaky if node B syncs too...

3 x mainnet nodes 1 is a bit flat 

3 x holesky 

we get Inbound UNKNOWN disconnects from besu and OpenEthereum eg OpenEthereum/v3.3.5-hbbft-0.9.3-unstable-6b34c53cb-20231028/x86_64-linux-gnu/rustc1.68.2

running a modified version of #6947 on a holesky node sample of disconnects (it's been running for under an hr) excluding MISMATCHED_NETWORK_ID disconnects since on holesky that's the vast majority...

updated #6947 to make the analysis easier ^^

disconnect reasons matched with client type - this is all disconnects (excluding mismatched network ID) on 6609-9x nodes (3 nodes) over about an hour https://docs.google.com/spreadsheets/d/1Bbu7YWwuwRJJ3KByfpnZsw_S1GNo4O9itM7a14GhACo/edit#gid=1710195989 this may prompt more questions...

Looking at 6609-90 which did not gain any peers via discovery over the last 9 hours * all inbound and outbound disconnects where client info is visible (since we disconnected...

some interesting stats (again off 6609-90 which seems to be stuck with zero peers) ``` sallymacfarlane@dev-elc-bu-tk-holesky-sally-6609-90:~$ grep -c "Timed out" /var/log/besu/besu.log 27883 sallymacfarlane@dev-elc-bu-tk-holesky-sally-6609-90:~$ grep -c "Failed to connect to peer"...

I've restarted besu on 6609-90 and it has connected to the 2 bootnodes and discovery looks a bit more varied (normal?) ``` {"@timestamp":"2024-04-16T22:17:23,738","level":"INFO","thread":"nioEventLoopGroup-3-3","class":"EthProtocolManager","message":"Disconnect - active Connection? false - Outbound -...