Pcap open an interface and inject packets - c

I need to write a program in C to read in pcap files and extract the packets and send them out . It's like a traffic replay. I know there's tcpreplay but I didn't see its C library, it seems to be only a command-line application.
I know how to do it with pcap_open(), but it's only available in WinPcap, I need to do it in linux with libpcap. Anybody can provide some hint? Thanks in advance.
edit: I can parse the packets, but now I just don't know how to open an interface to send the packets out. Thanks.

Use either pcap_open_live() or, in newer versions of libpcap, pcap_create() and pcap_activate() - all of which are available in the current version of WinPcap, by the way.

Related

Fetch dropped packet count of an interface with netlink sockets

I am familiar with different tools (like netstat, tcpdump, etc.) and files (like /sys/class/net/<dev>/statistics) with which we can get the count.
But can anyone tell me if there is a way of getting that information directly from the kernel, using netlink sockets?
Sure, take a look at IFLA_STATS. You may want to check the ifstat.c file of the iproute2 package, which is pretty much the standard tool to interact with netlink.

pCap capturing outgoing packets

The question is, does pCap library allow capturing packets that are generated by the local system? something like the netfitler hook NF_IP_LOCAL_OUT but in user-space? If pCap cannot support this, is there any well-supported library that can?
Looking on the web, some people mentioned that pCap has a function called setDirection which sets which traffic we're capturing according to traffic direction but many people said this function is only on Windows; and I am kinda limited in time to learn about pCap just to test if it can do what I need to do.
The question is, does pCap library allow capturing packets that are generated by the local system?
Yes. In fact, it captures them by default. You can, in newer versions of libpcap, disable that by calling pcap_setdirection(), but, by default, it captures both incoming and outgoing packets on the interface on which you're capturing. pcap_setdirection() exists in newer versions of WinPcap, but it just returns an error; there's a flag for the WinPcap-only pcap_open() that lets you disable capturing outgoing packets.
I've certainly use tcpdump (on linux) to capture traffic on local interface and originating from the own machine. Since tcpdump uses libpcap, this must be possible.
I'm afraid this is a rather rubbish answer, because I can't tell you exactly HOW to configure libpcap to capture your local packets. However, I would suggest that tcpdump is a good starting point - either by simply using tcpdump itself, or look at the code [which is probably quite large and complex, of course, but if you can figure out what settings you need to make tcpdump do what you want, then you can perhaps add some code to tcpdump to print the settings it uses for the same thing].
Again, slight apology for not "giving you the code".
Also dumpcap -i < capture interface> captures the live traffic,
Dumpcap is a network traffic dump tool. It lets you capture packet data from a live network and write the packets to a file. Dumpcap's native capture file format is libpcap format, which is also the format used by Wireshark, tcpdump and various other tools.

/proc/net/tcp Alternative Under Solaris 11

On Most Linux Distributions, i was able to list all tcp connections by reading /proc/net/tcp, but this Doesn't exists on solaris, is there a file that i can read tcp connections from on Solaris 11?
thanks.
EDIT: forgot to mention that i'm coding in c.
If you're trying to rewrite netstat, I suggest looking at the source code for it: https://hg.java.net/hg/solaris~on-src/file/tip/usr/src/cmd/cmd-inet/usr.bin/netstat/netstat.c
The important parts are mibopen, which opens /dev/arp and pushes the tcp STREAMS module onto it, and mibget which actually requests the connection information. The code is a bit complicated, so I suggest stepping through the code in a debugger to understand how it works. The key syscalls are open, ioctl, putmsg, and getmsg.
If you just want to see what sockets a process has open, you can inspect /proc/PID/fd, as in pfiles: https://hg.java.net/hg/solaris~on-src/file/tip/usr/src/cmd/ptools/pfiles/pfiles.c
You should either use netstat -an or pcp

"Replay" tcpdump file

I am writing a program for analyzing certain type of packets. I got the dump file containing test packets in tcpdump format. is there any way to send this dump into one of the interfaces? I thought tcpdump would be able to do this on its own (unfortunately it isn't). Only thing I managed to do is to look at packets via wireshark (which obviously isn't the way to go).
I could use libpcap function pcap_open_offline(), unfortunately I use pcap_loop() which doesn't seem to work with pcap_open_offline() and rewriting code to pcap_next() would be very painful. Is there any program that could send packets to the interface?
Did you try to take a look to tcpreplay that is done to :
Replay network traffic stored in pcap files
Newer versions of libpcap provide a pcap_inject() function that can be used to write packets back out.
You can see someone's testing program to use pcap_inject() over on UbuntuForums.

c udp chat testing

I am writing a udp chat application in c. I need to test if messages are received in an incorrect order. CAn anyone please tell me of a tool I can use to delay certain messages? also please tell me how to use it? thank you very much in advance! also I am using ubuntu x86_64 and OSX 10.6.4. A tool in either OS will work
When I created a syslog server I needed to see if it was catching the messages.
I used Wireshark from http://www.wireshark.org/ . This is a free tool that shows you all traffic passing your network cable. Even packages not intended for your computer.
Have fun...
If you need to verify this, you probably also don't want messages to disappear (or at least know if they do). UDP doesn't sound like what you want. Have a look at implementing this using TCP instead, you get this behaviour with the protocol.

Resources