Reading network connections for processes in a separate net namespaces from /proc/[pid]/net/tcp|tcp6

[Rami Rosen]

Hi, Darek,

cat  /proc/[pid]/net/tcp
 is handled by
 http://lxr.free-electrons.com/source/net/ipv4/tcp_ipv4.c#L2230

and cat /proc/[pid]/net/tcp6
is handled by:
http://lxr.free-electrons.com/source/net/ipv6/tcp_ipv6.c#L1782

Hope it helps!

Regards,
Rami Rosen
http://ramirose.wix.com/ramirosen

On 25 January 2016 at 15:00, dariusz ostolski
<dariusz.ostolski at gmail.com> wrote:
> Hello,
>
>
> 2016-01-22 10:21 GMT+01:00 Rami Rosen <roszenrami at gmail.com>:
>>>I've found
>>>functions for global files, maybe they are the same). I'd like to
>>>check when these files where introduced (from what kernel version they
>>>are available)
>>
>> Support for kernel network namesapces was added with kernel 2.6.29.
>> It is basically based on adding an object called "net_ns" to the
>> process descriptor, and instance of struct net, which represents a
>> network namesapce. You can think of such object as representing the
>> network state of a process, including all stats, sockets, devices,
>> tables, and so on. This net_ns is a member of an object called
>> nsproxy, which includes pointers to 4 other namesapces (uts, mnt, pid
>> and ipc).
>>
>>
>>>and there is no information about network
>>>namespaces at all (google, stackoverflow, man pages, kernel docs)
>>
>
> Thank You for your answer it gave me some clues so I was not
> completely blind when I checked kernel source code.
> Nevertheless, excuse me for not being precise enough, what I meant is
> that I couldn't find any docs about those 2 specific files:
> 1. /proc/[pid]/net/tcp
> 2. /proc/[pid]/net/tcp6
>
> And how is their content related to net namespaces?
>
> I want to read connections for a process that is in a separate net
> namespace but I'd like to avoid switching to that namespace,
> my experiments showed that reading /proc/[pid]/net/tcp|tcp6 should be
> enough, but I'd like to find confirmation of that
>  either in official docs (which I couldnt find) or in kernel source
> code (I failed there too).
>
> Again thank You in advance for your help.
>
> Regards,
> Darek