Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.debian.kernel > #67641 > unrolled thread
| Started by | Thorsten Glaser <tg@mirbsd.de> |
|---|---|
| First post | 2020-07-28 20:40 +0200 |
| Last post | 2020-08-04 21:10 +0200 |
| Articles | 8 — 3 participants |
Back to article view | Back to linux.debian.kernel
Bug#966459: linux: traffic class socket options (both IPv4/IPv6) inconsistent with docs/standards Thorsten Glaser <tg@mirbsd.de> - 2020-07-28 20:40 +0200
Bug#966459: linux: traffic class socket options (both IPv4/IPv6) inconsistent with docs/standards Ben Hutchings <ben@decadent.org.uk> - 2020-08-02 20:00 +0200
Bug#966459: linux: traffic class socket options (both IPv4/IPv6) inconsistent with docs/standards Thorsten Glaser <t.glaser@tarent.de> - 2020-08-02 21:50 +0200
Bug#966459: linux: traffic class socket options (both IPv4/IPv6) inconsistent with docs/standards Ben Hutchings <ben@decadent.org.uk> - 2020-08-02 22:40 +0200
Bug#966459: linux: traffic class socket options (both IPv4/IPv6) inconsistent with docs/standards Thorsten Glaser <t.glaser@tarent.de> - 2020-08-02 22:50 +0200
Bug#966459: linux: traffic class socket options (both IPv4/IPv6) inconsistent with docs/standards Ben Hutchings <ben@decadent.org.uk> - 2020-08-03 05:40 +0200
Bug#966459: linux: traffic class socket options (both IPv4/IPv6) inconsistent with docs/standards Thorsten Glaser <t.glaser@tarent.de> - 2020-08-03 19:10 +0200
Bug#966459: linux: traffic class socket options (both IPv4/IPv6) inconsistent with docs/standards Thorsten Glaser <t.glaser@tarent.de> - 2020-08-04 21:10 +0200
| From | Thorsten Glaser <tg@mirbsd.de> |
|---|---|
| Date | 2020-07-28 20:40 +0200 |
| Subject | Bug#966459: linux: traffic class socket options (both IPv4/IPv6) inconsistent with docs/standards |
| Message-ID | <AxCG6-6la-9@gated-at.bofh.it> |
Package: src:linux
Version: 5.7.6-1
Severity: normal
Tags: upstream
X-Debbugs-Cc: tg@mirbsd.de
I’m using setsockopt to set the traffic class on sending and receive
it in control messages on receiving, for both IPv4 and IPv6.
The relevant documentation is the ip(7) manpage and, because the ipv6(7)
manpage doesn’t contain it, RFC3542.
For the receiving side, the corresponding socket options are:
• IPPROTO_IP ⇒ IP_RECVTOS, with an int argument 1 (as in the manpage)
• IPPROTO_IPV6 ⇒ IPV6_TCLASS, with an int argument 1 (as in the RFC)
The receiving CMSG is then supposed to contain the traffic class octet
as first byte in the corresponding CMSG_DATA:
IP_RECVTOS (since Linux 2.2)
If enabled, the IP_TOS ancillary message is passed with incoming
packets. It contains a byte which specifies the Type of Ser‐
vice/Precedence field of the packet header.
… and…
In the cmsghdr structure containing this ancillary data, the
cmsg_level member will be IPPROTO_IPV6, the cmsg_type member will be
IPV6_TCLASS, and the first byte of cmsg_data[] will be the first byte
of the integer traffic class.
However, Linux has net/ipv6/datagram.c…
int tclass = ipv6_get_dsfield(ipv6_hdr(skb));
put_cmsg(msg, SOL_IPV6, IPV6_TCLASS, sizeof(tclass), &tclass);
… and net/ipv6/ipv6_sockglue.c…
int tclass = (int)ip6_tclass(np->rcv_flowinfo);
put_cmsg(&msg, SOL_IPV6, IPV6_TCLASS, sizeof(tclass), &tclass);
… both setting them as int, breaking standards/documentation-compliant
code on all big endian platforms. Same in net/ipv4/ip_sockglue.c…
int tos = inet->rcv_tos;
put_cmsg(&msg, SOL_IP, IP_TOS, sizeof(tos), &tos);
… in one place, but…
put_cmsg(msg, SOL_IP, IP_TOS, 1, &ip_hdr(skb)->tos);
… in ip_cmsg_recv_tos(), yielding inconsistent results for IPv4(!).
For the sending side, we use:
• IPPROTO_IP, IP_TOS, with an argument…
• IPPROTO_IPV6, IPV6_TCLASS, with an argument…
This is funny. The documentation says to use a byte for IPv4…
IP_TOS (since Linux 1.0)
Set or receive the Type-Of-Service (TOS) field that is sent with
every IP packet originating from this socket. It is used to
prioritize packets on the network. TOS is a byte. There are
… and setsockopt works with a byte argument, but for IPv6, using a
byte causes EINVAL (but this is because RFC3542 says int, overriding
the itojun draft which said byte).
Looking at the kernel code, IP_TOS indeed reads a byte if the size
given is less than 4, an int otherwise… except bpf_setsockopt, which
expects an int. OK, should be no problem for my userspace code.
IPV6_TCLASS always expects an int. Unexpected but apparently okay
wrt. the documentation.
tl;dr: Receiving traffic class values from IP traffic is broken on
big endian platforms.
I place the following suggestion for discussion, to achieve maximum
portability: put 4 bytes into the CMSG for both IPv4 and IPv6, where
the first and fourth byte are, identically, traffic class, second and
third 0.
Please forward this upstream. Thanks!
-- Package-specific info:
** Version:
Linux version 5.7.0-1-amd64 (debian-kernel@lists.debian.org) (gcc version 9.3.0 (Debian 9.3.0-14), GNU ld (GNU Binutils for Debian) 2.34) #1 SMP Debian 5.7.6-1 (2020-06-24)
** Command line:
BOOT_IMAGE=/vmlinuz-5.7.0-1-amd64 root=/dev/sda4 ro rootdelay=5 syscall.x32=y vsyscall=emulate net.ifnames=0 kaslr pcie_aspm=force consoleblank=0
** Tainted: W (512)
* kernel issued warning
** Kernel log:
Unable to read kernel log; any relevant messages should be attached
** Model information
sys_vendor: LENOVO
product_name: 7673AG4
product_version: ThinkPad X61
chassis_vendor: LENOVO
chassis_version: Not Available
bios_vendor: LENOVO
bios_version: 7NET30WW (1.11 )
board_vendor: LENOVO
board_name: 7673AG4
board_version: Not Available
** Loaded modules:
ufs
hfs
dm_mod
loop
netlink_diag
snd_seq_dummy
cdc_acm
ctr
aes_generic
libaes
crypto_simd
cryptd
glue_helper
ccm
cpufreq_conservative
cpufreq_userspace
cpufreq_powersave
binfmt_misc
nft_counter
nft_chain_nat
xt_MASQUERADE
nf_nat
nf_conntrack
nf_defrag_ipv6
nf_defrag_ipv4
libcrc32c
nft_compat
nf_tables
x_tables
nfnetlink
tun
snd_seq_midi
snd_seq_midi_event
snd_rawmidi
snd_seq
snd_seq_device
snd_hda_codec_analog
snd_hda_codec_generic
ppdev
iwl4965
coretemp
snd_hda_intel
iwlegacy
kvm_intel
snd_intel_dspcfg
pcmcia
kvm
snd_hda_codec
mac80211
snd_hda_core
snd_hwdep
snd_pcm_oss
irqbypass
snd_mixer_oss
cfg80211
serio_raw
pcspkr
snd_pcm
sg
iTCO_wdt
yenta_socket
iTCO_vendor_support
thinkpad_acpi
pcmcia_rsrc
watchdog
pcmcia_core
snd_timer
libarc4
nvram
ledtrig_audio
snd
soundcore
ac
rfkill
parport_pc
evdev
parport
button
acpi_cpufreq
ext4
crc16
mbcache
jbd2
crc32c_generic
sd_mod
t10_pi
crc_t10dif
crct10dif_generic
crct10dif_common
ata_generic
i915
ata_piix
sdhci_pci
i2c_algo_bit
ahci
libahci
drm_kms_helper
cqhci
libata
uhci_hcd
ehci_pci
ehci_hcd
sdhci
e1000e
cec
psmouse
scsi_mod
mmc_core
drm
usbcore
i2c_i801
lpc_ich
mfd_core
usb_common
ptp
pps_core
battery
video
** PCI devices:
00:00.0 Host bridge [0600]: Intel Corporation Mobile PM965/GM965/GL960 Memory Controller Hub [8086:2a00] (rev 0c)
Subsystem: Lenovo ThinkPad T61/R61 [17aa:20b3]
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort+ >SERR- <PERR- INTx-
Latency: 0
Capabilities: <access denied>
00:02.0 VGA compatible controller [0300]: Intel Corporation Mobile GM965/GL960 Integrated Graphics Controller (primary) [8086:2a02] (rev 0c) (prog-if 00 [VGA controller])
Subsystem: Lenovo GM965 [X3100] on ThinkPad T61/R61 [17aa:20b5]
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 0
Interrupt: pin A routed to IRQ 16
Region 0: Memory at f8000000 (64-bit, non-prefetchable) [size=1M]
Region 2: Memory at e0000000 (64-bit, prefetchable) [size=256M]
Region 4: I/O ports at 1800 [size=8]
Expansion ROM at 000c0000 [virtual] [disabled] [size=128K]
Capabilities: <access denied>
Kernel driver in use: i915
Kernel modules: i915
00:02.1 Display controller [0380]: Intel Corporation Mobile GM965/GL960 Integrated Graphics Controller (secondary) [8086:2a03] (rev 0c)
Subsystem: Lenovo GM965 [X3100] on ThinkPad T61/R61 [17aa:20b5]
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 0
Region 0: Memory at f8100000 (64-bit, non-prefetchable) [size=1M]
Capabilities: <access denied>
00:19.0 Ethernet controller [0200]: Intel Corporation 82566MM Gigabit Network Connection [8086:1049] (rev 03)
Subsystem: Lenovo 82566MM Gigabit Network Connection [17aa:20de]
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 0
Interrupt: pin A routed to IRQ 28
Region 0: Memory at f8200000 (32-bit, non-prefetchable) [size=128K]
Region 1: Memory at f8225000 (32-bit, non-prefetchable) [size=4K]
Region 2: I/O ports at 1840 [size=32]
Capabilities: <access denied>
Kernel driver in use: e1000e
Kernel modules: e1000e
00:1a.0 USB controller [0c03]: Intel Corporation 82801H (ICH8 Family) USB UHCI Controller #4 [8086:2834] (rev 03) (prog-if 00 [UHCI])
Subsystem: Lenovo ThinkPad T61/R61 [17aa:20aa]
Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 0
Interrupt: pin A routed to IRQ 20
Region 4: I/O ports at 1860 [size=32]
Kernel driver in use: uhci_hcd
Kernel modules: uhci_hcd
00:1a.1 USB controller [0c03]: Intel Corporation 82801H (ICH8 Family) USB UHCI Controller #5 [8086:2835] (rev 03) (prog-if 00 [UHCI])
Subsystem: Lenovo Thinkpad T61/R61 [17aa:20aa]
Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 0
Interrupt: pin B routed to IRQ 21
Region 4: I/O ports at 1880 [size=32]
Kernel driver in use: uhci_hcd
Kernel modules: uhci_hcd
00:1a.7 USB controller [0c03]: Intel Corporation 82801H (ICH8 Family) USB2 EHCI Controller #2 [8086:283a] (rev 03) (prog-if 20 [EHCI])
Subsystem: Lenovo ThinkPad T61/R61 [17aa:20ab]
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 0
Interrupt: pin C routed to IRQ 22
Region 0: Memory at f8426c00 (32-bit, non-prefetchable) [size=1K]
Capabilities: <access denied>
Kernel driver in use: ehci-pci
Kernel modules: ehci_pci
00:1b.0 Audio device [0403]: Intel Corporation 82801H (ICH8 Family) HD Audio Controller [8086:284b] (rev 03)
Subsystem: Lenovo ThinkPad T61/R61 [17aa:20ac]
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 0, Cache Line Size: 64 bytes
Interrupt: pin B routed to IRQ 26
Region 0: Memory at f8220000 (64-bit, non-prefetchable) [size=16K]
Capabilities: <access denied>
Kernel driver in use: snd_hda_intel
Kernel modules: snd_hda_intel
00:1c.0 PCI bridge [0604]: Intel Corporation 82801H (ICH8 Family) PCI Express Port 1 [8086:283f] (rev 03) (prog-if 00 [Normal decode])
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 0, Cache Line Size: 64 bytes
Interrupt: pin A routed to IRQ 24
Bus: primary=00, secondary=02, subordinate=02, sec-latency=0
I/O behind bridge: 00002000-00002fff [size=4K]
Memory behind bridge: f4000000-f5ffffff [size=32M]
Prefetchable memory behind bridge: 00000000f8500000-00000000f85fffff [size=1M]
Secondary status: 66MHz- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort+ <SERR- <PERR-
BridgeCtl: Parity- SERR+ NoISA+ VGA- VGA16- MAbort- >Reset- FastB2B-
PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-
Capabilities: <access denied>
Kernel driver in use: pcieport
00:1c.1 PCI bridge [0604]: Intel Corporation 82801H (ICH8 Family) PCI Express Port 2 [8086:2841] (rev 03) (prog-if 00 [Normal decode])
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 0, Cache Line Size: 64 bytes
Interrupt: pin B routed to IRQ 25
Bus: primary=00, secondary=03, subordinate=03, sec-latency=0
I/O behind bridge: 00003000-00003fff [size=4K]
Memory behind bridge: f6000000-f7ffffff [size=32M]
Prefetchable memory behind bridge: 00000000f8600000-00000000f86fffff [size=1M]
Secondary status: 66MHz- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- <SERR- <PERR-
BridgeCtl: Parity- SERR+ NoISA+ VGA- VGA16- MAbort- >Reset- FastB2B-
PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-
Capabilities: <access denied>
Kernel driver in use: pcieport
00:1d.0 USB controller [0c03]: Intel Corporation 82801H (ICH8 Family) USB UHCI Controller #1 [8086:2830] (rev 03) (prog-if 00 [UHCI])
Subsystem: Lenovo ThinkPad T61/R61 [17aa:20aa]
Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 0
Interrupt: pin A routed to IRQ 16
Region 4: I/O ports at 18a0 [size=32]
Kernel driver in use: uhci_hcd
Kernel modules: uhci_hcd
00:1d.1 USB controller [0c03]: Intel Corporation 82801H (ICH8 Family) USB UHCI Controller #2 [8086:2831] (rev 03) (prog-if 00 [UHCI])
Subsystem: Lenovo ThinkPad T61/R61 [17aa:20aa]
Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 0
Interrupt: pin B routed to IRQ 17
Region 4: I/O ports at 18c0 [size=32]
Kernel driver in use: uhci_hcd
Kernel modules: uhci_hcd
00:1d.7 USB controller [0c03]: Intel Corporation 82801H (ICH8 Family) USB2 EHCI Controller #1 [8086:2836] (rev 03) (prog-if 20 [EHCI])
Subsystem: Lenovo ThinkPad T61/R61 [17aa:20ab]
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 0
Interrupt: pin D routed to IRQ 19
Region 0: Memory at f8427000 (32-bit, non-prefetchable) [size=1K]
Capabilities: <access denied>
Kernel driver in use: ehci-pci
Kernel modules: ehci_pci
00:1e.0 PCI bridge [0604]: Intel Corporation 82801 Mobile PCI Bridge [8086:2448] (rev f3) (prog-if 01 [Subtractive decode])
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 0
Bus: primary=00, secondary=05, subordinate=08, sec-latency=32
I/O behind bridge: 00004000-00007fff [size=16K]
Memory behind bridge: d4000000-d7efffff [size=63M]
Prefetchable memory behind bridge: 00000000d8000000-00000000dbffffff [size=64M]
Secondary status: 66MHz- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort+ <SERR- <PERR-
BridgeCtl: Parity- SERR+ NoISA- VGA- VGA16- MAbort- >Reset- FastB2B-
PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-
Capabilities: <access denied>
00:1f.0 ISA bridge [0601]: Intel Corporation 82801HEM (ICH8M-E) LPC Interface Controller [8086:2811] (rev 03)
Subsystem: Lenovo ThinkPad T61/R61 [17aa:20b6]
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 0
Capabilities: <access denied>
Kernel driver in use: lpc_ich
Kernel modules: lpc_ich
00:1f.1 IDE interface [0101]: Intel Corporation 82801HM/HEM (ICH8M/ICH8M-E) IDE Controller [8086:2850] (rev 03) (prog-if 8a [ISA Compatibility mode controller, supports both channels switched to PCI native mode, supports bus mastering])
Subsystem: Lenovo ThinkPad T61/R61 [17aa:20a6]
Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx+
Latency: 0
Interrupt: pin C routed to IRQ 16
Region 0: Memory at 000001f0 (32-bit, non-prefetchable) [virtual] [size=8]
Region 1: Memory at 000003f0 (type 3, non-prefetchable) [virtual]
Region 2: Memory at 00000170 (32-bit, non-prefetchable) [virtual] [size=8]
Region 3: Memory at 00000370 (type 3, non-prefetchable) [virtual]
Region 4: I/O ports at 18e0 [virtual] [size=16]
Kernel driver in use: ata_piix
Kernel modules: ata_piix, ata_generic
00:1f.2 SATA controller [0106]: Intel Corporation 82801HM/HEM (ICH8M/ICH8M-E) SATA Controller [AHCI mode] [8086:2829] (rev 03) (prog-if 01 [AHCI 1.0])
Subsystem: Lenovo ThinkPad T61/R61 [17aa:20a7]
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 0
Interrupt: pin B routed to IRQ 27
Region 0: I/O ports at 1c30 [size=8]
Region 1: I/O ports at 1c24 [size=4]
Region 2: I/O ports at 1c28 [size=8]
Region 3: I/O ports at 1c20 [size=4]
Region 4: I/O ports at 1c00 [size=32]
Region 5: Memory at f8426000 (32-bit, non-prefetchable) [size=2K]
Capabilities: <access denied>
Kernel driver in use: ahci
Kernel modules: ahci
00:1f.3 SMBus [0c05]: Intel Corporation 82801H (ICH8 Family) SMBus Controller [8086:283e] (rev 03)
Subsystem: Lenovo ThinkPad T61/R61 [17aa:20a9]
Control: I/O+ Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- DisINTx-
Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Interrupt: pin A routed to IRQ 23
Region 0: Memory at f8427400 (32-bit, non-prefetchable) [size=256]
Region 4: I/O ports at 1c40 [size=32]
Kernel driver in use: i801_smbus
Kernel modules: i2c_i801
03:00.0 Network controller [0280]: Intel Corporation PRO/Wireless 4965 AG or AGN [Kedron] Network Connection [8086:4230] (rev 61)
Subsystem: Intel Corporation PRO/Wireless 4965 AG or AGN [Kedron] Network Connection [8086:1011]
Physical Slot: 3
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 0, Cache Line Size: 64 bytes
Interrupt: pin A routed to IRQ 29
Region 0: Memory at f7f00000 (64-bit, non-prefetchable) [size=8K]
Capabilities: <access denied>
Kernel driver in use: iwl4965
Kernel modules: iwl4965
05:00.0 CardBus bridge [0607]: Ricoh Co Ltd RL5c476 II [1180:0476] (rev ba)
Subsystem: Lenovo ThinkPad R61/T400 [17aa:20c6]
Physical Slot: 1
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 168
Interrupt: pin A routed to IRQ 16
Region 0: Memory at d7eff000 (32-bit, non-prefetchable) [size=4K]
Bus: primary=05, secondary=06, subordinate=07, sec-latency=176
Memory window 0: d8000000-dbffffff (prefetchable)
Memory window 1: c0000000-c3ffffff
I/O window 0: 00004000-000040ff
I/O window 1: 00004400-000044ff
BridgeCtl: Parity- SERR- ISA- VGA- MAbort- >Reset- 16bInt+ PostWrite+
16-bit legacy interface ports at 0001
Capabilities: <access denied>
Kernel driver in use: yenta_cardbus
Kernel modules: yenta_socket
05:00.2 SD Host controller [0805]: Ricoh Co Ltd R5C822 SD/SDIO/MMC/MS/MSPro Host Adapter [1180:0822] (rev 21)
Subsystem: Lenovo ThinkPad T400/W500 [17aa:20c8]
Physical Slot: 1
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 64
Interrupt: pin C routed to IRQ 18
Region 0: Memory at d7efec00 (32-bit, non-prefetchable) [size=256]
Capabilities: <access denied>
Kernel driver in use: sdhci-pci
Kernel modules: sdhci_pci
** USB devices:
Bus 005 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 006 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 004 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 001 Device 002: ID 17ef:1000 Lenovo Hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 003 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
-- System Information:
Debian Release: bullseye/sid
APT prefers unstable-debug
APT policy: (500, 'unstable-debug'), (500, 'oldstable-updates'), (500, 'buildd-unstable'), (500, 'unstable'), (500, 'oldstable'), (1, 'experimental-debug'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 5.7.0-1-amd64 (SMP w/2 CPU threads)
Kernel taint flags: TAINT_WARN
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/lksh
Init: sysvinit (via /sbin/init)
Versions of packages linux-image-5.7.0-1-amd64 depends on:
ii initramfs-tools [linux-initramfs-tool] 0.137
ii kmod 27+20200310-2
ii linux-base 4.6
Versions of packages linux-image-5.7.0-1-amd64 recommends:
pn apparmor <none>
ii firmware-linux-free 20200122-1
Versions of packages linux-image-5.7.0-1-amd64 suggests:
pn debian-kernel-handbook <none>
ii grub-pc 2.04-8
pn linux-doc-5.7 <none>
Versions of packages linux-image-5.7.0-1-amd64 is related to:
ii firmware-amd-graphics 20200619-1
pn firmware-atheros <none>
pn firmware-bnx2 <none>
pn firmware-bnx2x <none>
pn firmware-brcm80211 <none>
pn firmware-cavium <none>
pn firmware-intel-sound <none>
pn firmware-intelwimax <none>
pn firmware-ipw2x00 <none>
pn firmware-ivtv <none>
ii firmware-iwlwifi 20200619-1
pn firmware-libertas <none>
ii firmware-linux-nonfree 20200619-1
ii firmware-misc-nonfree 20200619-1
pn firmware-myricom <none>
pn firmware-netxen <none>
pn firmware-qlogic <none>
pn firmware-realtek <none>
pn firmware-samsung <none>
pn firmware-siano <none>
pn firmware-ti-connectivity <none>
pn xen-hypervisor <none>
-- no debconf information
[toc] | [next] | [standalone]
| From | Ben Hutchings <ben@decadent.org.uk> |
|---|---|
| Date | 2020-08-02 20:00 +0200 |
| Message-ID | <Azqr7-vc-3@gated-at.bofh.it> |
| In reply to | #67641 |
[Multipart message — attachments visible in raw view] — view raw
[The previous message is archived at <https://bugs.debian.org/966459>.] On Tue, 2020-07-28 at 20:31 +0200, Thorsten Glaser wrote: > Package: src:linux > Version: 5.7.6-1 > Severity: normal > Tags: upstream > X-Debbugs-Cc: tg@mirbsd.de > > I’m using setsockopt to set the traffic class on sending and receive > it in control messages on receiving, for both IPv4 and IPv6. > > The relevant documentation is the ip(7) manpage and, because the ipv6(7) > manpage doesn’t contain it, RFC3542. ip(7) also doesn't document IP_PKTOPIONS. [...] > Same in net/ipv4/ip_sockglue.c… > > int tos = inet->rcv_tos; > put_cmsg(&msg, SOL_IP, IP_TOS, sizeof(tos), &tos); > … in one place, but… > > put_cmsg(msg, SOL_IP, IP_TOS, 1, &ip_hdr(skb)->tos); > > … in ip_cmsg_recv_tos(), yielding inconsistent results for IPv4(!). Those are two different APIs though: recvmsg() for datagram sockets, vs getsockopt(... IP_PKTOPTIONS ...) for stream sockets. They obviously ought to be consistent, but mistakes happen. [...] > tl;dr: Receiving traffic class values from IP traffic is broken on > big endian platforms. Some user-space that uses getsockopt(... IP_PKTOPTIONS ...) for stream sockets might be broken. I searched for 'cmsg_type.*IP_TOS' on codesearch.debian.net, and found only two instances where it was used in conjunction with IP_PKTOPTIONS. libzorpll reads only the first byte (so is broken on big-endian): https://sources.debian.org/src/libzorpll/7.0.1.0%7Ealpha1-1.1/src/io.cc/#L239 squid reads an int and then truncates it to a byte (so is fine): https://sources.debian.org/src/squid/4.12-1/src/ip/QosConfig.cc/#L41 > I place the following suggestion for discussion, to achieve maximum > portability: put 4 bytes into the CMSG for both IPv4 and IPv6, where > the first and fourth byte are, identically, traffic class, second and > third 0. [...] I see no point in changing the IPv6 behaviour: it seems to be consistent with itself and with the standard, so only risks breaking user-space that works today. As for IPv4, changing the format of the IP_TOS field in the IP_PKTOPIONS value looks like it would work for the two users found in Debian. But you should know that the highest priority for Linux API compatibility is to avoid breaking currently working user-space. That means that ugly and inconsistent APIs won't get fixed if it causes a regression for the programs people actually use. If the API never worked like it was supposed to on some architectures, that's not a regression, and is lower priority. Ben. -- Ben Hutchings It is easier to write an incorrect program than to understand a correct one.
[toc] | [prev] | [next] | [standalone]
| From | Thorsten Glaser <t.glaser@tarent.de> |
|---|---|
| Date | 2020-08-02 21:50 +0200 |
| Message-ID | <Azs9z-1zu-3@gated-at.bofh.it> |
| In reply to | #67662 |
Ben Hutchings dixit: >ip(7) also doesn't document IP_PKTOPIONS. Hmm, I don’t use IP_PKTOPIONS though. I’m not exactly sure I found the correct place in the kernel for what I do. On the sending side, I use setsockopt with either IPPROTO_IP,IP_TOS or IPPROTO_IPV6,IPV6_TCLASS to set the default traffic class on outgoing packets. On the receiving side I use setsockopt with either IPPROTO_IP,IP_RECVTOS or IPPROTO_IPV6,IPV6_RECVTCLASS to set up the socket then recvmsg to get a cmsg(3) of IPPROTO_IP,IP_TOS/IPPROTO_IPV6,IPV6_TCLASS from which I read the traffic class octet. These are where I believe I found inconsistencies between code and documentation. >Those are two different APIs though: recvmsg() for datagram sockets, vs >getsockopt(... IP_PKTOPTIONS ...) for stream sockets. They obviously >ought to be consistent, but mistakes happen. OK, I’m currently looking at the datagram case only. This may change later if there’s enough time. >I see no point in changing the IPv6 behaviour: it seems to be >consistent with itself and with the standard Not really: if the kernel writes an int and userspace reads its first byte, it only works by accident on little endian, but not elsewhere. >so only risks breaking user-space that works today. Hrm. It risks breaking userspace that reads an int. But the RFC clearly says it should read the first byte, not an int. >But you should know that the highest priority for Linux API >compatibility is to avoid breaking currently working user-space. That >means that ugly and inconsistent APIs won't get fixed if it causes a >regression for the programs people actually use. If the API never >worked like it was supposed to on some architectures, that's not a >regression, and is lower priority. This is why I just put this up for discussion instead of requesting a specific change. That being said, given that the IPv6 API is *only* documented in the RFC and *not* documented in the Linux manpages… (Perhaps codesearching for IPV6_TCLASS might also help. It’s unclear how many users this has…) In the end, what I really want, is clear documentation for how I should implement the following file that it works on Linux, and ideally also other systems implementing the RFC API (FreeBSD supposedly does but needs testing): https://github.com/tarent/ECN-Bits/blob/master/linux-c/lib/ecn.c Given that there’s no documentation, trying to read the coffee grounds from the kernel source, finding it doesn’t even match the RFC (which, again, doesn’t match what itojun proposed, for some reason), does not instigate trust in the things I *think* I’ve found. bye, //mirabilos -- tarent solutions GmbH Rochusstraße 2-4, D-53123 Bonn • http://www.tarent.de/ Tel: +49 228 54881-393 • Fax: +49 228 54881-235 HRB 5168 (AG Bonn) • USt-ID (VAT): DE122264941 Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg
[toc] | [prev] | [next] | [standalone]
| From | Ben Hutchings <ben@decadent.org.uk> |
|---|---|
| Date | 2020-08-02 22:40 +0200 |
| Message-ID | <AzsVY-25w-17@gated-at.bofh.it> |
| In reply to | #67663 |
[Multipart message — attachments visible in raw view] — view raw
On Sun, 2020-08-02 at 19:29 +0000, Thorsten Glaser wrote: > Ben Hutchings dixit: > > >ip(7) also doesn't document IP_PKTOPIONS. > > Hmm, I don’t use IP_PKTOPIONS though. I’m not exactly sure I found > the correct place in the kernel for what I do. The first instance of put_cmsg(...IP_TOS...) you found in net/ipv4/ip_sockglue.c implements that socket option. [...] > >I see no point in changing the IPv6 behaviour: it seems to be > >consistent with itself and with the standard > > Not really: if the kernel writes an int and userspace reads > its first byte, it only works by accident on little endian, > but not elsewhere. The RFC says that the IPV6_TCLASS option's value is an int, and that "the first byte of cmsg_data[] will be the *first byte of the integer* traffic class" (my emphasis). We can infer from "the first byte of" that cmsg_data[] will hold more than one byte. And "the integer" suggests that it's a C int, like the socket option. > >so only risks breaking user-space that works today. > > Hrm. It risks breaking userspace that reads an int. But the > RFC clearly says it should read the first byte, not an int. [...] No, the wording is *not* clear. Ben. -- Ben Hutchings It is easier to write an incorrect program than to understand a correct one.
[toc] | [prev] | [next] | [standalone]
| From | Thorsten Glaser <t.glaser@tarent.de> |
|---|---|
| Date | 2020-08-02 22:50 +0200 |
| Message-ID | <Azt5D-295-3@gated-at.bofh.it> |
| In reply to | #67664 |
On Sun, 2 Aug 2020, Ben Hutchings wrote: > The RFC says that the IPV6_TCLASS option's value is an int, and that for setsockopt (“option's”), not cmsg > No, the wording is *not* clear. Agreed. So perhaps let’s try to find out what’s actually right… Thanks for helping, //mirabilos -- tarent solutions GmbH Rochusstraße 2-4, D-53123 Bonn • http://www.tarent.de/ Tel: +49 228 54881-393 • Fax: +49 228 54881-235 HRB 5168 (AG Bonn) • USt-ID (VAT): DE122264941 Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg
[toc] | [prev] | [next] | [standalone]
| From | Ben Hutchings <ben@decadent.org.uk> |
|---|---|
| Date | 2020-08-03 05:40 +0200 |
| Message-ID | <Azzup-68h-3@gated-at.bofh.it> |
| In reply to | #67665 |
[Multipart message — attachments visible in raw view] — view raw
On Sun, 2020-08-02 at 22:44 +0200, Thorsten Glaser wrote: > On Sun, 2 Aug 2020, Ben Hutchings wrote: > > > The RFC says that the IPV6_TCLASS option's value is an int, and that > > for setsockopt (“option's”), not cmsg > > > No, the wording is *not* clear. > > Agreed. > > So perhaps let’s try to find out what’s actually right… For what it's worth, FreeBSD/Darwin and Windows also put 4 bytes of data in a IPV6_TCLASS cmsg. So whether or not it's "right", it's consistent between three independent implementations. Ben. -- Ben Hutchings For every complex problem there is a solution that is simple, neat, and wrong.
[toc] | [prev] | [next] | [standalone]
| From | Thorsten Glaser <t.glaser@tarent.de> |
|---|---|
| Date | 2020-08-03 19:10 +0200 |
| Message-ID | <AzM8i-5Jc-9@gated-at.bofh.it> |
| In reply to | #67668 |
Hi Ben, > For what it's worth, FreeBSD/Darwin and Windows also put 4 bytes of > data in a IPV6_TCLASS cmsg. So whether or not it's "right", it's > consistent between three independent implementations. oh, thank you, I don’t have any of these systems around at the moment, so checking them was tricky for me. So basically I should read an int in host endianness then (or keep the code I currently have that compares byte 0 and 3, using the one that’s not 0, if any). Great, thank you! After some minor porting work, it turns out that the current code does work on MidnightBSD (equivalent to FreeBSD 10.4) for IPv6. I guess I’ll keep ints then. bye, //mirabilos -- 15:41⎜<Lo-lan-do:#fusionforge> Somebody write a testsuite for helloworld :-)
[toc] | [prev] | [next] | [standalone]
| From | Thorsten Glaser <t.glaser@tarent.de> |
|---|---|
| Date | 2020-08-04 21:10 +0200 |
| Message-ID | <AAatX-3Q6-19@gated-at.bofh.it> |
| In reply to | #67676 |
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.
bye,
//mirabilos
--
tarent solutions GmbH
Rochusstraße 2-4, D-53123 Bonn • http://www.tarent.de/
Tel: +49 228 54881-393 • Fax: +49 228 54881-235
HRB 5168 (AG Bonn) • USt-ID (VAT): DE122264941
Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg
[toc] | [prev] | [standalone]
Back to top | Article view | linux.debian.kernel
csiph-web