Thank you for the reply. Even when setting PDP to IPV6 only on the TMO MBN and pinging an IPV6 address for Google.com I am seeing ~70-85% ICMP packet loss along with regular latency spikes (100ms+) on both “fast” and “fast.t-mobile.com” APNs which are not observed when using the Generic MBN. Given these data points it seems the issue may be in the firmware as you have suggested. Discussing this matter with other developers using T-Mobile they are not seeing this issue on other 5G modems (ex. Sierra EM9191) so that could be further evidence of some issue in the Quectel firmware.
You have indicated that “more testing would be required” to eliminate this issue. I hope that this testing is already underway by Quectel engineers utilizing the T-Mobile network. If there is some additional testing or outputs I can provide from my end, please let me know and I will do my best to accommodate.
Thank you for your support.
You could do some testing for comparison:
- Setting IP type to IPV6 only on Sierra EM9191 and test the ICMP, and check the packet loss
- Setting IP type to IPV4 only on Sierra EM9191 and test the ICMP, and check the packet loss
- In RM502Q, disable CLAT and use IPV6 protocol, in host side, to make IPV6 data call ,and then test ICMP.
From testing above, we may point issue to T-Mobile IPV6 PDN context issue or IPV6 protocol issue in RM502Q-AE.
Btw, while CLAT and IPV6 only are both used, the IP address in host side will be 192.0.0.2, you could also check whether there is route table conlicting with this IP.
1 Like
For test #1 and #2 I have reached out to the developers I spoke with who have access to an EM9191 for them to test. I do not have one myself. @rbunch maybe you have one to perform these tests with as well?
For test #3 your criteria for testing as per your explanation underneath is not clear. You first indicate to disable CLAT and use IPV6 PDP; then you mention IP address on host side will be 192.0.0.2 when CLAT and IPV6 only are used. How can this be? If PDP is set to IPV6 only then there will be no IPV4 address assigned to the interface at all.
Given your reference to IPV4 address, I broke your test #3 into four test scenarios for completeness. See below for the results:
- T-Mobile MBN, CLAT ENABLED, PDP IPV4V6: Significant packet loss
- T-Mobile MBN, CLAT DISABLED, PDP IPV4V6: No packet loss
- T-Mobile MBN, CLAT ENABLED, PDP IPV6: No packet loss
- T-Mobile MBN, CLAT DISABLED, PDP IPV6: No packet loss
Screenshots below for your reference:
@WillieYao-Q ,
The other developers got back with me and confirmed they have no packet loss issues with any PDP setting on the EM9191 on T-Mobile:
IPv4
IPv6, IPv4v6
@WillieYao-Q @Peter.Zhu-Q @Isaac.Wang-Q,
Any updates on your internal testing of this issue?
Thank you.
Hazar, Sorry that I was blocked in field support in past few days.
I tried IPV6+xlat vs. IPV6 only with the same firmware RM502QAEAAR11A04M4G_01.003.01.003, the ping performance looks no big difference.
IPV6 only + xlat enabled
IPV6 only + no xlat:
May be you could try the latest QMI driver and Quectel connection manager tool?
Best Regards,
Thank you for the reply. Can you please confirm which MBN is selected during your tests and which QCPRFMOD settings you are using? I am already running the latest QMI driver. On my platform it is not possible for me to test Quectel connection manager directly at the moment due to some toolchain cross-compile issues. Is there something special about Quectel’s connection manager in regards XLAT/CLAT which I should be aware of?
Thank you for your support.
The chosen MBn is following:
“Commercial-TMO”,0x0A01050F,202110121
And the command QCPRFMOD is the default setting “IPV6”
AT$QCPRFMOD=PID:1,OVRRIDEHOPDP:“IPV6”
Also, there is no special about Quectel connection manager in regars XLAT/CLAT since xlat in done in modem side.
1 Like
Could there be special about IP traffics which starts with 192.x.x.x in host side? Are there any other route table incudes 192.168.x.x?
Also attach the iperf testing for both IPV6 only and IPV6&XLAT for your reference:
IPV6 + xlat:
IPV6 only + no xlat:
I am not sure what you mean by “Could there be special about IP traffics which starts with 192.x.x.x in host side?” Can you be more specific as to what problem you believe this would introduce? Yes, my LAN IPv4 is in range of 192.168.x.x but I’m not sure why this would impede only ICMP and UDP traffic flow.
Thank you for your support.
I’m suspecting that the LAN IP route table might affect the IP range 192.0.0.2. But I’m not sure. May be you could try to login LinuxOS via serial port and remove LAN interface(down the LAN interface and deltete the LAN ip table in route table), then try ping again.
I changed the LAN to use 10.x.x.x but the ping result is the same so I think there is no conflict in the routing table to blame. Any other ideas to try?
Thank you for your support.
You’re welcome. But currently I have no idea since it works in my setup. Different host may have different behaviors, to further debug we may need the same testing setup. You could try to install latest QMI driver 1.2.0.22 and compile quectel ConnectionManager if possible.
Best Regards,
