Feat: extended rate parsing by lukas-mbag · Pull Request #142 · mdlayher/wifi

lukas-mbag · 2025-11-27T09:38:01Z

This Pull Request makes the RateInfo available for the user.

I am looking for feedback (@SuperQ ?)on the API-Design for the User of this Library. If nobody objects, I will add in testcases and cleanup the documentation before un-drafting this Pull Request.

My Usecase
I want to access the MCS-Index and the number of Spacial Stream (NSS) for RX and TX of the current Connection together with a string description similar to the one provided by the iw wlan0 link command (i.e. rx bitrate: 173.3 MBit/s VHT-MCS 8 short GI VHT-NSS 2).

Changes

Introduce a new public Interface RateModulationInfo with the following Methodes:
- GetMCS() int
- GetNSS() int
- Description() string
- WifiGeneration() string
Introduce 4 concrete Types that implement the interface: HTModulationInfo, VHTModulationInfo, HEModulationInfo and EHTModulationInfo
Move Type rateInfo from client_linux.go to wifi.go and make it public
Add the new RateModulationInfo Interface to the RateInfo struct. Also add ChannelWidth and ModulationType
extend the parseRateInfo(b []byte) (*RateInfo, error) function to populate the new fields
Add RateInfo (for Rx and Tx) to the StationInfo Struct

Caveats

We return an Interface in the RateInfo Struct. If user wants to use parts of the types that are not in the Interface, they have type-cast the concrete struct to the desired type. MCS. NSS, Description and WiFiGeneration are available for all Types
Sorting of the sub-stings in Description() can differ from the iw output (i.e. in my real-world testcase the "shortGI" string is placed at the End of the string not in-between MCS and NSS as in the iw output)
Within Station Info there is now duplicate Information (the bitrate itself) is available directly via StationInfo.ReceiveBitrate and is also Part of the RateInfo Type StationInfo.ReceiveRateInfo.Bitrate. This keeps the API of Station Info backwards-compatible but also groups it with the rest of the rate and modulation info.
No Test-Cases yet (see above, will be added if we go forward with the current design)

The program was tested solely for our own use cases, which might differ from yours.

Lukas Raffelt < lukas.raffelt@mercedes-benz.com > on behalf of Mercedes-Benz Tech Innovation GmbH, Provider Information

Licensed under MIT

add basic MCS Decoding test: add additional station info test case with MCS attributes feat: add support for VHT MCS indexes in StationInfo and related parsing logic feat: enhance StationInfo with detailed rate information and VHT support

expose Interface create subtypes that implement the interface

lukas-mbag · 2026-01-21T15:12:16Z

I have added several testcases in TestLinux_clientStationInfoOK in order to increase the test coverage of the new Functionality

SuperQ · 2026-04-01T17:01:17Z

Thanks, I'll try and get to this soon.

Maybe @nickgarlis would also like to take a look.

nickgarlis

I am not familiar with this module but I've left some comments on things that I've noticed.

Overall, it seems like a good idea to extend StationInfo with those extra attributes.

nickgarlis · 2026-04-01T17:34:33Z

