GNOME Bugzilla – Bug 697586
[MM 0.8] Use only GetSignalStrength reply to determine access technology for CDMA/EVDO
Last modified: 2014-10-15 10:19:41 UTC
Apparently the Event Indication for signal strength may only report one radio type, while the explicit GetSignalStrength call reports all the active ones. This leads to flip-flopping between 1x and 1xevdo access technology: ModemManager[30723]: [/dev/cdc-wdm1] Received message (translated)... >>>>>> QMUX: >>>>>> length = 31 >>>>>> flags = 0x80 >>>>>> service = "nas" >>>>>> client = 1 >>>>>> QMI: >>>>>> flags = "response" >>>>>> transaction = 156 >>>>>> tlv_length = 19 >>>>>> message = "Get Signal Strength" (0x0020) >>>>>> TLV: >>>>>> type = "Result" (0x02) >>>>>> length = 4 >>>>>> value = 00:00:00:00 >>>>>> translated = SUCCESS >>>>>> TLV: >>>>>> type = "Signal Strength" (0x01) >>>>>> length = 2 >>>>>> value = B5:01 >>>>>> translated = [ strength = '-75' radio_interface = 'cdma-1x' ] >>>>>> TLV: >>>>>> type = "Strength List" (0x10) >>>>>> length = 4 >>>>>> value = 01:00:B5:02 >>>>>> translated = { [0] = '[ strength = '-75' radio_interface = 'cdma-1xevdo' ] '} ModemManager[30723]: <debug> [1365445356.036257] [mm-broadband-modem-qmi.c:1955] signal_strength_get_quality_and_access_tech(): Signal strength (cdma-1x): -75 dBm ModemManager[30723]: <debug> [1365445356.036299] [mm-broadband-modem-qmi.c:1970] signal_strength_get_quality_and_access_tech(): Signal strength (cdma-1xevdo): -75 dBm ModemManager[30723]: <debug> [1365445356.036332] [mm-broadband-modem-qmi.c:1981] signal_strength_get_quality_and_access_tech(): Signal strength: -75 dBm --> 62% ModemManager[30723]: <info> [1365445356.036442] [mm-iface-modem.c:726] mm_iface_modem_update_access_technologies(): Modem /org/freedesktop/ModemManager1/Modem/1: access technology changed (1xrtt -> 1xrtt, evdo0) ModemManager[30723]: <info> [1365445356.036565] [mm-iface-modem.c:976] update_signal_quality(): Modem /org/freedesktop/ModemManager1/Modem/1: signal quality updated (62) ModemManager[30723]: [/dev/cdc-wdm1] Received message... >>>>>> RAW: >>>>>> length = 18 >>>>>> data = 01:11:00:80:03:01:04:00:00:02:00:05:00:10:02:00:AC:01 ModemManager[30723]: [/dev/cdc-wdm1] Received message (translated)... >>>>>> QMUX: >>>>>> length = 17 >>>>>> flags = 0x80 >>>>>> service = "nas" >>>>>> client = 1 >>>>>> QMI: >>>>>> flags = "indication" >>>>>> transaction = 0 >>>>>> tlv_length = 5 >>>>>> message = "Event Report" (0x0002) >>>>>> TLV: >>>>>> type = "Signal Strength" (0x10) >>>>>> length = 2 >>>>>> value = AC:01 >>>>>> translated = [ strength = '-84' radio_interface = 'cdma-1x' ] ModemManager[30723]: <debug> [1365445356.768430] [mm-broadband-modem-qmi.c:5618] event_report_indication_cb(): Signal strength indication (cdma-1x): -84 dBm --> 47% ModemManager[30723]: <info> [1365445356.768663] [mm-iface-modem.c:976] update_signal_quality(): Modem /org/freedesktop/ModemManager1/Modem/1: signal quality updated (47) ModemManager[30723]: <info> [1365445356.768856] [mm-iface-modem.c:726] mm_iface_modem_update_access_technologies(): Modem /org/freedesktop/ModemManager1/Modem/1: access technology changed (1xrtt, evdo0 -> 1xrtt) This may happen because when MM calls NASSetEventReport(), it only configures the signal strength TLV, but doesn't enable the other ones (RSRP, SNR, SINR, IO, ECIO, RSSI). I'm not yet sure which one of those EVDO is.
So if we enable all the rest of the signal strength reporting, we get stuff like: ModemManager[3268]: [/dev/cdc-wdm1] Received message... >>>>>> RAW: >>>>>> length = 23 >>>>>> data = 01:16:00:80:03:01:04:00:00:02:00:0A:00:10:02:00:B2:01:13:02:00:4E:01 ModemManager[3268]: [/dev/cdc-wdm1] Received message (translated)... >>>>>> QMUX: >>>>>> length = 22 >>>>>> flags = 0x80 >>>>>> service = "nas" >>>>>> client = 1 >>>>>> QMI: >>>>>> flags = "indication" >>>>>> transaction = 0 >>>>>> tlv_length = 10 >>>>>> message = "Event Report" (0x0002) >>>>>> TLV: >>>>>> type = "Signal Strength" (0x10) >>>>>> length = 2 >>>>>> value = B2:01 >>>>>> translated = [ strength = '-78' radio_interface = 'cdma-1x' ] >>>>>> TLV: >>>>>> type = "RSSI" (0x13) >>>>>> length = 2 >>>>>> value = 4E:01 >>>>>> translated = [ rssi = '78' radio_interface = 'cdma-1x' ] ModemManager[3268]: [/dev/cdc-wdm1] Received message... >>>>>> RAW: >>>>>> length = 22 >>>>>> data = 01:15:00:80:03:01:04:00:00:02:00:09:00:14:02:00:EF:02:15:01:00:BE ModemManager[3268]: Cannot read the 'IO' TLV: expected '4' bytes, but only got '1' bytes ModemManager[3268]: [/dev/cdc-wdm1] Received message (translated)... >>>>>> QMUX: >>>>>> length = 21 >>>>>> flags = 0x80 >>>>>> service = "nas" >>>>>> client = 1 >>>>>> QMI: >>>>>> flags = "indication" >>>>>> transaction = 0 >>>>>> tlv_length = 9 >>>>>> message = "Event Report" (0x0002) >>>>>> TLV: >>>>>> type = "ECIO" (0x14) >>>>>> length = 2 >>>>>> value = EF:02 >>>>>> translated = [ ecio = '-17' radio_interface = 'cdma-1xevdo' ] >>>>>> TLV: >>>>>> type = "IO" (0x15) >>>>>> length = 1 >>>>>> value = BE >>>>>> translated = ModemManager[3268]: Cannot read the 'IO' TLV: expected '4' bytes, but only got '1' bytes ModemManager[3268]: [/dev/cdc-wdm1] Received message... >>>>>> RAW: >>>>>> length = 18 >>>>>> data = 01:11:00:80:03:01:04:00:00:02:00:05:00:14:02:00:30:02 ModemManager[3268]: [/dev/cdc-wdm1] Received message (translated)... >>>>>> QMUX: >>>>>> length = 17 >>>>>> flags = 0x80 >>>>>> service = "nas" >>>>>> client = 1 >>>>>> QMI: >>>>>> flags = "indication" >>>>>> transaction = 0 >>>>>> tlv_length = 5 >>>>>> message = "Event Report" (0x0002) >>>>>> TLV: >>>>>> type = "ECIO" (0x14) >>>>>> length = 2 >>>>>> value = 30:02 >>>>>> translated = [ ecio = '48' radio_interface = 'cdma-1xevdo' ]
Created attachment 240976 [details] [review] GobiAPI says ECIO and RSSI are unsigned
Created attachment 240977 [details] [review] Enable all signal indications that we've got We might as well, since the device doesn't seem to care about signal indications it can't provide.
Neither of these patches fix the real issue, which is access tech determination from the SignalStrength TLV, but they are just some things I found when looking into the original issue.
Should we just remove the call to mm_iface_modem_update_access_technologies() that's done in event_report_indication_cb()? That would only cause a problem if not all QMI modems supported NASGetSignalStrength, which I"m not sure about.
The current problem is that the access technology is updated from signal strength indications in isolation of other information. Since signal strength indications don't indicate all available radios together, the information is incomplete and leads to incorrect access tech. We really need to combine the signal strength and the access tech reporting in a slightly different way. We should actually have private data members for the following: 1) radio signal strengths on a per-radio (eg, GSM, UMTS, CDMA1x, EVDO, LTE) basis 2) current data service capability if registered with a network 3) current data bearer access technology if data is active these three items would be updated both synchronously via libqmi method calls (NAS GetSignalStrength/GetSignalInfo, WDS GetDataBearerTechnology, NAS GetServingSystem/GetSystemInfo) at various times, and also via appropriate event indications. Whenever any of 1..3 get updated, the "best radio" is calculated. #3 indicates the best radio and access technology explicitly. #2 doesn't so we need a hard-coded priority list, created by filtering #2 through which radios have a signal and prioritizing that. Then the signal strength is determined based on the best radio and emitted over D-Bus. If a bearer is active, the latest data bearer technology (#3) is always used as the access technology. If no bearer is active, then an access technology based on the 'best radio' from #2 is used instead.
(In reply to comment #2) > Created an attachment (id=240976) [details] [review] > GobiAPI says ECIO and RSSI are unsigned Moved this issue to the libqmi bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=85052
Moving bugreport to the new ModemManager bugzilla in fd.o; summarized the issue there as well. Please subscribe to the new bugreport to get new updates. https://bugs.freedesktop.org/show_bug.cgi?id=85051 Closing this report as NOTGNOME.