0

I am new to using XDP and trying to teach myself how to create ELF programs to do a variety of XDP actions. I am also a beginner to using C.

How can I parse through packets to show data from specific bytes in the data without using helper headers (ip.h, tcp.h, udp.h, etc.)?

I tried following the xdp_tutorial section on parsing packets found here. I also tried reading through how to parse packets from skbuff with bpf. There was an example found here in this git repo found here. Tbh, trying to follow the xdp_tutorial examples was fairly difficult for me as I am so new to C. I did find some XDP examples here as well which are more straight forward to me.

All of these examples suffer from the same problem of not detailing how to work with higher level headers in a packet (DNS, HTTP, etc.)

I understand the basics of setting up an xdp program. Clear out the buffers for *data and *data_end then find the length of the ethernet header, ip header, and L4 header. The problem is most examples and guides I follow require me to use structs from header files to parse through the structure of the packet. That's all well and good, however how would I parse through a DNS or HTTP header? What if I want to look at what the 11th byte of a FTP header is? How can I check if a HTTP header contains a GET or PUT request?

Just looking for an example of working though the a higher level packet like HTTP.

Dave
  • 727
  • 1
  • 9
  • 20
  • Re "*How can I check if a HTTP packet is a GET or PUT request?*", There's no such thing as a GET or PUT packet. You would need to reassemble the stream (i.e. put the fragments and packets in order, using only acknowledged packets) to parse the HTTP request, which might span more than one packet – ikegami Feb 21 '22 at 18:58
  • @ikegami, updated the post, sorry about that. – Dave Feb 21 '22 at 19:00
  • 2
    Doesn't change anything. There's no such thing as HTTP packets, only HTTP streams. You'd have to reimplement a chunk of TCP. Same for FTP. – ikegami Feb 21 '22 at 19:00
  • Inasmuch as the point of "without using helper headers" seems to be that you want to access application-layer information, you have an essential disconnect: that's not what XDP is intended for. XDP operates at the network layer, not the application layer. – John Bollinger Feb 21 '22 at 19:28
  • @JohnBollinger, not sure I follow, what do you mean XDP operates at the network layer? I am able to access L4 data like TCP/UDP ports, as well as L2 data. Why would I not be able to access L7 data? – Dave Feb 21 '22 at 19:31
  • I didn't say you *couldn't* access application-layer data. I said that's not what XDP is intended for. XDP operates at the level of individual packets, which is the network and transport layers. Application-layer messages are not, in general, split cleanly across network packets. To *usefully* access application-layer data, an XDP program would first need to duplicate the work of higher levels of the network stack to assemble data from multiple packets into a stream. And *then* it would need to parse the data according to the appropriate application-layer protocol. [...] – John Bollinger Feb 21 '22 at 19:53
  • [...] That's pretty heavyweight for XDP's position in the network stack, and again, it is not what XDP is intended for. – John Bollinger Feb 21 '22 at 19:54
  • To clarify sounds like XDP is not currently intended to be used on application layer protocols. Should I only be building XDP applications based around L2-L4, namely where I can use header structs to parse through packets? – Dave Feb 21 '22 at 19:58
  • That's more or less what I said, @Dave. XDP is a *packet* processing facility, which puts it primarily at layer 3 the OSI model. It can access per-packet data associated with layers 2 - 4. This is exactly the domain where using the kernel's structs modeling packet structure and contents is useful and appropriate. – John Bollinger Feb 21 '22 at 20:48
  • Did you have a look at [this bcc example filtering HTTP packets](https://github.com/iovisor/bcc/tree/master/examples/networking/http_filter)? – Qeole Feb 24 '22 at 15:11
  • As John Bollinger mentioned, HTTP rides on TCP which is a "stream" such that each packet can have partial HTTP message(s), multiple HTTP messages, partial and multiple HTTP message(s), or a single HTTP message. Take a look at the packet/message formats in the relevant RFC(s), and/or play around with Wireshark's "follow TCP stream" feature--that might help your understanding (since you seen to not like structs). – Andrew Feb 25 '22 at 16:37

0 Answers0