+func modulationAttributes(rateInfo RateModulationInfo) (attr []netlink.Attribute) {
+	// attr = append(attr, netlink.Attribute{Type: unix.NL80211_RATE_INFO_BITRATE, Data: nlenc.Uint16Bytes(uint16(bitrateAttr(s.ReceiveBitrate)))})
+	// attr = append(attr, netlink.Attribute{Type: unix.NL80211_RATE_INFO_BITRATE32, Data: nlenc.Uint32Bytes(bitrateAttr(s.ReceiveBitrate))})
+	switch ri := rateInfo.(type) {


Could the RateModulationInfo interface also implement a marshal and unmarshal function so that this becomes a bit easier to read ?

done, Is this as expected?

nickgarlis · 2026-04-01T17:48:52Z

+type BaseModulationInfo struct {
+	MCS           int
+	NSS           int
+	IwDescription string


Can IwDescription be built by the Description function instead ?

This would mean that it'd have to be implemented on each type that implements BaseModulationInfo. If you also turned those attributes into their own types, you could use their String methods.

Personally, I prefer to keep the deserialization/serialization logic focused on fields returned/sent from/to the kernel.

Sure, that would be an option,
I tried to follow closely the c implementation in iw since there the sting is build on the fly as the netlink atributes come in. Creating my own Description Function could not retain that infformation and only make some "nice to read and close to iw format"-String but no iw compatible string. On the other hand, iw warns you every time to not parse it's output and not rely on output format.

But no strong opinion on my side, Cleaning up the parsing is also a nice benefit, therefore I tend to follow your suggestion if no-one intervenes.

Is there any information in the raw netlink message that iw would include in the output string but that doesn't have a corresponding field in the struct? If not, the Stringer should be able to replicate iw's output. Right ?

nickgarlis · 2026-04-01T18:19:52Z

+			iwDescription += fmt.Sprintf(" VHT-MCS %d", vhtModulationInfo.MCS)
+		case unix.NL80211_RATE_INFO_40_MHZ_WIDTH:
+			channelWidth = ChannelWidth40
+			iwDescription += " 40MHz"


ChannelWidth implements a String function which seems to be returning the same values. Can it be reused ?

same discussion as above. Following the ìw` implementation gives slightly different String (no explicit 20MHz Channels in the description)
Good Place to clean up, if we drop the "lets-keep-the-descrition-cloase-to-iw"-premise

…ributes function

lukas-mbag · 2026-06-23T10:20:31Z

after merging in changes from release 0.8.0 I will work on the suggestions from the reviewers in the next few days

…nAttributes function

lukas-mbag · 2026-06-23T14:48:55Z

@nickgarlis or @SuperQ
Any opinion on the open question (see #142 (comment))
should we keep close to the description string of the iw implementation or switch to a library specific String() method?

Otherwise I will just do that and we can finalize this PullRequest

…nput cases

…eInfo types

lukas-mbag · 2026-06-23T15:46:19Z

last 2 commits implement the String Method on the objects itself.
If we want to go back to the almost iw-compatible description String, I can just revert the last 2 commits

nickgarlis · 2026-06-23T19:04:23Z

+
+func channelWithAttributes(cw ChannelWidth) (attr []netlink.Attribute) {
+	switch cw {
+	// case ChannelWidth20NoHT:


Leftover comments ?

intentionally left in, since we don't do anything for those two choices from the set of all Possible Channel-Widths. Could probably be more explicit like

case ChannelWidth20NoHT: return attr case ChannelWidth20: return attr

nickgarlis · 2026-06-23T19:25:16Z

+	for _, tt := range tests {
+		t.Run(tt.name, func(t *testing.T) {
+			got := modulationAttributes(tt.in)
+			if diff := cmp.Diff(tt.want, got); diff != "" {


I am not sure I understand the purpose of this test. It seems like you're testing modulationAttributes which is part of the test suite. Did you mean to do something like this instead ?

attrs := modulationAttributes(tc.in) got, err := parseRateInfo(attrs) if diff := cmp.Diff(tt.want, got); diff != "" { t.Errorf("mismatch (-want +got):\n%s", diff) }

Also, I appreciate the dynamic test fixtures since that means the tests can be endian-agnostic but I wonder whether that's relevant here. If not, should hard-coded byte fixtures be considered instead ? No strong opinions here.

Sorry for not asking this earlier. I must have thought marshaling was part of client_linux.go

Hey, thanks for finding this one.
I've updated the test to do the round-trip:

build attributes via modulationAttributes(tc.in)

marshal them

feed them into parseRateInfo

and assert the resulting ModulationType/Modulation match expectations.

I kept the original raw-attribute assertion too (renamed wantAttrs) since it's still useful for testing the test-file scope function modulationAttributes .

nickgarlis · 2026-06-23T20:10:16Z

-	var info rateInfo
+	var rateinfo RateInfo
+	// initialize with unknown values
+	htModulationInfo := HTModulationInfo{BaseModulationInfo: BaseModulationInfo{MCS: -1, NSS: -1}}


nit: instead of initializing with -1 for MCS and NSS could this be changed to something like

var ht *HTModulationInfo var vht *VHTModulationInfo var he *HEModulationInfo var eht *EHTModulationInfo

Then assign lazily like

if vht == nil { vht = &VHTModulationInfo{} } vht.MCS = int(attr.Uint8())

And finally do

switch { case eht != nil: rateinfo.ModulationInfo = eht case he != nil: rateinfo.ModulationInfo = he case vht != nil: rateinfo.ModulationInfo = vht case ht != nil: rateinfo.ModulationInfo = ht }

I think this pattern breaks on the following Attribute:

case unix.NL80211_RATE_INFO_SHORT_GI: htModulationInfo.ShortGI = true vhtModulationInfo.ShortGI = true

Both Modulation Types use the same Netlink Attribute and we cannot rely on the order of the attributes in the Netlink message. Therefore it is possible that we get this attribute before we get an attribute that defines the modulation.
Initializing both breaks the selection in the switch type != nil

But extracting shortGI in a temp-variable and assigning it in the switch-block would be a possible solution for that.

Nevertheless since we cannot predict the order of the attributes, the EHT case get's quite ugly and bad to read:

case unix.NL80211_RATE_INFO_EHT_MCS: if eht == nil { eht = &EHTModulationInfo{} } eht.MCS = int(a.Data[0]) case unix.NL80211_RATE_INFO_EHT_NSS: if eht == nil { eht = &EHTModulationInfo{} } eht.NSS = int(a.Data[0]) case unix.NL80211_RATE_INFO_EHT_GI: if eht == nil { eht = &EHTModulationInfo{} } eht.GI = int(a.Data[0]) case unix.NL80211_RATE_INFO_EHT_RU_ALLOC: if eht == nil { eht = &EHTModulationInfo{} } eht.RUAlloc = int(a.Data[0])

Let's keep the original implementaion, ok?

nickgarlis · 2026-06-23T20:20:42Z

+type BaseModulationInfo struct {
+	MCS           int
+	NSS           int
+	IwDescription string


Is there any information in the raw netlink message that iw would include in the output string but that doesn't have a corresponding field in the struct? If not, the Stringer should be able to replicate iw's output. Right ?

…default cases

…n rate parsing

… output

lukas-mbag · 2026-06-26T09:05:26Z

Hey @nickgarlis Thanks for all the feedback.
I did a major refactor of the String().
With a bit of help from our trusty AI friends (help needed in this heatwave) I realized, that the Order of the tokens in the strings in iw is deterministic (but ugly). String Method on RateInfo now produces a iw compatible string. The String() Methods on the ModulationInfo Types just print whats available without being compatible with ìw` but therefore being complete.

For me the main Functions I will use are: GetMCS() and GetNSS() and the Strings are just a nice way of validating and comparing the Values with iw.

nickgarlis · 2026-07-10T13:25:31Z

Hi @lukas-mbag

Sorry for the late response. I think it's all looking good now. It's just this comment that I think is pending.

Thanks for addressing the stringer implementation.

(help needed in this heatwave)

Hope you've been enjoying the weather 😎 🌞

lukas-mbag · 2026-07-21T13:41:59Z

Hi @nickgarlis Last comment has been committed and pushed. Thanks for your time for the review!

@SuperQ Any comment from your side or are we ready for the merge?

SuperQ

Thanks!

lukas-mbag added 10 commits November 26, 2025 12:13

add Basic Rate Info Parsing

1b362c4

add basic MCS Decoding test: add additional station info test case with MCS attributes feat: add support for VHT MCS indexes in StationInfo and related parsing logic feat: enhance StationInfo with detailed rate information and VHT support

refactor: remove unused rate modulation interfaces and related code

74d434d

refactor Rate Info

c490bd4

expose Interface create subtypes that implement the interface

add documentation

038a8dc

refactored variable names for better clarity

362fba8

feat: add WifiGeneration method to modulation info types

d6fae4a

improve Documantation

d5d5e85

fix: Linter Errors

c28fea0

Merge branch 'main' into feat-better-rate-parsing

e791304

Add Tests for RateModulationInfo

c608a43

lukas-mbag force-pushed the feat-better-rate-parsing branch from d82f780 to c608a43 Compare January 21, 2026 14:10

more test Cases

ff869d0

lukas-mbag marked this pull request as ready for review January 21, 2026 15:11

add missing 8MHz channel width to rate parsing

24e4be8

nickgarlis reviewed Apr 1, 2026

View reviewed changes

Comment thread client_linux.go Outdated

lukas-mbag added 3 commits June 23, 2026 12:11

Merge remote-tracking branch 'origin/main' into feat-better-rate-parsing

c83ad22

fix: correct spelling of "separately" in parseRateInfo function

ecd0cd4

fix: replace nlenc.Uint8 with direct byte conversion in modulationAtt…

598ca8f

…ributes function

lukas-mbag added 2 commits June 23, 2026 12:39

fix: update rateInfo handling to use value types instead of pointers

38ab304

refactor: implement marshaling for modulation info types in modulatio…

7a829e6

…nAttributes function

lukas-mbag added 3 commits June 23, 2026 16:58

test: add unit tests for modulationAttributes function with various i…

2526868

…nput cases

feat: implement String methods for RateModulationInfo and RateInfo types

3711732

refactor: remove unused IwDescription field and related code from Rat…

b27cd4e

…eInfo types

nickgarlis suggested changes Jun 23, 2026

View reviewed changes

lukas-mbag added 3 commits June 25, 2026 14:13

refactor: update channelWithAttributes function to explicirly handle …

a60b83a

…default cases

feat: add default channel width handling and legacy modulation type i…

1903aaf

…n rate parsing

feat: enhance RateModulationInfo and RateInfo formatting for iw-style…

c491236

… output

make Test_modulationAttributes meaningfull

0466f8b

lukas-mbag requested a review from nickgarlis July 21, 2026 13:45

nickgarlis approved these changes Jul 29, 2026

View reviewed changes

SuperQ approved these changes Jul 29, 2026

View reviewed changes

SuperQ merged commit 8303839 into mdlayher:main Jul 29, 2026
6 checks passed

Conversation

lukas-mbag commented Nov 27, 2025

Uh oh!

lukas-mbag commented Jan 21, 2026

Uh oh!

SuperQ commented Apr 1, 2026

Uh oh!

nickgarlis left a comment • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

nickgarlis Apr 1, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

lukas-mbag Jun 23, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

lukas-mbag commented Jun 23, 2026

Uh oh!

lukas-mbag commented Jun 23, 2026

Uh oh!

lukas-mbag commented Jun 23, 2026

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

lukas-mbag commented Jun 26, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

nickgarlis commented Jul 10, 2026

Uh oh!

lukas-mbag commented Jul 21, 2026

Uh oh!

SuperQ left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

nickgarlis left a comment •

edited

Loading

nickgarlis Apr 1, 2026 •

edited

Loading

lukas-mbag Jun 23, 2026 •

edited

Loading

lukas-mbag commented Jun 26, 2026 •

edited

Loading