STRUCT UDP_MEDIA_ADDR(9)

πŸ“¦ version 7.3.1, in nixpkgs unstable

πŸ’… struct udp_media_addr(9) πŸ’…

okay bestie, welcome to the Kernel API Manual β€” this one's a lil struct page for struct udp_media_addr, and honestly? it's giving "small but knows things" energy. stick with me 🫢


✨ NAME ✨

struct udp_media_addr β€” the IP/UDP addressing info πŸŽ€ like, literally where a message is coming from at the bearer level, no cap.


🌸 SYNOPSIS 🌸

struct udp_media_addr {
    __be16 proto;
    __be16 port;
    union {
      struct in_addr ipv4;
      struct in6_addr ipv6;
    };
 };

look at her. neat. tidy. two bytes here, two bytes there, and a lil anonymous union doing the most πŸ’…


πŸ¦‹ Members πŸ¦‹

  • proto β€” the Ethernet protocol in use. which flavour of traffic we're talking about, iykyk ⭐
  • port β€” the port being used. the door number, basically πŸšͺ✨
  • {unnamed_union} β€” anonymous. no name, no problem, she's just there being mysterious πŸ™ˆ (it's the union holding the address, in case you were wondering)
  • ipv4 β€” IPv4 address of the neighbor πŸ‘€ the struct in_addr version
  • ipv6 β€” IPv6 address of the neighbor 🌈 the struct in6_addr version

πŸ’œ Description πŸ’œ

so here's the tea πŸ“ β€” this is the bearer level originating address used in neighbor discovery messages. that's the whole vibe: "hey, this is where I'm coming from" but at the bearer layer.

and this part is important, so I'm saying it loud: all fields should be in network byte order. all of them. every single one. don't be out here putting host byte order in there, I'm begging 😭 (that's what the __be16 types are screaming at you about, fr fr)


πŸ”₯ SEE ALSO πŸ”₯

go read tipc_udp_enable(9) too, she ate πŸ‘‘


that's the whole page, bestie 🧚 from ./net/tipc, dated October 2026 β€” and that's the struct udp_media_addr(9) manual section, wrapped up with a bow πŸŽ€πŸ’–

πŸ“¦ where this page comes from