Skip to main content

linux - How can I read input from the hosts keyboard when connected via SSH?


I'm currently experimenting with an RFID card reader that emulates a keyboard. When you connect a card, it will read out data from it and then emulate keystrokes according to configuration.


I've connected this device to a Raspberry Pi and connected to the Raspberry Pi via SSH.


Obviously, when the reader now emulates keystrokes, they land on the local tty of the Pi (and not in my SSH session). So I'm having a hard time getting to that input right now.


Ultimately, I'll be writing a piece of software to handle the input, but for debugging and development purposes, it would be quite helpful to get the keyboard input in my SSH session.


I tried the following


sudo cat /dev/input/by-id/usb-HID_OMNIKEY_5127_CK_01010053423438303000835748112531-event-kbd

Which does give some output when I connect a card, but it's not what I would have expected. It seems like that would be raw input data. I would love to get the keys as readable values.


The data that is being read from the /dev/input device makes a bit more sense when piping it through hexdump:


pi@raspberrypi ~ $ sudo cat /dev/input/by-id/usb-HID_OMNIKEY_5127_CK_01010053423438303000835748112531-event-kbd | hexdump
0000000 eef8 5138 219a 0008 0004 0004 0024 0007
0000010 eef8 5138 21ad 0008 0001 0008 0001 0000
0000020 eef8 5138 21b3 0008 0000 0000 0000 0000
0000030 eef8 5138 6019 0008 0004 0004 0024 0007
0000040 eef8 5138 602a 0008 0001 0008 0000 0000
0000050 eef8 5138 602f 0008 0000 0000 0000 0000
0000060 eef8 5138 9e97 0008 0004 0004 0023 0007
0000070 eef8 5138 9eab 0008 0001 0007 0001 0000
0000080 eef8 5138 9eb1 0008 0000 0000 0000 0000
0000090 eef8 5138 dd18 0008 0004 0004 0023 0007
00000a0 eef8 5138 dd26 0008 0001 0007 0000 0000
00000b0 eef8 5138 dd2b 0008 0000 0000 0000 0000
00000c0 eef8 5138 1b9a 0009 0004 0004 0021 0007
00000d0 eef8 5138 1baf 0009 0001 0005 0001 0000
00000e0 eef8 5138 1bb4 0009 0000 0000 0000 0000
00000f0 eef8 5138 5a15 0009 0004 0004 0021 0007
0000100 eef8 5138 5a24 0009 0001 0005 0000 0000
0000110 eef8 5138 5a29 0009 0000 0000 0000 0000
0000120 eef8 5138 989e 0009 0004 0004 0020 0007
0000130 eef8 5138 98b3 0009 0001 0004 0001 0000
0000140 eef8 5138 98b9 0009 0000 0000 0000 0000
0000150 eef8 5138 d71d 0009 0004 0004 0020 0007
0000160 eef8 5138 d72b 0009 0001 0004 0000 0000
0000170 eef8 5138 d730 0009 0000 0000 0000 0000
0000180 eef8 5138 15a1 000a 0004 0004 0009 0007
0000190 eef8 5138 15b5 000a 0001 0021 0001 0000
00001a0 eef8 5138 15bb 000a 0000 0000 0000 0000
00001b0 eef8 5138 541e 000a 0004 0004 0009 0007
00001c0 eef8 5138 542d 000a 0001 0021 0000 0000
00001d0 eef8 5138 5432 000a 0000 0000 0000 0000
00001e0 eef8 5138 92a3 000a 0004 0004 0004 0007
00001f0 eef8 5138 92b8 000a 0001 001e 0001 0000
0000200 eef8 5138 92be 000a 0000 0000 0000 0000
0000210 eef8 5138 d123 000a 0004 0004 0004 0007
0000220 eef8 5138 d131 000a 0001 001e 0000 0000
0000230 eef8 5138 d136 000a 0000 0000 0000 0000
0000240 eef8 5138 0fab 000b 0004 0004 0021 0007
0000250 eef8 5138 0fbf 000b 0001 0005 0001 0000
0000260 eef8 5138 0fc5 000b 0000 0000 0000 0000
0000270 eef8 5138 4e22 000b 0004 0004 0021 0007
0000280 eef8 5138 4e31 000b 0001 0005 0000 0000
0000290 eef8 5138 4e36 000b 0000 0000 0000 0000
00002a0 eef8 5138 8ca5 000b 0004 0004 0023 0007
00002b0 eef8 5138 8cb9 000b 0001 0007 0001 0000
00002c0 eef8 5138 8cbe 000b 0000 0000 0000 0000
00002d0 eef8 5138 cb2b 000b 0004 0004 0023 0007
00002e0 eef8 5138 cb3a 000b 0001 0007 0000 0000
00002f0 eef8 5138 cb40 000b 0000 0000 0000 0000

