Bug#966459: linux: traffic class socket options (both IPv4/IPv6) inconsistent with docs/standards
- To: Thorsten Glaser <t.glaser@tarent.de>, 966459@bugs.debian.org
- Subject: Bug#966459: linux: traffic class socket options (both IPv4/IPv6) inconsistent with docs/standards
- From: Salvatore Bonaccorso <carnil@debian.org>
- Date: Thu, 20 Feb 2025 13:17:04 +0100
- Message-id: <[🔎] Z7cdQILQRjQLKTEe@eldamar.lan>
- Reply-to: Salvatore Bonaccorso <carnil@debian.org>, 966459@bugs.debian.org
- In-reply-to: <alpine.DEB.2.23.453.2008042058100.5839@tglase-nb.lan.tarent.de>
- References: <159596111771.2639.6929056987566441726.reportbug@tglase-nb.lan.tarent.de> <e67190b7de22fff20fb4c5c084307e0b76001248.camel@decadent.org.uk> <Pine.BSM.4.64L.2008021919500.2148@herc.mirbsd.org> <e1beb0b98109d90738e054683f5eb1dd483011dd.camel@decadent.org.uk> <159596111771.2639.6929056987566441726.reportbug@tglase-nb.lan.tarent.de> <alpine.DEB.2.23.453.2008022243310.15898@tglase-nb.lan.tarent.de> <db7d2f4dde6db2af82c880756d76af1b7c1e41e8.camel@decadent.org.uk> <alpine.DEB.2.23.453.2008031733520.11571@tglase-nb.lan.tarent.de> <159596111771.2639.6929056987566441726.reportbug@tglase-nb.lan.tarent.de> <alpine.DEB.2.23.453.2008042058100.5839@tglase-nb.lan.tarent.de> <159596111771.2639.6929056987566441726.reportbug@tglase-nb.lan.tarent.de>
Control: tags -1 + moreinfo
Hi,
On Tue, Aug 04, 2020 at 08:59:42PM +0200, Thorsten Glaser wrote:
> On Mon, 3 Aug 2020, Thorsten Glaser wrote:
>
> > keep the code I currently have that compares byte 0 and 3, using
>
> Actually not. I’ve added some debugging code with…
>
> static size_t
> cmsg_actual_data_len(const struct cmsghdr *cmsg)
> {
> union {
> const struct cmsghdr *cmsg;
> const unsigned char *uc;
> } ptr[(
> /* compile-time assertions */
> sizeof(socklen_t) <= sizeof(size_t)
> ) ? 1 : -1];
> ptrdiff_t pd;
>
> ptr[0].cmsg = cmsg;
> pd = CMSG_DATA(cmsg) - ptr[0].uc;
> return ((size_t)cmsg->cmsg_len - (size_t)pd);
> }
>
> … and dumping the received data on Linux and MidnightBSD
> (the two systems I currently have access) and found varying
> results but if this returns 4 I think I better consume an int.
I see it was forwarded back then to
https://lore.kernel.org/netdev/e67190b7de22fff20fb4c5c084307e0b76001248.camel@decadent.org.uk/
but there was no comment from netdev people.
Should this bug be closed?
Regards,
Salvatore
Reply to: