[GLAR750S - 3.100]-[BUG] iwinfo shows 'noise: unkown' intermittently and luci fluctuates to showing '0dbm' value for noise when using channels 48 and 161

To reproduce:

  1. Set wifi channel to 48 or to 161
  2. Scroll down in luci overview to see the connection stats at the bottom of the page OR
    Connect over ssh and run iwinfo command several times

Expectation:

The noise level should be displayed and reported correctly without any fluctuations at all. Channels 36-44 and 149-157 function in this manner.

Reality:

For channels 48 and 161 there is a bug causing the noise levels to not be reported correctly/consistently.

Questions:

  1. Is there any issue currently with these two channels that means they do not work properly?
  2. Are there any explanations to why this might occur on these channels?
  3. Should we avoid these channels?
  4. Is there any way to fix this?

@wellnw pls have a check.

@chromebook
I set the 48 and 161 channels and found that the noise has changed. Please see the screenshot below. After setting, the value is not updated so fast. You need to wait for a while.

This is what I mean by fluctuate, intermittent and inconsistent: one second the correct noise value is given, the next second it is shown as ‘unknown’ in iwinfo and as ‘0dbm’ in luCi.

This strange cycle continues indefinitely and appears only on channels 48 and 161. For the other channels, they have never shown a value of ‘0dbm’ or ‘unknown’ at all in my experience.

I appreciate your responses and your effort looking into the issue but your reply does not actually answer any of my questions.

I think you can understand why I might be interested in knowing what is the cause for this strange behavior - whether it is a only reporting error, or more significant such as a problem with the radio or a problem with the driver. However, your response currently only confirms what I am saying myself: that the noise level reported on channels 48 and 161 is not working as it does with other channels as by your own omission:

You need to wait for a while.

So why is this happening? Why do you have to wait for a while to see the correct noise level for channel 48 and 161? Why does the noise level then just as quickly revert to ‘unknown’ or ‘0 dbm’? Is it indicative of a driver issue? A radio issue? A malfunction in function in the firmware or in the reporting software?

If I were to hazard a guess, the noise level might be known to the radio only as it is sweeping the spectrum forwards and not backwards and that these last channels, being at the end of the scale, have moments where the scanning does not catch up with the reporting.

But I am only guessing!

I would be grateful for some actual explanations from the professionals.

EDIT: I also would like to point out that your new ‘channel optimization’ feature always chooses channel 161 for me. Also, when I restrict the region to world, the ‘auto’ channel option always chooses 48. Are these features going to work correctly if the radio is intermittently and inconsistently reporting the noise levels on channels 48 and 161?

@chromebook
Sorry, I understand your question wrong here. I confirmed again that the problem you mentioned does exist. I will check the code here and reply you later. Thank you for your feedback.

@chromebook
Sorry to reply to you so late

  1. Is there any issue currently with these two channels that means they do not work properly?
    ====>I test these two channels here, and there is no problem in actual use.
  2. Are there any explanations to why this might occur on these channels?
    ====>I checked this for a long time, and found no reasonable explanation. I guess the device works at 80MHz bandwidth, 48 and 161 are sideband channels, not the center frequency. Of course, this is just my guess.
    image
  3. Should we avoid these channels?
    =====》When using, do not avoid these channels, because I have not tested anything abnormal.
  4. Is there any way to fix this?
    ====>I looked at the source code of iwinfo and found nothing abnormal. It shows unknown. I still have to track the driver code. I haven’t found a fix.
    Thank you for pointing this out, I will delve into it, thank you.

hey thanks for the reply.

I’m not surprised if it is not obvious as to why it is happening.

I searched open wrt forums and did not see this anywhere, though it is not the easiest issue to search for.

I suppose it would be interesting to know if this was happening with other gl.inet routers but I have none to test.

thanks again.