GNOME Bugzilla – Bug 638039
USSD with Huawei E1750/E1650
Last modified: 2011-07-22 14:30:09 UTC
Created attachment 177063 [details] [review] USSD response on secondary port This is more of a "how to implement this properly" than an actual bug report: While we receive the OK of a USSD command as expected we don't get the actual USSD message since this is being send on the secondary port on Huawei E1750. I've set up a unsolicited_msg_handler (see attached patch) to capture the response but I didn't find a simple way to communicate this back to ussd_initiate_done. I know that I can override ussd_initiate in plugins/mm-modem-huawei-gsm.c (and have done so to deal with huawei specific coding issues) but how can I pass the USSD response? The only thing I could think of is to store all necessary state in the priv and fetch that in handle_ussd_reply. I would then do the mm_callback_info_schedule from there. Would that be the right way to go?
Any hint on howto handle this would be greatly appreciated.
Yeah sorry for the lag. So we probably want to use the same mechanism for handling the response, both on the primary port if it shows up there, or the secondary port. To do that, add the unsolicited message handler like you have done, which will capture the message on both ports. But I think we should do this in the generic GSM code in mm_generic_gsm_grab_port() instead, since the GSM 07.07 spec says that the response will always be returned via the unsolicited code, and that can happen on any port with any modem probably. So handling it generically instead of just in the Huawei plugin sounds better to me. So we'll move most of the processing logic from ussd_send_done() into the unsolicted response handler that we've just added. Of course to make the response useful, we'll need to cache the MMCallbackInfo that was the original request, so we can send the reply from the unsolicited response handler. Which means adding a pointer to the MMCallbackINfo into the MMGenericGsmPrivate struct. There's one problem though, which is that we don't know how long it will take that response to come through, and it may or may not be before we get the OK on the primary port. So we need to set up a timer, which also means caching the timer's ID and making sure we remove it when disabling the modem or disposing of it. We probably don't want to handle more than one USSD request in-flight (and reading GSM 07.07 that may not even be supported), so we might want to return an error from ussd_send() if we're waiting for the USSD response. So basically we add two new items to the Generic private structure, a MMCallbackInfo for the USSD request, and a second guint for the solicited request timer. We need to clear both of those when disabling the modem from disable(), and when disposing the modem from dispose(). Then, in ussd_send_done(), since we've added an unsolicited handler for +CUSD response, we won't get the +CUSD string in the reply as it will be consumed by the unsolicited reply handler already. So what happens here is that in ussd_send() we cache the new MMCallbackInfo into the MMGenericGsmPrivate struct, and then from the unsolicited handler if there is no cached callback info, we just drop the response. Also in ussd_send() we start the response timer with g_timeout_add(). In ussd_send_done() if there's an ERROR resposne of any kind, of course we send that in the callback info and clear the callback info *and* the response timer. If there is just an OK, we *don't* clear the callback info or the response timer, since those will be cleared from the unsolicited handler when the response is actually processed. The timer, if it fires because the modem screwed us, we create a new GError, complete the cached MMCallbackInfo with that error, and clear the cached MMCallbackINfo pointer and the timer. Does that make sense? It's somewhat complicated because we need the timer, but it's actually pretty contained in just the USSD code. Thanks for working on this!
Ping? Any more questions I can answer?
Just a lack of time on my side. I'll have a look next weekend.
The current USSD code is at: http://anonscm.debian.org/gitweb/?p=users/agx/ModemManager.git git://anonscm.debian.org/users/agx/ModemManager.git Please let me know if there's anything lacking. Tested with Huawei E1750 and N900.
Anything I can do to get this merged? Are patches preferred of a git pull?
Hi, i just tested this on my Fedora system and run into one problem when compiling. CC modem_manager-mm-serial-parsers.o CC modem_manager-mm-modem-base.o CC modem_manager-mm-generic-cdma.o CC modem_manager-mm-generic-gsm.o CC modem_manager-mm-modem-cdma.o mm-generic-gsm.c: In function 'ussd_received': mm-generic-gsm.c:4773:46: error: 'info' is used uninitialized in this function [-Werror=uninitialized] cc1: all warnings being treated as errors make[4]: *** [modem_manager-mm-generic-gsm.o] Error 1
Hmm...it looks Dan committed another implementation but it's at least lacking the Huawai code? Dan?
Created attachment 189997 [details] patches rebased Not sure if we have a misunderstanding here. I poked in your git repo at http://anonscm.debian.org/gitweb/?p=users/agx/ModemManager.git And then rebased these patches on current ModemManager. But looking at it again, i might have done something wrong. Could you rebase them? I cannot do this right now. Attached you find my try ...
You picked the right patches but Dan implemented it slightly different: http://cgit.freedesktop.org/ModemManager/ModemManager/commit/?id=51c409d1eba77804d9e1709808c2eb5e5eb064e0 omitting the Huawei part.
Thanks Guido for mentioning this. It seems Dan and I have looked at this at the same time. Now it compiles perfectly. Although when running I get: ppm: ERROR: ussd_initiate failed: org.freedesktop.ModemManager.Modem.General: Failed to encode USSD command '*101#' But I think this might be another bug now? I have a device which starts as a Bus 001 Device 018: ID 19d2:2000 ONDA Communication S.p.A. ZTE MF627/MF628/MF628+ HSDPA and then gets: Bus 001 Device 019: ID 19d2:0117 ONDA Communication S.p.A.
Yes, that looks like a different issue. Run modem-manger with --debug and try the USSD sequence using test/ussd.py. If you can reproduce it open another bug and feel free to add me as cc:.
Just for the record and anybody finding this via google. The report for my ZTE stick is bug #652682
Created attachment 190231 [details] [review] Huawei modems need ussd messages encoded as packed gsm This patch adds ussd_{encode,decode} to the MMModemGsmUSSD Interface so we can add quirks for the different modems. Huawei modems need to use packed gsm for USSD message which is implemented via the huawei plugin. Split up versions for easy review of this patch are available at: http://anonscm.debian.org/gitweb/?p=users/agx/ModemManager.git It would be great if this could be applied.
This has been fixed in git: http://cgit.freedesktop.org/ModemManager/ModemManager/commit/?id=70715c1c124b3220969a432be5ad2ad6f44913fe