Sending and receiving simple signals between computers?











up vote
0
down vote

favorite












I have a RaspberryPi, running the standard Pi distro, and a computer running Linux 16.04 in the same local network with fixed IP adresses. The Pi is used to wake the computer by sending a Wake-on-Lan package and then tunnelling onto the computer via SSH.



Is there an easy and simple way for the computer to send a message to the Pi, which the Pi then interprets as the computer having started up succesfully and being reachable?



I already have set up a system where the Pi is continuously pinging the computer until it gets a response, but I specificly want to have the computer message the Pi and not the Pi checking up on the computer.










share|improve this question









New contributor




UmBottesWillen is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
















  • 3




    Just put something like echo foo | nc <pi ip address> <port> into /etc/rc.local on computer, and have pi listen on the given port for messages in separate script or even background. You could then use wait from script to know when background task finished.
    – Sergiy Kolodyazhnyy
    Nov 16 at 18:42










  • And how would I set up the Pi to listen for that ping?
    – UmBottesWillen
    Nov 16 at 23:01










  • I've put that as an answer in more details. General idea is that you already have nc tool for sending packets and testing connection with most *nix systems, and it's easy to make a simpke server-client type of thing with it
    – Sergiy Kolodyazhnyy
    Nov 16 at 23:41















up vote
0
down vote

favorite












I have a RaspberryPi, running the standard Pi distro, and a computer running Linux 16.04 in the same local network with fixed IP adresses. The Pi is used to wake the computer by sending a Wake-on-Lan package and then tunnelling onto the computer via SSH.



Is there an easy and simple way for the computer to send a message to the Pi, which the Pi then interprets as the computer having started up succesfully and being reachable?



I already have set up a system where the Pi is continuously pinging the computer until it gets a response, but I specificly want to have the computer message the Pi and not the Pi checking up on the computer.










share|improve this question









New contributor




UmBottesWillen is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
















  • 3




    Just put something like echo foo | nc <pi ip address> <port> into /etc/rc.local on computer, and have pi listen on the given port for messages in separate script or even background. You could then use wait from script to know when background task finished.
    – Sergiy Kolodyazhnyy
    Nov 16 at 18:42










  • And how would I set up the Pi to listen for that ping?
    – UmBottesWillen
    Nov 16 at 23:01










  • I've put that as an answer in more details. General idea is that you already have nc tool for sending packets and testing connection with most *nix systems, and it's easy to make a simpke server-client type of thing with it
    – Sergiy Kolodyazhnyy
    Nov 16 at 23:41













up vote
0
down vote

favorite









up vote
0
down vote

favorite











I have a RaspberryPi, running the standard Pi distro, and a computer running Linux 16.04 in the same local network with fixed IP adresses. The Pi is used to wake the computer by sending a Wake-on-Lan package and then tunnelling onto the computer via SSH.



Is there an easy and simple way for the computer to send a message to the Pi, which the Pi then interprets as the computer having started up succesfully and being reachable?



I already have set up a system where the Pi is continuously pinging the computer until it gets a response, but I specificly want to have the computer message the Pi and not the Pi checking up on the computer.










share|improve this question









New contributor




UmBottesWillen is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.











I have a RaspberryPi, running the standard Pi distro, and a computer running Linux 16.04 in the same local network with fixed IP adresses. The Pi is used to wake the computer by sending a Wake-on-Lan package and then tunnelling onto the computer via SSH.



Is there an easy and simple way for the computer to send a message to the Pi, which the Pi then interprets as the computer having started up succesfully and being reachable?



I already have set up a system where the Pi is continuously pinging the computer until it gets a response, but I specificly want to have the computer message the Pi and not the Pi checking up on the computer.







shell-script networking






share|improve this question









New contributor




UmBottesWillen is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.











share|improve this question









New contributor




UmBottesWillen is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.









share|improve this question




share|improve this question








edited Nov 16 at 19:27









Rui F Ribeiro

38.2k1475123




38.2k1475123






New contributor




UmBottesWillen is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.









asked Nov 16 at 18:17









UmBottesWillen

81




81




New contributor




UmBottesWillen is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.





New contributor





UmBottesWillen is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.






UmBottesWillen is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.








  • 3




    Just put something like echo foo | nc <pi ip address> <port> into /etc/rc.local on computer, and have pi listen on the given port for messages in separate script or even background. You could then use wait from script to know when background task finished.
    – Sergiy Kolodyazhnyy
    Nov 16 at 18:42










  • And how would I set up the Pi to listen for that ping?
    – UmBottesWillen
    Nov 16 at 23:01










  • I've put that as an answer in more details. General idea is that you already have nc tool for sending packets and testing connection with most *nix systems, and it's easy to make a simpke server-client type of thing with it
    – Sergiy Kolodyazhnyy
    Nov 16 at 23:41














  • 3




    Just put something like echo foo | nc <pi ip address> <port> into /etc/rc.local on computer, and have pi listen on the given port for messages in separate script or even background. You could then use wait from script to know when background task finished.
    – Sergiy Kolodyazhnyy
    Nov 16 at 18:42










  • And how would I set up the Pi to listen for that ping?
    – UmBottesWillen
    Nov 16 at 23:01










  • I've put that as an answer in more details. General idea is that you already have nc tool for sending packets and testing connection with most *nix systems, and it's easy to make a simpke server-client type of thing with it
    – Sergiy Kolodyazhnyy
    Nov 16 at 23:41








3




3




Just put something like echo foo | nc <pi ip address> <port> into /etc/rc.local on computer, and have pi listen on the given port for messages in separate script or even background. You could then use wait from script to know when background task finished.
– Sergiy Kolodyazhnyy
Nov 16 at 18:42




Just put something like echo foo | nc <pi ip address> <port> into /etc/rc.local on computer, and have pi listen on the given port for messages in separate script or even background. You could then use wait from script to know when background task finished.
– Sergiy Kolodyazhnyy
Nov 16 at 18:42












And how would I set up the Pi to listen for that ping?
– UmBottesWillen
Nov 16 at 23:01




And how would I set up the Pi to listen for that ping?
– UmBottesWillen
Nov 16 at 23:01












I've put that as an answer in more details. General idea is that you already have nc tool for sending packets and testing connection with most *nix systems, and it's easy to make a simpke server-client type of thing with it
– Sergiy Kolodyazhnyy
Nov 16 at 23:41




I've put that as an answer in more details. General idea is that you already have nc tool for sending packets and testing connection with most *nix systems, and it's easy to make a simpke server-client type of thing with it
– Sergiy Kolodyazhnyy
Nov 16 at 23:41










1 Answer
1






active

oldest

votes

















up vote
1
down vote



accepted










Use nc - simplest method.



On computer( assuming it is a *nix system) : put ( echo "computer is up" | nc 192.168.0.123 6677 ) & into /etc/rc.local. The (...) & spawns background shell to prevent the rc.local script from blocking other things from execution while computer boots. Assume 192.68.0.123 is your Pi's IP address on same network as computer .



On Pi, have a process listening on port 6677 with nc -l 6677 after whatever command you're using to send wake on LAN signal. By default nc terminates once the sending side closed the connection ( which should happen after all bytes of "computer is up" string have been sent ). So you could do something like



netreply=$( nc -l 6677)
case $netreply in
"computer is up") echo "All good" ;;
*) echo some boo-boo happened ;;
esac





share|improve this answer





















  • Thanks, I'll try that out and see if that works.
    – UmBottesWillen
    Nov 17 at 2:07










  • I'm not sure rc.local works very well with systemd ... a more universal solution for most current Linux distros is to use a systemd service file that waits until the network interface is up and running... like this
    – RubberStamp
    Nov 17 at 2:23










  • @RubberStamp rc.local works with systemd and there is rc-local.service which executes /etc/rc.local script. See askubuntu.com/a/919598/295286 Can you explain what exactly you mean by "not sure ...works very well" part ? Even though I agree it'd be nicer to have an actual service made, /etc/rc.local is perfectly fine alternative.
    – Sergiy Kolodyazhnyy
    Nov 17 at 2:33










  • Some distros may not include (or enable) the rc.local service in the default configuration. My understanding is that the rc.local systemd service runs after the network is up and running anyway. So, why not just put the messaging script its own service file for easy visibility and uniformity? ... I guess the point was, it's possible that a given Linux distro will not automatically run rc.local ....
    – RubberStamp
    Nov 17 at 3:00










  • @RubberStamp Fair enough. But if it's not enabled by default nothing stops us from enabling that service. But sure, it may be a viable alternative for visibility/uniformity to have it's own service.
    – Sergiy Kolodyazhnyy
    Nov 17 at 3:05











