Cannot send/receive MMS while connected to Wi-Fi - Nuntium can't connect to MMSC on the correct interface
In order to send and receive an MMS, the MMS daemon (in our case, Nuntium) will have to contact the MessageCenter (MMSC) or MessageProxy over cellular data (more specifically, over a specific APN). If, at the moment, the phone is also connected to Wi-Fi, some mechanism has to make sure the connection from Nuntium goes over cellular data and not Wi-Fi. Otherwise, MMSC won't be able to figure out who is sending or receving.
Upstream oFono [1] solves this problem by setting up an IP route for a specific address to go over the interface MMS APN is using. The problem is that:
1.) it only happens for MessageProxy, not MMSC. Carriers are not required to use MessageProxy, and can just have MMSC. 2.) Even if oFono cares about a route to MMSC, carriers can specify MMSC in terms of domain name, not IP. oFono would have to also do DNS query to set the route correctly.
Canonical's fork of oFono solves both problems [2]. If MessageProxy isn't set, it'll look at MMSC. And if MMSC is a domain name, it'll look up its IP address. However, the patch is pretty big and I'm not sure how well it'll apply into Sailfish's fork. I'm also don't understand the code fully.
Sailfish's fork seems to care a bit about missing MessageProxy [3]. However, I don't think it cares to resolve the domain name to IP. So, if carriers specify MMSC as a domain name, it won't help.
I've considered making Nuntium do the "interface selection" itself. This seems to not be feasible.
-
SO_BINDTODEVICE
requiresCAP_NET_RAW
(until recent Linux kernel version???), something I don't think Nuntium warrants it... - Alternatively, using
bind()
to the interface address doesn't work either. Packets will have the source IP of that address, but will still be sent over the default route's interface. That will very much confuses the router that receive that packets, and the connection won't work.
So... yeah. I'm not sure what's the best approach here.
[1] At least the version we're using. I haven't checked what oFono 2.x do yet. Also, yes, oFono 2.x is out. What are we doing?!?!
[2] https://github.com/rilmodem/ofono/pull/194
[3] https://github.com/sailfishos/ofono/commit/500b5234b2c90ed499a167c41457cadca7a34a57