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.
Related
So here is what I want to do:
Broadcast some information to my neighbours via UDP (wireless scenario) without having to specify an IP address (a generic one is fine). The port will be the same on all nodes. The incoming packet should be accepted by the neighbouring nodes and handed up to the application layer.
I've read this question but I was not able to find the mentioned parameter. I also couldn't find out how to bind a socket to a specific interface by looking at the developers guide of inet.
So my question is: Is it even possible to broadcast from Application Layer?
If it is: Which parameters do I have to set?
If it is not possible: Do I have to go to a lower layer? I have seen the the pure ethernet examples in inet (inet/applications/ethernet/) but how can I apply this to a wireless scenario?
So I found it out myself. I'm posting an answer here to help other people encountering the same problem.
I solved the problem by setting several udp socket options. I set the following (some of them are not necessary but I found them to be useful):
socket.setMulticastOutputInterface(101);
socket.setMulticastLoop(false);
socket.bind(port);
L3Address address;
L3AddressResolver().tryResolve("224.0.0.1", address);
socket.joinMulticastGroup(address);
setMulticastOutputInterface(101): This sets the interface (by id) which should be used to broadcast (multicast) my messages.
setMulticastLoop(false): I found this to be useful to prevent ipv4 layer to sent
the multicast to my loopback device as well. This is not necessary though.
bind(port): This is to only receive udp packets with the given destination port. Not necessary too.
joinMulticastGroup(address): This is necessary to accept the packets with the given multicast address.
I imagined the solution to be somewhat different but this is fine for my use case. I tried to stay as far away from lower layer broadcasting as possible to avoid being dependent on a specific lower layer protocol. Check out the source code comments for more info. Hope this helps someone.
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.
I have a Keyspan PCI to RS-422 adapter that I'm using to connect old serial devices to a Macintosh. I would like to use NSInputStream and NSOutputStream to read and write so that I can take advantage of asynchronous nonblocking I/O since there will be several devices attached to this system that each have their own idiosyncrasies.
My question is how can I access some low level parameters for the devices using a NSStream (baud rate, count of stop bits, parity, etc)?
I thought I researched everything before I asked the question, but the answer was in another class (NSFilehandle).
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…