-
Notifications
You must be signed in to change notification settings - Fork 871
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Strange Behavior (including Segmentation Faults) when interacting over RPC Unix Socket #3569
Comments
I'm wondering if it is something with the newlines and You can run gdb lightningd -ex 'r your usual options' It'll immediately start running, and interrupt as soon as it hits the segfault. Once it interrupts you can use |
So I don't typically use gdb, so I'm not super sure what "your usual options" are. I tried just 'r', and it basically just hangs, doesn't do anything and I cannot recover it without doing a Ctrl+Z. Any advice here? |
OK so I managed to get SOMETHING. Here's the backtrace:
Doesn't look promising though, except maybe a nullptr deref |
K it looks like I need to recompile with -g |
The Makefile is a bit over my head here, since it appears that you are using ncc as opposed to gcc. I need to recompile so that the symbols are not stripped from the final product. If you have any advice on how to do this, I'd appreciate the help. Thanks! |
I am having the same issue, I expose the unix socket domain to a port to try and mimic Bitcoin Core's In swift I create a url request that looks something like:
The command that gets issued: The result in the lightningd log:
Where I just want to talk to |
@Fonta1n3 We use unwrapped plaintext JSONRPC. It looks like your interface is using HTTP. You will need to remove the HTTP wrapping and issue JSONRPC requests directly. Note as well that JSONRPC allows multiple parallel requests. Your choices are either to remove the HTTP wrapping at the client side, or add yet another server-side program that implements an HTTP server and unwraps the HTTP and issues the requests locally on the Unix socket. |
Exposing the interface over the network without any kind of password or challenge is also very dangerous, as anyone who pushes JSONRPC requests at the port can abscond with all your Lightning Bitcoins. You are better off creating a proper server that requires some password or challenge, that wraps the unix socket. Our assumption, and the reason we use a unix socket, is that you are in sole control of your hardware, and thus can open a unix socket, and thus we just trust whatever command is issued over the Unix RPC port. Exposing the socket over the network breaks this assumption. |
@ZmnSCPxj thanks for the explanation. Completely understand the concern/risk of exposing the socket to network connections. In this use case though you can only expose it to I have found a plugin thanks to @ProofOfKeags which should accomplish what I am after anyways, thank you for your time. |
Issue and Steps to Reproduce
d9b2482415a888d90e8d2a0f486bf96788e84b6f
(master) for MacOS./lightningd/lightningd
~/.lightning/bitcoin/lightning-rpc
in one of 5 waysSituation 1 (Unevaluated newline literals appended to json rpc message)
echo '{ "jsonrpc": "2.0", "method": "getinfo", "params": [], "id": 0 }\n\n' | nc -v -U ~/.lightning/bitcoin/lightning-rpc
Situation 2 (Evaluated newlines appended to json rpc message)
echo -e '{ "jsonrpc": "2.0", "method": "getinfo", "params": [], "id": 0 }\n\n' | nc -v -U ~/.lightning/bitcoin/lightning-rpc
Situation 3 (Unevaluated newline literals appended to json rpc message, No echo newline)
echo -n '{ "jsonrpc": "2.0", "method": "getinfo", "params": [], "id": 0 }\n\n' | nc -v -U ~/.lightning/bitcoin/lightning-rpc
Situation 4 (Evaluated newlines appended to json rpc message, No echo newline)
echo -ne '{ "jsonrpc": "2.0", "method": "getinfo", "params": [], "id": 0 }\n\n' | nc -v -U ~/.lightning/bitcoin/lightning-rpc
Situation 5 (No newlines at the end of json rpc message, No echo newline)
echo -n '{ "jsonrpc": "2.0", "method": "getinfo", "params": [], "id": 0 }' | nc -v -U ~/.lightning/bitcoin/lightning-rpc
getinfo
outputN/A, bug report is related to getting "getinfo"
Commentary
The closest I was able to get to behavior that was sane is with unevaluated newlines at the end of the message. This presumably pleases whatever system is reading messages off the socket, but is not pleasing the json parser, yet it still responds in a partially reasonable way: it gives me the response I was looking for, albeit with an erroneous extra complaint about the existence of newlines. The newline inserted by the
echo
command itself does not seem to make a difference in the behavior here. In every case, I would expect that misuse of the API would result in a json rpc error as opposed to segfault and termination of lightningd. Similarly, getting two responses for a single request seems like unexpected behavior as well.The text was updated successfully, but these errors were encountered: