I am looking for UDP debugger tool, for the following requirement
1) netstat -s, shows udpInOverflows=23000 and this counter is increasing continuously.
how can I check udp packets which are thrown because of no buffer space.
2) what are the possible reason for this problem to occur and how to solve it.
3) is there any way to check incoming UDP packet which are received by kernel after all verification like udp socket is open for that port and no check sum error, snoop will not work because it capture direct from network interface.
Regards
Nitin
If you are willing to spend a little time with kernel source you should be able to use dtrace to get at the information you want. For example "dtrace -n 'fbt::udp_input:entry{stack();}' will show you how packets are getting into udp_input (not all that interesting). You should also check the mib::: probes and fbt:ip:ip_drop*:. This is all dependent on the version of Solaris you are using of course.
Related
I discovered almost accidentally that my machine was sending and receiving UDP packets to a machine in Poland. Not that I have any problem with Poland, I just don't know why my laptop has the need to communicate with a server there. Reverse DNS shows just the ISP providing the address to some end user. Using Wireshark, I can monitor the messages, which were indecipherable as they were probably encrypted. All packets sent from my machine had the same source port, so clearly the application that sent them opened this UDP socket to use it. I am searching for ways to:
1) enumerate all current sockets open in the system, including the process that created it and, for both TCP and UDP, what ports and addresses they are current bound to.
2) because applications can open these sockets, use them, and close them right away, I would love to find (or perhaps even write) a program that once started would somehow get notification each time a socket gets created, or really more importantly when bound to a source and/or destination address and port. For UDP, I would love to also be able to monitor/keep track of the destination IP addresses and ports that socket has sent messages to.
I don't want to monitor the traffic itself, I have Wireshark if I want to view the traffic. I want to be able to then cross reference to discover what application is generating the packets. I want to know if it is from a process I trust, or if it is something I need to investigate further.
Does anybody know of any applications (for the Windows platform) that can do this? If not, any ideas about a .NET or Windows API that provides this capability, should I want to write it myself?
Edit:
After further research - looks like the APIs to use are GetExtendedUdpTable and GetExtendedTcpTable, CodeProject.com has some samples wrapping these in .NET (see http://www.codeproject.com/Articles/14423/Getting-the-active-TCP-UDP-connections-using-the-G). So a combination of this API and some sniffer code would be needed to monitor and keep track of what hosts at what ports using what protocol any particular application on your machine is talking to. If I ever get some free time, I'll consider creating this, if you know of an app that does all this, please let me know.
Try SysInternals TCPView. Despite its name, it handles UDP as well.
netstat -b to enumerate all ports along with the process names.
You can try using SysInternals' Process MOnitor (ProcMon.exe or ProcMon64.exe).
It allows for filtering of Processes by "UDP Send" Operation - and provides detailed UDP Connection data, including source and destination addresses(IP) and ports etc.
I'm writing an IPsec implementation for a microcontroller and I want to test it using a standard Linux box running Debian Lenny. Both devices should secure the communication between them using IPsec ESP in tunnel mode. The keys are setup manually using setkey. There's no (or at least should be no) user space program involved in processing an IPsec packet. Now I want to see how my created packets are processed by the Linux kernel. To see the raw packets I capture them using tcpdump and analyze them using wireshark.
What's the best way to obtain debug information about IPsec processing?
How can I figure out whether the packet is accepted by the kernel?
How can I view the reason for a packet to be dropped?
You can instrument the XFRM (or perhaps ipv4/esp.c) kernel code to print out debug messages at the right spots.
For example, in net/ipv4/esp.c there exists a function esp_input() which has some error cases, but you'll see most the interesting stuff is in the xfrm/*.c code.
That said, I didn't have a problem interoperating a custom IPSec with Linux. Following the 43xx specs and verifying the packets came out correctly via wireshark seemed to do well. If you're having issues and don't want to instrument the kernel then you can setup iptables rules and count the number of (various type of) packets at each point.
Finally, be sure you've actually added a security policy (SP) as well as a security association (SA) and setup firewall rules properly.
I have to make a windows based application for which captures network traffic per application where some of running application uses same port number for sending and receiving the packets.
I have used winpcap and successfully captured and filtered them port wise and destination wise but I dont know how to capture them application wise that means how to know application information from ip packets.
Is only winpcap can solve the problem or some other api's or library shoud be used.
Can we get the application information from which packet is generated from packet header?
**
Can anyone give me example that uses iphlpapi and winpcap in vc++ for capturing network traffic per application.
**
I don't think this is possible with winpcap.
Take a look at Windows Filtering Platform. It's not advanced at all.If you look in the samples you can find one which does exactly what you want.
winpcap doesn't have a good way to tell what process is sending what data.
But windows does.
try using
netstat -a -o
netstat is a program that tells you what ports are being used on your terminal.
-a switch says, "show me all the ports"
-o switch says, "show me the pid of the processes using this port"
you can't see what port your processes are sending on, but you can see what ports are receving on for udp packets.
for tcp packets you'll see all the info you could want, includeing the remote connections ip address.
Is it possible to track XWindow protocol with a tool? I thought wireshark would be a good framework to host such an idea but there seems no support. What should be done to achieve this goal?
Wireshark does have the ability to dissect the X-Window protocol.
However: You first have to be able to capture the actual X-Window traffic between an X-client (app) and an X-Server before Wireshark can dissect it.
X-Windows traffic between an app (X-Windows client) and an X-Windows Server both running on your local machine probably uses "Unix Domain sockets" to do direct interprocess communication (IPC) between the client and the server. There's no underlying network protocol used and thus the traffic is (AFAIK) not capturable for dissection by Wireshark).
It's been a while since I've dealt with X but I think basically what is needed is that an X-Server be running on a box such that the server is listening for (and willing to accept) network connections. If an Xclient app on a remote node (or local node ?) then connects to the XServer over the network, you will then be able to capture that traffic for dissection by Wireshark.
X is complicated; If you're not familiar with the details of running X, you'll need to do some reading or ask for additional info. I've long since blanked out details related to X.
It is possible in principle to capture X-Window protocol that goes through Unix socket using strace. Then it is possible to wrap this packet for Wireshark using text2pcap.
Example:
capture X-window protocol frames that goes to X-server with pid 1998 on unix socket with file descriptor 41:
bash$ sudo strace -e trace=read,write -e read=41 -p 1998 2>&1 | grep '^[ ]|' >/tmp/xdata.log
prepare the captured data for wireshark:
bash$ text2pcap -T 1234,6000 /tmp/xdata.log /tmp/xdata.dump
Now one can use wireshark on /tmp/xdata.dump.
Back in the '80s, there was an open source Xwindow proxy program that would be placed between the Server and the client. It was written in 'C' and easily modifiable to count types of messages, or volume of data passing in each direction. It also recognized malformed Xprotocol that would result when folks used the wrong functions in interrupt handlers.
I can't remember the name, but maybe searching on "Xwindow proxy" might help...
I'm not sure what the XWindow protocol is, but you could make a Lua Dissector for Wireshark:
http://wiki.wireshark.org/Lua
i have rule set up to drop udp/tcp packets with matching strings. however, my program which captures packet using libpcap, is still able to see this packet.
Why is this/, what should be the iptable rules to drop packets before it is seen by libpcap?
Is there anyway,perhaps other than iptables rules, to drop this packet before it is seen by libpcap/tcpdump?
Yes, libpcap sees all the packets..
They are being captured before being processed by the netfilter.
Did you try to change the priority of the netfilter hook you use? if you try hooking with the highest priority for incoming packets, it will get the packet before the packet socket kernel code, which is the way libpcap uses to capture packets.
* I assume you are using linux *
EDIT:
Libpcap uses different ways to capture packets - according to the OS. on linux it uses packet socket which is implemented in kernel code using the netfilter framework.
Theres no way for libpcap to see the packets before netfilter, netfilter is a kernel module, and processes all packets before they hit user mode, it can even see the packets before the kernel sees it.
Could you explain further explain ?
Its possible that libpcap is also setting hooks on netfilter that overwrite the one in iptables. The real issue is that looking and what hooks are set on netfilter is far from trivial, and can only be done in kernel mode. Investigate how libpcap gets the packets.