[maguro] Query CLIR SS returns unexpected values
Bug #1263229 reported by
Tony Espy
This bug affects 1 person
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
ofono (Ubuntu) |
Incomplete
|
Low
|
Alfonso Sanchez-Beato |
Bug Description
This bug is being reported against our upstream github branch, as USSD + SS support was just merged.
When running test case 2 in the USSD Supplementary Provisioning section, I noticed that the status reported both after the activation and subsequent interrogation both showed "enabled" instead of "disabled".
This works properly on mako.
Changed in ofono (Ubuntu): | |
status: | New → Confirmed |
importance: | Undecided → High |
assignee: | nobody → Alfonso Sanchez-Beato (alfonsosanchezbeato) |
To post a comment you must log in.
It looks like the logic for this SS is really messed up in some modems. Network-wise, what I see is:
mako:
test-ss "*31#" -> No line number shown in called phone. Shown status is "disabled".
test-ss "#31#" -> Line number shown in called phone. Shown status is "enabled".
maguro:
test-ss "*31#" -> Line number shown in called phone. Shown status is "enabled".
test-ss "#31#" -> No line number shown in called phone. Shown status is "enabled".
In both cases, RIL_REQUEST_ SET_CLIR is the same for the same string (*31# or #31#). SIM card is the same.
RIL_REQUEST_ GET_CLIR returns:
mako:
After (test-ss "*31#"): {2,4}
After (test-ss "#31#"): {1,4}
maguro:
After (test-ss "*31#"): {2,3}
After (test-ss "#31#"): {1,4}
The reason for the different status displayed is because of the interpretation that is done by the second integer in core ofono call_settings.c:
case CLIR_STATUS_ TEMPORARY_ RESTRICTED: // 3 OPTION_ SUPPRESSION) // 2
if (override == OFONO_CLIR_
value = "enabled";
else
value = "disabled";
break;
case CLIR_STATUS_ TEMPORARY_ ALLOWED: // 4 OPTION_ INVOCATION) // 1
if (override == OFONO_CLIR_
value = "enabled";
else
value = "disabled";
break;
The values returned by maguro do not really match this.
To complicate things more, ofono core uses inverse logic when activating/ deactivating this SS. For control type SS_CONTROL_ TYPE_ACTIVATION , it calls clir_set( OFONO_CLIR_ OPTION_ SUPPRESSION) , and for SS_CONTROL_ TYPE_DEACTIVATI ON it calls clir_set( OFONO_CLIR_ OPTION_ INVOCATION) . I do not think this is right, but it certainly matches maguro's behaviour, but not mako's (that is the reason for having the # command activating the SS instead of the * command, which seems to be the right thing looking at the standards).
So, my conclusion is that not all modems behave the right way regarding this SS and somewhat the messy ofono core code proves this. To get this right in both mako and maguro, we need different implementations, or detect the modem type and behave accordingly.