netdev - Re: [PATCH net-next] ipmr: ip6mr: Add ability to display non default caches and vifs

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <YR2TG2uodH4wHM1/@lunn.ch>
Date:   Thu, 19 Aug 2021 01:09:15 +0200
From:   Andrew Lunn <andrew@...n.ch>
To:     Stephen Suryaputra <ssuryaextr@...il.com>
Cc:     Nikolay Aleksandrov <nikolay@...dia.com>, netdev@...r.kernel.org
Subject: Re: [PATCH net-next] ipmr: ip6mr: Add ability to display non default
 caches and vifs

On Wed, Aug 18, 2021 at 06:50:22PM -0400, Stephen Suryaputra wrote:
> On Thu, Aug 19, 2021 at 01:37:21AM +0300, Nikolay Aleksandrov wrote:
> > 
> > Sorry, but I don't see any point to this. We don't have it for any of the other
> > non-default cases, and I don't see a point of having it for ipmr either.
> > If you'd like to display the non-default tables then you query for them, you
> > don't change a sysctl to see them in /proc.
> > It sounds like a workaround for an issue that is not solved properly, and
> > generally it shouldn't be using /proc. If netlink interfaces are not sufficient
> > please improve them.
> 
> We found that the ability to dump the tables from kernel point of view
> is valuable for debugging the applications. Sometimes during the
> development, bugs in the use of the netlink interfaces can be solved
> quickly if the tables in the kernel can be viewed easily.
>
> If you agree on the reasoning above, what do you recommend then? Again,
> this is to easily view what's in the kernel.

Does iproute2 allow you to dump the tables?

First work on a simple CLI tool to dump the tables. Make it bug free
and contribute it. Then work on your buggy multicast routing daemon.

    Andrew