Inconstencies (e.g. race conditions) for MediaTek MT7915E radio (in Cudy x6)

Installing and Using OpenWrt
1

I have recently provisioned two devices, of the identical model, Cudy x6, in OpenWrt.

I am not aware of any difference in hardware revision between the two devices, so I am assuming the specifications are identical.

Yet, I am experiencing inconsistencies in the radio operation, specifically in the detection of supported bands. The inconsistencies appear both between the two devices, and over time within a particular one.

The radio device is MediaTek MT7915E.

Immediately after I initially provisioned the first device with OpenWrt, the following four radios appeared in the Wireless page:

  1. Generic 802.11bg
  2. Generic 802.11bg (occurs twice)
  3. MediaTek MT7915E 802.11bgn
  4. MediaTek MT7915E 802.11nac

The initial allocation of master networks and SSIDs was very convoluted. Guest networks, and only guest networks, were provisioned for each of the bg networks, and each of the two others (bgn and nac) had a total of three networks provisioned, one of which was given SSID OpenWrt, the others given different SSIDs.

Radio layout and initial provisioning on the second device was very different. Only two radios were detected, each given one SSID, and no guest networks were provisioned.

Consistently, on this device, one particular radio band is given as MediaTek MT7915E 802.11nac. Consistently, too, there is one other band given, but its description oscillates intermittently between MediaTek MT7915E 802.11bgn and Generic 802.11bg.

My best inference is that the interaction between the supported drivers and the hardware (MT7915E) is rather flaky, leading to a variety of race conditions for detecting available radio bands.

For reference, I had loaded the manufacturer's build of OpenWrt, the only OpenWrt build currently published for this device.

Is anyone who has experience with this hardware able to shed some light on the peculiar effects I have observed?

2

You should probably be talking to Cudy support.

1 Like
4

My devices are not in need of recovery. Both boot and expose a Luci interface, and an SSH login.

I am not looking to load my own builds.

I am trying to gain the best understanding of how to use whatever images are available as published, and why the devices might be behaving so strangely with their loaded images.

1 Like
9

It doesn't appear that there your device is officially supported by OpenWrt 21.02, and that is probably why you need to use the manufacturer's build. That means that Cudy has clearly made some out-of-band modifications to OpenWrt to make it work on the x6. As such, questions or issues with the build (especially when it comes to low level drivers and such) really need to be directed to Cudy.

1 Like
10

Fair enough.

Even so, this is the group most familiar with the platform, and its quirks. I felt if anyone has any idea, for example, why the two devices originally came up with very different provisioning, it would be someone in the group represented by the current forum. Whatever logic makes these choices most likely a part of the platform.

I will consider contacting Cudy, as they would have the best understanding of their hardware, and their modifications.

Meanwhile, it would be nice if anyone has further comments following my observations and question from the original post.

I also look forward to an official release for this device, as it seems to be stalled in unapproved pull request, though still rather recent. It seems that even the manufacturer's image, which I hoped to use to good effect until one is available from the main project, lacks full support for the higher-speed radios, as best I understand from remarks given by @anon69880279, which is disappointing.

There are still many questions about the differences between various options for the device, and what is needed for full and consistent support for the platform.

One source of ongoing mystery for me is how much of the platform is managed by the package system, and may be upgraded dynamically, versus tied to the firmware image, and may be upgraded only by flashing a more recent image.

11

That is true for the official development tree and releases.

This is not the case for things that are forked and custom developed. Those customizations can have profound impacts on the way that the system functions. Everything from core stability to the syntax of config files and the features and functions that are available can be different as a result of changes that happen in a forked version. Consider that OpenWrt is a linux based OS and so is Ubuntu, but they couldn't be more different.

2 Likes
12

I agree with your recent comments in the sense of the open nature of the platform offering vendors extreme latitude to customize the behavior of images they might design, but my assumption is that Cudy has not undertaken such extensive customization. My impression is that in publishing the image, the company attempts, in a way that is not deeply burdensome on its internal resources, simply to provide the basic platform on their boxes.

