I am using a GPSD to feed GPS information to a virtual serial port. I'm generating the virtual serial port with socat, and I am listening to the virtual port using: sudo cat /dev/pts/2, where /dev/pts/2 is the drive created by socat. The GPS signal is being obtained in a C++ script . The C++ script is giving me the expected output every 1 second, but the information stream simply stops after 30 seconds.
What options can I consider in either the socat arguments or the GPSDO arguments in my C++ script, to lengthen the time past 30 seconds?
Socat in default setup has no timeout as long as both connections stay open. Apply options -d -d -d -d -lu to Socat to see in its output what happens!
Related
I have Socat command as follow :
socat -u TCP4-LISTEN:5000,reuseaddr,fork OPEN:/tmp/test1-2039-sip-i,creat,append
And I would like to modify to listen to many ports range, from port 10000 till 29999
What is the right command to fullfill that need?
yes, socat can only listen on one port at a time per instance so my amateur method for getting around this is is using an array in a bash script to open an instance of socat for each port I need to monitor. Doing this for thousands of ports isn't really practical, since while socat uses little resources when listening, running 20,000 instances of socat is impractical, but i've run 50 at a single time on a small SoC board. So name your defined ports in an array (ports that are actually used), then iterate through a bash array loop and spawn a few instances.
#!/bin/bash
ports=( 23 24 25 443 80 )
for port in "${ports[#]}"; do
socat tcp-listen:$port,reuseaddr,fork open:/tmp/$port.txt,creat,append
done
exit
This writes data coming in from the ports to "port number file".txt in /tmp, ie. 24.txt. If you get an error, it's because something else has bonded to the port already. Use inotifywatch to alert you when a file gets written to.
This question has been out here a while and it keeps coming up in my searches. So I decided to answer it.
I am new in world of network. I made a simple SDN that contains 3 hosts, one switch and a controller. I would like to monitor the traffic using tcpprobe. I opened a terminal using xterm h1 and ran the shell there. I also made iperf server in h2. But the tcpprobe was not existed in /proc/net/ directory when I use a SSH terminal!
enter image description here
However I installed it on my VM and it is exist in /proc/net/ of my VM.
enter image description here
sudo apt-get install transcode
Here is my shell code:
#!/bin/bash
#used variables
eth=h1-eth0
port_to_probe=5001
#we will probe the iperf port
server_addr=10.0.0.2
#LOAD TCP CONGESTION CONTROL MODULES
modprobe tcp_probe port=$port_to_probe full=1 bufsize=50
for time_test in 10 20 30 60 10 20
do
echo "Traffic transmission time set to " $time_test "s randomly.\n"
#start logging data
sudo cat /proc/net/tcpprobe > tcprobe.dat &
#get the cat process ID to later kill it
pid=$!
#kill the logger
kill $pid
done
Can anybody help me?
The problem was that, each SSH use a port to connect to VM and this cause a change on the address of /proc/net/. To solve this problem it is enough to change the mentioned address to /proc/6337/net/. By reading this address in fact you read the real VM directory. So the final code will change to:
cat /proc/6337/net/tcpprobe
is there any way to control an already running VLC player on ubuntu.
For example, i am trying to start a vlc video full screen with a default audio.
and then control the volume and other features through netcat or some other command remotely. is it possible?
The script player control from exic's answer is just a wrapper for some dbus commands.
To use them without the script, try the following:
dbus-send --type=method_call --dest=org.mpris.MediaPlayer2.vlc /org/mpris/MediaPlayer2 org.mpris.MediaPlayer2.Player.PlayPause
The last PlayPause can be replaced with, e.g., Play, Pause, Previous, Next.
If you have qdbus installed, it can be used as an alternative to dbus-send:
qdbus org.mpris.MediaPlayer2.vlc /org/mpris/MediaPlayer2 org.mpris.MediaPlayer2.Player.PlayPause
A list of all available calls can be obtained by leaving out the last argument:
qdbus org.mpris.MediaPlayer2.vlc /org/mpris/MediaPlayer2
Have you looked at the rc (remote control) interface ? It controls a VLC process via a Unix Domain Socket. See here and here for more info.
If you enable the HTTP remote interface on VLC, you can control VLC remotely with a web browser, or even an app on your phone.
With the HTTP interface enabled, you can also use wget or curl commands to send commands.
For example, enable VLC's HTTP interface (default port: 8080) with "password" for a password. Then you can issue curl commands, either remotely or locally:
Curl Prefix
For brevity I will show the first part of the curl command here (the IP will most likely be your localhost, but the 8080 port is the default:
curl -s -o /dev/null -u :password http://192.168.1.11:8080
then combine with the actions:
To pause:
.../requests/status.xml?command=pl_pause
To play:
.../requests/status.xml?command=pl_play
To play a specific playlist entry number:
.../requests/status.xml?command=pl_play&id=22
To change volume:
.../requests/status.xml?command=volume&val=133
Other command info: https://wiki.videolan.org/VLC_HTTP_requests/
I'm controlling it remotely using dbus. VLC has implemented the MPRIS2 specification:
Control player (e. g. run player-control vlc toggle)
Get current status (with argument vlc)
I'm debugging a shell script
so I add set -x at the beginning
a code snippet are as below
tcpdump -i $interface host $ip_addr and 'port 80' -w flash/flash.pcap &
sudo -u esolve firefox /tor_capture/flash.html &
sleep $capture_time
but I noticed that the execution sequence is as below
++ sleep 5
++ sudo -u esolve firefox /tor_capture/flash.html
++ tcpdump -i eth0 host 138.96.192.56 and 'port 80' -w flash/flash.pcap
tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
so the execution sequence is reversed compared to the command sequence in the script
what is wrong with this and how to deal with it?
thanks!
Since those lines are being backgrounded, I think the output from set -x comes from the subshell that is spawned to run the program, and the main shell gets to the sleep command before the subshells have proceeded to the point that they generate the output. That would explain why the sleep command shows up first. With regards to the other two, I would think you might occasionally get them in the other order, as well, since there's no synchronization between the two - depending on how many CPUs you have, how busy the system is, etc., the timing between the subshells is pseudo-non-deterministic...
Do you need the first 2 lines to run as background processes?
If not, remove the & at the end and try again.
I've got a device that I'm operating next to my PC and as it runs it's spitting log lines out it's serial port. I have this wired to my PC and I can see the log lines fine if I'm using either minicom or something like:
ttylog -b 115200 -d /dev/ttyS0
I want to write 5 seconds of the device serial output to a temp file (or assign it to a variable) and then later grep that file for keywords that will let me know how the device is operating. I've already tried redirecting the output to a file while running the command in the background, and then sleeping 5 seconds and killing the process, but the log lines never get written to my temp file. Example:
touch tempFile
ttylog -b 115200 -d /dev/ttyS0 >> tempFile &
serialPID=$!
sleep 5
#kill ${serialPID} #does not work, gets wrong PID
killall ttylog
cat tempFile
The file gets created but never filled with any data. I can also replace the ttylog line with:
ttylog -b 115200 -d /dev/ttyS0 |tee -a tempFile &
In neither case do I ever see any log lines logged to stdout or the log file unless I have multiple versions of ttylog running by mistake (see commented out line, D'oh).
I have no idea what's going on here. It seems to be a failure of redirection within my script.
Am I on the right track? Is there a better way to sample 5 seconds of the serial port?
It sounds like maybe ttylog is buffering its output. Have you tried running it with -f or --flush?
You might try the unbuffer script that comes with expect.
ttylog has a --timeout option, where you can simply specify for how many seconds it should run.
So, in your case, you could do
ttylog --baud 115200 --device /dev/ttyS0 --timeout 5
and it would just run for 5 seconds and then stop.
Indeed it also has the -f option as mentioned which flushes, but if you'd use --timeout you would not be needing that.