Received: by 2002:a05:6a10:1287:0:0:0:0 with SMTP id d7csp4963743pxv; Tue, 20 Jul 2021 15:43:27 -0700 (PDT) X-Google-Smtp-Source: ABdhPJx1+rR0PSR0i4YDhW9Vub8Dv0wa8gwct9BsTvzk+n8zm7sCWPIZXFbWfnyPhHBJzO/JksZL X-Received: by 2002:a17:906:b0c5:: with SMTP id bk5mr34790931ejb.428.1626821007487; Tue, 20 Jul 2021 15:43:27 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1626821007; cv=none; d=google.com; s=arc-20160816; b=NZH60AG4q1JB2cJgq9Kg/ffjhg6xddYUCyIc2si+zDH6zrhCjiLshHg8C8qRF53APW gZ8I39Bf6ZmR2CB32XxGDi2xQcOLU1KpvrfbDLsdcm+8SAcaMFG1GUYFacvxNYzb/F7g H3UBbPMB1LEMRAf5Cq3YMh3F4uE2ankaym/MtsnTsVxER5LfK6bfWyJL8wnjvdFEoW+S HiASE+dEeUmn3w7ZSiqPmqEN74g7nNq8vtpcLW6vsoX83Pcp35NzYD2xBjUqgTaygaVv 2yV1zQAJv+pa8Lmtivc6aFrtSxdMbmQf8glThUltMy+j7Ie8EtoxvwmJXWMRkbNQLHi8 w11Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :references:in-reply-to:message-id:subject:cc:to:from:date :dkim-signature; bh=q8ihxUcEiji5P4ZUEbiGoS1ejU8s0r5S2bgdmVxmVr4=; b=UVASef9qZqmEIXn3Q9P5Ws0hjwSmTmzC4XICReY2DeK1taDWY2NBQx3Pufw2qTwuJD E6rv9lNmrAaJZxwQ3uNs1lj0pj7XX8Tt4HQ7I5nozz75LL7Rg/uImlRiHLJQM05Zoqor yhozvvdLs1AZcn7rdkL2g5qHCoaynDPJQvG8K2F65cWEh9DIDr5ZRWFV7ocEUo0drpAZ RIA2JM1nYqxrafs+LeaF2uz2etoVZvBQ1QRG5YTtPZaZY6WzdF1kHM5FMYUENxLQP+ov 7BWoK57++S+MS9qXSjHbiGmHgyE+Kv2qWVjXjjupi/5diIT9fBiKKoqBayU4vt0PHU01 Rsew== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@networkplumber-org.20150623.gappssmtp.com header.s=20150623 header.b=kq+N+1dX; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id v5si4241795edr.313.2021.07.20.15.43.00; Tue, 20 Jul 2021 15:43:27 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@networkplumber-org.20150623.gappssmtp.com header.s=20150623 header.b=kq+N+1dX; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230381AbhGTWAl (ORCPT + 99 others); Tue, 20 Jul 2021 18:00:41 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:40746 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230030AbhGTWA3 (ORCPT ); Tue, 20 Jul 2021 18:00:29 -0400 Received: from mail-pj1-x102b.google.com (mail-pj1-x102b.google.com [IPv6:2607:f8b0:4864:20::102b]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 3FBFDC061762 for ; Tue, 20 Jul 2021 15:41:06 -0700 (PDT) Received: by mail-pj1-x102b.google.com with SMTP id me13-20020a17090b17cdb0290173bac8b9c9so2853773pjb.3 for ; Tue, 20 Jul 2021 15:41:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=networkplumber-org.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=q8ihxUcEiji5P4ZUEbiGoS1ejU8s0r5S2bgdmVxmVr4=; b=kq+N+1dXB5WxhR7BT4GdPfsRtGzqsUlEUetY/S6IML3buPvX8EEFewNZm4wdPM25X9 gHWxI+6XbJ51ynRq1tJmuDpiMBMNoa4LwTfnX6a2x/erUENCUjLeWpXTUeY9Abho/FkW DzWHd+rlO5RFAAimjitvtbtw/l1lHZZtdAP2Ny06lBNdgsKfYUJ/NH5J6kbp/fRUbpAH /oq6UWK0BIBRxVO3fc0rZVQPZkyDIicStjoKSzwPSJ79AJg9DL4RpjwGYVsiV/RP3J9/ ujxPiwx2GrkO+3AirdTA2SDZ4wdDuoyS4nfkhT6RvgHfvZc/npE6tdEJc0s/igaxuwEY ljFw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=q8ihxUcEiji5P4ZUEbiGoS1ejU8s0r5S2bgdmVxmVr4=; b=DD/S3SJyU4FC6qgFDGkc47IV/NdAPXQARgxOq3MOEzZbpEsZVHEx9hb4IQZVDppZAQ A8K09MHPOUEGdrWt8J3WB+/7kuOjuMNJh1/uEd54D5RF2DCsZ7JGzbzvdsqDeuhIIbGj j47yoJ9YBl1ILHLPI0g7+cQnA3WTqNE5vuNA3hel4XmQvQnxCBd3G+p7Q9FuYsVQUn/k lCEinkDWrfYHwCAsHqiBU0J0QdeLybfsC+v97WyEeDIetV0HZ/UA0nO7YDjCNp8dCRhd HirksrAmujAs6ycdg1KMySIv+7+M9Ng1lBXxkdgECe6taDj3o7vJGYHUTX0ZeF779DWd 9I/Q== X-Gm-Message-State: AOAM530GF6sGqbQKCzPWXbd/yANvEbPk9qGwgappxkPVN42hFApG7uS5 E3x174qdvAMqC+WGL2KbximTcQ== X-Received: by 2002:a17:90b:184:: with SMTP id t4mr646636pjs.161.1626820865587; Tue, 20 Jul 2021 15:41:05 -0700 (PDT) Received: from hermes.local (204-195-33-123.wavecable.com. [204.195.33.123]) by smtp.gmail.com with ESMTPSA id p3sm1901598pfw.171.2021.07.20.15.41.04 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 20 Jul 2021 15:41:05 -0700 (PDT) Date: Tue, 20 Jul 2021 15:41:01 -0700 From: Stephen Hemminger To: "Jason Vas Dias" Cc: linux-kernel@vger.kernel.org, linux-8086@vger.kernel.org, netdev@vger.kernel.org Subject: Re: /proc/net/{udp,tcp}{,6} : ip address format : RFC : need for /proc/net/{udp,tcp}{,6}{{n,h},{le,be}} ? Message-ID: <20210720154101.11df3494@hermes.local> In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, 20 Jul 2021 19:59:57 +0100 "Jason Vas Dias" wrote: > RE: > On 20/07/2021, Randy Dunlap wrote: > > On 7/20/21 2:14 AM, Jason Vas Dias wrote: > > ... > > Hi, > > I suggest sending your email to ndetdev@vger.kernel.org > > g'day. > >>> (he meant netdev@) > > Good day - > > I noticed that /proc/net/{udp,tcp} files (bash expansion) - the IPv4 > socket tables - contain IPv4 addresses in hex format like: > > 0100007F:0035 > > (Little-Endian IPv4 address 127.0.0.1 , Big Endian port 53) > > I would have printed / expected the IPv4 address to be printed EITHER > like: > 7F000001:0035 (Both Big-Endian) > OR > 0100007F:3500 (Both Little-Endian) > . > > It is rather idiosyncratic that Linux chooses > to print Little-Endian IPv4 addresses, but not > Little-Endian Ports , and where the other numbers > eg. (rx:tx) , (tr:tm/when) in those files are all > Big-Endian. > > Perhaps a later version of Linux could either > A) Print ALL IP addresses and Ports and numbers in network > (Big Endian) byte order, or as IP dotted-quad+port strings > ; OR: > B) Provide /proc/net/{udp,tcp}{,6}{n,be,h,le,ip} files > ( use shell : $ echo ^^ > to expand > ) - > which print IPv4 addresses & Ports in formats indicated by suffix : > n: network: always Big Endian > h: host: native either Little-Endian (LE) or Big Endian (BE) > be: BE - alias for 'n' > le: LE - alias for 'h' on LE platforms, else LE > ip: as dotted-decimal-quad+':'decimal-port strings, with numbers in BE. > ; OR: > C) Provide /proc/net/{udp,tcp}{,6}bin memory mappable binary socket > table files > . /proc is part of the guaranteed stable ABI in Linux. the format of those files can not change like that, it would break several applications. And adding new to /proc is actively discouraged since we have better interfaces like netlink or sysfs. > Should I raise a bug on this ? No > Rather than currently letting users discover this fact > by mis-converting IP addresses / ports initially as I did at first. > > Just a thought / request for comments. > > One would definitely want to inform the netstat + lsof + glibc > developers before choosing option A . Netstat is actually part of iputils and is mostly deprecated in favor of iproute2 ss command. > Option B allows users to choose which endianess to use (for ALL numbers) > by only adding new files, not changing existing ones. > > Option C would obviate the need to choose an endianess file by > just providing one new memory-mappable binary representation > of the sockets table, of size an even multiple of the page-size, > but whose reported size would be (sizeof(some_linux_ip_socket_table_struct_t) * > n_sockets_in_table). It could be provided alongside option B. > > I think options B and / or C would be nice to have - I might implement an > extension to the procfs code that prints these socket tables to > do this, maybe enabled by a new experimental > '+rational-ip-socket-tables' boot option - > then at least it would be clear how the numbers in those files are > meant to be read / converted. > > All the best, > Jason So, yes what you say makes sense but that was not how the early prehistoric (2.4 or earlier) versions of Linux decided to output addresses and it can never change.