I suspect any considerable variations from the core system behavior are most likely to be incidental or undeliberate.

13

Assumptions, obviously, don't necessarily reflect the truth. Only Cudy can really say what has been added/removed/modified to make their image work. And they're not steering people to an image that is hosted on OpenWrt's site (i.e. master/snapshot or an official release), so likely those changes have not been merged into the mainline.

Sure. Regardless of the internal resource allocation, they are almost certainly doing something that is not (yet) integrated into official OpenWrt. It would be even less work if they just relied on the OpenWrt developers themselves (in which case it would probably be part of the OpenWrt master/snapshot builds).

It's not a necessarily wrong to assume that they are trying to minimize the impact on the core functionality of OpenWrt, but figure that...

  • they need to provide support for new/different hardware
  • this, in some cases, may actually require certain core things change (slightly or massively) in order to function properly
  • they could introduce bugs into the system -- either issues with their own code/customizations, or clashes with other parts of the system.

Because the OpenWrt volunteer developer community is not the group that is making the updates to support that hardware, they (and the general community here) cannot know about the nuances for any changes that have happened and/or the bugs that may be present. Cudy, on the other hand, should have a pretty good understanding of how OpenWrt (specifically their customized build) works on their specific device.

1 Like
15

Is the manufacturer firmware running the mt7915e kmod, or some other driver?

I think the problem with these (besides the MT7621 CPU being underpowered to make a serious ax router) is that they split the four RF chains in the MT7915 chip to be 2x2 on both bands from a single chip. That mode is not supported by the open-source driver.

16

Yes, obviously not. The view I am expressing is that my assumptions represent a reasonable basis for opening a discussion, though not necessarily a replacement for concrete information. If you have any direct knowledge about what Cudy actually has done, plainly I welcome it.

I will look into contacted Cudy, though it may take some work to get my questions directed through the right channel. Even so, it seems a stretch that all of my observations, including the ones about SSID initialization being different on each device, result from customization the company has undertaken.

Naturally, to me it seems most likely their preference, as it is mine, to rely on an image for the device published by the community, only not presently an option, for anyone, because no such image has been published. (See my earlier reference for the open pull request.)

18

That decision should be made before purchasing the device.

20

If you understand processes or have found solutions helpful for those who would want to build the image themselves, then perhaps you would post a guide in a new topic.

I found your comments hard to follow and felt they were not on the subject I opened. Please understand not everyone wants to build software from source in order to deploy it on a device.

Nevertheless, others may be happy for such help, placed where they might find it readily. I think writing a guide on the subject would be very helpful for the community generally, even if following it is not the best path for me personally

.

22

See the problem?

23

(post deleted by author)

1 Like
24

I think you misunderstood....

As long as you keep giving, why should he do any of the work.

25

(post deleted by author)

26

The hardware and RF details of your question exceed my understanding, but it is a useful distinction whether the image includes a propriety versus open driver. Their stock firmware is loosely based on OpenWrt, in which they may use a propriety driver that fully utilizes the hardware. If so, it seems sensible that they would include the same driver in their custom image for OpenWrt.

If Cudy (or the OEM) were willing provide binaries of their driver, would the project accept it for integration into an official build image for the device?

27

Thanks for trying to help.

28

You need to ask that question in the For Developers forum...

Any development for a specific device would require that device to be in a developer's possession.

If there is developer interest, and you provided the device, there may be some traction.

29

Since you have CLI access you could run lsmod and see at least the names of the kernel modules installed.

Drivers have to be recompiled to match a new kernel version, since OpenWrt is always updating the kernel version that is not possible without the driver source code.

This model shares the same design with a lot of other low end ax routers like the (also unsupported) Belkin RT1800. Developer interest is not very strong, it's just not a design to write home about.