search

ubports / ubuntu-touch

Ubuntu Touch's issue inbox is now migrated to GitLab.
https://gitlab.com/ubports/ubuntu-touch
1.28k stars 110 forks source link

MMS drops on wifi, plunged in to the darkness. #1753

Open Openanonwriter opened 3 years ago

Openanonwriter commented 3 years ago

Pixel 3a drops MMS if you are on wifi.

Steps to reproduce

  1. While on Wifi, receive MMS.

Expected behavior

  1. Receive MMS while on wifi.

Actual behavior

MMS will fail to retrieve and is lost in the darkness forever.

Logfiles and additional information

What logs do you need?

fredldotme commented 3 years ago

We need to figure out why the MMS fetching isn't done through the rmnet interface. The ip route is set up correctly at first glance, so this is worrying me a little.

YepYepperson commented 2 years ago

I just got a Pixel 3a XL, and have been having this issue. I'm on the stable OTA-22. I'm using Red Pocket Mobile (US) with GSMT (T-Mobile MVNO). The help page for my carrier lists the APN as being http://wholesale.mmsmvno.com/mms/wapenc, and it works correctly when only cellular data is turned on.

When Wi-Fi and cellular data are both on, I see the routing table gives the Wi-Fi's default gateway a metric of 600, and the cellular's default gateway a metric of 700, which means Wi-Fi is the preferred route. If I do a packet capture with tcpdump while sending an MMS, I see that it uses the Wi-Fi connection, and the MMS fails. If I modify my routing table to give the cellular connection a lower metric than Wi-Fi, the MMS then goes out cellular and succeeds.

I had read on some blog that Android will often push MMS out cellular by temporarily making it the default gateway, and was curious if UT tried to do something like this, so I wrote a little bash while loop to spam the ip route command (after resetting my routing table back to normal and having both Wi-Fi and cellular turned on), and then tried sending an MMS, and I never saw the routing table change during the attempt to send the MMS. Am I correct in assuming this isn't something that oFono/telephony-service/all the other various components automatically do?

Though, maybe changing the routing table isn't how it's supposed to be done? Maybe one of the other components is able to just push connections out the rmnet_data0 link without affecting the kernel's routing table?

If anyone has any ideas or anything I can help test with, I'm very much interested in making progress with this. Thanks.