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.
shell-script networking
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.
add a comment |
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.
shell-script networking
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 likeecho 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 usewaitfrom 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 havenctool 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
add a comment |
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.
shell-script networking
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
shell-script networking
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.
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 likeecho 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 usewaitfrom 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 havenctool 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
add a comment |
3
Just put something likeecho 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 usewaitfrom 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 havenctool 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
add a comment |
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
Thanks, I'll try that out and see if that works.
– UmBottesWillen
Nov 17 at 2:07
I'm not surerc.localworks very well withsystemd... 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
@RubberStamprc.localworks with systemd and there isrc-local.servicewhich executes/etc/rc.localscript. 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.localis 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
|
show 3 more comments
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
Thanks, I'll try that out and see if that works.
– UmBottesWillen
Nov 17 at 2:07
I'm not surerc.localworks very well withsystemd... 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
@RubberStamprc.localworks with systemd and there isrc-local.servicewhich executes/etc/rc.localscript. 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.localis 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
|
show 3 more comments
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
Thanks, I'll try that out and see if that works.
– UmBottesWillen
Nov 17 at 2:07
I'm not surerc.localworks very well withsystemd... 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
@RubberStamprc.localworks with systemd and there isrc-local.servicewhich executes/etc/rc.localscript. 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.localis 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
|
show 3 more comments
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
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
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 surerc.localworks very well withsystemd... 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
@RubberStamprc.localworks with systemd and there isrc-local.servicewhich executes/etc/rc.localscript. 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.localis 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
|
show 3 more comments
Thanks, I'll try that out and see if that works.
– UmBottesWillen
Nov 17 at 2:07
I'm not surerc.localworks very well withsystemd... 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
@RubberStamprc.localworks with systemd and there isrc-local.servicewhich executes/etc/rc.localscript. 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.localis 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
|
show 3 more comments
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.
UmBottesWillen is a new contributor. Be nice, and check out our Code of Conduct.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
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
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
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
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 usewaitfrom 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
nctool 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