Netdev Archive on lore.kernel.org
help / color / mirror / Atom feed
From: Stephen Hemminger <stephen@networkplumber.org>
To: "Jason Vas Dias" <jason.vas.dias@gmail.com>
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}} ?
Date: Tue, 20 Jul 2021 15:41:01 -0700	[thread overview]
Message-ID: <20210720154101.11df3494@hermes.local> (raw)
In-Reply-To: <hhlf60vmj6.fsf@jvdspc.jvds.net>

On Tue, 20 Jul 2021 19:59:57 +0100
"Jason Vas Dias" <jason.vas.dias@gmail.com> wrote:

> 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
>     .

/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.

  reply	other threads:[~2021-07-20 22:41 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-07-20 18:59 Jason Vas Dias
2021-07-20 22:41 ` Stephen Hemminger [this message]
2021-07-22 10:41 ` Jason Vas Dias

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20210720154101.11df3494@hermes.local \
    --to=stephen@networkplumber.org \
    --cc=jason.vas.dias@gmail.com \
    --cc=linux-8086@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=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}} ?' \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).