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
which print IPv4 addresses & Ports in formats:
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
