from an ESXi 5.0 shell I would have access to a VM virtual serial interface (VM is running on the ESXi hypervisor). Using netcat (nc) available on ESXi, is possible to connect to the VM virtual serial interface via a UNIX socket binded to it (named pipe).
Now, to emulate a "real" terminal connected to the VM serial interface, I've set the pseudo-terminal in raw mode via "stty raw" command (issued on ESXi shell). Access to the OS running in the VM is fine but I can see that sent characters are echoed back
I've tried passing -echo to stty without lucky: the terminal seem blocked and the only way to recover is disconnect and riconnect again...
Someone can help me ?
I've solved concatenating stty and nc as follows:
stty raw -echo; nc -U 'unix socket'
which is the difference between stty and nc "concatenation" via ";" and just run the two commands one after the other ("stty raw -echo" and then "nc -U unix socket") ?
Related
I have an up and running service ( is an emulated machine or something similar ) on my local Ubuntu machine and i'm able to access it through a serial port and following socat command:
> sudo socat file:`tty`,raw,escape=0x1d,echo=0 unix-connect:/tmp/sample-serial
root#sample:~#
I exit from the service and with the following socat command i can execute the bash file ( is in local machine ) to this service.
> sudo socat file:my_bash_script.sh unix-connect:/tmp/sample-serial
If i enter again with the first socat command in the service i can see my_bash_script.sh output going on in the service terminal
The question is: how i can see the output of this my_bash_script.sh from local machine?
Consider that in the service, socat command not exist then i can't open a TCP connections or similar.
Kind Regards
in the second command, the file: address appends the command output to the script. Try something like
sudo socat file:my_bash_script.sh!!- unix-connect:/tmp/sample-serial
to get command output on your terminal.
Please note that '!' may substitute part of the command line with some terminal history, type
set +H
to turn this behaviour off.
I am trying to access a device which is attached to a USB-serial port. The settings are 57600 baud, 8 bit, 1 stop bit, no parity. The device outputs a status line every second and accepts typed commands.
I would like to use GNU screen to initiate 2 way communications, so I am using this command:
screen /dev/ttyS2 57600,cs8
However I just get a blank screen, nothing received from the device.
The communication is fine using teraterm, and I can also do this
stty -F /dev/ttyS2 57600 cs8
cat /dev/ttyS2
to see the status output from the device.
I've tried various combinations of ixon, ixoff, crtscts, and clocal but nothing makes any difference.
How can I determine what the correct command should be?
I am using Cygwin on Windows 10.
I faced the same issue with gnu-screen, I started using plink.exe instead from the PuTTY suite. It's not optimal, but it does the job. In my case serial is just for recovery, not for everyday usage.
Start PuTTY, create a profile with your serial connection.
Name and save the connection.
From cygwin, run: '/cygdrive/c/Program\ Files\ (x86)/PuTTY/plink.exe -load SerialProfile'
I am running embedded linux program, so that the kernel init script automatically start the program, and the stdin/stdout are going through the serial device, which is also the shell.
When I connect to target with telnet, I don't see the same stdin/stdout of the program.
Maybe I can redirect console stdin/stdout to telnet connection ?
What ways do I have to gain such capabilities using the telnet connection ?
Thanks,
Ran
I don't know if it is possible with telnet, but you can mock it through netcat. Just like below:
<STDOUT> | netcat -t www.example.com 80
I'm using Expect to connect to my server over a (virtual) serial port. (HP iLo, to be specific)
When booting from a Linux OS ISO image, you eventually get to the 'boot:' prompt. When my server reaches that prompt, I would like to enter my own custom boot options and press enter. Easy, right?
This is how the boot prompt looks when you're watching my Expect script execute (looks normal):
boot:
However, I have not been able to match 'boot:'. Looking at the Expect Buffer in my logfile, this is what is being captured for that line:
ESC\[25;01HbbESC\[25;01HESC\[25;02HooESC\[25;02HESC\[25;03HooESC\[25;03HESC\[25;04HttESC\[25;04HESC\[25;05H::ESC\[25;05HESC\[25;06H ESC\[25;06HESC\[25;07H"
I think all those control sequences are screwing up my match. If you look closely 'boot:' is actually in there, but it's surrounded by what I believe are ANSI control sequences.
In fact, the logfile is absolutely full of ANSI control characters.
Relevant pieces of the Expect script I've been playing around with:
bash #] expect -d -c '
.....
# SSH to the Virtual Serial Port Management server
spawn ssh user#1.2.3.4
.....
# Access the Virtual Serial Port for the server being booted
send "vsp\r"
.....
# After rebooting the server, when the boot: prompt appears, enter boot options
expect {
"boot:" {send $bootOptions \r\n"}
timeout {send_user "Never found boot prompt\n"; send_user "$expect_out(buffer)"; exit 1}
}
.....
exit'
Any ideas about what the best way to handle those control characters would be? I've tried exporting TERM=dumb and TERM=vt1000 on the machine I'm running the script on. Didn't make much of a difference.
Not sure if this will help, but you could create a wrapper for ssh and exec that instead of ssh and then have
ssh <host> | perl -pe 's/\e([^\[\]]|\[.*?[a-zA-Z]|\].*?\a)//g' | col -b
perhaps take out the col -b which filters newlines if you don't need that.
I am in the domain 192.168.1.xxx. I need to send broadcast traffic from a pc connected to a accesspoint to the android device wirelessly after connecting with a network through WiFi.
running iperf command iperf -c 192.168.1.255 -i 2 -t 60 -b 10000 -u on a Ubuntu 12.04 machine and running the command iperf -s -i 2 -u in adb shell.
But the client is unable to get the broadcast traffic and gives error as :
read failed : connection refused.
you cannot use iperf in broadcast mode.
if you are just testing whether broadcast works, you could try something like
# server
netcat -l -u -p 54321
# host
echo "foo" | netcat -ub 192.168.1.255 54321
note however, that on some systems, netcat might not be able to go into broadcast mode, so you might end up writing your own networking code.
You can't do iperf broadcast on linux.
Connection refused generally happens when the server and client are not on the same network or make sure the server IP address that you are specifying in the client is correct.
You can leverage DHCP's properties, DHCP is advertised with a broadcast DISCORVERY package, so by putting a DHCP-server and a DHCP-client (normal host) at the ends of your network you can test broadcast traffic within it.
If you get an address -> you're OK
If you keep waiting and nothing happens -> something went wrong
Hope this helps you ;)