Your Answer








StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "106"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);

StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});

function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
convertImagesToLinks: false,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: null,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});


}
});






UmBottesWillen is a new contributor. Be nice, and check out our Code of Conduct.










 

draft saved


draft discarded


















StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f482211%2fsending-and-receiving-simple-signals-between-computers%23new-answer', 'question_page');
}
);

Post as a guest















Required, but never shown

























1 Answer
1






active

oldest

votes








1 Answer
1






active

oldest

votes









active

oldest

votes






active

oldest

votes








up vote
1
down vote



accepted










Use nc - simplest method.



On computer( assuming it is a *nix system) : put ( echo "computer is up" | nc 192.168.0.123 6677 ) & into /etc/rc.local. The (...) & spawns background shell to prevent the rc.local script from blocking other things from execution while computer boots. Assume 192.68.0.123 is your Pi's IP address on same network as computer .



On Pi, have a process listening on port 6677 with nc -l 6677 after whatever command you're using to send wake on LAN signal. By default nc terminates once the sending side closed the connection ( which should happen after all bytes of "computer is up" string have been sent ). So you could do something like



netreply=$( nc -l 6677)
case $netreply in
"computer is up") echo "All good" ;;
*) echo some boo-boo happened ;;
esac





share|improve this answer





















  • Thanks, I'll try that out and see if that works.
    – UmBottesWillen
    Nov 17 at 2:07










  • I'm not sure rc.local works very well with systemd ... a more universal solution for most current Linux distros is to use a systemd service file that waits until the network interface is up and running... like this
    – RubberStamp
    Nov 17 at 2:23










  • @RubberStamp rc.local works with systemd and there is rc-local.service which executes /etc/rc.local script. See askubuntu.com/a/919598/295286 Can you explain what exactly you mean by "not sure ...works very well" part ? Even though I agree it'd be nicer to have an actual service made, /etc/rc.local is perfectly fine alternative.
    – Sergiy Kolodyazhnyy
    Nov 17 at 2:33










  • Some distros may not include (or enable) the rc.local service in the default configuration. My understanding is that the rc.local systemd service runs after the network is up and running anyway. So, why not just put the messaging script its own service file for easy visibility and uniformity? ... I guess the point was, it's possible that a given Linux distro will not automatically run rc.local ....
    – RubberStamp
    Nov 17 at 3:00










  • @RubberStamp Fair enough. But if it's not enabled by default nothing stops us from enabling that service. But sure, it may be a viable alternative for visibility/uniformity to have it's own service.
    – Sergiy Kolodyazhnyy
    Nov 17 at 3:05















up vote
1
down vote



accepted










Use nc - simplest method.



On computer( assuming it is a *nix system) : put ( echo "computer is up" | nc 192.168.0.123 6677 ) & into /etc/rc.local. The (...) & spawns background shell to prevent the rc.local script from blocking other things from execution while computer boots. Assume 192.68.0.123 is your Pi's IP address on same network as computer .



On Pi, have a process listening on port 6677 with nc -l 6677 after whatever command you're using to send wake on LAN signal. By default nc terminates once the sending side closed the connection ( which should happen after all bytes of "computer is up" string have been sent ). So you could do something like



netreply=$( nc -l 6677)
case $netreply in
"computer is up") echo "All good" ;;
*) echo some boo-boo happened ;;
esac





