WBA/IETF Connect-Info Implementation under way

[Alan DeKok]

On Oct 6, 2025, at 5:13 PM, Jouni Malinen <j at w1.fi> wrote:
> It is quite a bit more difficult understand why the Connect-Info
> attribute would be an appropriate location overall channel conditions
> like RSSI and noise and even some of the per-device specific items like
> TxBitRate/RxBitRate to report TX/RX rate of a single frame (and also
> noting that TX retries of a single frame might use different rates)

  Connect-Info is not really an appropriate place for this information.  Among other things, it violates the RFC 6158 prohibitions on packing complex data into one attribute.

  That being said, this format is supported by the WBA, and has been implemented.  There's an IETF draft for it, which is likely to be accepted by RADEXT as a working group document.

> do
> not feel like something I would add into this RADIUS attribute. If you
> are planning to contribute support for those, I'd suggest leaving those
> to the end of the set of patches since the likelihood of getting those
> accepted is quite a bit smaller than the items that I can understand
> making sense in this particular RADIUS attribute.

  I would strongly support VSAs for this data.  It is significantly easier to manage each field when the data is broken out into individual RADIUS attributes.  In contrast, parsing a complex string is difficult and error-prone.  The format as defined does not lend itself to easy parsing.

  I suspect that this proposal will at least become an informational RFC.  But having VSAs in addition to the Connect-Info string format would be very positive.  Doing that would also allow any RADIUS server to construct the Connect-Info from the VSA values.

  Alan DeKok.