From: Ben Greear <[email protected]>
This can be helpful for calculating roaming time and other
higher precision stats.
Signed-off-by: Ben Greear <[email protected]>
---
nl80211.h | 2 ++
station.c | 3 +++
2 files changed, 5 insertions(+)
diff --git a/nl80211.h b/nl80211.h
index e1ea2cb..ebaae12 100644
--- a/nl80211.h
+++ b/nl80211.h
@@ -3139,6 +3139,7 @@ enum nl80211_sta_bss_param {
* @NL80211_STA_INFO_TX_DURATION: aggregate PPDU duration for all frames
* sent to the station (u64, usec)
* @NL80211_STA_INFO_AIRTIME_WEIGHT: current airtime weight for station (u16)
+ * @NL80211_STA_INFO_AUTH_AT_MS: Timestamp of last assoc -> auth transition, in ms
* @__NL80211_STA_INFO_AFTER_LAST: internal
* @NL80211_STA_INFO_MAX: highest possible station info attribute
*/
@@ -3184,6 +3185,7 @@ enum nl80211_sta_info {
NL80211_STA_INFO_CONNECTED_TO_GATE,
NL80211_STA_INFO_TX_DURATION,
NL80211_STA_INFO_AIRTIME_WEIGHT,
+ NL80211_STA_INFO_AUTH_AT_MS,
/* keep last */
__NL80211_STA_INFO_AFTER_LAST,
diff --git a/station.c b/station.c
index 25cbbc3..3b0c5f1 100644
--- a/station.c
+++ b/station.c
@@ -557,6 +557,9 @@ static int print_sta_handler(struct nl_msg *msg, void *arg)
if (sinfo[NL80211_STA_INFO_CONNECTED_TIME])
printf("\n\tconnected time:\t%u seconds",
nla_get_u32(sinfo[NL80211_STA_INFO_CONNECTED_TIME]));
+ if (sinfo[NL80211_STA_INFO_AUTH_AT_MS])
+ printf("\n\tauthenticated at:\t%llu ms",
+ (unsigned long long)nla_get_u64(sinfo[NL80211_STA_INFO_AUTH_AT_MS]));
printf("\n");
return NL_SKIP;
--
2.7.5
From: Ben Greear <[email protected]>
This lets us more precisely calculate the absolute timestamp
of last-rix (ie, now - idle).
Signed-off-by: Ben Greear <[email protected]>
---
station.c | 8 +++++++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/station.c b/station.c
index 3b0c5f1..60804f2 100644
--- a/station.c
+++ b/station.c
@@ -314,6 +314,12 @@ static int print_sta_handler(struct nl_msg *msg, void *arg)
[NL80211_STA_INFO_ACK_SIGNAL_AVG] = { .type = NLA_U8 },
};
char *chain;
+ struct timeval now;
+ unsigned long long now_ms;
+
+ gettimeofday(&now, NULL);
+ now_ms = now.tv_sec * 1000;
+ now_ms += (now.tv_usec / 1000);
nla_parse(tb, NL80211_ATTR_MAX, genlmsg_attrdata(gnlh, 0),
genlmsg_attrlen(gnlh, 0), NULL);
@@ -561,7 +567,7 @@ static int print_sta_handler(struct nl_msg *msg, void *arg)
printf("\n\tauthenticated at:\t%llu ms",
(unsigned long long)nla_get_u64(sinfo[NL80211_STA_INFO_AUTH_AT_MS]));
- printf("\n");
+ printf("\n\tcurrent time:\t%llu ms\n", now_ms);
return NL_SKIP;
}
--
2.7.5
On Fri, Apr 12, 2019 at 2:40 PM <[email protected]> wrote:
>
> From: Ben Greear <[email protected]>
>
> This lets us more precisely calculate the absolute timestamp
> of last-rix (ie, now - idle).
Can you use 64-bit timestamps? struct timeval suffers from the
overflow after 2038 problem.
>
> Signed-off-by: Ben Greear <[email protected]>
> ---
> station.c | 8 +++++++-
> 1 file changed, 7 insertions(+), 1 deletion(-)
>
> diff --git a/station.c b/station.c
> index 3b0c5f1..60804f2 100644
> --- a/station.c
> +++ b/station.c
> @@ -314,6 +314,12 @@ static int print_sta_handler(struct nl_msg *msg, void *arg)
> [NL80211_STA_INFO_ACK_SIGNAL_AVG] = { .type = NLA_U8 },
> };
> char *chain;
> + struct timeval now;
> + unsigned long long now_ms;
> +
> + gettimeofday(&now, NULL);
> + now_ms = now.tv_sec * 1000;
> + now_ms += (now.tv_usec / 1000);
>
> nla_parse(tb, NL80211_ATTR_MAX, genlmsg_attrdata(gnlh, 0),
> genlmsg_attrlen(gnlh, 0), NULL);
> @@ -561,7 +567,7 @@ static int print_sta_handler(struct nl_msg *msg, void *arg)
> printf("\n\tauthenticated at:\t%llu ms",
> (unsigned long long)nla_get_u64(sinfo[NL80211_STA_INFO_AUTH_AT_MS]));
>
> - printf("\n");
> + printf("\n\tcurrent time:\t%llu ms\n", now_ms);
> return NL_SKIP;
> }
>
> --
> 2.7.5
>
On 4/12/19 2:43 PM, Kirtika Ruchandani wrote:
> On Fri, Apr 12, 2019 at 2:40 PM <[email protected]> wrote:
>>
>> From: Ben Greear <[email protected]>
>>
>> This lets us more precisely calculate the absolute timestamp
>> of last-rix (ie, now - idle).
>
> Can you use 64-bit timestamps? struct timeval suffers from the
> overflow after 2038 problem.
What is the preferred API to do this? Whatever it is, it would need
to compile on old crufty systems as well.
Thanks,
Ben
--
Ben Greear <[email protected]>
Candela Technologies Inc http://www.candelatech.com
On Fri, Apr 12, 2019 at 2:49 PM Ben Greear <[email protected]> wrote:
>
> On 4/12/19 2:43 PM, Kirtika Ruchandani wrote:
> > On Fri, Apr 12, 2019 at 2:40 PM <[email protected]> wrote:
> >>
> >> From: Ben Greear <[email protected]>
> >>
> >> This lets us more precisely calculate the absolute timestamp
> >> of last-rix (ie, now - idle).
> >
> > Can you use 64-bit timestamps? struct timeval suffers from the
> > overflow after 2038 problem.
>
> What is the preferred API to do this? Whatever it is, it would need
> to compile on old crufty systems as well.
I am not sure what the guidance for userspace is. The kernel uses
'struct timespec64' I think.
Arnd (cc-ed) who has mostly led the 2038 problem in the kernel might
have more input on the
"old crufty systems" part.
>
> Thanks,
> Ben
>
> --
> Ben Greear <[email protected]>
> Candela Technologies Inc http://www.candelatech.com
>
On Sat, Apr 13, 2019 at 12:07 AM Kirtika Ruchandani <[email protected]> wrote:
>
> On Fri, Apr 12, 2019 at 2:49 PM Ben Greear <[email protected]> wrote:
> >
> > On 4/12/19 2:43 PM, Kirtika Ruchandani wrote:
> > > On Fri, Apr 12, 2019 at 2:40 PM <[email protected]> wrote:
> > >>
> > >> From: Ben Greear <[email protected]>
> > >>
> > >> This lets us more precisely calculate the absolute timestamp
> > >> of last-rix (ie, now - idle).
> > >
> > > Can you use 64-bit timestamps? struct timeval suffers from the
> > > overflow after 2038 problem.
> >
> > What is the preferred API to do this? Whatever it is, it would need
> > to compile on old crufty systems as well.
>
> I am not sure what the guidance for userspace is. The kernel uses
> 'struct timespec64' I think.
> Arnd (cc-ed) who has mostly led the 2038 problem in the kernel might
> have more input on the
> "old crufty systems" part.
I'm not sure what you are trying to do, and there are different
answers depending on the usecase.
For getting the time in the kernel, see Documentation/core-api/timekeeping.rst
do_gettimeofday() is going away for many reasons, so don't use that.
It sounds like you want "ktime_to_ms(ktime_get())" here.
In userspace interfaces, you should pass 64-bit nanoseconds as returned
by ktime_get_ns().
If you want to pretty-print the current wall-clock, use the %pt format string
on a 'struct rtc_time'.
Arnd
On Sat, Apr 13, 2019 at 10:00 AM Arnd Bergmann <[email protected]> wrote:
>
> On Sat, Apr 13, 2019 at 12:07 AM Kirtika Ruchandani <[email protected]> wrote:
> >
> > On Fri, Apr 12, 2019 at 2:49 PM Ben Greear <[email protected]> wrote:
> > >
> > > On 4/12/19 2:43 PM, Kirtika Ruchandani wrote:
> > > > On Fri, Apr 12, 2019 at 2:40 PM <[email protected]> wrote:
> > > >>
> > > >> From: Ben Greear <[email protected]>
> > > >>
> > > >> This lets us more precisely calculate the absolute timestamp
> > > >> of last-rix (ie, now - idle).
> > > >
> > > > Can you use 64-bit timestamps? struct timeval suffers from the
> > > > overflow after 2038 problem.
> > >
> > > What is the preferred API to do this? Whatever it is, it would need
> > > to compile on old crufty systems as well.
> >
> > I am not sure what the guidance for userspace is. The kernel uses
> > 'struct timespec64' I think.
> > Arnd (cc-ed) who has mostly led the 2038 problem in the kernel might
> > have more input on the
> > "old crufty systems" part.
>
> I'm not sure what you are trying to do, and there are different
> answers depending on the usecase.
>
> For getting the time in the kernel, see Documentation/core-api/timekeeping.rst
> do_gettimeofday() is going away for many reasons, so don't use that.
> It sounds like you want "ktime_to_ms(ktime_get())" here.
>
> In userspace interfaces, you should pass 64-bit nanoseconds as returned
> by ktime_get_ns().
>
> If you want to pretty-print the current wall-clock, use the %pt format string
> on a 'struct rtc_time'.
Ah, I see now this was just userspace code. In that case, using gettimeofday()
works fine, it will end up using a 64-bit version of 'timeval', and converting
that to 64-bit milliseconds is safe.
Using clock_gettime() is generally preferred over gettimeofday() since it
avoids the conversion from nanoseconds to microseconds (which you then
convert to milliseconds).
Arnd