Suppose we have a device which can operate on both RS232 and RS422 protocols. we know which serial port is connected to the device, lets say /dev/ttyS4.
In Linux environment using setserial, dmesg and proc file-system (following commands) helps to identify the serial ports and some hardware/software configurations of them but not much about the device connected to them. (am I missing something here?)
dmesg | grep tty
cat /proc/tty/driver/serial
setserial -a /dev/ttyS[0-4]
My question being, Is there a good way in which we can point out exactly which protocol the device is using?
Related
I emulate the firmware of a embedded device with qemu-system-arm. The output of the console is working fine by appending "console=ttyAMA0" to the kernel. On the guest there is a binary which opens another serial port for communication (bi-directional) on /dev/ttyGS0 and listens on that port. Now I need to connect to this port from the host, to send commands to the binary and receive the output.
I already tried different things like creating character devices and pseudo ttys, but I don't know how to define the serial device for the guest.
Is there a way to do this?
Thanks in advance.
If you pass multiple -serial options to QEMU they will be interpreted as defining what you want to do for UARTs 0, 1, 2, etc. So for example "-serial stdio -serial tcp::4444,server" will send UART 0 to your terminal and connect UART 1 to a TCP server on port 4444 which you can then connect to with netcat or similar utility. (You can connect serial output to a lot of different backends, not just stdio or TCP: check the QEMU documentation.)
(NB: this relies on your board model actually creating multiple UARTs and wiring them up to the command line options correctly, of course.)
Is there a foolproof way to discover the MAC address of a device that is freshly plugged into an ethernet network in linux?
I'm looking specifically for something that works on the MAC address level. Assume everything at the ip address level is broken.
i.e. maybe ethernet chip drivers expose a list of the MAC's they've seen in /proc?
Taken from a similar question, this gets pretty close:
sudo tshark -i eth0 -e eth.src -Tfields
However, it doesn't de-duplicate lines, and it seems there are intermittent line number prefixes.
I am using Virtual COM Port (VCP) example code from http://blog.memsme.com/stm32f4-virtual-com-port-2/ on STM32F4 Discovery Board to have USB VCP. This code is originally by ST and used by many other people in their projects
Communication with the STM32F4 over VCP works fine from Windows. In Linux (Ubuntu 12.04 x86), if I send data to the port with
echo "aasfg" > /dev/ttyACM0
then, the MCU gets the data and everything works fine. I can receive the continuous data stream with
cat /dev/ttyACM0
However, if I send data with the simple Python script that uses pySerial
import serial
sercom = serial.Serial('/dev/ttyACM0')
sercom.write('asdf')
then I stop receiving data with the cat command, and following cat commands also don't receive any data. The MCU is constantly executing some USB interrupt routines, never returning to execute actual application code. I can receive data from VCP again after re-plugging the device.
The STM32 USB VCP code is probably not perfect, but it is used by many other people in many projects so it should be good enough. I am not able to debug that code. I suspect that sending data with pySerial does something with the port that the VCP driver (either on STM32 or PC) does not like and I would like to track it down and hopefully still use pySerial.
I executed
stty --file=/dev/ttyACM0 -a
before and after pyserial broke the communication. After breaking the VCP with pyserial, setting -clocal became clocal and setting min = 1 became min = 0. Are these relevant in VCP communication and could they hint how to fix VCP with pySerial?
The serial port was actually fine. As I mentioned, the pySerial call changed the port parameters. The param min = 0 meant that cat /dev/ttyACM0 returned immediately, reconfiguring to min = 1 with stty made cat blocking and outputted the data as before.
Using an embedded Linux development board, I need to put together a widget that does the following:
Reads packets in via physical serial port, and relays those packets to a number of IP addresses (up to 20 of them; with IP destinations read from a configuration file).
Also 'sniff' those serial packets using a custom program, perhaps written in c.
As someone with a programming background, the most obvious solution (to me) would be to create a c program from scratch to achieve the above. However, as this is something I need to throw together quickly, and because I need an excuse to learn more about existing Linux command-line programs and script writing (which I'm not so good at), I'm wondering if much of this could be achieved with existing command-line programs and a shell script. Then, the only part I write from scratch is my packet sniffer (call it sniffer.c).
I understand that netcat and socat can be used for relaying between devices and addresses, and I have started experimenting with both. The thought occurs to me that I could avoid having to develop and test TCP/IP software by running multiple instances of socat to relay serial data from the TTY port to remote IP addresses. Each instance of socat could handle a particular remote IP address.
Does this sound feasible, and if so, how could I effectively 'multiplex' a stream from /dev/ttyS0 (say) as the source for multiple instances of socat plus one instance of sniffer.c? Could one way be to relay data read from /dev/ttyS0 to a cache file, and then have my socat instances and sniffer.c all have a read-only access to that file?
How to know which network path my program is using ?
I have a program running on solaris, this machine has multiple network interfaces few connected to 1Gig and few 10 gig. Suppose my application with PID P is running. IS there any command which display which network interface my program is submitting packets.
Not really. Your program is delegating to the kernel the task to choose which network interface(s) to use. If there is no ambiguity, i.e. if only one interface is suitable for the job, you can then identify it.
To get what IP addresses your program is connected to, you can use this command:
pfilepid| grep AF_INET
ifconfig -a and netstat -rn will help knowing what interfaces are there and what routes use what interfaces.