When I inject any packet via WinPcap it will be captured in this moment.
I dont want to capture packets, witch were injected myself.
What is the easiest way?
The best way is to use PCAP_OPENFLAG_NOCAPTURE_RPCAP flag..
You could perhaps use a capture filter (pcap_setfilter()) and filter out packets by their source MAC address.
That may not be exactly what you want though, because MAC addresses can be spoofed, you might want to see outgoing packets from other sources on your machine, etc.
The only other thing I can think of would be to compute a hash value of each packet you send, and discard any captured packet with the same hash value.
There's got to be a better way…
Related
Is there anything in the Ruby library, or as a Ruby gem, that would help me construct a UDP datagram? I've looked into sockets, but there doesn't seem to be a way to simply build one and not send it.
My use case is this:
I need to build a single UDP datagram, and then pass it off to another module which will be responsible for sending it out. Simply put, I just need to be able to specify the src/dst address and port, as well as the payload.
I suppose in the worse case I can build some kind of a struct and fill in respective bits by hand, but it feels like reinventing the wheel as well as a lot of work. The underlying stuff in the sockets API should have something similar that I can make use of, shouldn't it?
The so called socket API is inherently a very low-level C-language API. When you create a UDP socket the connection information is stored in the kernel. You're never "building UDP datagrams", you're writing data into a UDP socket file descriptor, and the physical data packets to be sent over the wire are then constructed inside the kernel.
So yes, if you want a data structure that you can pass around your application that contains a destination address and some data, then you need to create this structure yourself since it doesn't exist by itself anywhere else.
It's not that much work. Just two (or three) data elements. You could use a simple Struct to do the job, unless you need more elaborate functionality and then you just build a normal class.
EDIT
Looks like I misunderstood your question. See my comment below for resources. For example here's some code from the Racket library docs, which probably is closer to what you were looking for:
# tack on UDP
n.l4 = UDP.new
# randomize source port
n.l4.src_port = 1024 + rand(65535-1024)
# take destination port from the commandline
n.l4.dst_port = ARGV[2].to_i
# build a random amount of garbage for the payload
n.l4.payload = Misc.randstring(ARGV[3].to_i)
# fix 'er up (checksum, length) prior to sending
n.l4.fix!(n.l3.src_ip, n.l3.dst_ip)
A professional videocamera is sending me packets over UDP and RTP, which contain MJPG-data in YUV422-pixelformat (RFC 2435). By using the DatagramSocket and DatagramPacket classes I am able to receive the packet. Now I am looking for an efficient way to get from:
approx 80 * RTP_socket.receive(rtpPacket) ---> 1 jpg-File on my Harddisk (with 25 fps)
Otherwise I am pretty soon loosing relatively many packets as, according to the UDP standard the packets are send continuously by the camera (Loosing a package once a while is not the worst as I don't need every frame).
Right now I am using a ByteBuffer to store the packets sequentially (with the header cut off using put (.. int offset...) until I got the final packet of one frame.
But unfortunately, it seems like I need to use the ImageIO.write function in order to get the necessary jpg-Header, correct? Because it cannot handle a ByteBuffer directly...
If I would do some after-processing of the image in another thread (not implemented yet), would a DirectByteBuffer make sense?
Hope you understood what I am asking :) . If not please don't hesitate to ask
Thanks a lot
You can port this C# Implementation which achieves over 100 FPS quite easily :)
https://net7mma.codeplex.com/SourceControl/latest#Rtp/RFC2435Frame.cs
I am the author and if you need porting help let me know!
I need to get a list of interfaces on my local machine, along with their IP addresses, MACs and a set of QoS measurements ( Delay, Jitter, Error rate, Loss Rate, Bandwidth)...
I'm writing a kernel module to read these information from local network devices,So far I've extracted every thing mentioned above except for both Jitter and Bandwidth...
I'm using linux kernel 2.6.35
It depends what you mean by bandwidth. In most cases you only get from the PHY something that is better called bitrate. I guess you rather need some kind of information on the available bandwidth at a higher layer, which you can't get without active or passive measurements done, e.g. sending ICMP echo-like probe packets, and investigating replies. You should also make clear what the two points in the network are (both the actual endpoints and the communication layer) between which you would like to measure available bandwidth.
As for jitter you also need to do some kind of measurements, basically the same way as above.
I know this is an old post, but you could accomplish at least getting jitter by inspecting the RTCP packets if they're available. They come in on the +1 of the RTP port and come along with any RTP stream as far as I've seen. A lot of information can be gotten from RTCP, but for your purposes just the basic source description would do it:
EDIT: (didn't look at the preview)
Just check out this link for the details of the protocol, but you can get the jitter pretty easily from an RTCP packet.
Depending on what you're using the RTP stream for too there are a lot of other resources, like the VoIP Metrics Report Block in the Extended Report (https://www.rfc-editor.org/rfc/rfc3611#page-25).
EDIT:
As per Artem's request here is a basic flow of how you might do it:
An RTP stream is started on say port 16400 (the needed drivers/mechanism for this to happen are most likely already in place).
Tell the kernel to start listening on port 16401 (1 above your RTP stream's port) as well; this is where the RTCP pkts will start coming in.
As the RTCP pkts come in send them wherever you want to handle them (ie, if you're wanting to parse it in userspace or something).
Parse the pkts for the desired data. I'm not aware of a particular lib to do this, but it's pretty easy to just point some struct at it (in C) and dereference, watching out for Endianess.
I want to grab the PC screen. I use QPixmap::grab, and I get a QPixmap. Then I want to send this image using QUdpsocket. The image has been already converted to binary.
http://www.java2s.com/Code/Cpp/Qt/Udpserver.htm 's demo can send and receive the image, but use pixel, I wanna send all binary data each 250ms.
If you want to send the whole image in one go, you could try using QDataStream for serialization of a QByteArray.
The problem with this is that a UDP packet has a limited size, and could get fragmented if too large, and while large packets may work on your LAN, they could get fragmented over the internet. As UDP doesn't provide ordering guarantees like TCP, the fragments could come in the wrong order without the QDataStream header. This is probably why in your linked example they are only sending a single line at a time.
You may want to read a comparison of TCP and UDP and evaluate which fits your needs better.
There is a field in the ethernet header called the ethernet type. I am writing a communication library in windows using raw ethernet frames. What should I do to take the Ethernet type into consideration? The one I must use is 0xBEEF. Does this mean I can't use anything like NDIS?
The best thing to do is to read about EtherType field.
It is used to indicate which protocol is encapsulated in the frame data.
This means that if you use 0xBEEF, other machines running standard software will not recognize the frame's payload.
You can, of course, send any kind of data in the frame. You will merely have to have your software installed on the receiving end to interpret the data.
Ethernet type is basically the type of the protocol of the data that is contained in that particular Ethernet frame .
If there aren't very good reasons for doing so, I would never use raw Ethernet frames. It's usually much simpler and more futureproof to e.g. use UDP packets.