I have a BarCode-Scanner and I need to get some information about it,
such as Serial Number.
The problem is that it communicates with the host via parallel port
(like a keyboard). I need to know how to send commands to the parallel port.
I've tried:
$ echo -n 'hexadecimal command' > /dev/input/by-path/platform-i8042-serio-0-event-kbd
but that only get's trash!
does anybody have any idea how to send and read data from parallel port?
(it works just like a keyboard).
tks,
Related
I have a device as a telnet server but drops the connection if no packet is received in 60 seconds, for some reason this behavior cannot be changed. Putty has a feature to send null packets to the server periodically to keep the session alive, which works fine for me. But some times I have to telnet to the device from linux terminal, where putty is not available. So I wonder if it's possible to periodically send null packets with the linux telnet client, or any other way to keep the session alive, or other command line telnet client that could do this.
This is not a perfect solution, but might suffice. Wrap the telnet within an expect script that detects lack of input. It sends the escape sequence control-] to the telnet client to get the command prompt telnet>, and issues the command send nop (no-operation). I assume this is enough to keep the connection alive. If not there are other commands to try.
#!/usr/bin/expect
spawn telnet localhost
expect "ogin: "
send "username\r"
expect "assword:"
send "mypw\r"
expect {$ }
interact timeout 10 {
log_user 0; send "\x1d"; expect "telnet>" { send "send nop\r" };
expect "send nop\r\n"; log_user 1 }
Obviously, you need to edit this with the desired hostname, username, password, and expected command prompt. See man expect for the syntax.
With the command line telnet client that's not possible. You can enable frequent TCP keepalives globally: TCP Keepalive HOWTO. I don't know if this has any side-effects, but it seems like a viable workaround.
By the way, putty is available on Linux. You just need to have an X server on your machine to run it on a remote host (I assume you're ssh-ing into the Linux box where you do your telnet work). If you're on Windows, the Linux Subsystem for Windows together with an X server might do the trick. Cygwin also works for this.
This is a more constrained version of this question:
I have an embedded ARM device running a custom image with a Linux 3.10.0 kernel.
The only physical interface (no, USB, no Ethernet) is the default Linux shell which is connected one of the serial interfaces.
My question is: Is there any built-in or external tool that opens an IP tunnel over this connection?
I see some general issues:
The device is already use by Linux, so it must use stdin/out to communicate instead of accessing the device directly.
After starting the tunneling application, the application must wait for a tunnel client to connect because I need to close the serial connection on my computer and then start the tunnel client.
There should be a way to close the connection and go back to the normal shell
The actual requirement is, that I can access a REST interface that is running on the embedded device from a computer connected to the embedded device via serial cable.
This already works on devices with a physical Ethernet or Ethernet-over-USB but this device does not offer that.
[UPDATE]
As explained, socat is currently not available on our embedded device so as a first attempt, I used the following:
A Linux (Ubuntu) laptop with a physical serial interface
A Windows Laptop with a physical serial interface and cygwin+socat installed
Both connected via Null-modem cable
Note: I'm using a Windows laptop on one side because we will have the socat client running on Linux (unfortunately).
Direct STDIO Connection
Server
socat stdio file:/dev/ttyS0,b115200
Client
socat file:/dev/ttyS4,b115200 stdio
In cygwin, ttyS0 is COM1, ttyS4 in this case is COM5.
Using these, socat works like a little chat program. Why I type on one side is output on the other and vice-versa.
TCP Connection
The next step is to use a TCP connection.
Server
socat /dev/ttyS0,b115200,crtscts=1,raw,echo=0 tcp-connect:localhost:80
Client
socat -T2 file:/dev/ttyS4,b115200,crtscts=1,raw,echo=0 tcp-l:7777,reuseaddr
I specified the baud rate (115200), used raw transmission, no echo (The HTTP request would otherwise be sent back to the requester) using hardware flow control. Pus I had to use a timeout -T2 wich terminates the connection after 2s. Otherwise, curl does not terminate either and waits for more data.
When I use curl on the windows computer, it successfully transmits the request over serial connection and returns the complete HTTP response of the HTTP server on the Linux computer:
curl localhost:7777/index.html
However, it works only once. After the request is completed, both socatclient and server terminates.
Moreover, when I use a browser (Chorme), it uses g-zip encoding which most probably sends binary characters. And one of these characters will be a EOF character which again terminates socat before completing the request/response.
Then I tried to add fork to the server:
socat /dev/ttyS0,b115200,crtscts=1,raw,echo=0 tcp-connect:localhost:80,fork
This keeps the server alive, but curl returns a 400 Bad Request. So it seems as if the socat server initiated a request for each line or chunk since it does not understand HTTP.
IP Connection
Then I thought about going a layer below and using a TUN connection. However, this is not implemented on the Windows version of socat.
HTTP connection
Correct me if I'm wrong, but as far as I understand, socatdoes not provide a connection type that actually understands HTTP and is able to serialize it properly over a serial connection.
So, I couldn't find any stable way to start both client and server and run multiple HTTP requests over the serial connection.
On a normal linux, you could use socat.
This program allows you to connect several stream types (file, socket, tcp, udp, ...). In your case it would be tcp to file or more precisely a tcp socket at port xx to /dev/ttyUSB1. You should launch socat on both sides to build a tunnel.
Edit 1:
Sorry I got also disappointed by socat. I can't find a solution that keeps my TCP listener active for multiple successive connections, but handles only one connection at a time.
My solution is a simple C# program that uses 4 threads:
1. wait for input on stdin e.g. exit command
2. the TCP listener
3. the TCP worker thread for a active connection
4. if TCP is open, it opens another thread for COM
Thread 3 reads from TCP and writes to COM and Tread 4 reads from COM and writes to TCP. If thread gets a TCP close event, it stops thread 4, which closes COMx, and exits it self. Now thread 2 can accept a new connection. If thread 1 reads exit on stdin, it passes a message to all threads to stop and shutdown.
Maybe you can implement such a short program in C with pthreads on your embedded system, which has no socat.
The EOF problem:
I tried to google for a program that escapes a special character or reencodes a data stream from ASCII to ANSI or base64 or whatever.... If you can find such a program or write it also in C you can pipe it in between
Server <=> reencode <=> socat <--serial--> socat <=> reencode <=> client
We've now solved the problem halfway using pppd. As it turns out, even Windows supports ppp. In contrast to socat, pppd actually uses a protocol that will have error detection included and it automatically creates network devices on the Linux and Windows system.
The only problem is, that pppd requires to have access to the serial device. There is no direct mode like the ppp tool provides.
We are now disabling the shell on demand, rebooting into IP-over-serial mode. When we are done, we reboot the system which automatically switch back to getty using the serial line.
The is not the prettiest solution but right now, it seems to work.
I am interested in finding out when things SSH into my boxen to create a reverse tunnel. Currently I'm using a big hack - just lsof with a few lines of script. So my goal is to see when a socket calls bind() and, ideally, get the port it binds to (it's listening locally since it's a reverse tunnel) and the remote host that I would be connecting to. My lsof hack is basically fine, except I don't get instant notifications and it's rather... hacky :)
This is easy for files; once a file does just about anything, inotify can tell me in Linux. Of course, other OSs have a similar capability.
I'm considering simply tailing the SSHD logs and parsing the output, but my little "tunnel monitor" daemon needs to be able to figure out the state of the tunnels at any point in time, even if it hasn't been running the whole time SSHD has.
I have a pretty evil hack I've been considering as well. It's a script that invokes GDB on /usr/sbin/sshd, then sets a breakpoint on bind. Then it runs it with the options -d -p <listening port> -- Running a separate SSHD for these tunnels is fine. Then it waits for that breakpoint to get hit, and uses GDB's input to get the remote hosts's IP address and the local IP on which SSH is now listening. Again, that's text parsing and opens some other issues.
Is there a "good" way to do this?
I would use SystemTap for a problem like this. You can use it to probe the kernel to see when a bind is done by any process on the system. http://sourceware.org/systemtap/
I have an interesting problem. I am working on an embedded box with multiple instances of Linux running each on an ARM processor. They are connected over internal 1GBps network. I have a serial port device node attached to processor A (Lets say Linux-A running on it). I have a program running on processor B (Lets say on Linux-B) access the serial port device as if it is attached to Linux-B locally.
My program invokes term i/o type api calls on device node to control tty echo, character mode input. What I am wondering is if there is a way to create a virtual serial device that is available on Linux-B somehow talking to real serial device on Linux-A over internal network.
I am thinking something along the lines of:
Linux-B has /dev/ttyvirtual. Anything that gets written to it gets transported over network socket to Linux-A serialserver. The serial server exrcises the api calls on real device lets say /dev/ttys0.
Any data waiting on ttys0 gets transported back to /dev/ttyvirtual.
What are all the things involved to get this done fast?
Thanks
Videoguy
Update:
I found a discussion at
http://fixunix.com/bsd/261068-network-socket-serial-port-question.html with great pointers.
Another useful link is http://blog.philippklaus.de/2011/08/make-rs232-serial-devices-accessible-via-ethernet/
Take a look at openpty(3). This lets you create a pseudo-TTY (like /dev/pts/0, the sort that ssh connections use), which will respond as a normal TTY would, but give you direct programmatic control over the connections.
This way you can host a serial device (eg. /dev/pts/5) that you forward data between a network connection, and then other apps can perform serial operations on it without knowing about the underlying network bridge.
I ended up using socat
Examples can be found here: socat examples
You socat back to back on both the machines. One listens on a tcp port and forwards data to local virtual port or pty. The socat on other box uses real device as input and forwards any data to tcp port.
I am looking for a tool (under linux) that will allow me to set up an end to end proxy that accepts multiple simultaneous clients on one port at one end, forwards the data to the other end with a single connection then "expands" the connection at the other end to connect back to a service that accepts multiple connections. To clarify, here is a diagram of what I want to achieve:
http://i.stack.imgur.com/rgTMd.png
(apparantly I need more then 10 rep to have the image embedded in this page)
If you're interested, the reason why I am attempting to do this is because I want to build a system that would make it easier to tunnel over arbitrary protocols, as long as the protocol supports some way to send some message from one end to another. I would put the system in between proxy end A and proxy end B in the diagram above.
Here is an example of how I want it to work:
First I will run the following commands
mkfifo backpipe
nc -l 7778 0<backpipe | tee f1 | nc localhost 7777 | tee f2 >backpipe
The "server proxy" will be running on port 7777.
The "client proxy" that the application will connect to will be running on port 8080
The client proxy will connect to port 7778
Solve for "server proxy" and "client proxy"
OpenSSH already supports this with the -D option:
ssh -D <port> -l username remotehost
A SOCKS server will listen for connections on and forward them to the other end of the SSH connection.
I've decided to code my own solution for the mean time. It's a bit of python code that accepts multiple clients and basically proxies the communication through the standard input/output. If anyone is interested, here's the code http://pastebin.com/1E45Exsy
Don't trust this code to work perfectly. I have not tested it properly and it doesn't handle disconnecting clients.
I will continue to search for a more elegant and robust solution, but this should do in the meantime. I'll post updates to the code here if I make them.