Received-SPF: pass (google.com: domain of linux-wireless+bounces-5222-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.199.223 as permitted sender) client-ip=147.75.199.223;
Message-ID: <f3ab160dd84e936134c6aa60e2f6d0fcf4d61e4c.camel@sipsolutions.net>
Subject: Re: [PATCH v12] Add JSON output options to 'iw' for scan results
From: Johannes Berg <johannes@sipsolutions.net>
To: Isaev Ruslan <legale.legale@gmail.com>, linux-wireless@vger.kernel.org
Date: Mon, 25 Mar 2024 17:32:51 +0100
In-Reply-To: <206d1b47b7ece7ccd1c371d23ae1f1c6.legale.legale@gmail.com>
References: <206d1b47b7ece7ccd1c371d23ae1f1c6.legale.legale@gmail.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
User-Agent: Evolution 3.50.4 (3.50.4-1.fc39) 
Precedence: bulk
MIME-Version: 1.0

Hmm.

Honestly, this output is awful. I can kind of understand where that's
coming from (the desire to have an object created for each element in
the frame, but ...)

>=20
>         TSF:
>                 usec: 321559832898
>                 dd: 3
>                 hh: 17
>                 mm: 19
>                 ss: 19

Really?  We used to print this as

	TSF: 0 usec (0d, 00:00:00)

(not sure why all zeroes here but anyway)

>         Frequency: 5180
>         Beacon Interval, TUs: 100
>         Capability:
>                 ESS
>                 Privacy
>                 ShortPreamble
>         Capability Raw Value: 0x0031

	capability: ESS Privacy SpectrumMgmt RadioMeasure (0x1111)

>         Signal: -72.00 dBm
>         Last Seen Ago, ms: 2740
>         BSS Probe Response Data Frame:
>                 SSID:
>                         SSID: tobe52

That's just silly.

>                 Supported rates:
>                         Rates:
>                                 6.0*
>                                 9.0
>                                 12.0*
>                                 18.0
>                                 24.0*
>                                 36.0
>                                 48.0
>                                 54.0

	Supported rates: 6.0* 9.0 12.0* 18.0 24.0* 36.0 48.0 54.0=20

And that stuff is a really pointless output in JSON, for JSON it'd be
much more useful to output an object with actual (integer) values, and a
flag to indicate 'basic', or something.

Anyway ... I think you're hyper-focused on exactly the wrong thing.

Arguably, for scan results, the right thing to do would be to just
output the raw elements in the JSON, and not do any of this parsing.
Then you can use your favourite parsing library (dpkt? tshark? ...) to
actually understand the data there. We really don't need to expose the
element parsing logic of iw, especially not in a bad way like this.

Also, outputting the *string* data in a machine-readable format like you
do now has very little value, and yet it ties us to a specific output
format that we'd probably have to consider stable. Bad idea.

So I guess I'm saying yhou should abandon this line of changes in this
code entirely.

Much more interesting, IMHO, would be to focus in pretty much anything
_else_ in the iw code, e.g. the output of 'iw dev', 'iw wlan0 info',
statistics, etc. Maybe 'iw list' and similar too.

Although I suspect that what we really need is better access for tools
from nl80211. Maybe the "JSON" output format should just dump the raw
nl80211 message attributes that are involved, or something.

johannes