RM551E-GL IP Passthrough (IPPT) aka bridge mode

IoT Modules 5G Module
1

This is actually the same as this issue, but for the RM551E-GL.

The documentation mentions the at+qmap=“mpdn_rule” comment set for this module as well, but at least in conjunction with ethernet usage, it doesn’t work and returns “ERROR”.

@Quectel: I want to use that modem with a M2 to Ethernet adapter and have the IPv4- and IPv6-addresses on that interface as assigned by the ISP.

IPv6 is relayed, but for the IPv4, Quectel or rather the embedded OpenWRT provides it’s own /22 network and performs NAT/PAT.

How can I change that?

2

I don’t think PCIe RC mode is officially supported yet. Nonetheless it does seem to work anyways. A feel like there are some things that need worked on for the QMAP set of commands on Quectel’s end but I’m still researching that.

The mpdn rule now requires an actual Mac address specified not the FF:FF:FF:… Wildcard.

3

Thanks, when specifying a concrete MAC address using the command e.g. AT+QMAP=“mpdn_rule”,0,1,0,1,1,“AB:CD:EF:AB:CD:EF”, it is accepted and when acts as follows:

If AT+QMAP=“ippt_nat” is set to “1”, then the ISP’s IP address is forwarded to the ethernet interface, however, the DNS-server still is provided by the modem with its IP address 192.168.224.1

If AT+QMAP=“ippt_nat” is set to “0”, then not only the ISP’s IP address is forwared to the ethernet interface, but also the DNS servers.

I have to investigate this further, but at least in the AT+QMAP=“mpdn_rule”,0,1,0,1,1,“AB:CD:EF:AB:CD:EF” & AT+QMAP=“ippt_nat”,0 - scenario, I’ve already lost routing towards the WAN twice. The connection stays up, the ISP’s IP address remains assigned, but no traffic is forwarded anymore randomly until the RM551E-GL is rebooted, which obviously sucks.

@Quectel: besides this possible bug, could you please elaborate on what that “ippt_nat” - option is actually supposed to be doing? Naming-wise, it is somehow counter-intuitive that a ippt_nat (namingly “IP PassThrough”) set to zero for “disabled” actually leads to passthrough in terms of the DNS servers, while a ippt_nat option set to “1” (for ethernet) actually leads to DNS servers referring to the modem (thus not being passthrough DNS-wise).

When in doubt, I would expect it it to be the other way around.

4

Dear @little-endian
RM551E is ES, it is not recommanded to use it and it is not stable now.

Could you tell me where you get it?

5

Hello silvia, thank you for your concern.

Well, good for Quectel that they have (end) customers willing to play their unpaid alpha testers out of technical interest.

By “Not recommended to use”, you probably mean in addition “… by end customers”, as someone obviously has to use them in order to iron out the bugs and I were you, I would welcome any source for feedback, being it a private person or not.

At your service, so what is your recommendation in terms of the next steps or tests to take? Are there any differences to be expected in the module’s behavior depending on the used ippt nat mode? Currently, I have only the AT+QMAP=“mpdn_rule”,0,1,0,1,1,“AB:CD:EF:AB:CD:EF" option applied but without AT+QMAP=“ippt_nat”,0 to see if that makes any difference.

Furthermore, how about picking up my remark about the counterintuitive ippt_nat behavior reagrding the DNS server forwarding?

Only stating that the RM551E-GL is some beta or even alpha product, although factual correct as you would know best, isn’t exactly helpful to improve the product, is it?

As about where I got it from: the usual suspect Alibaba, virtually the only source when it comes to any Quectel module as they aren’t directly sold anyway, at least not in good old Germany which used to have nice technical innovations on its own (good old days which are long gone now I guess).

1 Like
6

After several more days: the modem connect is stable as long as it’s used in routing mode. So I guess the bridge mode is indeed buggy yet.

@awesome Quectel support: what else can I test for you in order for you to improve the product?

7

Further update. Unfortunately, the connection issue not only occurs when using the bridge mode, although more often so far, but also in routing mode after all:

Screenshot_20241104-013513_Termux
Screenshot_20241104-013513_Termux1768×1243 150 KB

The modem is run with this adapter, hooked up to a bridged wireless access point.

The modem itself remains pingable, but the routing towards the WAN randomly stops working.

Since this doesn’t occur with a MC888A with O2 Germany, I assume it’s a bug of the RM551E-GL.

8

Dear @little-endian
For this issue, please capture log for analyze which inculde your problem.

9

I had same issues. PM sent. I seen the exact same issue and like you said worse on IPPT, but still happening in router mode.

10

Further update and clarification in order to prevent any confusion:

The observed issue when using the “routing mode” where the Quectel RM551 itself act as a NAT/PAT-router and controls the connection, seems to have been a singular/provider-related one as in general, at least in the past weeks, this is stable so far.

So in further test, I would concentrate on the original bridge mode issues.

