Board for 5G NR Radio

Hello all,

I am considering building a router to connect to the local 5G network. For that I would need a board, and a 5G module, and of course they should work with OpenWRT (or Linux in general).

I am thinking of getting a SIMCOM SIM8200EA-M2. This is a Qualcom X55 based module which is supported by Linux.

I would also need a board though, and my usual goto board for this only supports MiniPCIe, whereas the 5G modules is an M2 module (in fact, all the modules I found were M2 form factor).

Any good suggestions for a system board with an M2 slot, a Ge port, preferably POE powered? I don't need any WiFI on it.


I am also interested in build my own 5G NR router, what i find so far for the board is a MTK MT7621 board accepting M2 PCIe with gigabit lan from UniElec Store on aliexpress.

I don't know if it is a good board and if it can handle correctly the module but it runs openWRT by default for 45$.

Very interessted in what you've find so far :slight_smile:

qualcomm IPQ4019 with 5G M.2 slot

hello, i know there is a manufacturer named waveshare, they design a 5G dongle dev board which use SIM8200 EA-M2 moudule, I bought one and it works well under windows and ubuntu,
here is the link:,
but when i tried to compiler the qmi-wwan-simcom( simcom's special linux driver ) for openwrt ,it didn't work well

I've actually ordered the waveshare + SIMCOM modem kit. Should arrive next year. I will first try it out together with a stock Linux on a Raspberry Pi.

So I have now received the kit.
First impressions: The kit is not as good as I first thought. The position of the SIM card is such that you need to disassemble everything to replace the sim. I think I will have to buy a sim extender.

I tried first with the stock qmi-wwan and libqmi in the latest Raspberry OS, and this did appear to work, but speeds were disappointing. I am getting a sim from a different provider, and a different enclosure so I can use it with a PCEngines box. Then I will try out OpenWRT and maybe also IPFire.

1 Like

I have successfully compiled a version, but there are still problems with this version. Here are some logs of this system and the imgs.To be honest, I think the driver provided by simcom has a big problem

Can't download the logs, but you are right about the simcom driver. It's pointless at best. Use the stock driver and report any problems with it. For example here.

FYI: I wrote that driver and am still trying to maintain it.

1 Like

How disappointing? Like not getting the full gigabit? Or much worse?

You might have do dive into the complicated QMAP muxing stuff to get full speed out of the modem. This is not very well documented, and pretty obscure. There are some hints here:

The point isn't to get multiple PDN support but to get the packet aggregation features. This will probably allow higher speeds. I say probably because I don't have any fast enough modem to test that myself :frowning:

And you'll want this very recent fix as well to get max speed when using QMAP:

Actually, I am a beginner. I have a question, why the same option.c and qmi-wwan-simcom can be used on raspberry pi OS but not on openwrt

Not sure I understand the question. Both the RPi OS and OpenWrt use recent and maintained kernels, which come with updated option and qmi_wwan drivers.

qmi-wwan-simcom is not relevant for any maintained Linux distro. And IMHO it's not even a good solution for those who are stuck with some outdated kernel. It's always better to push any new patches to mainline Linux and backport the results.

You are right. I can see that information about 5G modules from quectel and other vendors has appeared in the latest kernel, such as rm500q. Maybe I should consider using modules from more sophisticated manufacturers :sweat_smile:

I compiled a new version of the openwrt image, and now option.c and qmi-wwan.c are working properly. But I still haven't figured out how to dial-up the Internet using ndis. It is not feasible to use the luci-app-qmi tool directly.
In fact, the official provides some additional drivers for dial-up Internet access. You can see these drivers in this link:, I think it’s only one step away from success ! :face_with_monocle:

Not sure what you mean by dialup. There's no switched circuit involved here. You cannot dial a phone number. You create a packet network session to some APN. If you're SIM has the PIN enabled then you need to configure that to unlock the SIM. Most other settings can usually be left at default


dial up means PPP 、NDIS or other ways to connect to internet, i tried luci-app-qmi ,but it didn't work well

And I assume you don't want any help with that since you keep the details to yourself?

I am currently trying with the stock kernel on a fedora33 box. There the option.c etc. do not need to be patched. Currently speeds I get are 30 down, 70 up. (Yes. up higher then down).

My current 4G router (a Zyxel one) reliable gives me 60 down, 60 up, with peaks up to 120 down. I was hoping to get somewhat better. But I am currently in the country. I plan on taking my rig back to the city with m and see if I get better speeds there.

I tried to follow the instructions in that page, but did not get anywhere.

This gave an error:

[root@rixx qmi]# qmicli -p -d /dev/cdc-wdm0 --wds-bind-mux-data-port=mux-id=0,ep-iface-number=2 --client-no-release-cid --client-cid=17
error: couldn't bind mux data port: QMI protocol error (3): 'Internal'

But I also noticed this:

[root@rixx ~]# qmicli -p -d /dev/cdc-wdm0 --wda-get-data-format
[/dev/cdc-wdm0] Successfully got data format
QoS flow header: no
Link layer protocol: 'raw-ip'
Uplink data aggregation protocol: 'disabled'
Downlink data aggregation protocol: 'disabled'
NDP signature: '0'
Downlink data aggregation max datagrams: '0'
Downlink data aggregation max size: '0'

Now looking at the help of qmicli I see that there are different options you can have here...

[root@rixx ~]# qmicli -p -d /dev/cdc-wdm0 --help-wda
qmicli [OPTION…] - Control QMI devices

WDA options:
--wda-set-data-format=["key=value,..."] Set data format (allowed keys: link-layer-protocol (802-3|raw-ip), ul-protocol (tlp|qc-ncm|mbim|rndis|qmap), dl-protocol (tlp|qc-ncm|mbim|rndis|qmap), dl-datagram-max-size, dl-max-datagrams, ep-type (undefined|hsusb), ep-iface-number)
--wda-get-data-format=["key=value,..."] Get data format (allowed keys: ep-type (undefined|hsusb), ep-iface-number); also allows empty key list
--wda-get-supported-messages Get supported messages
--wda-noop Just allocate or release a WDA client. Use with --client-no-release-cid' and/or --client-cid'

But I seem to be unable to find any info on what the different options mean. I mean, googling for example qc-ncm turns up nothing...

So I am a bit stuck here, and could use some help from someone who understands this. I will also follow your suggestion and go back to using the stock driver. (I'm on kernel 5.10 and will be on 5.11 soon).

The problem you, I and everyone else has here is that the documentation is Qualcomm proprietary and only available to their customers under NDA. So we don't know what all the settings do or how to use them. We only know a few of the possible values, and try to guess the rest of hte picture based on parameter names etc. I assume for example that the "2" in "ep-iface-number=2" refers to number of the USB interface with the attached USB endpoints. I.e. the interface qmi_wwan is bound to. Or maybe something else?

Aleksander has been working on QMAP support in ModemManager recently. You can probably find a few hints on how to make it work there:

Thanks. But do I really need QMAP? From what I read it is a way to connect to multiple APNs, and my provider only uses one. I though that carrier aggregation was done by the cards themselves, an was hoping I just needed to change some settings...

That said, is the SIM8200EA-M2 a good choice anyway? I got that one because it came in a kit. I am now wondering if it is right.
One disadvantage this card has is its 6 antenna connectors, of which you only need to connect four. But it varies on the band you want to use which for. Where I live 5G uses a refarmed GSM band (n1), but I intend to take the rig to the city tomorrow and test it on n78. For that I will need to rearrange the antenna's :frowning: