topic Re: How to debug "Error: unhandled value 0 for OFDM l_sig_rate" in ExtremeWireless (WiNG)

How to debug "Error: unhandled value 0 for OFDM l_sig_rate"

Valter_Veiga — Wed, 30 Oct 2019 09:37:47 GMT

Hello,

How can I debug the following message ?

Oct 30 02:16:29 2019: %KERN-6-INFO: [401607.670569] athko_fill_wips_rxinfo: Error: unhandled value 0 for OFDM l_sig_rate.

Re: How to debug "Error: unhandled value 0 for OFDM l_sig_rate"

ckelly — Wed, 30 Oct 2019 20:10:38 GMT

Valter,

What version of WiNG is running on this AP?

Re: How to debug "Error: unhandled value 0 for OFDM l_sig_rate"

Valter_Veiga — Wed, 30 Oct 2019 21:21:13 GMT

Hi Chris,

AP7632 version 5.9.4.1-004R

Re: How to debug "Error: unhandled value 0 for OFDM l_sig_rate"

ckelly — Wed, 30 Oct 2019 21:31:07 GMT

I can’t find anything that specifically matches this error message in the subsequent release notes, but there are a 2-3 SPRs that are marked as fixed in 5.9.6 that sound like they MIGHT be related to this message. For now, at least as a test, I’d try upgrading to 5.9.6 and see if the message re-appears. If it does, I’d certainly recommend opening up a case with GTAC.

Re: How to debug "Error: unhandled value 0 for OFDM l_sig_rate"

Valter_Veiga — Thu, 16 Jul 2020 16:41:15 GMT

I’m running the version 5.9.7.0-011R and the error message is still there.

“athko_fill_wips_rxinfo: Error: unhandled value 0 for OFDM l_sig_rate”

Can it be because: rate-selection opportunistic ? (I use this beause of the MESH config.)

Info :

According to documentation the The L-SIG is one OFDM symbol with a duration that varies with channel bandwidt.

Non-HT (Legacy) Signal Field

The legacy signal (L-SIG) field is the third field of the 802.11 OFDM PLCP legacy preamble. It consists of 24 bits that contain rate, length, and parity information. The L-SIG is a component of HE, VHT, HT, and non-HT PPDUs. It is transmitted using BPSK modulation with rate 1/2 binary convolutional coding (BCC).

Can it be because: rate-selection opportunistic ?

Re: How to debug "Error: unhandled value 0 for OFDM l_sig_rate"

ckelly — Fri, 17 Jul 2020 00:16:58 GMT

Valter, I can’t say 100% based on the message itself:

athko_fill_wips_rxinfo: Error: unhandled value 0 for OFDM l_sig_rate

At this point, now that you’ve upgraded to 5.9.7 and are continuing to see the message, I would recommend reaching out to GTAC.

If you wanted to explore the possibility that this is a ‘opportunistic’ rate selection standard problem, try could try changing from opportunistic to standard and see if the messages continue.

Re: How to debug "Error: unhandled value 0 for OFDM l_sig_rate"

Valter_Veiga — Fri, 17 Jul 2020 20:48:41 GMT

Hi Chris,

I have open the case # 02202923.

The support is doing its initial look.

How can I take a wifi capture in the wing to capture this “l_sig_rate” field ?

Re: How to debug "Error: unhandled value 0 for OFDM l_sig_rate"

ckelly — Fri, 17 Jul 2020 22:54:43 GMT

Valter,

The L-SIG (legacy signaling) field is part of an .11 Preamble and the Preamble contains the transmission and vector information for the each transmitted frame. The L-SIG field itself contains a length and rate sub-field. It’s this rate sub-field that seems to be at issue. For 5GHz transmissions, the rate sub-field should always be set to 6Mbps and is represented by a 4-bit value (1101).

The problem, according to the error message, is that the rate value is being interpreted as being “0”...which is certainly not an existing data rate, right? And hence the error message.

As for actually capturing an example to see what is in the air, this is going to be a problem because as far as I know, the Preamble is not something that is decoded and presented by capture tools. The preamble is essentially information that is really only useful to the wireless hardware (I’ve never needed or wanted to look at actual Preamble information in a wireless capture before).

I’ve looked in Wireshark, using an adapter in monitor mode, and the most I’m seeing in the radio-tap header section under the ‘Present Flags’ is whether the L-SIG is absent or not. It doesn’t tell us what the ‘rate’ value is in the L-SIG sub-field in the frame’s Preamble. And w/o this, you cannot analyze a wireless capture to validate if a frame’s rate value is actually “0” or not.

This is going to be one of those issues where we need to let GTAC and engineering do what they do best.