I'm writing a kernel module and I need to know which port the tcp sock is sent out. The 'port' here means WLAN port， 4g port or IP port.
I've been looking for port information in the kernel source code tcp.h (struct tcp_sock), sock.h (struct sock) and some other struct that relate to sock for days, but I found nothing. There are some variables look like port information but not.
Did I just go the wrong way? How can I get that information in kernel?
My kernel is linux-mptcp, just linux 414 with some multipath-tcp code in it.
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 it possible to build a modbus-RTU ethernet gateway using a linux box or arduino?
I have plc slaves linked together using modbus RTU, and I want to connect one of them over TCP with my pc as master.
I wonder if I can use a linux box (rasbery pi/raspbian) connected to a router, as a modbus-to-tcp converter by piping the usb port to my local ip on some port, as one plc will be connected in modbus rtu to the linux box`s usb port.
Piping command will be something Like this:
nc -l 5626 > /dev/ttyUSB0 < /dev/ttyUSB0
My goal is to connect a pc (networked with the linux box) to that plc through the linux box using modbus.
Yes you can use a linux box with ethernet port.
Its not a simple 'nc' is it.
First things first, you need to know, Does your PLC's support Modbus TCP or Modbus RTU over TCP.
bcos both the formats are not the same, they are not interchangeable.
once you ascertain this, you need to write a TCP Client to Connect to the Slaves as they run the Servers.
If they don't support Modbus TCP yet, you need to write a TCP servers as well.
on top of that, you have the handshaking delays and half open connections and what not.
If it is a commercial device, you need to look at the setup it will be running as well.
Hope this helps
I'm not entirely sure as to what your requirements are, but you may want to have a look at the following library. It's a Modbus TCP->RTU library I assume you can use.
https://github.com/3cky/mbusd
Best Regards
While it's certainly possible to build a Modbus TCP/RTU gateway, you won't be able to do it with a simple nc command, for two reasons:
The actual Modbus protocol data unit (PDU), merely containing the Modbus function code and data, is embedded in an application data unit (ADU) so the request reaches the correct device free of communication errors. This ADU is different for RTU and TCP. Generically, the ADU looks like this:
------------------------------------------
| Additional address | PDU | Error check |
------------------------------------------
For RTU, the "Additional address" is a single byte identifying the unit/slave on the serial line, and the "Error check" is a 16-bit CRC.
For TCP, the "Additional address" is the 7-byte Modbus application protocol header (MBAP), consisting of transaction identifier, protocol identifier, and a length field (2 bytes each), plus a single byte identifying the unit/slave (usually 255, though for a gateway, this would be the ID of the RTU slave behind it). The "Error check" is empty (zero bytes) as that is already taken care of by TCP.
The communication semantics are different for RTU and TCP.
For RTU, you write a request to the serial line, wait for the reply, and only then write the next request. There must be 3½ characters of silence between frames.
For TCP, you can in principle have multiple connections being served concurrently. If you tried to forward two TCP requests to the serial line simultaneously, chaos would ensue.
Still, you can build a working gateway with a slightly more complicated program than nc:
Accept connections on TCP port 5626 (note that the actually recommended port number for Modbus TCP is 502), convert the received TCP ADUs to RTU ADUs and put them into a queue together with a back channel.
Another part of your program takes one item at a time from that queue, sends the ADU over the serial line and reports the result back through the back channel. Then it goes on the to the next item, and so on.
The results arriving on the back channels are converted to TCP ADUs and sent back on the respective TCP connection.
This would certainly work on a Raspberry Pi, and possibly also on Arduino, depending on how large you want your queue to be.
Sources:
http://www.modbus.org/docs/Modbus_Application_Protocol_V1_1b.pdf
http://www.modbus.org/docs/Modbus_Messaging_Implementation_Guide_V1_0b.pdf
I am programming a server and client program to communicate between a windows PC using the Boost libraries and a Linux ARM beagleboard using the asio stand alone libraries. I have for a while had successful UDP communication between the two devices but now I want to recover the port from the endpoint the server discovers when the client connects. The way the client connects is via query:
udp::resolver resolver(io_service);
udp::resolver::query query_tx(udp::v4(), hostIP, "43210");
udp::endpoint receiver_endpoint_tx = *resolver.resolve(query_tx);
where host IP is a string and this works fine. Upon debugging though I notice that when i check the value returned by:
receiver_endpoint_tx.port()
This returns 51880. Now don't jump the guns and yell out network byte order and host byte order. I AM AWARE. The strange part is that this number 51880 sometimes is a different number and when i check what the server has stored in its endpoint it is a completely different number: 21743. Now I know I must be doing something wrong with the byte orders but i tried:
//unsigned long port_long = boost::asio::detail::socket_ops::host_to_network_long(receiver_endpoint_tx.port());
//unsigned long port_short = boost::asio::detail::socket_ops::host_to_network_short(receiver_endpoint_tx.port());
And they do not give me back my original port: 43210. Neither does network to host. So what am i missing and how can I on both ends recover my 43210 port? Obviously it must be there somewhere because they are successfully communicating.
Thanks in advance, sorry if noob mistake :)
Fistly, UDP is connectionless, there is no connection.
I'm not sure if I understand you correctly, but it sound too me like you want to bind to specific port numbers. If you want the client to send a packet from port x to port y on the server, and the server should respond from port y to port x, then you need to bind the sockets to the desired ports. Alternatively you can use the constructor to bind. Not doing so will result in the OS using ephemeral ports.
Further, to get the remote endpoint that a packet was received from the async_receive_from takes the sender_endpoint reference parameter. When the read handler is called, you can retrieve host and port from it.
I want to know some general communication strategies, which should be followed for a communication via COM (serial) Port.
I can read/write at the port, also can list all the available ports on the machine. I'm using Qt C++ with QSerialDevice. For testing on a windows machine with no physical serial port, I'm using VPSE (virtual port)
Typical Flow (assumed):
List all the available serial ports of the computer.
Find out at which port my device (micro-controller) is connected - how to do it?
Device found.
Start a thread for reading from the port, another thread for writing it.
Safely close connection
Finding out at which port the device is connected sounds challenging to me. How to achieve it? I guess, I will send a HELLO message to each ports, if my device replies a specific per-defined reply message I can be sure my device is connected at that port. Can I?
Also I think, to seperate threads are necessary because at any time I may receive message from the Micro-controller device.
Thanks for helping :)
I have a question about Qt & network sockets. If I have a computer with multiple IP-Adresses in different networks, how do I open an udp socket for a multicastgroup on a specific network-adapter/ip adress.
eg: ip 192.168.2.1 and 172.20.0.1 and I want to create a socket that receives packets from the multicast group 228.5.6.7 on the 172.20.0.1 network adapter.
You should set that in imr_interface as shown below: (probably it's set to INADDR_ANY now)
struct ip_mreq mreq;
mreq.imr_multiaddr.s_addr = inet_addr("228.5.6.7");
mreq.imr_interface.s_addr = inet_addr("172.20.0.1");// <---- right here
...
QSocketDevice* sdev = new QSocketDevice(QSocketDevice::Datagram);
...
setsockopt(sdev->socket(), IPPROTO_IP, IP_ADD_MEMBERSHIP,(const char *)&mreq, sizeof(struct ip_mreq));
...
If it's a listening socket, you can use bind to IP address to bind it to a specific IP address to listen on.
If it's a client socket, the OS manage the right interface to create it on to reach that IP address as per routing table rules.