The behaviour of addnode onetry changed without notice. This restores the ability to at least get the original behaviour.
Needed for properly testing DoS rules.
The behaviour of addnode onetry changed without notice. This restores the ability to at least get the original behaviour.
Needed for properly testing DoS rules.
rpc_net.py fails
194 | @@ -195,17 +195,16 @@ UniValue addnode(const JSONRPCRequest& request) 195 | std::string strCommand; 196 | if (!request.params[1].isNull()) 197 | strCommand = request.params[1].get_str(); 198 | - if (request.fHelp || request.params.size() != 2 || 199 | + if (request.fHelp || request.params.size() < 2 || request.params.size() > 3 || 200 | (strCommand != "onetry" && strCommand != "add" && strCommand != "remove")) 201 | throw std::runtime_error( 202 | - "addnode \"node\" \"add|remove|onetry\"\n" 203 | + "addnode \"node\" \"add|remove|onetry\" (privileged)\n"
Missing spaces inside ().
222 | - g_connman->OpenNetworkConnection(addr, false, nullptr, strNode.c_str(), false, false, true); 223 | + g_connman->OpenNetworkConnection(addr, false, nullptr, strNode.c_str(), false, false, privileged); 224 | return NullUniValue; 225 | } 226 | 227 | + if (privileged) {
Should be if (!request.params[2].isNull()) {? Furthermore, if the default is true then this will always fail.
request.params[2].isNull() is checked when setting the bool above. But yes, it's inverted here.
I mean, it doesn't matter the value, at this point command is not onetry, so privileged should not be specified.
privileged=true is required for non-onetry. (Maybe some day we will support false too.)
The error should be thrown for (!privileged) then, it's backwards?
213 | @@ -215,14 +214,19 @@ UniValue addnode(const JSONRPCRequest& request) 214 | throw JSONRPCError(RPC_CLIENT_P2P_DISABLED, "Error: Peer-to-peer functionality missing or disabled"); 215 | 216 | std::string strNode = request.params[0].get_str(); 217 | + const bool privileged = request.params[2].isNull() ? true : request.params[2].get_bool();
WDYT moving this to onetry if block below.
It's needed for all cases.
223 | + g_connman->OpenNetworkConnection(addr, false, nullptr, strNode.c_str(), false, false, privileged); 224 | return NullUniValue; 225 | } 226 | 227 | + if (privileged) { 228 | + throw JSONRPCError(RPC_INVALID_PARAMETER, "Unprivileged connections are only supported for the \"onetry\" command for now");
This error seems ambiguous to me, could either mean onetry only supports unprivileged, or unprivileged is only supported by onetry and not add
I don't see how it could mean the former in standard English.
Concept ACK
This breaks our outbound-connection-counting logic in the aut-connect loop as it uses the manual connection flag to figure out how many other connections to make.
206 | - "Nodes added using addnode (or -connect) are protected from DoS disconnection and are not required to be\n" 207 | - "full nodes/support SegWit as other outbound peers are (though such peers will not be synced from).\n" 208 | "\nArguments:\n" 209 | "1. \"node\" (string, required) The node (see getpeerinfo for nodes)\n" 210 | "2. \"command\" (string, required) 'add' to add a node to the list, 'remove' to remove a node from the list, 'onetry' to try a connection to the node once\n" 211 | + "3. privileged (boolean, optional, default=true) If true, nodes added will be protected from DoS disconnection and not required to be full nodes or support segwit as other outbound peers are (though such peers will not be synced from). Only supported for command \"onetry\" for now.\n"
This setting is called 'manual_connection' internally. I don't think it makes sense to add new terminology here.
manual_connection does not express the nature of the flag.
Why no PR description? What's the use case for this?
Added a PR description, and kicked Travis.
Can you address @TheBlueMatt's comment here: #12674 (comment) ?
@TheBlueMatt @sipa I don't consider that broken. A non-privileged connection should be treated the same as any other normal outgoing connection.
<!--e57a25ab6845829454e8d69fc972939a-->
The following sections might be updated with supplementary metadata relevant to reviewers and maintainers.
<!--174a7506f384e20aa4161008e828411d-->
Reviewers, this pull request conflicts with the following ones:
If you consider this pull request important, please also help to review the conflicting pull requests. Ideally, start with the one that should be merged first.
Rebased
223 | - "full nodes/support SegWit as other outbound peers are (though such peers will not be synced from).\n", 224 | + "Or try a connection to a node once.\n", 225 | { 226 | {"node", RPCArg::Type::STR, /* opt */ false, /* default_val */ "", "The node (see getpeerinfo for nodes)"}, 227 | {"command", RPCArg::Type::STR, /* opt */ false, /* default_val */ "", "'add' to add a node to the list, 'remove' to remove a node from the list, 'onetry' to try a connection to the node once"}, 228 | + {"privileged", RPCArg::Type::BOOL, /* opt */ true, /* default_val */ "true", "If true, nodes added will be protected from DoS disconnection and not required to be full nodes or support segwit as other outbound peers are (though such peers will not be synced from). Only supported for command \"onetry\" for now."},
{"privileged", RPCArg::Type::BOOL, /* default */ "true", "If true, nodes added will be protected from DoS disconnection and not required to be full nodes or support segwit as other outbound peers are (though such peers will not be synced from). Only supported for command \"onetry\" for now."},
I don't see how that would compile.
I understand your frustration you recently raised on IRC that pull requests frequently need to be rebased and that you prefer not to rebase unless the pull request is ready for merge. However, a pull request that needs rebase is less likely to receive review, since reviewers can't trivially run the latest tests on it (without having to solve a merge conflict). Also, they'd need to redo the solution of the merge conflict after you solve it to re-ACK, so that drives back reviewers even more. I think solving trivial merge conflicts is a nice courtesy to reviewers. If the pull request in general does not attract reviewers that seems like a separate problem.
227 | @@ -228,17 +228,16 @@ static UniValue addnode(const JSONRPCRequest& request) 228 | std::string strCommand; 229 | if (!request.params[1].isNull()) 230 | strCommand = request.params[1].get_str(); 231 | - if (request.fHelp || request.params.size() != 2 || 232 | + if (request.fHelp || request.params.size() < 2 || request.params.size() > 3 ||
#18606 tries to unify the coding-style of all non-hidden RPC calls by using RPCHelpMan::Check
If #18606 gets merged before this PR, this change shouldn't be necessary (should be automatically handled by RPCHelpMan::IsValidNumArgs). Only the line adding the parameter privileged in RPCHelpMan below will be necessary.
And thanks to #18606 the new bash auto-completion file will be generated automatically by running test/functional/tool_cli_completion.py --overwrite before committing :smiley:
If this PR gets merged before #18606 I'll update my PR accordingly.
<!--cf906140f33d8803c4a75a2196329ecb-->
🐙 This pull request conflicts with the target branch and needs rebase.