Is there a way to preserve metadata or any equivalent data while sending and receiving mbuf to and from kni interface in dpdk??
Thanks in advance.
If you are asking for an out of the box solution, then no there is no such functionality. Only length and frame content get copied to/from the host kernel. For more information please see kni_net_tx/rx() functions in kni_net.c:
http://dpdk.org/browse/dpdk/tree/lib/librte_eal/linuxapp/kni/kni_net.c#n202
But sure, you can add whatever you want to each mbuf passing from/to kernel. The only requirement is that you have to change both user-space (i.e. DPDK lib/librte_kni) and kernel-space (i.e. lib/librte_eal/linuxapp/kni) to support the metadata you need.
Related
I'm trying to read the data from HTTP stream with TCP inside Linux kernel. I'm able to get most data from skb_buff here. However, if the server pushes data to the client without requests, the data won't be copied to user space so that I cannot find it any more.
Using Wireshark, I can find the additional data as a single packet normally. Therefore I think these data should go into kernel somewhere, even if they are not requested by the user space. Is it possible to find all the data when they are retrieved from Network Interface like Wireshark did? If so, where should I find them?
Thanks! Any ideas are appreciable.
EDIT: It should be different from another similar question. I even couldn't get the skb instance containing the data I need because the client didn't request it. Therefore such data won't be copied into user space. Thanks for pointing that question to me but I still need to find the correct skb instance first. I suspect I should catch the data somewhere when the data is retrieved from network interface.
CAN Protocol- Message Object (MObs)
As per my Knowledge these are the Buffers that will contain most recent message.
A very less information is available on Internet.
Please can anyone explain me in detail what exactly are Message Objects?
How these can be used in Programs?
Thanking in anticipation
Message objects are structured dependant on the processor type. So what you have to do is get the datasheet of your processor and see how is stores it's can messages and message box configuration.
This means the following: Each message object is a structure composed of the message's current data and the message configuration. The configuration refers to the message id filters.
Depending on the type of message you want to store in that message object you configure the filter for a range of ids and the processor will store them for you when they are received from the wire. In case you use for transmit the filters are not used.
Of course the structure might also contain flags to confirm that a message was sent, or that you want to cancel the message transmission, of if a message object is configured for transmission or reception.
If you have the datasheet we can find out more on what do you have in that Message Object.
Messages sent on a CAN bus, from what I've read seem to be referred to as "Frames".
There are 2 types messages:
Remote frames - from what I've seen so far these are used by ECU's to request Data frames from micro controllers on other ECU's on the bus
Data frames - replies to a remote frame with the the current state of that ECU, sending these can also be used to imitate a "command" from one ECU to another with e.g. the RF receiver for unlocking the door will (when triggered) send a data frame to the Door lock system (usually on a different bus connected to the can bus by a gateway ECU, vehicle specific) and the data will contain the requested state.
This link may assist you as a start point in learning more about CAN protocols/frames/bus
http://hem.bredband.net/stafni/developer/CAN.htm
Depending on the protocol, hardware and OS you're working with you may find SocketCan very useful as you can use it to create raw CAN frames: http://python-can.readthedocs.org/en/latest/socketcan.html
I'm trying to adjust TCP to work well over real-time communication. To do this one of the specification is to force TCP to accept new data written by the application even when the buffer is full which makes TCP sometimes 'unreliable'. This way the applications write calls are never blocked and the timing of the sender application is not broken.
I think there must be an option in NS2 to make it possible.
So, How can I force TCP to discard the oldest data segment in the buffer and accept the new data written by the application in NS2?
You cannot. TCP is a "reliable stream". Any functionality that allowed data to be dropped would be counter to that goal and so there is no such support.
If you want to be able to drop data, you're going to have to switch to something like UDP and implement your own windowing/retry if you want "mostly reliable delivery" instead of "best effort".
If you are going to be dropping data anyway, just drop it before you send it to the socket. You can use select to see if the socket is available for writing, and if not drop the data at the application layer. If it is of the utmost importance that you have the latest freshest data, then see Brian's answer.
Edit
On a side note you may want to google for real time network protocols, and see what already exists.
Wireshark doesn't seem to be able to change the content of filtered packets in real time.
Does anyone know a symilar software which can change packet content that is filtered.
Finding something like this will really be a life saver
Thanks.
At least on Unices and -like where raw sockets are used, this is not possible, since the packet is copied to userspace and you only work on that copy. Furthermore, sending a packet back through the raw socket may be considered an "outgoing" packet so that it is, in fact, not reinjected to the input path where it should be. Raw sockets were — according to the Linux manpage — designed to implement new protocols, IOW, raw sockets are an "endpoint", not a "passthrough station".
For packet modification in the input path (passthrough-like), each OS has its own set of interfaces. In Linux (you were sort of unspecific as to which you target), that would be the nfqueue mechanism, usable through libnetfilter_queue. And of course, that is how wireshark, if it wanted to (I don't see it doing packet alteration last time I checked), would go about doing this.
Please give Burp Suite a try. It includes a repeater that let's you modify HTTP requests.
No wireshark won't let you change the contents of the packets and place them back on the line. However there are ways to change packets as they pass through the machine. Typically the host is setup with two nics bridged together. One nic is connected to one network and the other nic to the other network. Then as packets pass through this point the host can see them. Now you can use iptables/netfilter and write a module that changes data in the packet. For example you can write something that can remap source ip addresses. It's been a while since I've used netfilter/iptables, so I can't provide anymore details, but I have used it in a previous job to do some neat things with packets while they were inflight. It does mean you need a host machine sitting at network junction points though.
The documentation suggests that node.get("nextSibling") and node.get("previousSibling") are what you need.
Yes, it can.
You need to pass this option to the configure script before you build it:
--enable-packet-editor
I am writing an application in C, using libpcap. My program listens for new packets and parses them
according to a grammar. The payload actually is XML.
Sometimes one packet is not enough for an XML file, so the XML buffer is splitted into separate packets.
I want to add code logic in order to handle these cases. However I don't know in advance that a packet does not contain the whole data. How do I know that a packet has more data that will be send next? How to i recognize that a new packet contains the rest of the data?
Do I have to use the TH_FIN flag? Could you please explain it to me?
There's nothing in TCP that defines packets, that's up to the higher layers to define if they need to - TCP is just a stream.
If this is raw XML over a TCP stream, you actually need to parse the xml - you'll know when you have a whole xml document when you've received the end of the document element.
If it's XML packaged over HTTP , you might be able to parse out the Content-Length: header which should contain the length of the body.
Note, reassembling a TCP stream from captured packets is a very hard problem, there's a lot of corner cases, e.g. you'd need to handle retransmission , out of sequence tcp segments and many more. http://libnids.sourceforge.net/ might help you.
As Anon say use a higher level stream library.
But even then you need to know the chunk side before starting to handle it, as you will read from the stream in block's of n bytes.
Thus you want to first send in binary the number of bytes to be sent, then send x bytes, and repeat, thus when you are receiving the chucks via select/read to know went you have all of chunk one to pass to the processor.
If you're using TCP, use a TCP library that gives you the data as a stream instead of trying to handle the packets yourself.
Stream is good. Another option is to store the incoming data in a buffer (eg char*) and search for application messaging framing characters or in the case of Xml, the root end tag. Once you've found a complete xml message at the front of the buffer, pull it out and process.
The XMPP instant messaging protocol, used by Jabber, has means to move XML chunks over a TCP stream. I don't know how exactly it is done myself, but RFC 3290 is the protocol definition. You should be able to work it out from that.