STRUCT RT2X00DUMP_HDR(9)

πŸ“¦ version 7.3.1, in nixpkgs unstable

πŸ’– struct rt2x00dump_hdr(9) πŸ’–

okay so first things first: this is a page from the Kernel API Manual, and we're talking about struct rt2x00dump_hdr β€” literally the dump frame header. bestie, it's the little name tag every dumped frame wears. let's get into it 🫢


✨ NAME ✨

struct rt2x00dump_hdr β€” Dump frame header. that's it, that's the vibe πŸ’…


🌸 SYNOPSIS 🌸

struct rt2x00dump_hdr {
    __le32 version;
  #define DUMP_HEADER_VERSION     3;
    __le32 header_length;
    __le32 desc_length;
    __le32 data_length;
    __le16 chip_rt;
    __le16 chip_rf;
    __le16 chip_rev;
    __le16 type;
    __u8 queue_index;
    __u8 entry_index;
    __le32 timestamp_sec;
    __le32 timestamp_usec;
 };

like, look at her. iconic struct layout, no notes πŸ”₯


πŸŽ€ Members πŸŽ€

  • version β€” the header version, and it should always be set to DUMP_HEADER_VERSION. fr fr, this is the field userspace has to check to figure out whether it can even handle this frame. don't skip the vibe check on this one πŸ‘‘
  • header_length β€” the length of the rt2x00dump_hdr structure itself. it's there for compatibility reasons, so userspace can easily determine the location of the next field in the dump. thoughtful queen behavior tbh πŸ’–
  • desc_length β€” the length of the device descriptor.
  • data_length β€” the length of the frame data (including the ieee802.11 header.
  • chip_rt β€” RT chipset ⭐
  • chip_rf β€” RF chipset ⭐
  • chip_rev β€” chipset revision.
  • type β€” the frame type (rt2x00_dump_type). yes, that's a whole other page, see SEE ALSO bestie 😌
  • queue_index β€” the index number of the data queue.
  • entry_index β€” the index number of the entry inside the data queue.
  • timestamp_sec β€” timestamp, in seconds ⏱️
  • timestamp_usec β€” timestamp, in microseconds. precision, we love to see it ✨

πŸ¦‹ Description πŸ¦‹

so every frame that gets dumped to the debugfs file starts with this header attached β€” like, it literally pulls up with its own lil intro card. and that header contains the description of the actual frame which was dumped. the way that the struct is just shipping the metadata first, obsessed 😭

⚠️ important rule, bestie, don't come for me: new fields inside the structure must be appended to the end of the structure. that way, userspace tools compiled for earlier header versions can still correctly handle the frame dump β€” although, and I say this with love, they will not handle all data passed to them in the dump. growth is a process 🌱

🌈 SEE ALSO 🌈

  • Kernel file ./drivers/net/wireless/ralink/rt2x00/rt2x00dump.h
  • Introduction(9), enum rt2x00_dump_type(9)

aaaaand that's the page!! πŸ“ this one came straight out of ./drivers/net/wireless/ralink/..., dated October 2026, and it's struct rt2x00dump_hdr(9) β€” go forth and dump your frames responsibly, ily, bye πŸ‘‹πŸ’œπŸ§š

πŸ“¦ where this page comes from