Is there Internal NAT in RM520N-GL 5G Modem

IoT Modules 5G Module
1

Hi, I have the following setup: Raspberry Pi 5 with RM520N-GL 5G HAT+.

Hi, I need to understand if the IP address assigned to the NIC “rmnet_mhi0.1” by the Waveshare-CM driver is provided by the real eNB (evolved NodeB), or if there is a virtual LAN between this NIC and the 5G modem.

For example, if the assigned IP is 10.93.13.141 and the default gateway is 10.93.13.142, is the gateway IP address the IP of the actual eNB, or is it a virtual gateway provided by the modem?

In other words, is there some kind of internal NAT in the modem, or is it only present on the eNB?

Thanks

2

Hi Francesco

The 10.93.13.141 is from the carrier. But the gateway 10.93.13.142 is caculated by the Quectel.

3

Here is the example that how the gw and netmask generated.

#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <sys/socket.h>
#include <netinet/in.h>
#include <arpa/inet.h>


int main(int argc,char *argv[])
{
    int cnt = 0;
    int flag = 1;
    struct in_addr addr;
    inet_aton(argv[1],&addr);
    uint32_t input = ntohl(addr.s_addr);
    uint32_t pub_ip = ntohl(addr.s_addr);

    in_addr_t netmask = 0xffffffff;

    if(1 == (input & 1))
    {
        //printf("1\n");
        while(1 == (input & 1))
        {
            input = input >> 1;
            cnt++;
            //printf("cnt %d\n",cnt);
        }
        netmask = netmask << cnt;
        addr.s_addr = htonl(netmask);
        printf("net_mask %s\n",inet_ntoa(addr));
        if(0xffffffff == ((pub_ip + 1) | netmask))
        {
            addr.s_addr = htonl(pub_ip - 1);
        }else{
            addr.s_addr = htonl(pub_ip + 1);
        }
        printf("gate_way %s\n",inet_ntoa(addr));
    }else{
        //printf("0\n");
        while(0 == (input & flag))
        {
            flag = (flag << 1) + 1;
            cnt++;
            //printf("cnt %d\n",cnt);
        }
        netmask = netmask << cnt;
        addr.s_addr = htonl(netmask);
        printf("net_mask %s\n",inet_ntoa(addr));
        if(0xffffffff == ((pub_ip + 1) | netmask))
        {
            addr.s_addr = htonl(pub_ip - 1);
        }else{
            addr.s_addr = htonl(pub_ip + 1);
        }
        printf("gate_way %s\n",inet_ntoa(addr));
    }
    return 0;
}

gcc test.c  

 ./a.out 10.93.13.141
net_mask 255.255.255.254
gate_way 10.93.13.142
4

I understand that what I need is to enable IPPT on my RM520N-GL to obtain a direct public IP.

I have this firmware:
AT+QGMR
RM520NGLAAR01A08M4G_01.200.01.200

My configuration is as follows:
at+qmap=“mpdn_rule”
+QMAP: “MPDN_rule”,0,0,0,0,0
+QMAP: “MPDN_rule”,1,0,0,0,0
+QMAP: “MPDN_rule”,2,0,0,0,0
+QMAP: “MPDN_rule”,3,0,0,0,0

at+qmap=“MPDN_status”
+QMAP: “MPDN_status”,0,0,0,0
+QMAP: “MPDN_status”,1,0,0,0
+QMAP: “MPDN_status”,2,0,0,0
+QMAP: “MPDN_status”,3,0,0,0

AT+qmap=“ippt_nat”
+QMAP: “IPPT_NAT”,1

But i can’t get a public IP

5

You cannot get a public IP until it is assigned to you by your carrier. That has nothing to do with Quectel and their modems.
What is assigned is shown in AT+CGPADDR output, that is a standard 3GPP command.

Yes, in ECM and RNDIS modes.

6
  1. You need to upgrade the firmware to support the IPPT.
  2. With this settings, the IPPT is not enabled.

Do you use the ECM or Ethernet cable?

7

The modem is connected to the Pi 5 through the “RM520N-GL 5G HAT+” waveshare product, so there is a PCIe connection, and it is also possible to use the serial interface via minicom tool.

I will explain my scenario:
I have two of these devices (Pi 5 with RM520N-GL 5G HAT+), and my objective is to conduct experiments aimed at evaluating 5G performance, example, throughput for simplicity.
At my university, we have a testbed capable of assigning each 5G modem a private IP address, meaning all the devices will receive a “5G private IP address” from the eNB, so there is no problem of Public IP, its NAT and so on…

So, I need to understand whether there is a NAT inside the modem because, for example, to measure throughput, the system uses the iperf3 tool. For this to work, one device must act as a server (listening on port 1234), while another device acts as a client, sending messages to that port.

However, even if both devices have a private IP, if there is an internal NAT, I will encounter problems.
So, updatinf firmware can resolve this issue?

8

If the Quectel Module connect with the RPI through PCIe, it do no need the IPPT at all.
The module would work as the rmnet network interface.

image
image792×284 8.51 KB

Actually we would call the RPI5 as UE, and it is the UE set up data call.
But if you must need the IPPT. It means that
image
image832×280 10.1 KB

It is the AP side of the module set up the data call.

9

Thank you very much for the images and support.

Since running the driver provided by “Waveshare” enables the rmnet interface, it provides internet access to the UE.

Below, I am showing the output of my program that reads the IP and MAC address of the rmnet interface.

image
image1350×141 9.96 KB

Currently, I am in a scenario where my ISP does not provide me with a public IP address but a private one, as shown in the screenshot → 10.142.98.74.
I have tried enabling IPPT mode to obtain a public IP directly, but I realized that this is not allowed by my ISP.

However, I will soon travel for work to a lab where they have a 5G cell capable of providing private IP addresses without NAT. This means that two UEs connected to that cell will have addresses from the same network.
Now, I need to understand whether there is an internal NAT inside the modem that blocks incoming connections.

For example, if I run a server on UE1, can it receive packets sent from UE2?
As in the following scenario

10

10.142.98.74 is the public addres already from the carrier/ISP.
But normally it is not the real public IP address.
If you use two RM520N at the same time in the private network, it should be able to access each other at the same time.

1 Like
11

Ok, perfect.

In my previous message, I wasn’t able to attach the picture of my setup due to forum limitation of only one picture for message.
For this reason i’ve inserted two pictures in one otherwise also this message would be incompleted.

The “Picture 1” in red, is about my preovious message:

scenario
scenario771×666 43.1 KB

My doubt arises from the fact that, on both RM520GN modules, when running a tcpdump to observe the MAC addresses in use in the outgoint packets, I see the same source and destination MAC address specifically 02:50:f4:00:00:01 and this behaviour happens on both probes (both RM520GN). See tcpdump Picture 2.

This made me think of some sort of internal NAT within the modem itself, which could be hiding the IP address assigned by the carrier/ISP (whether private or public) and potentially blocking incoming connections to the probe (such as probe1 in the picture 1).

12

It is not NAT. You see the same MAC address 02:50:f4:00:00:01. it is because that rmnet_mhi0.1 is in RAWIP mode. We would not care about the mac address. The 02:50:f4:00:00:01 is just the virutal address to make the rmnet_mhi0.1 could work in the Linux environment.
If you try the dump the usbmon/pciemon log, you can find that the Modem and the Linux Host only transfer in RAWIP packet.

2 Likes