Cannot send MMS from "Yoigo"

current build number: 46
device name: krillin
channel: ubuntu-touch/ubuntu-rtm/14.09-proposed

Since this is a primary operator for Spain, marking Critical

I think I can reproduce this here. What I'm seeing here seems to be related to PIN locking. I put PIN locked SIM from one operator to slot 1 and not locked SIM from another operator to slot 2. I reboot the phone and run list-contexts. I see contexts set for slot2. I disable the PIN lock for slot1 and contexts change to settings of slot1. Contexts are not active however and running enable-gprs test script or activate-context scripts does not help. If I run the same case with SIM in slot 1 not locked, internet context is active as it should right when list-contexts is firstly run and activating the mms context works.

@Jussi

I'm not sure how this might affect MMS. The original description doesn't mention anything about locked SIMs.

You mention that when you disable the PIN lock for SIM 1, that list-contexts now shows you the contexts for SIM1 instead of SIM2. This could be because that's the default system setting ( ie. which SIM do you use for mobile data ), although that sounds wrong to me. Did you check the system settings to see which SIM was selected for mobile data? Also, the UI for this only appears if the system detects more than one SIM. Is the UI visible when you test the first scenario, and if so is SIM2 selected for data? If you can isolate this, it also might be worthwhile opening a new bug, unless you're able to prove that Victor is actually hitting this problem.

Instead of asking for specific logs and since this is a long running thing and ubuntu-bug isn't working well for the rtm images; I'm going to ask you to install network-test-session from https://launchpad.net/~phablet-team/+archive/ubuntu/testtools by either
- a wget dpkg -i on it should work.
- adding the sources list of the PPA to the rtm image is possible
   # echo "deb http://ppa.launchpad.net/phablet-team/testtools/ubuntu utopic main" > /etc/apt/sources.list.d/testools.list
   # apt-key adv --keyserver keyserver.ubuntu.com --recv-keys 5E51A24C
   # apt update
   # echo this next command brings in the location test deb, but we need the # echo latest package
   # apt install network-test-session
- reboot

And read
https://github.com/sergiusens/network-test-session/blob/master/README.md

Once your test session is done, please upload the tar it creates.

A quick note, once start returns, you can disconnect the phone and wander around, just don't reboot.

So nestled deep in the network-test-session log is the following error:

2014/09/26 23:07:04 Cannot Activate interface on %s: %s /ril_0/context2 org.ofono.Error.NotAttached: GPRS is not attached

So, I'm thinking this may be related to the Network Manager bug that describes mobile data connections not always being activated when FlightMode is toggled off. MMS only works when "mobile data" is enabled. When mobile data is enabled, NM is responsible for toggling the ConnectionManager's 'Powered' property, which is turn causes the 'Attached' property toggle to true. So even though in this case the MMS context is stand-alone, if NM hasn't toggled 'Powered', GRPS will never become attached.

On krillin, the modem initialization sequence takes longer than mako due to the dual SIM. Of note is the fact that the ConnectionManager interface is the last to get created, and there's a few seconds lag with the other interfaces. It's been discussed that this lag is what causes NM to miss setting the 'Powered' property. I will add a network-manager task to the bug.

Victor provided the log so setting this to confirmed. If you have all the information you need then set it to Triaged

Somehow my last comment explaining my updates to the bug went missing, so I'll try again...

Based on the network logs we reviewed, the phone is bouncing back and forth between Yoigo's network ( MCC=214 MNC=04 ) and the movistar ( MCC=214 MNC=07 ) network. This explains the occasional loss of mobile data, as unless "Data Roaming" is enabled, you will lose mobile data every time the phone roams to the movistar network. Further log analysis reveals that nuntium tries to send the MMS while roaming, which fails.

It turns out that Yoigo's network doesn't fully support UMTS and as such they have a roaming agreement with movistar to provide UMTS coverage. As we have no way to detect this, nor do we support a "national roaming" capability ( ie. allow data roaming only within the same country ), there's not much you can do other than enable "Data roaming", and be careful to disable if you leave the country. It also should be noted that if/when phones are sold in conjunction with Yoigo, that the phones are probably customized to be aware of this roaming arrangement. I will enter ofono wishlist bugs for both of these and will link to this bug.

I've assigned a nuntium task to Sergio as he's working on adding retry logic to nuntium, and also a messaging-app task to Tiago, as the messaging-app should have reported an error when the send failed.

@Victor - when you lose mobile data connectivity, does it ever come back, or do you need to reboot? If the latter, then could you open a new network-manager bug for that specific problem?

I created bug #1376375 to track the lack of a roaming agreement customization feature in ofono.

The nuntium task will only alleviate activating the context if it is at all possible; but given the network stability, it can still fail.

@Víctor, @Tony:

Regarding roaming, there are already mechanisms that check the content of SIM files and the registered network that should prevent the registration state to be roaming, even in these cases when we bounce between different networks.

Víctor, could you please check if you see a roaming indicator on the screen at any time? If that is the case, then that is an ofono bug. Otherwise, my best bet here is NetworkManager not trying to attach to the data network after a network change, as Tony has suggested above.

I have just noticed that the output of monitor-ofono is part of the logs, and I see that network status actually gets into roaming state. But, it is in very short time windows:

