Based on #11580 because I'm lazy.
We should generally avoid writing to debug.log unconditionally for inbound peers which misbehave (the peer being about to be banned being an exception, since they cannot do this twice).
Based on #11580 because I'm lazy.
We should generally avoid writing to debug.log unconditionally for inbound peers which misbehave (the peer being about to be banned being an exception, since they cannot do this twice).
Concept ACK
1510 | @@ -1514,7 +1511,9 @@ bool static ProcessMessage(CNode* pfrom, const std::string& strCommand, CDataStr 1511 | if (nVersion < MIN_PEER_PROTO_VERSION) 1512 | { 1513 | // disconnect from peers older than this proto version 1514 | - LogPrintf("peer=%d using obsolete version %i; disconnecting\n", pfrom->GetId(), nVersion); 1515 | + std::string obsolete_msg(strprintf("peer=%d using obsolete version %i; disconnecting\n", pfrom->GetId(), nVersion)); 1516 | + if (pfrom->fInbound) LogPrint(BCLog::NET, "%s", obsolete_log);
obsolete_msg or above obsolete_log?
1510 | @@ -1511,7 +1511,9 @@ bool static ProcessMessage(CNode* pfrom, const std::string& strCommand, CDataStr 1511 | if (nVersion < MIN_PEER_PROTO_VERSION) 1512 | { 1513 | // disconnect from peers older than this proto version 1514 | - LogPrintf("peer=%d using obsolete version %i; disconnecting\n", pfrom->GetId(), nVersion); 1515 | + std::string obsolete_msg(strprintf("peer=%d using obsolete version %i; disconnecting\n", pfrom->GetId(), nVersion)); 1516 | + if (pfrom->fInbound) LogPrint(BCLog::NET, "%s", obsolete_log); 1517 | + else LogPrintf( "%s", obsolete_log);
Same as above.
Concept ACK.
utACK dba516034898cd390a07edf86af3e9ff9f52c911. I didn't try to verify there were no missing logprints, but these changes seem reasonable.
I think it would be good to add your "We should generally avoid writing to debug.log unconditionally..." comment from the commit message to the LogFlags enum, so there is a little information about good logging practices and how the enum values are supposed to be used.
Concept ACK
"We should generally avoid writing to debug.log unconditionally"
Yes please. Loose logging practices just cause scared users.
Concept ACK.
1510 | @@ -1514,7 +1511,9 @@ bool static ProcessMessage(CNode* pfrom, const std::string& strCommand, CDataStr 1511 | if (nVersion < MIN_PEER_PROTO_VERSION) 1512 | { 1513 | // disconnect from peers older than this proto version 1514 | - LogPrintf("peer=%d using obsolete version %i; disconnecting\n", pfrom->GetId(), nVersion); 1515 | + std::string obsolete_log(strprintf("peer=%d using obsolete version %i; disconnecting\n", pfrom->GetId(), nVersion)); 1516 | + if (pfrom->fInbound) LogPrint(BCLog::NET, "%s", obsolete_log); 1517 | + else LogPrintf( "%s", obsolete_log);
Would prefer to create a BCLog::ALWAYS category and use something like pfrom->fInbound ? BCLog::NET: BCLog::ALWAYS instead of repeating the log statements in this way.
(after that you could even factor it to a uint32_t log_category = ...` at the beginning of the function ProcessMessage)
After discussion on IRC I removed the weird branching on fInbound to decide between LogPrint and LogPrintf...added a new "New outbound peer connected" log to ::VERACK handling to replace it. Also added a general comment in util.h about LogPrint/LogPrintf usage.
What about the debug.log message "connection from <Peer> dropped (banned)"?
I banned the nodes in gmaxwells banlist.cli.txt, and some of them aggressively try to connect permanently every few seconds after being banned, e.g. this one (this is a original cutout of the debug.log, the messages are exactly like this (except the x-anonymization), I did not remove other log entries in between)
2017-11-x 15:55:34 connection from 129.13.252.x:36133 dropped (banned)
2017-11-x 15:55:39 connection from 129.13.252.x:36225 dropped (banned)
2017-11-x 15:55:43 connection from 129.13.252.x:36363 dropped (banned)
2017-11-x 15:55:47 connection from 129.13.252.x:36474 dropped (banned)
2017-11-x 15:55:50 connection from 129.13.252.x:36579 dropped (banned)
2017-11-x 15:55:53 connection from 129.13.252.x:36673 dropped (banned)
2017-11-x 15:55:56 connection from 129.13.252.x:36780 dropped (banned)
2017-11-x 15:56:00 connection from 129.13.252.x:36888 dropped (banned)
2017-11-x 15:56:03 connection from 129.13.252.x:36989 dropped (banned)
2017-11-x 15:56:07 connection from 129.13.252.x:37108 dropped (banned)
2017-11-x 15:56:10 connection from 129.13.252.x:37210 dropped (banned)
2017-11-x 15:56:13 connection from 129.13.252.x:37307 dropped (banned)
2017-11-x 15:56:17 connection from 129.13.252.x:37409 dropped (banned)
2017-11-x 15:56:20 connection from 129.13.252.x:37516 dropped (banned)
2017-11-x 15:56:23 connection from 129.13.252.x:37612 dropped (banned)
2017-11-x 15:56:27 connection from 129.13.252.x:37712 dropped (banned)
2017-11-x 15:56:30 connection from 129.13.252.x:37814 dropped (banned)
Because this permanently spammed the debug.log, I added iptables rules to drop these silently on OS layer :-/
Edit: running 0.15.1rc1
We should generally avoid writing to debug.log unconditionally for
inbound peers which misbehave (the peer being about to be banned
being an exception, since they cannot do this twice).
To avoid removing logs for outbound peers, a new log is added to
notify users when a new outbound peer is connected which mimics
the version print.
Added the banned listing to the list as well (thanks!)...I'm sure there's others that are missed that can be triggered in validation logic, but I'll leave those for a future PR.
Concept ACK.
utACK be9f38c6131ab0c7ad96e4f6f3d8b5ae6f870ea9