Date:   Tue, 31 Mar 2020 18:09:44 -0700
From:   Maciej Żenczykowski <zenczykowski@...il.com>
To:     Pablo Neira Ayuso <pablo@...filter.org>
Cc:     Jan Engelhardt <jengelh@...i.de>, Florian Westphal <fw@...len.de>,
        Linux Network Development Mailing List 
        <netdev@...r.kernel.org>,
        Netfilter Development Mailing List 
        <netfilter-devel@...r.kernel.org>,
        Manoj Basapathi <manojbm@...eaurora.org>,
        Subash Abhinov Kasiviswanathan <subashab@...eaurora.org>
Subject: Re: [PATCH] netfilter: IDLETIMER target v1 - match Android layout

Right, so if you look at the android common kernel implementation.
  https://android.googlesource.com/kernel/common/+/refs/heads/android-mainline/net/netfilter/xt_IDLETIMER.c#201

(and in particular grep for send_nl_msg throughout the file) the core
difference is the call to notify_netlink_uevent() at
  https://android.googlesource.com/kernel/common/+/refs/heads/android-mainline/net/netfilter/xt_IDLETIMER.c#101

this function is also defined in the same file, and it ends up calling
  kobject_uevent_env(idletimer_tg_kobj, KOBJ_CHANGE, envp);
with INTERFACE, STATE, UID and TIME_NS metadata.

this is later parsed in netd C++:
  https://android.googlesource.com/platform/system/netd/+/refs/heads/master/server/NetlinkHandler.cpp#208

which then via notifyInterfaceClassActivityChanged() I believe
generates a binder call into the java network stack
for further processing.

void NetlinkHandler::notifyInterfaceClassActivityChanged(int label,
bool isActive,
int64_t timestamp, int uid) {
LOG_EVENT_FUNC(BINDER_RETRY, onInterfaceClassActivityChanged,
isActive, label, timestamp, uid);
}

Ultimately the goal is to know WHO (uid - on Android it's 1 unix uid
per {user,app} combination) generated traffic
activity, WHEN (timestamp) and WHERE (label ie. interface).

ie. To figure out whether an interface is idle or not and can be
shutdown, or powersaved, etc.
WHO matters because some users (apps!) might be insufficiently
important (lack of background data privs) to prevent
a network device powersavings/sleep/disconnect or to cause a wakeup (I think).

My understanding is the 'timer' thing (aka HARDIDLETIMER) was added
because phones are almost constantly
entering suspend state, so we care about real clock time
(CLOCK_BOOTTIME) rather than cpu activity time (CLOCK_MONOTONIC which
doesn't include time the device is suspended).

I think this could probably be eventually switched to use the sysfs
notification mechanism,
but we can't change that on any of the already shipped devices and
it's kind of late even for devices shipping this year,
and that system would presumably need to be extended to support uids.

On Tue, Mar 31, 2020 at 4:28 PM Pablo Neira Ayuso <pablo@...filter.org> wrote:
>
> On Tue, Mar 31, 2020 at 02:21:00PM -0700, Maciej Żenczykowski wrote:
> > Right, this is not in 5.6 as it's only in net-next atm as it was only
> > merged very recently.
> > I mentioned this in the commit message.
> >
> > I'm not sure what you mean by code that uses this.
> > You can checkout aosp source and look there...
> > There's the kernel code (that's effectively already linked from the
> > commit message), and the iptables userspace changes (
> > https://android.googlesource.com/platform/external/iptables/+/refs/heads/master/extensions/libxt_IDLETIMER.c#39
>
> OK, so this is field ised set in userspace.
>
> > ), and the netd C++/Java layer that uses iptables -j IDLETIMER
> > --send_nl_msg 1 (
> > https://android.googlesource.com/platform/system/netd/+/refs/heads/master/server/IdletimerController.cpp#151
> > ) and the resulting notifications parsing (can't easily find it atm).
> >
> > If you mean by code that uses this patch... that's impossible as this
> > patch doesn't implement a usable feature.
> > It just moves the offset.
> >
> > Could you clarify what you're asking for?
>
> Maybe I'm misunderstanding. How is this field used in aosp?
>
> I mean, if --send_nl_msg 1 is passed, how does the existing behaviour
> changes?

Powered by blists - more mailing lists