I have a windows application on my PC which connects to a device over telnet. It sends a series of commands to the device, and the device responds to it.
Is there any way I can listen to what that program is writing to the device?
I tried using win32 socket programming to create a client that connects to the application. But, I get an error saying connection refused. When I analyze the traffic between the application and device on wireshark, I can see that the application uses different ports each time it reads from or writes to the telnet port(23) of the device.
Is there any way I can read the commands sent by the program to the device?
If you want to capture program's output to the device
programmatically, the right way is not to connect to the program (you
can't tap into an existing connection), but instead provide a server
that will stand for target device from the program's point of view.
It's going to work if the program can be configured to connect to the
device at different address and port. Write a "proxy" that listens on
some fixed port, and for any accepted connection, opens a client
connection to the real device. Then it should forward data in both
directions between the accepted connection from the program and the
client connection to the device. During this, you can also parse data
or do whatever you want with them, e.g. forward them to yet another
connection to another real device.
Related
I need to write a proxy server in C language on Linux (Ubuntu 20.04). The purpose of this proxy server is as follows. There're illogical governmental barriers in accessing the free internet. Some are:
Name resolution: I ping telegram.org and many other sites which the government doesn't want me to access. I ask 8.8.8.8 to resolve the name, but they response of behalf of the server that the IP may be resolved to 10.10.34.35!
Let's concentrate on this one, because when this is solved many other problems will be solved too. For this, I need to setup such a configuration:
A server outside of my country is required. I prepared it. It's a VPS. Let's call it RS (Remote Server).
A local proxy server is required. Let's call it PS. PS runs on the local machine (client) and knows RS's IP. I need it to gather all requests going to be sent through the only NIC available on client, process them, scramble them, and send them to RS in a way to be hidden from the government.
The server-side program should be running on RS on a specific port to get the packet, unscramble it, and send it to the internet on behalf of the client. After receiving the response from the internet, it should send it back to the client via the PS.
PS will deliver the response to the client application which originates the request. Of course this happens after it will unscramble and will find the original response from the internet.
This is the design and some parts is remained gloomy for me. Since I'm not an expert in network programming context, I'm going to ask my questions in the parts I'm getting into trouble or are not clear for me.
Now, I'm in part 2. See whether I'm right. There're two types of sockets, a RAW socket and a stream socket. A RAW socket is opened this way:
socket(AF_PACKET, SOCK_RAW, htons(ETH_P_ALL));
And a stream socket is opened this way:
socket(AF_INET, SOCK_STREAM, 0);
For RAW sockets, we use sockaddr_ll and for stream sockets we use sockaddr_in. May I use stream sockets between client applications and PS? I think not, because I need the whole RAW packet. I should know the protocol and maybe some other info of the packet, because the whole packet should be retrieved transparently in RS. For example, I should know whether it has been a ping packet (ICMP) or a web request (TCP). For this, I need to have packet header in PS. So I can't use a stream socket, because it doesn't contain the packet header. But until now, I've used RAW sockets for interfaces and have not written a proxy server to receive RAW packets. Is it possible? In another words, I've the following questions to go to next step:
Can a RAW socket be bound to localhost:port instead of an interface so that it may receive all low-level packets containing packet headers (RAW packets)?
I may define a proxy server for browser. But can I put the whole system behind the proxy server so that packets of other apps like PING may route automatically via it?
Do I really need RAW sockets in PS? Can't I change the design to suffice the data I got from the packets payload?
Maybe I'm wrong in some of the concepts and will appreciate your guidance.
Thank you
Can a RAW socket be bound to localhost:port instead of an interface so that it may receive all low-level packets containing packet headers (RAW packets)?
No, it doesn't make sense. Raw packets don't have port numbers so how would it know which socket to go to?
It looks like you are trying to write a VPN. You can do this on Linux by creating a fake network interface called a "tun interface". You create a tun interface, and whenever Linux tries to send a packet through the interface, instead of going to a network cable, it goes to your program! Then you can do whatever you like with the packet. Of course, it works both ways - you can send packets from your program back to Linux through the tun interface, and Linux will act like they just arrived on a network cable.
Then, you can set up your routing table so that all traffic goes to the tun interface, except for traffic to the VPN server ("RS"), which goes to your real ethernet/wifi interface. Otherwise you'd have an endless loop where your VPN program PS tried to send packets to RS but they just went back to PS.
I'm trying to send and receive data between a board (Dialog DA14531) and a simulation application of a temperature sensor.
I can easily send and receive data between the board and my computer, using Termite for instance.
By using Com0Com, I can receive the data sent from the sensor simulator in Termite as well.
However; I can't directly send data between this simulator and my board. I'm using Advanced Serial Port Monitor application and while the simulator states that the connection has been established, there seem to be nothing going on with this port.
Does someone have any idea about what might have caused the problem and how should I proceed for debugging?
So, I've figured out a new way to fix the issue:
Created a pair of virtual ports by using Com0COM.
Connected the simulator to one of these ports and Termite to the other one.
Connected the board to the system.
Used port forwarding in Termite to send the received data to the board.
This way, I can also monitor the data traffic between the board and the simulator.
I'm trying code TCP server in C language. I just noticed accept() function returns when connection is already established.
Some clients are flooding with random data some clients are just sending random data for one time, after that I want to close their's current connection and future connections for few minutes (or more, depends about how much load program have).
I can save bad client IP addresses in a array, can save timings too but I cant find any function for abort current connection or deny future connections from bad clients.
I found a function for windows OS called WSAAccept that allows you deny connections by user choice, but I don't use windows OS.
I tried code raw TCP server which allows you access TCP packet from begin including all TCP header and it doesn't accept connections automatically. I tried handle connections by program side including SYN ACK and other TCP signals. It worked but then I noticed raw TCP server receiving all packets in my network interface, when other programs using high traffic it makes my program laggy too.
I tried use libnetfilter which allows you filter whole traffic in your network interface. It works too but like raw TCP server it also receiving whole network interface's packets which is making it slow when there is lot of traffic. Also I tried compare libnetfilter with iptables. libnetfilter is slower than iptables.
So in summary how I can abort client's current and future connection without hurt other client connections?
I have linux with debian 10.
Once you do blacklisting on packet level you could get very fast vulnerable to very trivial attacks based on IP spoofing. For a very basic implementation an attacker could use your packet level blacklisting to blacklist anyone he wants by just sending you many packets with a fake source IP address. Usually you don't want to touch these filtering (except you really know what you are doing) and you just trust your firewall etc. .
So I recommend really just to close the file descriptor immediately after getting it from accept.
I am not clearly understanding the difference between using TCP socket with client connecting to 127.0.0.1 server address and other IPC such as message queues. Since both are used for communication within the same host, why at all someone would go for socket approach leaving the message queue one, as in this case, sockets will cause more overhead compared to the queues.
The differences that I am seeing:-
In case of sockets we can see the contents in wireshark, in queues there is no such way.
The point of the loopback interface / address is not that you write programs to use it specifically.
The point is that it lets you talk to network services running on the local computer in the same way that you would talk to network services running on a remote host. For instance, if I'm developing a website, I can start up a test instance of its server on my local computer and then point my browser at http://127.0.0.1/ and there it is. I don't have to modify the code of my browser to talk over AF_UNIX sockets or whatever first. Similarly, if I am writing an application that needs a database, I might start out with the database running on the same computer as the application, talking to it over loopback, but then later when the database gets bigger I can move it to a dedicated host and I don't have to change anything other than the connection configuration.
You are absolutely correct that local IPC has lower overhead, and should be used when the two processes that need to communicate will always be on the same machine.
TCP and IPC both approach we use for inter process communication in distributed architecture. If processes are running in same machine we will go for message queue but surely not TCP. But suppose one application is running in one box and another application is running in a different box definitely we have to go for TCP for inter process communication. Even web services also internally implement TCP for communicating to a remote application.
But still we need a TCP base communication in the same machine between two process where synchronize communication is must. For example if you send a request for an account information of a client and waiting for the response you need this approach. But if you just need to send a client information to a server to store it in a table and you don't need an answer from that server whether your records has been stored successfully or not you just go for a queue only to drop the message.
I'm developing a windows console application (C-language) which continuously communicates with network.
Application should start the database services immediately after the network connection has established.
Using socket, pipe or curl etc., seems not to be good approaches.
We can use curl to check network reachability but it does not seems correct way.
So, is there any way to check if network is reachable or not in 'C'?