Replacing OEM-Shipped OpenWRT Install

Hardware Questions and Recommendations
1

Yesterday, while browsing around in a thrift shop, I came across one of those generic WiFi repeaters with no branding on it. Since it was so cheap, I decided to take a chance on it and bought it since I've been wanting to get an extender anyway.

Out of the box, the repeater's functionality is very limited. Although it certainly works as a repeater, you have pretty much no control over it. The repeater works by setting up its own subnet for all of the devices that are connected to it. I did not like that, so I did some exploring, and to make a long story short, I managed to hack my way into it only to find that it runs a fork of OpenWRT. After reconfiguring the NGINX server for the OEM's basic UI to run on a different port, I used opkg to install LuCI and reconfigured the repeater to use relayd.

Although this setup works (aside from the fact that I cannot figure out how to get devices connected through the repeater to be able to access LuCI), there are various functions of OpenWRT that are broken due to the changes that were made to it by the OEM. For example, the LED configuration options appear to just not do anything at all and trying to access the Network > IP Security tab also fails with this error:

/usr/lib/lua/luci/dispatcher.lua:1347: module 'luci.cbi' not found:
	no field package.preload['luci.cbi']
	no file './luci/cbi.lua'
	no file '/usr/share/lua/luci/cbi.lua'
	no file '/usr/share/lua/luci/cbi/init.lua'
	no file '/usr/lib/lua/luci/cbi.lua'
	no file '/usr/lib/lua/luci/cbi/init.lua'
	no file './luci/cbi.so'
	no file '/usr/lib/lua/luci/cbi.so'
	no file '/usr/lib/lua/loadall.so'
	no file './luci.so'
	no file '/usr/lib/lua/luci.so'
	no file '/usr/lib/lua/loadall.so'
stack traceback:
	[C]: in function 'require'
	/usr/lib/lua/luci/dispatcher.lua:1347: in function '_cbi'
	/usr/lib/lua/luci/dispatcher.lua:1024: in function 'dispatch'
	/usr/lib/lua/luci/dispatcher.lua:479: in function </usr/lib/lua/luci/dispatcher.lua:478>

This got me wondering if it would be possible to update the repeater to use an official OpenWRT instance instead of the OEM's fork. Although the repeater is not listed as having official support for OpenWRT, the LuCI status page showed that the target platform for the repeater is a mediatek/mt7981, so I attempted to use the sysupgrade image from here to upgrade. Perhaps unsurprisingly, this bricked the repeater. After some frantic searching, I figured out how to get the repeater into recovery mode and re-flashed it with a firmware image from the manufacturer.

This brings me to my question. Given that this device is already running an unofficial OpenWRT fork and OpenWRT does not officially support this specific device but does support its chipset, is there anything I can do to upgrade to a newer version of OpenWRT, and ideally, completely eliminate all of the OEM-specific tweaks that were made to the version that I am currently running?

The LuCI status page lists the OpenWRT firmware version as: OpenWrt 21.02-SNAPSHOT r0-10d74dc / LuCI openwrt-21.02 branch git-23.093.57360-e98243e

2

Someone (read you, as you're the only one with this hardware) would have to do the necessary development/ porting first. These are embedded devices and everyone of them needs a bespoke image, down to the hardware revision, custom tailored to the exact hardware you have at hand.

3

Getting the linux kernel version would be a good first step.

Then try to get the DTS file for the kernel (you can dump it from the running image if you’ve got command line access). Re-align the DTS with the mainline OpenWRT and you’d be pretty close… assuming there’s no additional closed source tweaks that the vendor has done.

You could try to find / request the GPL source code (i.e. the kernel source) from the vendor also.

4

Good, mt7981 is a well supported platform and porting OpenWrt to this should be “easy“ in theory.

Try obtaining the DTS from stock firmware. With that, try writing the OpenWrt support like this commit: https://github.com/openwrt/openwrt/commit/536a25ebf849b2de22792786b4c6f0c15471ee93

You can use other “mediatek: filogic: Add support for“ commits. Also you can get some ideas reading other mt7981 DTS files: https://github.com/openwrt/openwrt/tree/main/target/linux/mediatek/dts

I wanted to port vanilla OpenWrt to a unsupported router last year and I remember doing the same.

5

Thanks for the link! Yes, that's pretty much what I had expected to hear.

By the way, since I failed to mention it in my first post, the device is a COMFAST CF-XR186. I do not know if there is any difference in the hardware between the two, but there seem to be two variations of the device's outer shell. One variation has the COMFAST branding on it as you see in the image on the page I linked and the other variation does not have any reference to COMFAST on either the unit itself or anywhere on the packaging. This listing on eBay uses the same packaging and unit design as the one I bought (although I paid much, much less for mine :slight_smile:). I assume that despite minor differences in external appearance, there is no hardware difference between the two. It may also be worth noting that there were some minor differences to the firmware that came with my unit out of the box compared to what I flashed from the COMFAST website when attempting to recover from the bricking incident. Aside from lacking the COMFAST branding, the out-of-the-box firmware also seemed to be missing some of the features that are available in the COMFAST release.

I do see that there are several COMFAST devices that are supported by OpenWRT. This just isn't one of them.

I have full root access through SSH, so that shouldn't be an issue! The bigger issue for me is to figure out how to get the DTS file.

As for requesting the GPL source code, that's not a bad idea, but given that COMFAST seems to be using OpenWRT without giving it proper credit anywhere that I could find, I doubt that they will respect GPL licensing rules if I contact them.

Great! Since I don't know where to start with obtaining the DTS, I'll try to use your thread as a starting point. Even though it's a different device, I hope there's enough overlap for me to get something out of it.

6

@Wolfman_Mac you seem to have a good grasp on the subject, just based on your use of the term OEM fork, but for posterity reasons I still want to link a little write-up for people who stumble upon your thread who do not: https://docs.openwrt.melmac.ca/openwrt.html

1 Like
7

Thank you! I am very new to OpenWRT but I am a software developer with experience working on other open source projects, so the high-level concepts are pretty much the same.

I have a small update on this. I haven't tried contacting COMFAST but I did try looking to see if I could find the GPL source code on their website. I didn't find it, but I did find this post from the old OpenWrt forum. As I expected, they do not care about following the GPL rules.