Great discovery of the parameter in the MBN that causes this problem. I can confirm just using AT$QCPRFMOD=PID:1,OVRRIDEHOPDP:“IP” allows UDP to work better but it is not a perfect solution. A Wiregard VPN which uses UDP now works but there are errors in the log indicating problems with the connection. Also, I can confirm the IP addres assigned by T-Mobile is in a different subnet with a geolocation a further distance from my actual location than with the OVRRIDEHOPDP:“IPV6” setting in MBN file.
I agree with @hazarjast that this issue impacts many people using this module with T-Mobile and we request a better fix to this UDP issue.
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.
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.
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
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?
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.
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.
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 184.108.40.206 and compile quectel ConnectionManager if possible.