To: @rbunch , @Peter.Zhu-Q, @Isaac.Wang-Q
I have completed additional testing this week and narrowed down the issue to the “Commercial-TMO” MBN profile. Something in this profile is broken (intentionally by the carrier or otherwise maybe due to bug) which is causing UDP traffic to fail shortly after cell attach when the end client is Windows 10 based. When switching to the generic MBN profile, UDP passes unmolested over IPv4 (and I assume IPv6 but I only ever had issues with IPv4 UDP, thus my only test case at present).
What is extremely curious is that if I switch back to the “Commerical-TMO” profile, remove power from the modem, power it back up again and immediately test IPv4 UDP traffic it passes successfully for some minutes before failing. I do not want to assume malicious intent by the carrier but this certainly seems like some fingerprint or heuristic profile is being set when attempting to pass UDP traffic on the carrier end. Else, maybe there is just some legitimate bug in the carrier MBN profile which only appears after passing some quantity of UDP traffic.
Regardless, the workaround for RM502Q-AE at this time appears to be selecting the generic MBN (which I will detail below). Unfortunately it has one troublesome side effect of getting assigned an exit node from the carrier APN which is not appropriately geolocated. While the “Commercial-TMO” MBN always routed me out of an address geolocated within 50 miles of my physical location (with some minor variance on exact location), the generic MBN only seems to route me out of Denver, Colorado or Chicago, Illinois (USA). This is undesirable as it raises my latency (ping) quite considerably vs. routing through a properly geolocated IP.
The commands to switch to the generic MBN profile are below:
Given that the “Commercial-TMO” profile exists in the first place, I would assume Quectel has some sort of partnership with T-Mobile USA. If Quectel itself cannot find and resolve the UDP issue as related to the carrier MBN, I would humbly (but strongly) suggest that Quectel engage their appropriate channel partner contact within T-Mobile to sort out the issue which is dropping UDP traffic.
Due to +QMBNCFG default behavior of “AutoSel” anyone developing a product for use on T-Mobile will likely encounter this hard to diagnose issue and may reconsider use of the RM502Q-AE unless they happen to stumble upon this thread and accept the degraded latency offered by switching MBN profile to generic. I have accepted this limitation for my project but others with latency dependent requirements may not.
Thank you for your continued support.