I need to queue all tcp packets sent out from the local device programmatically so that the application I implemented using libnetfilter_queue and libpcap would start capturing packets within the queue. But the current solution I have is to manually type in,
sudo iptables -A OUTPUT -p tcp -j NFQUEUE
In the terminal before I run my application which is not acceptable as the application should queue all tcp packets and capture and show them automatically.
I would be really grateful if you experts could provide a solution so that sudo iptables -A OUTPUT -p tcp -j NFQUEUE coud be done within the application itself without the need of user typing it in the terminal every time the program is run.
Thank you :)
EDIT
Reason I am seekiing a solution to this programatically is because : until I type in iptables -F the device will hold on to the data without releasing. I want to capture the packets, which is happening now, modify it and send it without it being held in the queue :) the current code modifies the packets but it is kept in the queue until the -F command is given. I want the modified packets to be sent out to its destination without being held in the queue :)
Related
I have a C program that is currently logging events via syslog, after calling openlog to specify a program name.
The meat of my program that logs events to syslog is just three lines:
openlog(program_name, 0, facility);
syslog(log_level|facility,"%s\n",message);
closelog()
However, there are situations in my program where I should be sending the syslog event to a remote machine instead of logging locally, as the syslog function ordinarily does. What I'd like to do is optionally supply some other information to the function containing the above lines, such as a host (and optionally, a port), and whether to use udp or tcp, and if such information is present, send the syslog event to another machine via the rsyslog protocol to that machine.
What I categorically do NOT want to do is have to change any of the configuration files for the syslog daemon. I simply wish to, under program control, be able to send the same messages to another machine's syslog that would have otherwise shown up locally using the above three lines.
The only way I've been able to verify for sure I would be able to do this under program control is to construct a message manually that conforms to RFC 5424, and send it over a socket connection manually. Will I have to write the code to do all of this from scratch myself, or is there some existing facility out there (open source) that will do what I need?
Not in C but I used this to test my syslog server...
echo "$(TZ=UTC date +%FT%T.%NZ) $(uname -n) subsystem: hello" | socat -d -d - udp-sendto:syslog-server:514
I want to redirect stdout and stderr to a socket that I can then use to remotely monitor the status of my application over Ethernet. Currently I accomplish this by using ssh and watching the output in the shell console. I'd prefer to remove the middle man if possible and just send the entire stdout and stderr output to a udp or tcp/ip port and have my monitoring computer connect to it.
I cannot use UART or any other wired connection. It has to be Ethernet. Also, if possible, I'd like to accomplish this via a bash script, to prevent having to rebuild my application.
Thanks for the help.
The way you describe it, it sounds like your going to need either your existing application to open a passive socket and wait for connections, or your going to have to wrap your application in something that sets up a listening socket. This post suggests that is not possible in just Bash, however it does show ways to do it from the command line with netcat or perl. For example you could do something like this with netcat: nc -l -p <port> -c "tail -F /var/log/blah"
On the monitored application side, there is a way to redirect both outputs to an outbound connection, using netcat:
$ ./application 2>&1 | nc <remote-host> <remote-port>
This way, you're redirecting stderr to stdout and then pipe it all together to netcat, which will take care of setting up the socket, establish connection with the remote host and all that stuff.
However, bear in mind that you can suffer from printf()'s buffering, if that's the function you're using to write to stdout. In my local tests, I've seen that the data sent to stderr by the application is seen immediately on the other listening end, but on the other hand the data sent to stdout is only sent when the application exits or there's enough data in the buffer to flush it all at once. So, if you care about the order and the availability of the info on the monitoring side, I'd suggest you to place calls to fflush(stdout); whenever you print something interesting to stdout, or replace the calls to printf(), fprintf() and the like to write(), which does not buffer. The downside is that you have to touch the code of the application, of course, but I don't know any way to externally force flushing of an application's output buffers (i.e. from bash).
The scenario is pretty simple:
Using TCP/IP I have a client which connects to me (server) I want to forward the data the socket sends me to another socket which I opened and the data I received from that socket backwards.Just like a proxy.
Right now I have 1 thread one who listens from incoming connection and spawns another 2 when a connection from the client is established. I must use a mechanism for communicating in the threads.
Is there anything simpler which I can use to act as a TCP/IP proxy ? Does Linux have socket forwarding or some kind of mechanism ?
You can use iptables to do port forwarding. It's not a c solution, but it is a 2-line that has good performance and which will have minimal debugging.
From the second link:
iptables -A PREROUTING -t nat -i eth1 -p tcp \
--dport 80 -j DNAT --to 192.168.1.50:80
iptables -A INPUT -p tcp -m state --state NEW \
--dport 80 -i eth1 -j ACCEPT
The first line forward from port 80 to port 80 on 192.168.1.50 and the second accepts the connection, keeping iptables from dropping it.
You can add additional constraints with other iptables flags such as -s 10.0.3.0/24 would catch all the addresses with a source of 10.0.3.0 to 10.0.3.255
One user level solution is using socat. For example, to accept connections on port 8080 and forward them to 192.168.1.50:9090 you can use:
socat TCP-LISTEN:8080,fork TCP:192.168.1.50:9090
The fork option makes socat permit multiple connections.
You don't need threads. Take a look at select(), epoll() or kqueue() in order to manage multiple sockets without any thread (if you're on Windows, it's the completion port).
This is an example of a select-based server, it will be a good start.
For simple socket forwarding, let the kernel do it. Use iptables, or one of the frontends to configure it.
If you need complicated data sniffing/mangling/forwarding for real-world use, write an iptables module.
If you need to tee (duplicate/split) the data stream, or inspect or modify the data, then read on.
Linux 2.6.17 and later, with glibc 2.5 and later, do provide a couple of nice functions: splice() and tee(). You can use these to avoid having the payload copied to and from userspace, telling the kernel to transfer a specific amount of bytes from one descriptor to another. (tee() does not consume the data, allowing you to send one or more copies of the data to other descriptors.)
You could use your two threads per connection (one per direction), and have each thread read inspect/mangle/tee the data stream as necessary. When you know you have N incoming bytes to forward to one outgoing socket, use splice(). If you have more than one outgoing socket, use nonblocking outgoing sockets, tee() small chunks at a time (but use splice() for the last outgoing socket for each chunk).
Your threads can read some/all of the incoming data to decide what to do with it, but remember that you need to write() or send() the part you already read that needs to be sent, before using splice() or tee(); they don't magically pick up already consumed data.
I have a small server program in C which prints a message to the client. This program uses UDP Port for communication.
My question is: Is there a way or application by which I can test the functionality of my program from my windows machine. Example, if I type in some command, I can see the response from my program on my computer.
telnet xx.xx.xx.xx. PortNum, I believe telnet wpuld not work.
Not aware of any existing tools. I assume your server receives a message from the client and sends a response message back. If this is correct, create a basic client program which sends a message (sendto()) and then calls recvfrom() (default is blocking mode on my platform), then print the response message received. This works well for me. Don't have time to ferret around for an example (which is on linux) but you should be able to use an example udp client for windows from the web, I imagine. Let me know if you would like my client program as a template.
I think you may want to use netcat; if it's installed on your machine, it's typically executed by "nc"
netcat can connect to or listen on tcp or udp ports; -u is udp.
nc -u host port # connect to a udp port
nc -u -l 127.0.0.1 1026 # listen on port 1026, in udp mode.
etc.
libpcap can only read the packets, how can I change it?
Basically I want to register a callback function that operates on all incoming packets,
how can this be done?
What kind of traffic is this? How do you want to modify it? What OS?
On linux, you may be able to use iptables to have the kernel modify the packets for you.
If that can't do what you want (i.e., you need to get the packets into user space), you could look at netfilter_queue. Or as a simpler alternative, use an iptables REDIRECT rule to send all the packets to a single port, and write an application to listen on that port.