Confirming, it seems that anything starting with "*" is rejected by the UI. 
Also resetting severity and priority to defaults.

(In reply to comment #1)
> Confirming, it seems that anything starting with "*" is rejected by the UI. 

also # in the beginning isn't accepted. I think what a good and what a bad
number is should be decided by the network, not the phone..

> Also resetting severity and priority to defaults.
sorry for changing them. I just read the howto and won't touch them in the
future so unthought again

*** Bug 5380 has been marked as a duplicate of this bug. ***

Destinations starting with * or # are accepted by the UI for SIP and XMPP cals.

*** Bug 5380 has been marked as a duplicate of this bug. ***

Comment 6 Andre Klapper 2009-10-13 20:57:40 UTC

Heh, I had a bet three weeks ago that this will get 20 dups....

*# codes were never defined as a requirement for this release.
According to the internal ticket this is planned for later on.

Feel free to vote.

why is this seen as an enhancement and not a bug? 
It's not a rhetorical question, I am curios why other people consider this as
not important.

Comment 8 Valério Valério 2009-10-14 00:41:11 UTC

(In reply to comment #7)
> why is this seen as an enhancement and not a bug? 
> It's not a rhetorical question, I am curios why other people consider this as
> not important. 
> 

As a example, in some cheap carriers in Portugal, the only way to consult the
remaining credit is through these codes. I bet this happens in other carriers
at least in Europe

(In reply to comment #7)
> why is this seen as an enhancement and not a bug? 

Mainly since:

(comment #6)
> *# codes were never defined as a requirement for this release.

Doesn't mean this isn't an important omission, and votes can help illustrate
that.

*** Bug 5547 has been marked as a duplicate of this bug. ***

*** Bug 5644 has been marked as a duplicate of this bug. ***

Comment 12 Andre Klapper 2009-11-05 18:05:05 UTC

*** Bug 6044 has been marked as a duplicate of this bug. ***

*** Bug 6084 has been marked as a duplicate of this bug. ***

Comment 14 Naba Kumar 2009-11-14 01:29:52 UTC

We are aware of missing USSD support, we plan to do it in some release update.

IMHO it would be nice to add this feature to this flagship device. USSD is part
of the GSM standard:

Quote from
http://en.wikipedia.org/wiki/Unstructured_Supplementary_Service_Data:
================================================================================
USSD Phase 1, specified in GSM 02.90, only supports mobile initiated operation
(pull operation). In the core network the message is delivered over MAP. USSD
Phase 2, specified in GSM 03.90, supports network-initiated operation (pulls
and push operation).
================================================================================

Yves DESSERTINE

I think that this should be treated as a major bug, because "#" is often used,
for essential operations.

Eg: in italy the bis service, from vodafone (twin SIMs) is managed via SAT or
via USSD string.

SAT is absent USSD doesn't works, so is essential to fix this bug.

Here -- http://juick.com/Unatine/394204 (beware, Russian-only) -- people were
able to get USSD working in 1.2009.42-11 by directly communicating with a
modem:

ATZ
OK
AT+CUSD=1,"*102#",15
+CUSD: 0,"04110430043B0430043D0441003A0020003900310032002E003600320440002E",72

OK

Then
$ echo "04110430043B0430043D0441003A0020003900310032002E003600320440002E" |
echo -n -e $(tr -d '[:space:]' | sed 's/../\\x&/g') | iconv -f UCS-2BE -t UTF8
Баланс: 912.62р.

What it shows that it is possible to run USSD commands on 1.2009.42-11 even
though it is not yet user-friendly. Quite a UNIX way though.

PAYG customers in the UK will be unable to quickly check their balance if *# is
not implemented.

For examples the following are used to check balance for PAYG in the UK and
other countries where I travelled to (using their local sim).

*#10#
*#101#
*#100#

For contract customers, they can quickly check their monthly usage, bill date
and recent charges.

I would consider this as a high priority fix.

Comment 19 Mikhail Zabaluev 2009-11-30 13:51:56 UTC

*** Bug 6454 has been marked as a duplicate of this bug. ***

Comment 20 Andre Klapper 2009-11-30 15:02:28 UTC

*** Bug 6439 has been marked as a duplicate of this bug. ***

Major issue in US w/T-Mobile as well. How to set, change, activate, deactivate
conditional call forwarding and many other critical functions. This
unquestionably is a major bug that needs to be fixed very quickly. Not allowing
any number regardless of what the device thinks is valid is incomprehensible
and have never seen something like this in any phone.

(In reply to comment #21)
> Major issue in US w/T-Mobile as well. How to set, change, activate, deactivate
> conditional call forwarding and many other critical functions. This
> unquestionably is a major bug that needs to be fixed very quickly. Not allowing
> any number regardless of what the device thinks is valid is incomprehensible
> and have never seen something like this in any phone.
> 
Conditional call forwarding is able to set up under Settings->Phone IIRC. If
you don't see that right away, scroll it down a little bit. It is not really
flexible, but fits most needs and is better than nothing.

I confirm, * # does not work.

N900
version 1.2009.42-11
RX-51

Sure - appreciate it, but that much I know, but you can't use any other MMI
codes such as check status, change ring time, or set a different number
depending on the condition (well, aside from hassling with putting the SIM into
another phone - not very handy as often as I change these and usually
individually). I also don't like only 20-seconds, which is the other variable I
change to 30. Similar, but different (and hopefully not a 'feature'), but where
is unconditional call forwarding? I use that regularly and if can't be set in
the phone settings, people should be able to do it this way.

I won't bother with the various codes I use periodically, but this was simply
one I discovered when I went to check current status, then tried a few other
MMI codes.

Not to mention how much quicker it is.

I apologize, I know this is a bit venty as was my posting, but I'm already
being very patient for some updates and adds to a pretty bare featured device
that I expected a bit more out of and this issue is as basic, 101 as you get
with a GSM device.

Comment 25 Naba Kumar 2009-12-02 13:21:38 UTC

Hi everyone, we know the significance of this feature. It's planned to 
released in an update later. Please have patience; it will be eventually there
:)

Comment 26 Mikhail Zabaluev 2009-12-02 14:08:57 UTC

We got news from our secret underground bunker lab that the implementation is
on its way.

(In reply to comment #25)
> Hi everyone, we know the significance of this feature. It's planned to 
> released in an update later. Please have patience; it will be eventually there
> :)

Comment #17 mentions a link which includes the following:

dbus-send --system --dest=com.nokia.csd.Call --type=method_call --print-reply
/com/nokia/csd/call com.nokia.csd.Call.CreateWith string:"$1" uint32:0

It is meant to be called from a shell script, so $1 is the number to dial. This
bypasses the interface restriction meaning you can make voice calls to numbers
with *#.

Is there a similar dbus method call that we can use as a temporary workaround
for non-voice calls, i.e. where the phone prints the response on the screen
(balance, etc.)? I am assuming that the response would be instead printed to
the terminal as a result of the dbus-send command.

Brilliant, thanks.!

(In reply to comment #27)
> (In reply to comment #25)
> > Hi everyone, we know the significance of this feature. It's planned to 
> > released in an update later. Please have patience; it will be eventually there
> > :)
> 
> Comment #17 mentions a link which includes the following:
> 
> dbus-send --system --dest=com.nokia.csd.Call --type=method_call --print-reply
> /com/nokia/csd/call com.nokia.csd.Call.CreateWith string:"$1" uint32:0
> 
> It is meant to be called from a shell script, so $1 is the number to dial. This
> bypasses the interface restriction meaning you can make voice calls to numbers
> with *#.
No, this script still does not help in initiating calls to *#. This is just a
script to initiate a call.

You'd need to directly communicate with a modem with commands mentioned in
comment #17 to get USSD responses. A person at that link did it with PC
connected to N900 as a modem.

Comment 30 Lassi Syrjälä 2009-12-02 16:11:00 UTC

> No, this script still does not help in initiating calls to *#. This is just a
> script to initiate a call.

Yes, it will make a call request, and the network will tell you the same thing
that the UI already does (Invalid number, number not in use, or similar).
Besides talking directly to the modem, there's no way to set up a USSD session
yet.

Comment 31 Lassi Syrjälä 2009-12-02 16:29:23 UTC

I.e. the UI does not prevent you from calling any valid number but it does
prevent making call requests with SS and USSD codes.

Thus, "Incorrect number" in this case should be interpreted as "Not a callable
number".

WTF!!!!!!!!!!!!!!

Comment 33 Andre Klapper 2009-12-03 23:41:27 UTC

(In reply to comment #32)
> WTF!!!!!!!!!!!!!!

Do not post completely useless comments, otherwise your account will be
disabled.
This is a technical bugtracker, not a forum. Thanks.

Comment 34 Quim Gil 2009-12-07 09:38:41 UTC

This is being handled as a bug by the Fremantle program.

(In reply to comment #34)
> This is being handled as a bug by the Fremantle program.
> 

Do you expect it to be taken care of in the next firmware release?

Thank you.

Comment 36 Andre Klapper 2009-12-07 16:09:23 UTC

(In reply to comment #35)
> Do you expect it to be taken care of in the next firmware release?

Too early to say.
Also, Nokia does not announce release dates of updates in advance.

got the same problem with my n900, is there any solution for this?

Comment 38 Andre Klapper 2009-12-07 22:42:00 UTC

(In reply to comment #37)
> got the same problem with my n900, is there any solution for this?

It's all clearly written in this report, but adding more comments makes it
harder to quickly find the useful information of course... ;-)
General info: Bugzilla is not a forum.

Comment 17 provides an extremely hackish solution. No other solution is listed
here. Apart from that, the bug report is still "ASSIGNED" and not "FIXED".

> Also, Nokia does not announce release dates of updates in advance.


I know that here isn't exactly the right place to discuss this, but I think
that the sealed mouth on firmware release date fits well on a classic OS
development process, but not on a widely open sourced OS like maemo, even if
bits or this OS are still closed.

Comment 40 Andre Klapper 2009-12-08 14:07:11 UTC

(In reply to comment #39)
> I know that here isn't exactly the right place to discuss this

Exactly. See bug 5709 and its link instead.

MMI for UE is well defined in 3GPP TS 22.030.
Most recent version to be found here:
http://www.3gpp.org/ftp/Specs/html-info/22030.htm hope that helps.
I was surprised to see Nokia implementing phone capabilities without such basic
functionality. 
Sidenote: On PIN enty the "#" symbol is consequently missing as well, on most
phones you can even press "#" after PIN to proceed ...

Comment 42 Lassi Syrjälä 2009-12-09 09:12:32 UTC

(In reply to comment #41)
> MMI for UE is well defined in 3GPP TS 22.030.
> Most recent version to be found here:
> http://www.3gpp.org/ftp/Specs/html-info/22030.htm hope that helps.

22.030 is about the well-defined supplementary service procedures but most
people here are asking for USSD (which is practically everything that's not
covered by 22.030).

We have already promised USSD support in a later update. Let's see about the
structured codes for forwarding/barring/waiting/interrogating caller id related
settings... There was a bug about these, but I believe it was resolved as
WONTFIX. Feel free to reopen or vote for it, though.

> Sidenote: On PIN enty the "#" symbol is consequently missing as well, on most
> phones you can even press "#" after PIN to proceed ...

Not consequently. Please file that as a separate ticket to Connectivity.

(In reply to comment #42)
> (In reply to comment #41)
> > MMI for UE is well defined in 3GPP TS 22.030.
> > Most recent version to be found here:
> > http://www.3gpp.org/ftp/Specs/html-info/22030.htm hope that helps.
> 
> 22.030 is about the well-defined supplementary service procedures but most
> people here are asking for USSD (which is practically everything that's not
> covered by 22.030).
> 
> We have already promised USSD support in a later update. Let's see about the
> structured codes for forwarding/barring/waiting/interrogating caller id related
> settings... There was a bug about these, but I believe it was resolved as
> WONTFIX. Feel free to reopen or vote for it, though.
> 
> > Sidenote: On PIN enty the "#" symbol is consequently missing as well, on most
> > phones you can even press "#" after PIN to proceed ...
> 
> Not consequently. Please file that as a separate ticket to Connectivity.
> 

Could you point me to the BUG ?

From the name of the bug and the description you can see the misunderstanding
here. You are talking USSD (purely) but in the comment you read "Also they
can be used to set call diversions". 
My wrong assumption here was that we are facing an MMI error in the phone
frontend and further thought that all specs handling the signalling procedures
are implemented. But what you are saying is that you are "only" looking into
USSD and NOT into general implementation of Supplementary Services.
That means YES for USSD, but NO for call divertion or CLIR....
Since all of that starts with *# it will "feel" like an unpredictable outcome
for MMI users. (why does one command work and the other don't).
Anyway, if you can show me the bug # where you are WONTFIX "Supplementary
Services" I will vote there.

Think the title is a mislead and should be changed.

*# or * are more like a carrier service commands initiation.

*** Bug 6989 has been marked as a duplicate of this bug. ***

Comment 46 Neil MacLeod 2009-12-15 19:32:18 UTC

Not sure about "*#" but it seems that any phone number containing a hash (#) is
considered an "incorrect number".

This is a problem for N900 users wishing to sign up with HulloMail[1]

"For example, i had to dial **004*xxxxxxxxxxxxxx# (where x = number) from my
then HTC Hero, to activate the service."

and I've also been informed by a N900 user in Saudi Arabia, this prevents
checking the balance on PAYG SIMs:

"If I wanna check my Balance on one of my PAYG Saudi sims in Saudi, I have to
dial (*142#) and you read on the screen "Sending Request" after which, you get
your balance."

also from the same user in Saudi, another code which isn't accepted:

"The number that all you have kindly been testing out [**21*1431#] is for
switching a certain service on (where if people call you, they hear as if your
phone is switched off, You however will get a notification text stating who
called and what time)

There is of course another code to dial to switch that service off."

None of the above numbers are accepted as valid in 1.2009.42-11.


1. http://www.hullomail.com/gb/hullomail/FAQs-reg.html

Comment 47 Lassi Syrjälä 2009-12-15 21:04:34 UTC

(In reply to comment #46)
> Not sure about "*#" but it seems that any phone number containing a hash (#) is
> considered an "incorrect number".

Numbers ending in a hash are either Unstructured Supplementary Service Data
(USSD) or Supplementary Service (SS) codes, neither of which 1.2009.42-11
supports.

> This is a problem for N900 users wishing to sign up with HulloMail[1]
> 
> "For example, i had to dial **004*xxxxxxxxxxxxxx# (where x = number) from my
> then HTC Hero, to activate the service."

This is an SS code that registers and activates all conditional (no answer,
unreachable, or busy) diverts to the given number. On N900, this type of divert
can be configured from Settings > Phone.

> "If I wanna check my Balance on one of my PAYG Saudi sims in Saudi, I have to
> dial (*142#) and you read on the screen "Sending Request" after which, you get
> your balance."

This is a USSD code, similar to "*100#" from the first comment of this bug.

> also from the same user in Saudi, another code which isn't accepted:
> 
> "The number that all you have kindly been testing out [**21*1431#] is for
> switching a certain service on (where if people call you, they hear as if your
> phone is switched off, You however will get a notification text stating who
> called and what time)

This is an SS code to register an unconditional divert to number 1431.

Comment 48 Grigori Timonen 2009-12-16 09:34:48 UTC

I think it is useless to put just more examples here. This makes technical
discussion much harder to read and track. Please just vote for a bug, this
gives more effort.

(In reply to comment #48)
> I think it is useless to put just more examples here. This makes technical
> discussion much harder to read and track. Please just vote for a bug, this
> gives more effort.
> 

I don't know if this is considered an useless example, but I just tried
(successfully) to send the special command to swap the master and slave "BIS" 
SIMs (the italian vodafone's twin sim service).

This is normally done via a SAT menu (missing on the n900)

or

via the *101*1# command (refused by the n900 because the '#' character).

So I simply issued the command "atd *101*1# " to the modem's serial port and
the command worked perfectly.

So I'm still convinced that the main problem is just a stupid bug in the UI
that refuses the # symbol.

Fixing this can solve a lot of troubles to the n900 users, although it surely
not fix all the special commands related problems.

(In reply to comment #49)

> So I simply issued the command "atd *101*1# " to the modem's serial port and
> the command worked perfectly.
> 

How do you do this?

(In reply to comment #50)
> (In reply to comment #49)
> 
> > So I simply issued the command "atd *101*1# " to the modem's serial port and
> > the command worked perfectly.
> > 
> 
> How do you do this?
> 


I did it from windows with absolute telnet, but you can use hypeterminal or any
similar program, or minicom/xminicom if you are using a linux box.

 I think that the same can obtained directly on the n900 if a working version
of minicom is available for the armel architecture.

Comment 52 Lassi Syrjälä 2009-12-17 09:13:32 UTC

(In reply to comment #49)
> This is normally done via a SAT menu (missing on the n900)

Is it not done via the SAT menu because no GSM phone lets you /dial/ "*101*1#"?
If they do, they would have to have special handling for this particular
command, since by the spec, the command should be sent as a USSD, which might
or might not have the same effect.

> So I'm still convinced that the main problem is just a stupid bug in the UI
> that refuses the # symbol.

The UI is aware of supplementary service commands, but unfortunately it cannot
handle them yet and the rather generic banner fails to convey this clearly. As
a curiosity, dialing "*101*1p#" should succeed though I don't expect it to be
handled the same as "ATD *101*1"...

(In reply to comment #52)
> The UI is aware of supplementary service commands, but unfortunately it cannot
> handle them yet and the rather generic banner fails to convey this clearly. As
> a curiosity, dialing "*101*1p#" should succeed though I don't expect it to be
> handled the same as "ATD *101*1"...

Interestingly, nobody pointed out that the standard command to get your IMEI
does not work either. The correct behaviour for this is to type in "*#06#" and
as soon as you hit the last "#" the UE should spit out your IMEI. This has
nothing to do with dialling and the modem, and is handled (mostly) only by the
UI. This, to me, suggests that the issue here is probably really in the UI
handling of "#" and a terminating one at that. Otherwise, what I just described
is a separate bug, to do with "N900 unable to reports its IMEI via *#06#
command". I will leave it to the developers to decide if a new bug is needed.
I'll monitor the discussion here for a while and raise a new bug if I don't see
anyone commenting it is the same issue as discussed here (i.e. SS commands).

BTW, the standard Nokia sequence for getting the UE SW version does not seem to
work either. Not listing it here in case it's not supposed to be public
knowledge (even if I know it already is). ;)

(In reply to comment #51)
>  I think that the same can obtained directly on the n900 if a working version
> of minicom is available for the armel architecture.

Does anyone know the entry under /dev for the modem on the n900?

Comment 55 Mikhail Zabaluev 2009-12-17 11:24:47 UTC

(In reply to comment #53)
> Otherwise, what I just described
> is a separate bug, to do with "N900 unable to reports its IMEI via *#06#
> command". I will leave it to the developers to decide if a new bug is needed.

Isn't "Settings -> About" a more user-friendly way to look up the same?

(In reply to comment #55)
> (In reply to comment #53)
> > Otherwise, what I just described
> > is a separate bug, to do with "N900 unable to reports its IMEI via *#06#
> > command". I will leave it to the developers to decide if a new bug is needed.
> 
> Isn't "Settings -> About" a more user-friendly way to look up the same?
> 

Cool. Now just to fix the SS codes... Theres a lot of NWs using them.

(In reply to comment #55)

> Isn't "Settings -> About" a more user-friendly way to look up the same?
> 

It's much longer steps and keys to press.

(In reply to comment #57)
> (In reply to comment #55)
> 
> > Isn't "Settings -> About" a more user-friendly way to look up the same?
> > 
> 
> It's much longer steps and keys to press.
> 

I still agree with Mikhail. You need this so rarely, that it's not worth
providing a second way of doing the same thing. It's all trade-offs in SW
engineering. I'd rather have the SS codes fixed sooner and type a few extra
keys 
 to get to the SW version and IMEI.

isn't this discussion going into that direction ?:
https://bugs.maemo.org/show_bug.cgi?id=5380


(In reply to comment #58)
> (In reply to comment #57)
> > (In reply to comment #55)
> > 
> > > Isn't "Settings -> About" a more user-friendly way to look up the same?
> > > 
> > 
> > It's much longer steps and keys to press.
> > 
> 
> I still agree with Mikhail. You need this so rarely, that it's not worth
> providing a second way of doing the same thing. It's all trade-offs in SW
> engineering. I'd rather have the SS codes fixed sooner and type a few extra
> keys 
>  to get to the SW version and IMEI.
>

(In reply to comment #59)
> isn't this discussion going into that direction ?:
> https://bugs.maemo.org/show_bug.cgi?id=5380
> 

IMO the two are duplicates. Which one is kept open is a different issue. I
would go for 5380 for the better title, but this one has had more discussion so
far. 

OTOH, do we need all this discussion when the issue is clearly that none of the
3GPP SS commands can be issued on N900?

Comment 61 Lassi Syrjälä 2009-12-17 16:09:58 UTC

*#06# for IMEI and *#0000# for SW version are something for the UI to handle.
They will be supported in a forthcoming release as well.

(In reply to comment #52)
> (In reply to comment #49)
> > This is normally done via a SAT menu (missing on the n900)
> 
> Is it not done via the SAT menu because no GSM phone lets you /dial/ "*101*1#"?

Sorry but I cant understand your point.

Any phone is able to manage that code, with the exception of n900, and some
phones from the jurassic era...

Any phone I tried in the last 5 years is able to manage  both, the SAT menu
with the SIM applications *and* the special codes as *101*1# .

Any phone, even a cheap Nokia 1100


> 
> > So I'm still convinced that the main problem is just a stupid bug in the UI
> > that refuses the # symbol.
> 
> The UI is aware of supplementary service commands, but unfortunately it cannot
> handle them yet and the rather generic banner fails to convey this clearly. As
> a curiosity, dialing "*101*1p#" should succeed though I don't expect it to be
> handled the same as "ATD *101*1"...
> 

Indeed the string *101*1p# is accepted from the phone (p is accepted as a
capital) and treated as a normal call, as you guessed it has no effect on the
service management (the sim aren't swapped).

If I send the same string via the com port, the phone returns "ERROR".


BTW I'm just curios...  

Why "# > send key" and "* > send key" are treated differently by the UI? 



P.S. Just to point to a potential additional problem, what happen if one locks
the SIM entering 3 times the wrong PIN code ?

The PUK unlock code will be accepted ? I bet it doesn't (I haven't tried yet)

As it was stated several times, please do not use bugzilla for forum-like
discussion, please use talk.maemo.org for that. The issue filed as this bug
(#5357) is under active work by several Maemo development teams already. As
Lassi and others noted, fixes will be introduced in upcoming software updates.

(In reply to comment #63)
> As it was stated several times, please do not use bugzilla for forum-like
> discussion, please use talk.maemo.org for that. The issue filed as this bug
> (#5357) is under active work by several Maemo development teams already. As
> Lassi and others noted, fixes will be introduced in upcoming software updates.
> 

???

I think that your message is a forum like one, if you think that others
opinions/findings/etc are unuseful just skip them, no one force you to read the
message you don't like.

Comment 65 Lassi Syrjälä 2009-12-18 09:32:37 UTC

(In reply to comment #62)
> Any phone I tried in the last 5 years is able to manage  both, the SAT menu
> with the SIM applications *and* the special codes as *101*1# .

They should send it as a USSD request, which the N900 will do as well. ATD to
me sounds like a command one dials a call with, but perhaps the modem can
handle USSD with it, too? The UI in any case does not interface with the modem
via AT commands...

> The PUK unlock code will be accepted ? I bet it doesn't (I haven't tried yet)

No but there's a UI for that.

Comment 66 Mikhail Zabaluev 2009-12-18 10:43:19 UTC

(In reply to comment #64)
> I think that your message is a forum like one, if you think that others
> opinions/findings/etc are unuseful just skip them, no one force you to read the
> message you don't like.

This is the bug tracker, with mail notifications going to developers who have
many things to work on. Please keep the discussion to necessary technical
details. Refusal to do so may result in termination of your account. We hope
for your understanding.

Same issue in France with this phone number : #123#
It's used to see your consumation with the Orange provider.

At the moment I am using the phone with Orange Dominican Republic on a a
pre-paid plan. It is IMPOSSIBLE for me to recharge the account. I CANNOT make
phone calls (credit balance is zero), and will soon lose the ability for me to
receive them once the current credit expires.

I need a work around (some kind of script to invoke the modem directly maybe)
in the mean time. Can anyone help?

(In reply to comment #68)
> At the moment I am using the phone with Orange Dominican Republic on a a
> pre-paid plan. It is IMPOSSIBLE for me to recharge the account. I CANNOT make
> phone calls (credit balance is zero), and will soon lose the ability for me to
> receive them once the current credit expires.
> 
> I need a work around (some kind of script to invoke the modem directly maybe)
> in the mean time. Can anyone help?
> 

The only workaround yet is described in thread here. Attach the phone via cable
in PC Suite mode, and use terminal program (minicom/hyperterminal/etc) to issue
AT commands.

(In reply to comment #69)
> (In reply to comment #68)
> > At the moment I am using the phone with Orange Dominican Republic on a a
> > pre-paid plan. It is IMPOSSIBLE for me to recharge the account. I CANNOT make
> > phone calls (credit balance is zero), and will soon lose the ability for me to
> > receive them once the current credit expires.
> > 
> > I need a work around (some kind of script to invoke the modem directly maybe)
> > in the mean time. Can anyone help?
> > 
> 
> The only workaround yet is described in thread here. Attach the phone via cable
> in PC Suite mode, and use terminal program (minicom/hyperterminal/etc) to issue
> AT commands.

You can also open the X Terminal, execute sudo gainroot (it requires rootsh to
be installed), then execute pnatd and enter AT commands.

with n900, I just use 'root' command to become root.

so, the script
Nokia-N900-41-10:~# cat bal.sh 
#!/bin/sh
echo "$1" | echo -n -e $(tr -d '[:space:]' | sed 's/../\\x&/g') | iconv -f
UCS-2BE -t UTF8

and usage

Nokia-N900-41-10:~# bal.sh
04110430043B0430043D0441003A00200034003700390034002E00390440002E002000440065007000650063006800650020004D006F0064006500210020041D043004310435044004380020002A003200380032002300200028003500200440044304310029
Баланс: 4794.9р. Depeche Mode! Набери *282# (5 руб)Nokia-N900-41-10:~#


The magic sequence extracted in dialog with pnatd:

Nokia-N900-41-10:~# pnatd 
AT
OK
AT+CUSD=1,"*100#",15
+CUSD:
0,"04110430043B0430043D0441003A00200034003700390034002E00390440002E002000440065007000650063006800650020004D006F0064006500210020041D043004310435044004380020002A003200380032002300200028003500200440044304310029",72

(In reply to comment #68)
> At the moment I am using the phone with Orange Dominican Republic on a a
> pre-paid plan. It is IMPOSSIBLE for me to recharge the account. I CANNOT make
> phone calls (credit balance is zero), and will soon lose the ability for me to
> receive them once the current credit expires.
> 
> I need a work around (some kind of script to invoke the modem directly maybe)
> in the mean time. Can anyone help?
> 

Well, there's a very simple solution to that. Take the sim card out and put it
in your old phone and do the top-up for credits.

Btw, this still has not been fixed in PR1.1? 
A little disappointed if it isn't which means we'll have to wait at least until
February for the fix.

This bug is very strange in mobile (with phone) device! )

*#0000# and *#06# work fine in PR1.1. Is this the only scope of the bug? If
yes, this can be VERIFIED FIXED.

This bug is about the UI which was blocking the input of * an #. This is solved
in the PR 1.1 Firmware and so the bug indeed is verified fixed.

Comment 76 Lassi Syrjälä 2009-12-26 10:39:38 UTC

There are various kinds of MMI codes which the UI needs to recognize, parse,
and handle accordingly:

1) SS procedures (e.g. *43# to activate call waiting)
2) SIM control procedures (e.g. **04*...# to change the PIN code)
3) IMEI presentation procedure (*#06#)
4) Manufacturer-defined procedures (e.g. *#0000#)
5) USSD commands (operator-defined, e.g. *100# to check prepaid credit)

In 1.2009.42-11, anything that fell into these categories was rejected as
"Incorrect number" (which is less shameful than requesting a call be set up).
PR1.1 adds *#06# and *#0000# from categories 3 and 4 but retains the old
behavior for the rest. Categories 1 and 2 are to an extent configurable from
the settings UI but for the 5th one (that this bug is about), there's
unfortunately no support in the PR1.1 (pre-)release either.

This has already been addressed internally, though, so resolved/fixed is a
truthful resolution in any case...

(In reply to comment #76)

> This has already been addressed internally, though, so resolved/fixed is a
> truthful resolution in any case...
> 

Truthfully the initial bug report was for handling *100# USSD commands so this
should not consider as fixed.

Marking this as fixed will throw out 3 new separate bug reports for each of the
following categories:

1) SS procedures (e.g. *43# to activate call waiting)
2) SIM control procedures (e.g. **04*...# to change the PIN code)
5) USSD commands (operator-defined, e.g. *100# to check prepaid credit)

Comment 78 Lassi Syrjälä 2009-12-26 11:53:50 UTC

(In reply to comment #77)
> Truthfully the initial bug report was for handling *100# USSD commands so this
> should not consider as fixed.

The fix is ready, so it's merely a question of when it can be released to
public. I believe we have usually closed publicly tracked bugs as they are
closed internally, but it's up to you guys if you prefer to keep this open
until the fix hits a public release.

Comment 79 Attila Csipa 2009-12-26 14:45:59 UTC

How deep are the changes in question ? Would it be possible/feasible to
negotiate having the fix (even in source form, with a 1m x 1m Caveat Emptor
sign) attached here ? I'd rather recompile things than wait till ~April for the
next firmware release.

This has been verified in my 2.2009.51-1. I tried the IMEI code and it worked.

Comment 81 Ryan Abel 2009-12-26 19:59:08 UTC

(In reply to comment #78)
> (In reply to comment #77)
> > Truthfully the initial bug report was for handling *100# USSD commands so this
> > should not consider as fixed.
> 
> The fix is ready, so it's merely a question of when it can be released to
> public. I believe we have usually closed publicly tracked bugs as they are
> closed internally, but it's up to you guys if you prefer to keep this open
> until the fix hits a public release.
> 

Bugs are RESOLVED when the code has been committed, bugs are CLOSED when the
code has been released.

(In reply to comment #80)
> This has been verified in my 2.2009.51-1. I tried the IMEI code and it worked.
> 

Verified against initial bug report? (issuing *100# like USSD commands)

Looking up IMEI using *#06# and *#0000# is NOT a fix for this bug report, which
apparently claimed as a fix as a whole in '09.51-1

Comment 83 Lassi Syrjälä 2009-12-27 00:38:57 UTC

(In reply to comment #81)
> Bugs are RESOLVED when the code has been committed, bugs are CLOSED when the
> code has been released.

A resolved bug can be REOPENED, suggesting the bug has entered the first stage
of closure. ;-)

Anyway, the point was that although this bug entered RESOLVED/FIXED state on
seemingly wrong grounds, the state is actually representative of our internal
builds. Verification and final closure must wait until the fix has been
released, obviously.

(As for the possibility of an intermediate release, I am afraid the changes are
too deep. After all, we are talking about a missing feature rather than a
simple bug in the UI)

Comment 84 Andre Klapper 2009-12-28 15:27:08 UTC

*** Bug 7360 has been marked as a duplicate of this bug. ***

Comment 85 Andre Klapper 2009-12-29 12:33:15 UTC

*** Bug 7412 has been marked as a duplicate of this bug. ***

Comment 86 Andre Klapper 2009-12-30 16:28:49 UTC

*** Bug 7492 has been marked as a duplicate of this bug. ***

*** Bug 7589 has been marked as a duplicate of this bug. ***

See http://talk.maemo.org/showpost.php?p=454839&postcount=23 for an
intermediate solution for USSD codes.

*** Bug 7721 has been marked as a duplicate of this bug. ***

I have updated firmware, 2009.44-1.002, but the issue has not been fixed yet.

I have t-mobile USA prepaid SIM, so just tried to call #225# to get
account balance information, but the phone app shows
"Incorrect Number" as before.

Comment 91 Andre Klapper 2010-01-11 23:12:12 UTC

This will be included in the "PR1.2" update release it seems. Hence the next
release (called PR1.1) will probably not include this...

*** Bug 7922 has been marked as a duplicate of this bug. ***

I have updated firmware, 2.2009.51-1.002, but the issue has not been fixed yet.

I have t-mobile USA prepaid SIM, so just tried to call #225# to get
account balance information, but the phone app shows
"Incorrect Number" as before.

Comment 94 Andre Klapper 2010-01-14 12:59:37 UTC

(In reply to comment #93)
> I have updated firmware, 2.2009.51-1.002, but the issue has not been fixed yet.

As already written in comment 91, this is not included in 2.2009.51-1. If it
was, I would have reset the Target Milestone to 2.2009.51-1 anyway already.

Comment 95 Andre Klapper 2010-01-14 18:11:02 UTC

*** Bug 7984 has been marked as a duplicate of this bug. ***

Here in Hong Kong. Also need **21*xxxxxx# / ##21# to enable /disable divert
call. Still not working. 

If it's not in this fix, why in resolved fixed?

(In reply to comment #94)
> (In reply to comment #93)
> > I have updated firmware, 2.2009.51-1.002, but the issue has not been fixed yet.
> 
> As already written in comment 91, this is not included in 2.2009.51-1. If it
> was, I would have reset the Target Milestone to 2.2009.51-1 anyway already.
>

Comment 97 Andre Klapper 2010-01-14 19:35:49 UTC

(In reply to comment #96)
> If it's not in this fix, why in resolved fixed?

Please read bug reports before adding useless comments - in this case comment
91. Also please do not fullquote the entire former posting without any reason,
please do not answer above the quote, and please read the basic stuff before
adding comments, such as the "Resolution" link which leads to
https://bugs.maemo.org/page.cgi?id=fields.html#resolution .

(In reply to comment #97)
> (In reply to comment #96)
> > If it's not in this fix, why in resolved fixed?
> 
> Please read bug reports before adding useless comments - in this case comment
> 91. Also please do not fullquote the entire former posting without any reason,
> please do not answer above the quote, and please read the basic stuff before
> adding comments, such as the "Resolution" link which leads to
> https://bugs.maemo.org/page.cgi?id=fields.html#resolution .
> 
many of us have been linux users before the n900 and are familier with the way
bugzila works. however there are many who are new to all this. the best
approach is to be polite and repond to comments in a respectful manner. we are
a community and we need to have a level what is not acceptable level of
interaction.

Comment 99 Andre Klapper 2010-01-14 20:36:42 UTC

*** Bug 7991 has been marked as a duplicate of this bug. ***

(In reply to comment #98)
> (In reply to comment #97)
> > (In reply to comment #96)
> > > If it's not in this fix, why in resolved fixed?
> > 
> > Please read bug reports before adding useless comments - in this case comment
> > 91. Also please do not fullquote the entire former posting without any reason,
> > please do not answer above the quote, and please read the basic stuff before
> > adding comments, such as the "Resolution" link which leads to
> > https://bugs.maemo.org/page.cgi?id=fields.html#resolution .
> > 
> many of us have been linux users before the n900 and are familier with the way
> bugzila works. however there are many who are new to all this. the best
> approach is to be polite and repond to comments in a respectful manner.

Correct. And it seems that this has been the case above.

This bug has been belaboured ad nauseam, and while it is difficult to go
through all of the almost 100 comments, one should really before commenting.
That's also part of the community spirit. I do not see any problem with Andre's
comment. It is polite, respectful, and to the point, following all the common
rules of public forums. And public forums are older than Linux, too. Remember
USENET? ;)

(Full disclosure: I do work for Nokia. However, I am in no way associated with
N900 or Maemo. My comments are my own, and do not necessarily reflect Nokia
position on any given topic.)

To summarise, there are 5 different types of "*#" as mentioned by Lassi

1) SS procedures (e.g. *43# to activate call waiting)
2) SIM control procedures (e.g. **04*...# to change the PIN code)
3) IMEI presentation procedure (*#06#)
4) Manufacturer-defined procedures (e.g. *#0000#)
5) USSD commands (operator-defined, e.g. *100# to check prepaid credit)

PR1.1 only fixed 3 & 4

If 'those in charge' thinks it's fixed for this bug report and refuse to reopen
to fix 1 & 2 & 5, then we'll open new bug reports for them.

Comment 102 Neil MacLeod 2010-01-18 12:27:58 UTC

*** Bug 8180 has been marked as a duplicate of this bug. ***

(In reply to comment #101)
> To summarise, there are 5 different types of "*#" as mentioned by Lassi
> 
> 1) SS procedures (e.g. *43# to activate call waiting)
> 2) SIM control procedures (e.g. **04*...# to change the PIN code)
> 3) IMEI presentation procedure (*#06#)
> 4) Manufacturer-defined procedures (e.g. *#0000#)
> 5) USSD commands (operator-defined, e.g. *100# to check prepaid credit)
> 
> PR1.1 only fixed 3 & 4
> 
> If 'those in charge' thinks it's fixed for this bug report and refuse to reopen
> to fix 1 & 2 & 5, then we'll open new bug reports for them.
> 

do you know what resolved fixed here means?
https://bugs.maemo.org/page.cgi?id=fields.html#resolution

(In reply to comment #103)

> do you know what resolved fixed here means?
> https://bugs.maemo.org/page.cgi?id=fields.html#resolution
> 

No because Bugzilla made it too confusing.

There should only be 4 states for a bug

NEW - When bug first filled
OPEN - Bug verified exists
FIXED - Bug fixed 
CLOSED - Fix confirmed

'Status' and 'Resolution' combined in a bug confused everyone.

What I want to know is, have 

1) SS procedures (e.g. *43# to activate call waiting)
2) SIM control procedures (e.g. **04*...# to change the PIN code)
5) USSD commands (operator-defined, e.g. *100# to check prepaid credit)

been fixed for the next update? As no one seem to be able to give a definite
answer here.

(In reply to comment #104)
> (In reply to comment #103)
> 
> > do you know what resolved fixed here means?
> > https://bugs.maemo.org/page.cgi?id=fields.html#resolution
> > 
> 
> No because Bugzilla made it too confusing.
> 
> There should only be 4 states for a bug
> 
> NEW - When bug first filled
> OPEN - Bug verified exists
> FIXED - Bug fixed 
> CLOSED - Fix confirmed
> 
> 'Status' and 'Resolution' combined in a bug confused everyone.

this doesn't belong here

> What I want to know is, have 
> 
> 1) SS procedures (e.g. *43# to activate call waiting)
> 2) SIM control procedures (e.g. **04*...# to change the PIN code)
> 5) USSD commands (operator-defined, e.g. *100# to check prepaid credit)
> 
> been fixed for the next update? As no one seem to be able to give a definite
> answer here.
> 

As usual, nokia doesn't announce beforehand about anything. So you have just
wait for next update and see if it has been fixed.

(In reply to comment #104)
> (In reply to comment #103)
> 
> > do you know what resolved fixed here means?
> > https://bugs.maemo.org/page.cgi?id=fields.html#resolution
> > 
> 
> No because Bugzilla made it too confusing.
> 
> There should only be 4 states for a bug

Your view of software development and bug life cycles is too simplified.
This is also off-topic here.

> What I want to know is, have 
> 
> 1) SS procedures (e.g. *43# to activate call waiting)
> 2) SIM control procedures (e.g. **04*...# to change the PIN code)
> 5) USSD commands (operator-defined, e.g. *100# to check prepaid credit)
> 
> been fixed for the next update? As no one seem to be able to give a definite
> answer here.

If you have read all the comments before posting, you would have seen comment
#91 (https://bugs.maemo.org/show_bug.cgi?id=5357#c91) which clearly states
where the fix will be released in. 

Now just for PR1.2 to be released and we'll all be happy! ;)

(In reply to comment #106)
> (In reply to comment #104)
> > (In reply to comment #103) 

> Now just for PR1.2 to be released and we'll all be happy! ;)
> 

https://bugs.maemo.org/show_bug.cgi?id=5380
From comment #5 onwards.

"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."

Meaning: NO FULL SUPPORT OF *# MMI COMMANDS IN MAEMO5.
Especially NOT:
> 1) SS procedures (e.g. *43# to activate call waiting)
> 2) SIM control procedures (e.g. **04*...# to change the PIN code)

*** Bug 8242 has been marked as a duplicate of this bug. ***

Call me stupid, but the bug description and initial reports is about USSD
codes. From what I see those are the exact one left out at least for now. And
then the bug is marked as fixed/resolved. How come? 
From what I understand a bug is fixed and resolved when the bug was fixed in
the code and submitted to public review. Am I missing something?

(In reply to comment #109)
> From what I understand a bug is fixed and resolved when the bug was fixed in
> the code and submitted to public review. Am I missing something?

I think it's the case that a bug is "resolved" when it has been fixed and
verified *internally*. When it becomes available to public via update
mechanisms depends on internal Nokia plans, not shared with the public.

Somewhere among the 110 comments here, there was a SW version given that
includes the fix. When a public update includes it, or later SW, it will become
generally available.

Comment 111 Andre Klapper 2010-01-22 16:41:26 UTC

(In reply to comment #109)
> From what I understand a bug is fixed and resolved when the bug was fixed in
> the code and submitted to public review. Am I missing something?

Yes. You forgot reading before commenting (and creating bugmail). ;-)
It has been explained several times in this thread already, but of course a bug
report becomes unreadable when more and more unhelpful comments are added to
it.

Hi! Anyone knows when This PR1.2 will be realised?
It's sad because in Romania the only option for cost control is *123#.
Please give me at least a clue about the date. I was written around here
something about an internal build version, something like 1.2010.02... If so,
can you help me to aproximate using this internal figures. Maybe a link who
explain how to do it.
Thank you!!!

Comment 113 Andre Klapper 2010-01-22 18:36:59 UTC

(In reply to comment #112)
> Hi! Anyone knows when This PR1.2 will be realised?

You did read this report (comment 36, comment 63, comment 97, comment 111)
before commenting I assume? If so, what was not clearly explained in those
comments?

And again: BUGZILLA IS NOT A FORUM. I lean towards disabling some user accounts
here if this continues to be constantly ignored.

In Many countries after you make each call you get a message receipt screen
stating your balance. and the same screen comes while using USSD commands like
*1100#

Come on people!

Please stop spamming the bug tracker. If Andre has to read every repeated post
with no new and useful information, he'll have that much time less to deal with
real work and problems. him and the developers, too.

In the long run this will benefit us all...

(In reply to comment #115)
> Come on people!
> Please stop spamming the bug tracker. If Andre has to read every repeated post
> with no new and useful information, he'll have that much time less to deal with
> real work and problems. him and the developers, too.
> In the long run this will benefit us all...

Dear Vlad. I apologize for any disturbance which I caused in your valuable
time, but you have to understand that the world's cheapest phone recognizes
USSD commands but since Nokia has contracted Maemo, rest assured nokia users
will have to face perpetual torment.

Anyways a message for Mr. Andre is that as I mentioned after each call we get a
receipt for balance inquiry which does not appear on N900, instead! something
keeps in progress while the phone is Idle. I've checked it several times by
putting my N900 next to computer speakers and they keep on buzzing as someone
is trying to make call or expecting a message. I presume that the mobile
network tries to send receipt to the phone which the "Stubborn" Maemo does not
comprehend. 

I'm sure you gentlemen can look into that as well. 

P.S   I checked three N900s with the same issue so uncle Maemo needs to be
fixed

Comment 117 Lassi Syrjälä 2010-01-22 22:53:56 UTC

(In reply to comment #116)
> Anyways a message for Mr. Andre is that as I mentioned after each call we get a
> receipt for balance inquiry which does not appear on N900, instead!

USSD can also be network-originated. Though I am quite surprised to hear it's
used after each call somewhere.  Part of the package anyways, but makes me
wonder if we made the UI too modal. We cannot really tell if the message is
something not to miss or "just" your balance.

(In reply to comment #117)
> ...
> Though I am quite surprised to hear it's
> used after each call somewhere.  Part of the package anyways, but makes me
> wonder if we made the UI too modal. We cannot really tell if the message is
> something not to miss or "just" your balance.

In fact O2 UK does the same. After an MO call or SMS you are sent a message
with the remaining balance. Similarly, the easiest way to get your balance is
to send *#10#, not currently supported on N900. Luckily, O2 allows you to dial
4445 as a voice call to top up/query balance. This is not such an unusual NW
feature.

> USSD can also be network-originated. Though I am quite surprised to hear it's
> used after each call somewhere.  Part of the package anyways, but makes me
> wonder if we made the UI too modal. We cannot really tell if the message is
> something not to miss or "just" your balance.

Balance receipt is an automated and free service from my cellular network which
pops up after every call or text message i send. There are 2 problems I am
facing. First is that it CAN NOT be disabled from the network where it's
originated and second is that it's the same (Window/Screen/Text Box) which
appears while we get different info using USSD Commands. Since the USSD's
message screen is unavailable, my cellular network tries to keep on sending
balance receipt which N900 never gets and turns out to keep phone busy by
hopeless struggles. 

As I mentioned earlier that after I make a call the "automated receipt" tries
to pop up on the screen but N900 wont let which results as a constant buzz from
my computer's monitor and speakers (The buzz you normally hear while the call
is in progress OR when you're about to receive an SMS)

And it wont go away till I put my phone in Offline mode.

What I'm trying to say is that we have another problem attached to this by not
having USSD service.

(In reply to comment #119)
> ...
> my cellular network tries to keep on sending
> balance receipt which N900 never gets and turns out to keep phone busy by
> hopeless struggles. 
> ...
> As I mentioned earlier that after I make a call the "automated receipt" tries
> to pop up on the screen but N900 wont let which results as a constant buzz from
> my computer's monitor and speakers...

In which case the best course of action is to raise a new bug report, to cover
the case of USSD codes being received, rather than sent. One problem, one bug
report. 

BTW, I am not seeing this issue on O2 UK which provides the same service as
your operator.

Comment 121 Attila Csipa 2010-01-23 12:01:12 UTC

As a stopgap solution (mentioned in #88, but much improved since then), if you
REALLY REALLY need this feature and are not afraid to install an application
under development (BACKUP ! Might break things ! You have been warned !) based
on information snippets on this page, see this project:

https://garage.maemo.org/projects/ussd-widget/

To avoid keeping things clean, if you do not know how to install deb files, DO
NOT use this page for asking about that. Use the maemo.org wiki or search
around in talk.maemo.org. Feedback, contact with authors at

http://talk.maemo.org/showthread.php?t=32878&page=11

Comment 122 Ryan Abel 2010-01-24 15:19:12 UTC

*** Bug 8464 has been marked as a duplicate of this bug. ***

Comment 123 Ryan Abel 2010-01-25 12:17:48 UTC

*** Bug 8489 has been marked as a duplicate of this bug. ***

(In reply to comment #122)
> *** Bug 8464 has been marked as a duplicate of this bug. ***
> 

I just want to confirm that **interactive** type of *100 numbers are considered
in bug 5357 where the service provider will send back a message prompting for
input.
Thank you

*** Bug 8585 has been marked as a duplicate of this bug. ***

Comment 126 Andre Klapper 2010-02-02 13:54:54 UTC

*** Bug 8758 has been marked as a duplicate of this bug. ***

Plz get this fixed at the earliest

Confirmed

Comment 129 Ryan Abel 2010-02-04 19:34:59 UTC

*** Bug 8831 has been marked as a duplicate of this bug. ***

Comment 130 Andre Klapper 2010-02-04 21:15:22 UTC

*** Bug 8830 has been marked as a duplicate of this bug. ***

Comment 131 Andre Klapper 2010-02-13 01:42:36 UTC

*** Bug 9032 has been marked as a duplicate of this bug. ***

Comment 132 Andre Klapper 2010-02-15 11:30:44 UTC

*** Bug 9058 has been marked as a duplicate of this bug. ***

*** Bug 9251 has been marked as a duplicate of this bug. ***

*** Bug 9346 has been marked as a duplicate of this bug. ***

Comment 135 Andre Klapper 2010-03-03 13:04:58 UTC

*** Bug 9374 has been marked as a duplicate of this bug. ***

(In reply to comment #135)
> *** Bug 9374 has been marked as a duplicate of this bug. ***
> 

I see thi bug as fixed. Does it mean it will be enabled on the next update ?
This is ab ver important feature & we must see this on the next update.

(In reply to comment #136)
> (In reply to comment #135)
> > *** Bug 9374 has been marked as a duplicate of this bug. ***
> > 
> 
> I see thi bug as fixed. Does it mean it will be enabled on the next update ?
> This is ab ver important feature & we must see this on the next update.
> 

While you wait for the fix to be release for public, there is an immidiate
alternative solution by using USSD Widget -
http://maemo.org/packages/view/ussd-widget

(In reply to comment #137)
> (In reply to comment #136)
> > (In reply to comment #135)
> > > *** Bug 9374 has been marked as a duplicate of this bug. ***
> > > 
> > 
> > I see thi bug as fixed. Does it mean it will be enabled on the next update ?
> > This is ab ver important feature & we must see this on the next update.
> > 
> 
> While you wait for the fix to be release for public, there is an immidiate
> alternative solution by using USSD Widget -
> http://maemo.org/packages/view/ussd-widget
> 

ussd-widget never worked for me and many others. Nokia should not even try to
think that this bug has been fixed* by the community. They need to come out
with a proper fix. Its been hell using the n900 as the only mobile phone. And
the fact that 3 updates has been released and this not included in any of them
is frankly not inspiring. I am not asking for portrait mode support. or for
meego to be made available to N900. or for turn by turn Navigations. I am just
asking for a simple basic functionality which every single GSM device in the
world supports. Something which should have been included in the first place.
That is all we are asking. I have tried to be the good citizen. Vote for the
bug and wait for the fix to be released, and not try to add noise to this
report. But that does not mean I and many others who are less geeky than me are
not suffering because of this major and critical omission from Nokia. Please
guys who work at nokia and reading this bug report should talk to Nokia so that
this fix can be released. Tell them its critical and a real deal breaker.
making the lives of many of their users miserable. Thanks

Comment 139 Andre Klapper 2010-03-06 15:37:35 UTC

(In reply to comment #138)
> ussd-widget never worked for me and many others. Nokia should not even try to
> think that this bug has been fixed* by the community.

And Nokia does not, as this will be fixed in the next update (as written a few
billion times in this report before), hence I stopped reading your comment at
this point. So please don't post such comments here, or go to talk.maemo.org
for telling Nokia what to do and what not to do. Thanks a lot!

(In reply to comment #139)
> (In reply to comment #138)
> > ussd-widget never worked for me and many others. Nokia should not even try to
> > think that this bug has been fixed* by the community.
> And Nokia does not, as this will be fixed in the next update (as written a few
> billion times in this report before), hence I stopped reading your comment at
> this point. So please don't post such comments here, or go to talk.maemo.org
> for telling Nokia what to do and what not to do. Thanks a lot!

Greetings Vlad

I have purchased N900 two days ago and I couldnt find any word better than
"Disappointed" what N900 has to offer. Lack of USSD in a mobile phone is like a
person with no brain, no wonder all the qualified retards at Nokia and Maemo
have proven their lack of efficiency and brains. 

I just hope I'd come across CEO of Nokia and Maemo and make them witness as I
destroy this piece of bowel with sledge hammer. I had to save money to get this
phone and now I'm stuck with it! I desperately need to sell this phone and buy
some Chinese.

Thankyou.

(In reply to comment #140)
> (In reply to comment #139)
> > (In reply to comment #138)
> > > ussd-widget never worked for me and many others. Nokia should not even try to
> > > think that this bug has been fixed* by the community.
> > And Nokia does not, as this will be fixed in the next update (as written a few
> > billion times in this report before), hence I stopped reading your comment at
> 
> Greetings Vlad

I assume you mean Andre here, but I do agree with him... ;)

For ussd-widget not working the best thing is to complain to its author.

(In reply to comment #140)
> (In reply to comment #139)
> > (In reply to comment #138)
> > > ussd-widget never worked for me and many others. Nokia should not even try to
> > > think that this bug has been fixed* by the community.
> > And Nokia does not, as this will be fixed in the next update (as written a few
> > billion times in this report before), hence I stopped reading your comment at
> > this point. So please don't post such comments here, or go to talk.maemo.org
> > for telling Nokia what to do and what not to do. Thanks a lot!
> 
> Greetings Vlad
> 
> I have purchased N900 two days ago and I couldnt find any word better than
> "Disappointed" what N900 has to offer. Lack of USSD in a mobile phone is like a
> person with no brain, no wonder all the qualified retards at Nokia and Maemo
> have proven their lack of efficiency and brains. 
> 
> I just hope I'd come across CEO of Nokia and Maemo and make them witness as I
> destroy this piece of bowel with sledge hammer. I had to save money to get this
> phone and now I'm stuck with it! I desperately need to sell this phone and buy
> some Chinese.
> 
> Thankyou.
> 

http://talk.maemo.org is a place for things like that. I hope you get banned
for this stupid spam you put here.

Comment 143 Naba Kumar 2010-03-09 10:41:22 UTC

Spare your angers. I will repeat comment #14

(In reply to comment #14)
> We are aware of missing USSD support, we plan to do it in some release update.
> 

"some release" is basically the next update.

Comment 144 Andre Klapper 2010-03-14 21:15:49 UTC

*** Bug 9537 has been marked as a duplicate of this bug. ***

Comment 145 Andre Klapper 2010-03-15 20:51:37 UTC

Setting explicit PR1.2 milestone (so it's clearer in which public release the
fix will be available to users).

Sorry for the bugmail noise (you can filter on this message).

i am sorry to say this
BUT NOKIA ARE STUPID 
how come no USSD 
OMG
and 3 updates and its still NOT FIXED
i wish i never bought my stupid N900 at jan
i should have wait tell the NEXT device ( meego ) to come out
NOKIA ARE STUPID
LOSER
I HATE NOKIA because of the N900

(In reply to comment #145)
> Setting explicit PR1.2 milestone (so it's clearer in which public release the
> fix will be available to users).
> 
> Sorry for the bugmail noise (you can filter on this message).
> 

so how come it's fixed if it's not!
i'm in Poland right now and can't even top up my balance
is there another solution/quickfix until(if/when/whenever) update is released?

(In reply to comment #147)
> (In reply to comment #145)
> > Setting explicit PR1.2 milestone (so it's clearer in which public release the
> > fix will be available to users).
> > 
> > Sorry for the bugmail noise (you can filter on this message).
> > 
> 
> so how come it's fixed if it's not!
> i'm in Poland right now and can't even top up my balance
> is there another solution/quickfix until(if/when/whenever) update is released?
> 
Please read this link through:

https://bugs.maemo.org/page.cgi?id=fields.html#resolution

(In reply to comment #147)
> (In reply to comment #145)
> > Setting explicit PR1.2 milestone (so it's clearer in which public release the
> > fix will be available to users).
> > 
> > Sorry for the bugmail noise (you can filter on this message).
> > 
> 
> so how come it's fixed if it's not!
> i'm in Poland right now and can't even top up my balance
> is there another solution/quickfix until(if/when/whenever) update is released?
> 

Install the USSD widget, look in the forum for details. It works great.

(In reply to comment #149)
> (In reply to comment #147)
> > (In reply to comment #145)
> > > Setting explicit PR1.2 milestone (so it's clearer in which public release the
> > > fix will be available to users).
> > > 
> > > Sorry for the bugmail noise (you can filter on this message).
> > > 
> > 
> > so how come it's fixed if it's not!
> > i'm in Poland right now and can't even top up my balance
> > is there another solution/quickfix until(if/when/whenever) update is released?
> > 
> 
> Install the USSD widget, look in the forum for details. It works great.
> 
For your information, USSD WIDGET DOESN'T WORK WITH FIDO (CARRIER) IN CANADA.

(In reply to comment #150)
> (In reply to comment #149)
> > (In reply to comment #147)
> > > (In reply to comment #145)
> > > > Setting explicit PR1.2 milestone (so it's clearer in which public release the
> > > > fix will be available to users).
> > > > 
> > > > Sorry for the bugmail noise (you can filter on this message).
> > > > 
> > > 
> > > so how come it's fixed if it's not!
> > > i'm in Poland right now and can't even top up my balance
> > > is there another solution/quickfix until(if/when/whenever) update is released?
> > > 
> > 
> > Install the USSD widget, look in the forum for details. It works great.
> > 
> For your information, USSD WIDGET DOESN'T WORK WITH FIDO (CARRIER) IN CANADA.
> 

Thanks for spelling it out so clearly. Then perhaps they have a non*# number as
well. Orange in EU has.

Either way I believe the update should be out next week.

Comment 152 Andre Klapper 2010-05-02 17:31:51 UTC

*** Bug 10078 has been marked as a duplicate of this bug. ***

Comment 153 Andre Klapper 2010-05-21 16:46:05 UTC

*** Bug 10217 has been marked as a duplicate of this bug. ***

Comment 154 Andre Klapper 2010-05-23 16:12:52 UTC

*** Bug 10242 has been marked as a duplicate of this bug. ***

Comment 155 Andre Klapper 2010-05-25 11:16:17 UTC

*** Bug 10259 has been marked as a duplicate of this bug. ***

(In reply to comment #155)
> *** Bug 10259 has been marked as a duplicate of this bug. ***
> 
This is still not fixed in PR1.2!

(In reply to comment #156)
> (In reply to comment #155)
> > *** Bug 10259 has been marked as a duplicate of this bug. ***
> > 
> This is still not fixed in PR1.2!
> 

It seems to work for me. What exact codes have you tried that have failed?

(In reply to comment #156)
> (In reply to comment #155)
> > *** Bug 10259 has been marked as a duplicate of this bug. ***
> > 
> This is still not fixed in PR1.2!
> 

It works very well for me!
Very nice to make link to desktop and tap for the info ;)

Still does not work for me in PR1.2. Trying to change my outgoing caller ID by
entering the following command: *004*[phonenumber]# gives the error "service
code not supported"

(In reply to comment #159)
> Still does not work for me in PR1.2. Trying to change my outgoing caller ID by
> entering the following command: *004*[phonenumber]# gives the error "service
> code not supported"
> 

Are you sure your operator supports this code? The message you get looks
suspiciously like a reply you'd get from the network if it wasn't. Have you
tried the same command on a different phone (with the same SIM, in the same
place).

In my country the format is usually *[some number]# and all invalid
combinations such as yours (for my operator) give a "request not completed"
message after a short while - not instant!

Looks to me that the code is being sent...

Comment 162 Attila Csipa 2010-05-26 23:26:15 UTC

THIS bug/enhancement is fixed. If there is a specific code/operator that does
not work, please doublecheck with different phone and same SIM, and potentially
open a new bug if it really IS up to Maemo5, but the generic 'has no *#
support' is certainly not an issue any more (verified).

(In reply to comment #162)
> THIS bug/enhancement is fixed. If there is a specific code/operator that does
> not work, please doublecheck with different phone and same SIM, and potentially
> open a new bug if it really IS up to Maemo5, but the generic 'has no *#
> support' is certainly not an issue any more (verified).
> 
I am from Canada and I am unsing fido.

With the same SIM card, USSD code works with my old Motorolla but they don't
work with my Nokia N900 and the new firmware.  So, it is not an code/operator
issue.  It is a Nokia N900 issue.

Comment 164 Andre Klapper 2010-05-27 01:39:14 UTC

(In reply to comment #163)
Please avoid vague comments. If something does not work and you are SURE that
this is related at all to this bug, add *EXACT* steps.
If not or if you are in doubt, please go to talk.maemo.org first.

Also, please read comment 47 first to understand about the differences of
existing codes.

(In reply to comment #164)
> (In reply to comment #163)
> Please avoid vague comments. If something does not work and you are SURE that
> this is related at all to this bug, add *EXACT* steps.
> If not or if you are in doubt, please go to talk.maemo.org first.
> 
> Also, please read comment 47 first to understand about the differences of
> existing codes.
> 
«Please avoid vague comments.»

SOFTWARE VERSION:
10.2010.19-1.002

STEPS TO REPRODUCE THE PROBLEM:
1. Open Phone to make a call.
2. #21#
3. Click on Call-button

EXPECTED OUTCOME:
cancel Call Forwarding

ACTUAL OUTCOME:
Service code not supported

REPRODUCIBILITY:
always

CARRIER: WWW.FIDO.CA

SEE THE PROBLEM ON YOUTUBE: http://www.youtube.com/watch?v=_76aeo9UXEk

WOW Update of MEMO resolve the USSD code problem now all Prepaid users can
check there balance or execute any query to us USSD like *123# its working
perfectly 
Thanks Memo Team to resolve this problem

(In reply to comment #165)
> (In reply to comment #164)
> > (In reply to comment #163)
> > Please avoid vague comments. If something does not work and you are SURE that
> > this is related at all to this bug, add *EXACT* steps.
> > If not or if you are in doubt, please go to talk.maemo.org first.
> > 
> > Also, please read comment 47 first to understand about the differences of
> > existing codes.
> > 
> «Please avoid vague comments.»
> 
> SOFTWARE VERSION:
> 10.2010.19-1.002
> 
> STEPS TO REPRODUCE THE PROBLEM:
> 1. Open Phone to make a call.
> 2. #21#
> 3. Click on Call-button
> 
> EXPECTED OUTCOME:
> cancel Call Forwarding
> 
> ACTUAL OUTCOME:
> Service code not supported
> 
> REPRODUCIBILITY:
> always
> 
> CARRIER: WWW.FIDO.CA
> 
> SEE THE PROBLEM ON YOUTUBE: http://www.youtube.com/watch?v=_76aeo9UXEk
> 

Yes he's right #21# doesn't work. We should however start a bug thread for ##
issues. My operator however does not use such numbers.

Comment 168 Naba Kumar 2010-05-27 12:34:05 UTC

(In reply to comment #167)
> 
> Yes he's right #21# doesn't work. We should however start a bug thread for ##
> issues. My operator however does not use such numbers.
> 

Please note that this bug is about USSD codes, which is fixed and reported to
be working by many.

Don't confuse it with SS codes (see comment #47 and various comments by Lassi).
SS codes is not officially enabled in PR1.2, mainly because most useful actions
are more conveniently done by UI in (Settings->Phone settings) such as call
forwarding, Call ID enable/disable etc.). These are legacy codes, so don't get
bogged down by this -- just visit your "Phone Settings". Less useful ones are
less useful, anyways.

If you are *still* interested to play with SS codes "dialing" via Dialer
(despite the User-Interface), there is an ester egg available to enable it in
PR1.2. You have to work it out yourself or tip Lassi with some beers before he
reveals it :).

*111# Portugal -> Optimus -> Works fine

Works perfectly with *....# codes

Comment 171 Graham Cobb 2010-05-27 14:07:08 UTC

(In reply to #168)

In my view, not supporting SS codes is a big mistake.  There are many reasons,
including the fact that users do not understand the difference between
different types of codes.  But the main reason is that they are not "legacy",
they are "standard"!

Every GSM phone I have had (last 15 years or so), I have had entries in my
phonebook for quickly changing forwarding settings (forward to work, forward to
home, cancel forwarding).  Users use the SS codes.  I want to put a widget on
my home screen to set up forwarding to home with a single click!

Either a new bug needs to be created, or this one needs to be reopened, for SS
code support.

Comment 172 Andre Klapper 2010-05-27 14:15:38 UTC

(In reply to comment #171)
> Either a new bug needs to be created, or this one needs to be reopened, for SS
> code support.

New request, as this report is pretty useless thanks to many people abusing it
as a forum, and as this report is about *#.

(In reply to comment #171)
> (In reply to #168)
> 
> In my view, not supporting SS codes is a big mistake.  There are many reasons,
> including the fact that users do not understand the difference between
> different types of codes.  But the main reason is that they are not "legacy",
> they are "standard"!
> 
> Every GSM phone I have had (last 15 years or so), I have had entries in my
> phonebook for quickly changing forwarding settings (forward to work, forward to
> home, cancel forwarding).  Users use the SS codes.  I want to put a widget on
> my home screen to set up forwarding to home with a single click!
> 
> Either a new bug needs to be created, or this one needs to be reopened, for SS
> code support.
> 

I suggest a new bug report or even a brainstorm.

No new bug report needed, I guess this can be revived. Basicially requesting
full 
3GPP TS 22.030 compatibility. (explicitly including SS)
https://bugs.maemo.org/show_bug.cgi?id=8830


(In reply to comment #173)
> (In reply to comment #171)
> > (In reply to #168)
> > 
> > In my view, not supporting SS codes is a big mistake.  There are many reasons,
>

Comment 175 Andre Klapper 2010-05-27 15:18:01 UTC

(Please avoid quoting the complete previous comment and answering above.)

(In reply to comment #174)
> No new bug report needed, I guess this can be revived.

Again: New bug welcome. This bug is unusable "thanks" to forum-like comments in
Bugzilla which is not a new forum. 
-- Your friendly bugmaster.

Comment 176 Naba Kumar 2010-05-27 17:47:29 UTC

(In reply to comment #171)
> 
> In my view, not supporting SS codes is a big mistake.  There are many reasons,
> including the fact that users do not understand the difference between
> different types of codes.  But the main reason is that they are not "legacy",
> they are "standard"!
> 
Now that you know you can do the same thing from UI, would you still insist on
using the codes? "Legacy" is the codes part, not the functional part. These
were mainly created for dump phones, not for UI rich phones like N900. As for
standard compliance, let Nokia worry about it.

If you see that "Phone Settings" miss any useful features (that you have been
doing with SS codes), please feel free to file them as separate bug. And please
be specific about the feature and how it impacts your usage (i.e. don't file a
bug like "N900 should be standard compliance" or similar).

> Every GSM phone I have had (last 15 years or so), I have had entries in my
> phonebook for quickly changing forwarding settings (forward to work, forward to
> home, cancel forwarding).  Users use the SS codes.  I want to put a widget on
> my home screen to set up forwarding to home with a single click!
> 
Sounds like this is what you are after:
http://maemo.org/downloads/product/Maemo5/callforwarding/
If you need improvements in it's UI, please feel free to file bugs to it for
the author.

Comment 177 Graham Cobb 2010-05-27 18:43:11 UTC

(In reply to comment #176)
> Now that you know you can do the same thing from UI, would you still insist on
> using the codes? 

Yes, for particular purposes.  I have been using them for 15 years.  They are
documented all over the web.  They work on all phones.  Nokia should not
arrogantly decide which parts of the standards they will choose to implement --
the standards are written for *my* convenience, as a user, not theirs.

Imagine what would happen if Nokia suddenly decided that it would not support
dialing "+" to indicate international numbers, but provided a GUI button to
make international calls!

> Sounds like this is what you are after:
> http://maemo.org/downloads/product/Maemo5/callforwarding/

No, I know that app well and use it heavily -- I wrote a similar, earlier app
which I dropped when this one came along as its GUI is better. I have been in
communication with its author, and I plan (one day) to extend it to provide
some additional features such as profiles (which combine multiple settings) and
automatic changes ("always forward to home when my location is within 100m of
my house", etc.).

None of that replaces the use of SS.  Particularly for things other than
forwarding!

Let's take the discussion to bug #8830, which is the bug report for the SS code
bug.

Comment 178 Lassi Syrjälä 2010-05-27 18:44:33 UTC

(In reply to comment #168)
> If you are *still* interested to play with SS codes "dialing" via Dialer
> (despite the User-Interface), there is an ester egg available to enable it in
> PR1.2. You have to work it out yourself or tip Lassi with some beers before he
> reveals it :).

The following lines in ~/.osso/call-ui.ini do the trick:
[supplementary]
ssc=1

Please note that officially this feature does not exist and therefore does not
come with a warranty of any kind. The settings applet (Settings > Phone) does
not properly indicate some of the services and does not allow revoking all of
them. Only modify the .ini file if you are feeling experimental and already
know your way around the MMI codes.

(In reply to comment #178)
> (In reply to comment #168)
> > If you are *still* interested to play with SS codes "dialing" via Dialer
> > (despite the User-Interface), there is an ester egg available to enable it in
> > PR1.2. You have to work it out yourself or tip Lassi with some beers before he
> > reveals it :).
> 
> The following lines in ~/.osso/call-ui.ini do the trick:
> [supplementary]
> ssc=1
> 
> Please note that officially this feature does not exist and therefore does not
> come with a warranty of any kind. The settings applet (Settings > Phone) does
> not properly indicate some of the services and does not allow revoking all of
> them. Only modify the .ini file if you are feeling experimental and already
> know your way around the MMI codes.
> 

Thank you very much  M. Lassi Syrjälä.  Your solution solved my *21# problem
:-)

This Bug is confirmed with me also
I use 
**62*737#
##62#
**21*737#
##21#

(In reply to comment #180)
> This Bug is confirmed with me also
> I use 
> **62*737#
> ##62#
> **21*737#
> ##21#
> 

khrm which one starts with "*#" as per description?

(In reply to comment #181)
> which one starts with "*#" as per description?

I believe the description should say "Does not accept GSM (USSD) Codes starting
with * or #".

Comment 183 Andre Klapper 2010-07-18 13:28:23 UTC

No, as we prefer specific bug reports instead of dumping several issues into
one ticket. Please query if there is an existing ticket for your issue as it is
unrelated to this issue.

Issue seems to be there (or back) in PR1.3

I get "service code not supported" with **62*0xyzxyzxyz# in Phone... Not sure
if it is expected behavior or not.