If you could tell me how to do that with the RM551, I’m happy to do that.

1 Like
11

What provider did you see it happen or not happen on? We have been noticing it on tmobile.

Iamroman above has a ticket open for same issue. Ticket 187579.

12

Has anyone found an answer for this yet. I am having the same problem trying to passthough to me UDM pro. It will get a connection from the modem and then drop it. it will work fine if i don’t enable IPPT but cuts my internet speed down to about nothing.

13

I was hoping they were going to investigate but seems to be no reponse from anyone lately unless they are working privately with little-endian. He didnt resond to my pms either so not sure.

14

Thanks, seems like i have a paper weight for now. works great if i just want to eth to my laptop but that isn’t why i bought it.

15

O2 Germany, annoyingly disconnecting the IP-session every almost 24 hours (about 23 hours, 59 minutes ans a few seconds) which - even worse - constantly leads to a shift of the point of disconnection over time even if no unplanned disconnection occurs, only counterfeitable by disconnecting manually once in a while on purpose.

16

IPPT mode is still unstable until the firmware is figured out over there lol

You can use poor mans IPPT for now
DMZ Passthrough

What you do is you limit your DHCP to 1 IP or set a Static address to a client from the modem. Then you use the commands
AT+QMAP=“DMZ”,1,4,IPv4 of client
AT+QMAP=“DMZ”,1,6,IPv6 of client

Basically the same thing as IPPT.
External requests on ports are to be routed to said internal IP with DMZ

17

Yes, and Quectel seems to be highly eager to change that fact, themselves stating:

Which is close to real life satire. Like “we sell a product but ourselves don’t recommend to use it”. This kind of attitude and support is really pathetic and I can only wonder how they can survive on the market like this.

About that - is it also forwarding non-port based data traffic like protocols directly addressing the IP-Layer 3 such as GRE tunnels? I mean, there is more than UDP/TCP to IP-based communication.

18

Quectel is just like any company, it has a left hand and a right.

These forums are great for us to all talk. Support now and then will answer stuff here as well. This isn’t their real ticketing system though. I have an open ticket for this problem in their real one and not even the support rep is in possession of an RM551E-GL

Send me a PM on here and I’ll send you in the right direction to be able to collect a log from the modem that will be useful to them. I’ve been busy and haven’t had time to do it myself. Then again my intention for buying this Engineering sample 1 (ES1) was really just to get a head start on development on it.
It works fine not in true IPPT mode and delivers some pretty nice speeds. That’s all I really need.

They sell an early release version of a product that is still in active development. What they mean by that is don’t be using it in mission critical production environments. I’ve heard rumors that hardware won’t be changing but that’s no guarantee. Maybe in March we will see new firmware.

Messenger_creation_FA2EB2E6-4CC9-4A8C-942B-280FB2A61191
Messenger_creation_FA2EB2E6-4CC9-4A8C-942B-280FB2A611911035×426 22.2 KB

About the DMZ Passthrough, I would test and see if you see any improvement
¯_(ツ)_/¯

1 Like
19

Yes, the decease of any bigger company. Nonetheless there are several things I just don’t understand and which I would definitely handle differently if I had a saying there (maybe they are hiring, haha):

However, with - no offense intended - quite limited language capabilities it seems, mostly ultra brief and hardly picking up all points raised.

Well, find the mistake. They are sold widely via Aliexpress and Alibaba. How difficult can it be for the own Quectel support to acquire one?

Had the same time issue but I’ll follow it up directly with you, thanks for the kind offer!

Yep, same for me so far. I have it running in the usual routing mode where the modem itself does the NAT/PAT - part and that seems to be quite reliable.

Nothing wrong with that.

That I also understand. But still they could make their life and the user’s a lot easier. It already starts with that unnecessary secretiveness with their documentation and firmware updates. Instead of simply publishing that somewhere online with easy access, they individually send it only to the ones who ask where one has to get lucky that someone here from Quectel responds, etc. Carrier Aggregation combinations? “Oh no, sir. That is also our secret, way too sensitive to share.” It would only be very substantial for any knowledgeable customer caring for the details. God forbid to state such things right away. :roll_eyes:

Furthermore, the communication link between the not-entirely-stupid-somewhat-knowledgable customers and companies is traditionally bad which is especially ironic if one thinks about the fact that we’re talking about companies who are in the field of communications after all. One hardly gets a contact with developers but only to some miserable first-level-nonsense if at all.

Probably I don’t tell you anything new - you’re at a totally different skill level but look at your great documentation about the RM551E-GL and how to set it up. I find that on your website, but not Quectel’s which is quite absurd.

Hope they offer you a job at least. :slight_smile:

1 Like
20

Is this still the case today? I have an RM551E-GL and ETH enclosure in route that I plan on using with T-Mobile and as a third WAN on my UDM SE; therefore I would prefer bridged mode to keep things simple.