This is the same issue as reported in bug 5337.

*** This bug has been marked as a duplicate of bug 5357 ***

Comment 2 Valério Valério 2009-10-13 17:03:44 UTC

(In reply to comment #1)
> This is the same issue as reported in bug 5337.
> 
> *** This bug has been marked as a duplicate of bug 5357 ***
> 

What ? #5337 is about the GPS lock without a SIM card.

Anyway this is a very important issue, because almost all carriers use these
codes for diverse proposes, like getting the remaining credit, credit bonus,
etc...

Sorry, typo :-(  The second link (bug 5357) was the correct one.

*** This bug has been marked as a duplicate of bug 5357 ***

(In reply to comment #3)
> Sorry, typo :-(  The second link (bug 5357) was the correct one.
> 
> *** This bug has been marked as a duplicate of bug 5357 ***
> 

Please re-open, this is NOT a duplicate of 5357.
See comments on SS versus USSD.
https://bugs.maemo.org/show_bug.cgi?id=5357#c42

It could also act as a workaround for poor divertion options.

Sure, let's keep this one open for SS (and feel free to suggest a better
summary).

*** This bug has been confirmed by popular vote. ***

Comment 7 Lassi Syrjälä 2009-12-30 00:49:56 UTC

Here's what we support from TS 22.030:

2009.42: *31# and #31# for temporary CLIR control
2009.51: the above and *#06# for IMEI (+ Nokia-specific *#0000# for SW version)

A later update will bring full USSD support (covering e.g. the said *#1345#;
bug 5357), but it seems that Maemo 5 will not _officially_ support other MMI
codes.

There will likely be some trick[*] to enable experimental support for more
codes, though. With the exception of abbreviated dialing (N(N)(N)#) and the
short codes for call control (e.g. 2 + send to hold/swap), everything that the
modem supports should work. There's however no proper QA nor localization for
those and hence no guarantees that things work on all commercial networks out
there.

[*] Probably a nice little tool called Tweakr can be used to enable the feature

Comment 8 Lassi Syrjälä 2009-12-30 00:54:54 UTC

(In reply to comment #7)
> A later update will bring full USSD support (covering e.g. the said *#1345#;
> bug 5357), but it seems that Maemo 5 will not _officially_ support other MMI
> codes.

And this is other MMI codes from TS 22.030 specifically. Everything that's
*not* mentioned there (and not a phone number, obviously) is sent as USSD.

Comment 9 Andre Klapper 2010-01-14 12:28:12 UTC

The problem reported here should be fixed in the update released today for
public: The Maemo5 update version 2.2009.51-1 (also called "PR1.1" sometimes).
Please leave a comment if the problem is not fixed for you in this update
version.

*101# to check my amount of money in my prepaid doesn't work

Comment 11 Andre Klapper 2010-01-14 13:48:27 UTC

(In reply to comment #10)
> *101# to check my amount of money in my prepaid doesn't work

Totally different issue - see bug 5357.

(In reply to comment #9)
> The problem reported here should be fixed in the update released today for
> public: The Maemo5 update version 2.2009.51-1 (also called "PR1.1" sometimes).
> Please leave a comment if the problem is not fixed for you in this update
> version.

Wrong implementation of MMI.
The terminal character is the <SEND> (aka CALL) button, not the # as now
wrongly implemented. Type *#06# and you will be presented the IMSI before you
have a chance to push send button. Same goes for *#0000#.

Please re-open ticket.
How could "Dialer does not accept SS (3GPP TS 22.030) dial strings" which
includes MMI support and 22.004 functionality be FIXED with 2 codes that don't
even involve network interrogation.

(In reply to comment #7)
> Here's what we support from TS 22.030:

appreciate the tweakr "hope", but not relevant to 22.030:

"The supplementary services shall be controlled in accordance with the
procedures described below. All User Equipment with MMI shall be able to be
controlled in this way, to minimize the confusion of users using different
types of User Equipment...."

Comment 15 Lassi Syrjälä 2010-01-18 14:26:45 UTC

(In reply to comment #12)
> Wrong implementation of MMI.

May I suggest you refrain from such statements before you have carefully read
the spec. Thank you.

*#06# and generally any procedure without network interaction does not require
SEND. Also, feel free to cross-check this with any other handset correctly
implementing MMI.

(In reply to comment #13)
> How could "Dialer does not accept SS (3GPP TS 22.030) dial strings" which
> includes MMI support and 22.004 functionality be FIXED with 2 codes that don't
> even involve network interrogation.

I believe it was set to FIXED because it's no longer reproducible with the
steps from the initial report. I agree it's not fixed the way you'd like it to
be, but this is a confusing topic for those not familiar with TS 22.030...

(In reply to comment #14)
> "The supplementary services shall be controlled in accordance with the
> procedures described below. All User Equipment with MMI shall be able to be
> controlled in this way, to minimize the confusion of users using different
> types of User Equipment...."

This is true, and to minimize the confusion we left the whole MMI out of Maemo5
initially. Which may have been an oversight as there seem to be more MMI
(especially USSD) users out there than we perhaps anticipated.

(In reply to comment #15)
> (In reply to comment #12)
> > Wrong implementation of MMI.
> 
> May I suggest you refrain from such statements before you have carefully read
> the spec. Thank you.
> 
> *#06# and generally any procedure without network interaction does not require
> SEND. Also, feel free to cross-check this with any other handset correctly
> implementing MMI.

My bad, sorry. But after reading through a number of 3GPP's I did confuse a
few.

> (In reply to comment #13)
> 
> I believe it was set to FIXED because it's no longer reproducible with the
> steps from the initial report. I agree it's not fixed the way you'd like it to
> be, but this is a confusing topic for those not familiar with TS 22.030...

It's not what I want, it's about what this ticket and other tickets are about.
See "other comment" on this ticket, or the sister ticket with >100 comments BUG
5357. There are dozens of duplicates for the USSD bug, where certainly a number
of people used USSD as an abbreviation for all "*#" (incl. SS) commands ....
It's exactly that 22.030 confusion. (ussd, ss, sim, vendor procedures
nightmare)

The title says SS dialstrings from 3GPP TS 22.030.
Ok, description picked a bad example and the comment also includes USSD.
Formally wrong, but exactly describing what the users are thinking, since they
don't care that much about 3gpp specs, but those "*#" things to work as in the
last 10 years.

If the description said correctly #21# would would it also be fixed resolved ?
This ticket here has been mentioned in the changelogs with it's title, so
everybody thinks SS are supported via MMI now.

> (In reply to comment #14)
> > "The supplementary services shall be controlled in accordance with the
> > procedures described below. All User Equipment with MMI shall be able to be
> > controlled in this way, to minimize the confusion of users using different
> > types of User Equipment...."
> 
> This is true, and to minimize the confusion we left the whole MMI out of Maemo5
> initially. Which may have been an oversight as there seem to be more MMI
> (especially USSD) users out there than we perhaps anticipated.

Understood and thanks for explanation. 
So what's the way forward ?
Keeping it closed and issuing a seperate ticket for every SS procedure in TS
22.004 ? 
Getting the same bug in again with a correct example ?
Changing to notfixed ? 

Sorry for the lengthy response in a bugtracker but I've seen a lot of issues in
this *# area. Would be a shame to loose those n900 users on that.

Verifying for PR1.1 now showing IMEI

"STEPS TO REPRODUCE THE PROBLEM:
dial *#06#

EXPECTED OUTCOME:
reports IMEI"