2014-09-26 20:11:18,643 {NetworkRegistration} [/ril_0] Status = roaming
2014-09-26 20:11:19,323 {NetworkRegistration} [/ril_0] Status = registered
...
2014-09-26 20:16:31,743 {NetworkRegistration} [/ril_0] Status = roaming
2014-09-26 20:16:31,803 {NetworkRegistration} [/ril_0] Status = registered
...
2014-09-26 22:03:43,743 {NetworkRegistration} [/ril_0] Status = roaming
2014-09-26 22:03:43,779 {NetworkRegistration} [/ril_0] Status = registered
...
2014-09-26 22:10:58,077 {NetworkRegistration} [/ril_0] Status = roaming
2014-09-26 22:10:58,104 {NetworkRegistration} [/ril_0] Status = registered
...
2014-09-26 22:18:20,377 {NetworkRegistration} [/ril_0] Status = roaming
2014-09-26 22:18:20,411 {NetworkRegistration} [/ril_0] Status = registered
...
2014-09-26 22:26:05,503 {NetworkRegistration} [/ril_0] Status = roaming
2014-09-26 22:26:05,535 {NetworkRegistration} [/ril_0] Status = registered
...
2014-09-26 22:34:39,565 {NetworkRegistration} [/ril_0] Status = roaming
2014-09-26 22:34:39,598 {NetworkRegistration} [/ril_0] Status = registered
...
2014-09-26 22:53:31,359 {NetworkRegistration} [/ril_0] Status = roaming
2014-09-26 22:53:31,398 {NetworkRegistration} [/ril_0] Status = registered
...
2014-09-26 23:00:20,671 {NetworkRegistration} [/ril_0] Status = roaming
2014-09-26 23:00:20,732 {NetworkRegistration} [/ril_0] Status = registered
...
2014-09-26 23:07:00,161 {NetworkRegistration} [/ril_0] Status = roaming
2014-09-26 23:07:00,185 {NetworkRegistration} [/ril_0] Status = registered

This does not really affect the reasoning above, imho the main problem here is NetworkManager not attaching after coming back to registered state. However, these "Status" flash changes can be annoying and the user could potentially see a flickering roaming indicator in the GUI. I would like to get more traces for this, Víctor, could it be possible to do this:

$ phablet-shell
$ sudo su
# stop ofono
# export OFONO_RIL_DEVICE=mtk OFONO_RIL_NUM_SIM_SLOTS=2
# export OFONO_RIL_HEX_TRACE="" export OFONO_RIL_TRACE=""
# ofonod -n -d -P stktest,provision,sap,udev,dun,smart,hfp >& /tmp/ofono_log.txt &
# python3 -u /usr/share/ofono/scripts/monitor-ofono &> /tmp/monitor-ofono.txt &

walk around so the phone switches networks, and then attach the logs here?

Having understood a bit more the nature of this bug, I'd still like to be critical.

This bug was fixed in the package nuntium - 0.1+14.10.20141002-0ubuntu1

---------------
nuntium (0.1+14.10.20141002-0ubuntu1) 14.09; urgency=low

  [ Sergio Schvezov ]
  * Allow context selection over the org.ofono.mms.Service interface
    (LP: #1370660)
  * Syncing upload/download operations with activation/deactivation per
    request. Moving all the ofono context property checks and reflection
    logic to proper functions for easier reuse and readability. (LP:
    #1376224)
  * Retry on NotAttached ofono errors (LP: #1371032)
 -- Ubuntu daily release <email address hidden> Thu, 02 Oct 2014 15:06:31 +0000

LP bug #1377148 has been reported to follow the -different from this one- bug of the flickering roaming status.

@Victor

Can you re-test and confirm whether or not you see errors reported in the messaging-app when a MMS send fails? We've released a fix for nuntium to retry, and after discussing with Tiago he suggested a re-test as the messaging-app has changed quite a bit since this bug was first reported.

current build number: 85
device name: krillin
channel: ubuntu-touch/ubuntu-rtm/14.09-proposed

wrt comment #9 what is the scenario?

Seems you could tx and rx, at least from the logs; tx:
2014/10/06 23:17:02 Status changed for /org/ofono/mms/214040100434425/a275ec5be93f61f4b3e13124cfb24e21 to Sent

and rx:
2014/10/06 23:18:40 Created /home/phablet/.cache/nuntium/store/0bc39c22524ac5e6e7cc4dbea90e2dfc.m-notifyresp.ind to handle m-notifyresp.ind for 0bc39c22524ac5e6e7cc4dbea90e2dfc

Is there something missing in the messaging app or any particular thing to notice from what Tiago requested?

I received the MMS to Yoigo, but couldn't send from it (at least the
message didn't arrive to my other phone).

The requested logs me trying to send mms to my Z10 phone, was never received (i've never received any mms there so tbh may be a Z10 fault)

On Tuesday, October 7, 2014, Víctor R. Ruiz <email address hidden>
wrote:
> I received the MMS to Yoigo, but couldn't send from it (at least the
> message didn't arrive to my other phone).

Oh, that is not the fault of nuntium or our stack. The carrier replied an
OK for the send request.

Does it take long when sent from a different OS?

Delivery in any case depends on many things.

>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1371032
>
> Title:
> Cannot send MMS from "Yoigo"
>
> To manage notifications about this bug go to:
>
https://bugs.launchpad.net/ubuntu/+source/messaging-app/+bug/1371032/+subscriptions
>

I have procured a yoigo SIM and I can now test this