share|improve this answer





















  • Thanks, I'll try that out and see if that works.
    – UmBottesWillen
    Nov 17 at 2:07










  • I'm not sure rc.local works very well with systemd ... a more universal solution for most current Linux distros is to use a systemd service file that waits until the network interface is up and running... like this
    – RubberStamp
    Nov 17 at 2:23










  • @RubberStamp rc.local works with systemd and there is rc-local.service which executes /etc/rc.local script. See askubuntu.com/a/919598/295286 Can you explain what exactly you mean by "not sure ...works very well" part ? Even though I agree it'd be nicer to have an actual service made, /etc/rc.local is perfectly fine alternative.
    – Sergiy Kolodyazhnyy
    Nov 17 at 2:33










  • Some distros may not include (or enable) the rc.local service in the default configuration. My understanding is that the rc.local systemd service runs after the network is up and running anyway. So, why not just put the messaging script its own service file for easy visibility and uniformity? ... I guess the point was, it's possible that a given Linux distro will not automatically run rc.local ....
    – RubberStamp
    Nov 17 at 3:00










  • @RubberStamp Fair enough. But if it's not enabled by default nothing stops us from enabling that service. But sure, it may be a viable alternative for visibility/uniformity to have it's own service.
    – Sergiy Kolodyazhnyy
    Nov 17 at 3:05













up vote
1
down vote



accepted







up vote
1
down vote



accepted






Use nc - simplest method.



On computer( assuming it is a *nix system) : put ( echo "computer is up" | nc 192.168.0.123 6677 ) & into /etc/rc.local. The (...) & spawns background shell to prevent the rc.local script from blocking other things from execution while computer boots. Assume 192.68.0.123 is your Pi's IP address on same network as computer .



On Pi, have a process listening on port 6677 with nc -l 6677 after whatever command you're using to send wake on LAN signal. By default nc terminates once the sending side closed the connection ( which should happen after all bytes of "computer is up" string have been sent ). So you could do something like



netreply=$( nc -l 6677)
case $netreply in
"computer is up") echo "All good" ;;
*) echo some boo-boo happened ;;
esac





share|improve this answer












Use nc - simplest method.



On computer( assuming it is a *nix system) : put ( echo "computer is up" | nc 192.168.0.123 6677 ) & into /etc/rc.local. The (...) & spawns background shell to prevent the rc.local script from blocking other things from execution while computer boots. Assume 192.68.0.123 is your Pi's IP address on same network as computer .



On Pi, have a process listening on port 6677 with nc -l 6677 after whatever command you're using to send wake on LAN signal. By default nc terminates once the sending side closed the connection ( which should happen after all bytes of "computer is up" string have been sent ). So you could do something like



netreply=$( nc -l 6677)
case $netreply in
"computer is up") echo "All good" ;;
*) echo some boo-boo happened ;;
esac






share|improve this answer












share|improve this answer



share|improve this answer










answered Nov 16 at 23:39









Sergiy Kolodyazhnyy

8,10212051




8,10212051












  • Thanks, I'll try that out and see if that works.
    – UmBottesWillen
    Nov 17 at 2:07










  • I'm not sure rc.local works very well with systemd ... a more universal solution for most current Linux distros is to use a systemd service file that waits until the network interface is up and running... like this
    – RubberStamp
    Nov 17 at 2:23










  • @RubberStamp rc.local works with systemd and there is rc-local.service which executes /etc/rc.local script. See askubuntu.com/a/919598/295286 Can you explain what exactly you mean by "not sure ...works very well" part ? Even though I agree it'd be nicer to have an actual service made, /etc/rc.local is perfectly fine alternative.
    – Sergiy Kolodyazhnyy
    Nov 17 at 2:33










  • Some distros may not include (or enable) the rc.local service in the default configuration. My understanding is that the rc.local systemd service runs after the network is up and running anyway. So, why not just put the messaging script its own service file for easy visibility and uniformity? ... I guess the point was, it's possible that a given Linux distro will not automatically run rc.local ....
    – RubberStamp
    Nov 17 at 3:00










  • @RubberStamp Fair enough. But if it's not enabled by default nothing stops us from enabling that service. But sure, it may be a viable alternative for visibility/uniformity to have it's own service.
    – Sergiy Kolodyazhnyy
    Nov 17 at 3:05


















  • Thanks, I'll try that out and see if that works.
    – UmBottesWillen
    Nov 17 at 2:07










  • I'm not sure rc.local works very well with systemd ... a more universal solution for most current Linux distros is to use a systemd service file that waits until the network interface is up and running... like this
    – RubberStamp
    Nov 17 at 2:23










  • @RubberStamp rc.local works with systemd and there is rc-local.service which executes /etc/rc.local script. See askubuntu.com/a/919598/295286 Can you explain what exactly you mean by "not sure ...works very well" part ? Even though I agree it'd be nicer to have an actual service made, /etc/rc.local is perfectly fine alternative.
    – Sergiy Kolodyazhnyy
    Nov 17 at 2:33










  • Some distros may not include (or enable) the rc.local service in the default configuration. My understanding is that the rc.local systemd service runs after the network is up and running anyway. So, why not just put the messaging script its own service file for easy visibility and uniformity? ... I guess the point was, it's possible that a given Linux distro will not automatically run rc.local ....
    – RubberStamp
    Nov 17 at 3:00










  • @RubberStamp Fair enough. But if it's not enabled by default nothing stops us from enabling that service. But sure, it may be a viable alternative for visibility/uniformity to have it's own service.
    – Sergiy Kolodyazhnyy
    Nov 17 at 3:05
















