GNOME Bugzilla – Bug 733690
USSD send trouble due to uninitalized variable
Last modified: 2014-12-11 22:06:13 UTC
Created attachment 281628 [details] [review] Patch for variable initialization In earlier versions of ModemManager (can't specify exact version) USSD commands was sent in 7-bit mode, i.e unencoded. In version 1.2.0 there is a support for both encoded and unencoded type of USSD, but due to important variable "use_unencoded_ussd" not being initialized ModemManager always sends only encoded USSD, not trying to switch into unencoded mode (and fails on my ZTE MF180, which can only handle unencoded USSD). So there is a simple patch to init variable with correct value.
Not sure that variable should be initialized to TRUE by default. If not explicitly initialized, it will be FALSE. The thing is that we'll try to kind of guess which mode to use in each modem (encoded/unencoded), depending on success or failure of the initial tries. Can you send some debug logs of the actual issue to see why it didn't switch to encoded version automatically?
Created attachment 281886 [details] Log file with patch applied
Created attachment 281887 [details] Log file without patch
OK, I got it. For first, I think that use of uninitialized variable is bug by itself. It may be initialized to FALSE... Or may not. There is no guarantee that allocated memory will be filled up with zeroes. So, next is actual issue. It seems that modem responds "OK" both to encoded and unencoded USSD request, but then USSD sent encoded, modem after some time says "CME ERROR 258", while in case with unencoded USSD things goes fine. I've attached two log files, one with my patch applied (in this case ModemManager uses unencoded USSD) and one without it (encoded USSD).
(In reply to comment #4) > OK, I got it. > For first, I think that use of uninitialized variable is bug by itself. It may > be initialized to FALSE... Or may not. There is no guarantee that allocated > memory will be filled up with zeroes. That's not true :) the private memory allocated for a GObject is always initialized to zeroes by default. > So, next is actual issue. It seems that modem responds "OK" both to encoded and > unencoded USSD request, but then USSD sent encoded, modem after some time says > "CME ERROR 258", while in case with unencoded USSD things goes fine. I've > attached two log files, one with my patch applied (in this case ModemManager > uses unencoded USSD) and one without it (encoded USSD). Ok, so that's a completely different thing... and not sure how to handle that properly then. I guess that we could always try to start trying with unencoded_ussd in this specific device/vendor? (i.e. a per-plugin update)
> That's not true :) the private memory allocated for a GObject is always initialized to zeroes by default. My mistake. I'm not familiar with GLib internals, I'm bare hw developer and because of that got scared by each uninitialized variable =) > Ok, so that's a completely different thing... and not sure how to handle that properly then. I guess that we could always try to start trying with unencoded_ussd in this specific device/vendor? (i.e. a per-plugin update) Hm, I think that this will be quick but not very clean fix, maintaining device DB isn't very simple. Maybe some sort of autodetection will be better, i.e if _plugged in first time_ modem didn't reply with proper USSD anwser for safe to use request (*100# or so) in, just to say, 60 seconds, try to use different method. Another option is to provide this per-device setting ("Use encoded USSD") over D-Bus interface, so then it can be configured by user software (ModemManagerGUI or another application). It will be simpler solution as I think, but still not very clear (users shouldn't be aware of internals, should they?).
Created attachment 287257 [details] [review] Patch 1/2: new property to request unencoded or encoded USSD
Created attachment 287258 [details] [review] Patch 2/2: request unencoded USSD in ZTE modems
Could you try the attached 2 patches and send back debug logs? They will add a new property in the broadband modem object, so that plugins like the ZTE can request encoded or unencoded USSD for every operation. Both patches are also in the "aleksander/zte-prefer-ussd-unencoded" branch in upstream git.
Hey Alex, could you retry with the attached patches?
I moved the patches and the bug to the new ModemManager bugzilla in fd.o; please follow the issue in the new bugreport here: https://bugs.freedesktop.org/show_bug.cgi?id=87247