netdev - Re: pull-request: wireless-next-2023-03-30

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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <SN7PR11MB6996329FFC32ECCBE4509531FF669@SN7PR11MB6996.namprd11.prod.outlook.com>
Date:   Sun, 23 Apr 2023 13:33:19 +0000
From:   "Stern, Avraham" <avraham.stern@...el.com>
To:     Richard Cochran <richardcochran@...il.com>,
        "Greenman, Gregory" <gregory.greenman@...el.com>
CC:     "kuba@...nel.org" <kuba@...nel.org>,
        "linux-wireless@...r.kernel.org" <linux-wireless@...r.kernel.org>,
        "johannes@...solutions.net" <johannes@...solutions.net>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>
Subject: Re: pull-request: wireless-next-2023-03-30

hi Richard,

I will try to clarify.

> > Then, the timestamps are added to the rx/tx status
>> via mac80211 api.

> Where?  I don't see that in the kernel anywhere.

> Your WiFi driver would need to implement get_ts_info, no?

so, the rx/tx timestamp is put in the skb hwstamps field, and the ack (tx/rx) timestamp is put in the mac80211 rx/tx status.
if you follow mac80211/cfg80211 patches sent earlier, you'll see that mac80211 uses these to fill cfg80211_rx_info and cfg80211_tx_status with
the timestamps.
eventually, these are sent to userspace in nl80211_send_mgmt() and nl80211_frame_tx_status() as part of the frame's meta data.

since wifi uses management frames for time sync, the timestamping capability is also advertised using nl80211 capability (NL80211_ATTR_MAX_HW_TIMESTAMP_PEERS).
implementing get_ts_info() doesn't seem right since it's usually queried over a data socket, and the wifi driver doesn't timestamp data frames (since these are not used
for time sync over wifi).

>> Actually, we already have a functional implementation of ptp4l
>> over wifi using this driver support.

> Why are changes needed to user space at all?

As you mentioned, time sync over wifi leverages the existing FTM protocol, which is different from the protocols used over ethernet.
In particular, FTM uses management frames unlike the ethernet protocols that use data frames.
So obviously for ptp4l to support time sync over wifi, it will need to implement the FTM protocol (sending FTM frames via nl80211 socket) and use the kernel APIs added here
to get tx/rx and acks timestamps. Then it can pass the collected data (t1, t2, path delay etc.) to the existing logic to calculate the time sync itself.
Note that for time sync the FTM frames also need to contain a vendor specific IE with all the time sync information (which is dynamic since it contains timestamps data from each measurement), so using FTM offload is not a good option.

I hope this clarifies thing a bit.

Thanks,
Avi

________________________________________
From: Richard Cochran <richardcochran@...il.com>
Sent: Thursday, April 20, 2023 6:43 AM
To: Greenman, Gregory
Cc: kuba@...nel.org; linux-wireless@...r.kernel.org; johannes@...solutions.net; netdev@...r.kernel.org; Stern, Avraham
Subject: Re: pull-request: wireless-next-2023-03-30

On Tue, Apr 18, 2023 at 01:35:50PM +0000, Greenman, Gregory wrote:

> Just a few clarifications. These two notifications are internal to iwlwifi, sent
> by the firmware to the driver.

Obviously.

> Then, the timestamps are added to the rx/tx status
> via mac80211 api.

Where?  I don't see that in the kernel anywhere.

Your WiFi driver would need to implement get_ts_info, no?

> Actually, we already have a functional implementation of ptp4l
> over wifi using this driver support.

Why are changes needed to user space at all?

Thanks,
Richard
---------------------------------------------------------------------
A member of the Intel Corporation group of companies

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.