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;
From:   "Jason Vas Dias" <jason.vas.dias@gmail.com>
To:     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}} ?
Reply-To: "Jason Vas Dias" <jason.vas.dias@gmail.com>
Date:   Tue, 20 Jul 2021 19:59:57 +0100
Message-ID: <hhlf60vmj6.fsf@jvdspc.jvds.net>
MIME-Version: 1.0
Content-Type: text/plain
Precedence: bulk


RE:
On 20/07/2021, Randy Dunlap <rdunlap@infradead.org> 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
    .
 ?

 Should I raise a bug on this ?

 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 .

 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