That should have been the input: 7643fa46



Answer



This hacked together script works for me for now:


import string

from evdev import InputDevice
from select import select

keys = "X^1234567890XXXXqwertzuiopXXXXasdfghjklXXXXXyxcvbnmXXXXXXXXXXXXXXXXXXXXXXX"
dev = InputDevice('/dev/input/by-id/usb-HID_OMNIKEY_5127_CK_01010053423438303000835748112531-event-kbd')

while True:
r,w,x = select([dev], [], [])
for event in dev.read():
if event.type==1 and event.value==1:
print( keys[ event.code ] )

It uses python-evdev to read from /dev/input/foo and very dirtyly converts them to readable values.


This is what I get when I run the script and connect a card to the reader:


pi@raspberrypi ~ $ python test.py
7
6
4
3
f
a
4
6

Comments

Popular Posts

How do I transmit a single hexadecimal value serial data in PuTTY using an Alt code?

I am trying to sent a specific hexadecimal value across a serial COM port using PuTTY. Specifically, I want to send the hex codes 9C, B6, FC, and 8B. I have looked up the Alt codes for these and they are 156, 182, 252, and 139 respectively. However, whenever I input the Alt codes, a preceding hex value of C2 is sent before 9C, B6, and 8B so the values that are sent are C2 9C, C2 B6, and C2 8B. The value for FC is changed to C3 FC. Why are these values being placed before the hex value and why is FC being changed altogether? To me, it seems like there is a problem internally converting the Alt code to hex. Is there a way to directly input hex values without using Alt codes in PuTTY? Answer What you're seeing is just ordinary text character set conversion. As far as PuTTY is concerned, you are typing (and reading) text , not raw binary data, therefore it has to convert the text to bytes in whatever configured character set before sending it over the wire. In other words, when y...

linux - Extract/save a mail attachment using bash

Using normal bash tools (ie, built-ins or commonly-available command-line tools), is it possible, and how to extract/save attachments on emails? For example, say I have a nightly report which arrives via email but is a zip archive of several log files. I want to save all those zips into a backup directory. How would I accomplish that? Answer If you're aiming for portability, beware that there are several different versions of mail(1) and mailx(1) . There's a POSIX mailx command, but with very few requirements. And none of the implementations I have seem to parse attachments anyway. You might have the mpack package . Its munpack command saves all parts of a MIME message into separate files, then all you have to do is save the interesting parts and clean up the rest. There's also metamail . An equivalent of munpack is metamail -wy .

ubuntu - Why does my USB hdd returns SG_IO: bad/missing sense data?

I am able to boot and run commands from external USB hdd; the message in question appears for about 45 seconds then booting continues. GRUB2 is installed on internal HDD. When choosing to boot directly to /dev/sdb the message doesn't appear, however boot time is about the same as booting to internal HDD. /dev/sdb: Timing cached reads: 1018 MB in 2.00 seconds = 508.97 MB/sec Timing buffered disk reads: 80 MB in 3.03 seconds = 26.37 MB/sec pfeiffep@de:~$ sudo hdparm -i /dev/sdb /dev/sdb: SG_IO: bad/missing sense data, sb[]: 70 00 05 00 00 00 00 10 00 00 00 00 20 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 HDIO_GET_IDENTITY failed: Invalid argument Gparted correctly identifies the drive as SAMSUNG MP0402H. Any ideas how to remedy the HDIO & SG_IO messages?

Desktop reboots itself on sleep or hibernate

I have been using an ASUS M2NPV-VM motherboard for main home desktop workstation, operating Windows Vista x64. This computer has right from day one not been able to enter hibernate or standby; after Windows performs its final actions and brings the machine down, it would automatically revive itself for a reboot. Updating to the second latest BIOS (1201)has not helped (the latest BIOS revision would induce video refresh problems rendering it unusable). I have been reading related discussions on incidents similar to mine to no avail of a true workable solution. They appear to be more speculative guesses rather than actual knowledge on the inner workings of motherboard hardware. Does anybody have any electronic engineering experience on PC energy-saving standards to provide a more informed opinion how to go about getting this to work? More stories: this motherboard could not even reboot properly the first thing i used it. It was due to refresh rate of the onboard GPU, which had no influe...