Thanks, I'll try that out and see if that works.
– UmBottesWillen
Nov 17 at 2:07




Thanks, I'll try that out and see if that works.
– UmBottesWillen
Nov 17 at 2:07












I'm not sure rc.local works very well with systemd ... a more universal solution for most current Linux distros is to use a systemd service file that waits until the network interface is up and running... like this
– RubberStamp
Nov 17 at 2:23




I'm not sure rc.local works very well with systemd ... a more universal solution for most current Linux distros is to use a systemd service file that waits until the network interface is up and running... like this
– RubberStamp
Nov 17 at 2:23












@RubberStamp rc.local works with systemd and there is rc-local.service which executes /etc/rc.local script. See askubuntu.com/a/919598/295286 Can you explain what exactly you mean by "not sure ...works very well" part ? Even though I agree it'd be nicer to have an actual service made, /etc/rc.local is perfectly fine alternative.
– Sergiy Kolodyazhnyy
Nov 17 at 2:33




@RubberStamp rc.local works with systemd and there is rc-local.service which executes /etc/rc.local script. See askubuntu.com/a/919598/295286 Can you explain what exactly you mean by "not sure ...works very well" part ? Even though I agree it'd be nicer to have an actual service made, /etc/rc.local is perfectly fine alternative.
– Sergiy Kolodyazhnyy
Nov 17 at 2:33












Some distros may not include (or enable) the rc.local service in the default configuration. My understanding is that the rc.local systemd service runs after the network is up and running anyway. So, why not just put the messaging script its own service file for easy visibility and uniformity? ... I guess the point was, it's possible that a given Linux distro will not automatically run rc.local ....
– RubberStamp
Nov 17 at 3:00




Some distros may not include (or enable) the rc.local service in the default configuration. My understanding is that the rc.local systemd service runs after the network is up and running anyway. So, why not just put the messaging script its own service file for easy visibility and uniformity? ... I guess the point was, it's possible that a given Linux distro will not automatically run rc.local ....
– RubberStamp
Nov 17 at 3:00












@RubberStamp Fair enough. But if it's not enabled by default nothing stops us from enabling that service. But sure, it may be a viable alternative for visibility/uniformity to have it's own service.
– Sergiy Kolodyazhnyy
Nov 17 at 3:05




@RubberStamp Fair enough. But if it's not enabled by default nothing stops us from enabling that service. But sure, it may be a viable alternative for visibility/uniformity to have it's own service.
– Sergiy Kolodyazhnyy
Nov 17 at 3:05










UmBottesWillen is a new contributor. Be nice, and check out our Code of Conduct.










 

draft saved


draft discarded


















UmBottesWillen is a new contributor. Be nice, and check out our Code of Conduct.













UmBottesWillen is a new contributor. Be nice, and check out our Code of Conduct.












UmBottesWillen is a new contributor. Be nice, and check out our Code of Conduct.















 


draft saved


draft discarded














StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f482211%2fsending-and-receiving-simple-signals-between-computers%23new-answer', 'question_page');
}
);

Post as a guest















Required, but never shown





















































Required, but never shown














Required, but never shown












Required, but never shown







Required, but never shown

































Required, but never shown














Required, but never shown












Required, but never shown







Required, but never shown







Popular posts from this blog

List directoties down one level, excluding some named directories and files

list processes belonging to a network namespace

list systemd RuntimeDirectory mounts