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]

Date:   Mon, 24 Apr 2023 15:04:05 -0700
From:   Richard Cochran <richardcochran@...il.com>
To:     "Stern, Avraham" <avraham.stern@...el.com>
Cc:     "Greenman, Gregory" <gregory.greenman@...el.com>,
        "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

On Sun, Apr 23, 2023 at 01:33:19PM +0000, Stern, Avraham wrote:
> 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.

Um, no, I haven't seen those.

> 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).

Okay, so you are creatively making some kind of back door for wifi.  Whatever.

> >> 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

ptp4l isn't doing to implement anything without my ok.

Thanks,
Richard