Femtocell Detection: Toast message despite CDMA device

[SecUpwN]

Good evening developers, I have received a message from user "Ted", who mentioned that our warning toast message Femtocell detection is available on CDMA only also comes up on his CDMA device.

Solution:

1. The warning toast message should only appear to unsupported devices, related to #6.
2. Improve code to detect if the device is really supported - if not, display the toast message.
3. Gray out Femtocell Detection (and maybe also Femtocell Protection) if device is unsupported.
4. Replace message (currently CDMA Phones ONLY) with Your device is currently not supported
5. If the device is supported though, use the message Detect connections with Femtocells.

If his logcat is needed (which I think won't be the case for now), drop me a line and I'll send it to you.

Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.

[E3V3A]

The problem seem to be that most our developers are non-US based without CDMA based devices or networks. We simply can't test.

[ph0t0n]

can we find out which phone he has? it might be this problem:

typical USA user who reports US-CDMA phone is a Verizon customer. they have a mix of legacy US-CDMA proprietary plus 4G LTE.

some of their phones support only the world of Verizon (maybe North America), so that's this order of preference:

4GSM LTE, 3G US-CDMA (EVDO), 2.5G US-CDMA (1xRTT), ... (this phone is not very world friendly but roams well in USA rural area)

or

all of those modes PLUS 3GSM 2GSM so that it works in the entire rest of world =)

i am not sure exactly how these phones describe themselves via the Android APIs since they have mixed radios. I can try to look at an example Samsung S5.

i may also have errors here because their phones are custom hardware & firmware and i personally was always on 2-4GSM. it's a weird thing to keep track of.

[SecUpwN]

can we find out which phone he has?

He is using our app on his Sharp Aquos Crystal. The real question behind the whole Issue is this: Does the toast message appear by default on all devices, or is a mechanism implemented that prevents this toast message to appear once the device really is a CDMA device? @banjaxbanjo, please have a look.

[TPS]

I'm the original reporter; sorry for taking so long to chime in. (Mondays, being the beginning of the workweek here in the US, don't work well for me. ;)

For the record, my Aquos Crystal is on a Sprint (owned by Softbank) MVNO called Ting (owned by Tucows… yes, that Tucows ;). It occurs to me this phone is strange in that it's US CDMA, but international-only (Japanese local, I believe) GSM — at least, I think I read that in the phone specs somewhere — so it often identifies the network it's on as "Chameleon". Do you think that might be the problem?

Why not have a configurable option (defaulted auto, like now) to tell the Femtocell detection to operate in spite of whether or not CDMA is detected. I think that might help in such strange situations.

Please let me know what I can do to help. I'm not terribly technical on Android, so my devices are stock & non-rooted, & I'd like to keep them that way, but I'll give whatever info I can find.

Ted ☺

[DJaeger]

I would deactivate (grey out) the Femtocell options that doesn't support CDMA in any network mode. That could prevent much confusion.

[SecUpwN]

@DJaeger, sounds like a great solution to me. Can you craft a PR for this, please?

[DJaeger]

Will do it tomorrow.

[TPS]

I'm sorry, I'm confused: I thought femtocell detection (currently?) worked ONLY on CDMA, & this bug was about the fact CDMA isn't properly detected on my phone (& others?). Based on this, I'm not sure how @DJaeger 's solution fixes this.… Please clarify; I'd love to test a fix to this! ☺

[E3V3A]

@TPS You're not confused, someone else must be. That is correct what you describe:

I thought femtocell detection (currently?) worked ONLY on CDMA, & this bug was about the fact CDMA isn't properly detected on my phone (& others?).

Phone type should be detected here somewhere...

[E3V3A]

Go into settings and under network blahblah, set it to use CDMA only (or whatever it says).

[DJaeger]

@TPS My proposal is to prevent confusion of users if the toast only informs them or tells them they can't use, which is "The real question behind the whole Issue" like @SecUpwN said in https://github.com/SecUpwN/Android-IMSI-Catcher-Detector/issues/457#issuecomment-110230990

What has my proposal to do with https://github.com/SecUpwN/Android-IMSI-Catcher-Detector/issues/479 ?

[TPS]

@DJaeger I thought the graying-out had to with the icons' coloring of that issue, as I didn't understand what you were proposing vs. what I understand as the root problem of this issue. Now I understand you want to disable UI for non-applicable features, but I'm reporting that femtocell detection is incorrectly disabled on my phone (though the app's own display does say the phone is CDMA, I realize now, but still shows that "Femtocell detection is available on CDMA only" toast periodically).

@E3V3A The only option I have anywhere in my Android settings is to toggle "Preferred Network Type" between "LTE/CDMA" & "CDMA", which seems to have no effect on femtocell detection, even with full cold reboots (ie., shutdown, pull battery, wait, reinsert, startup) between toggles. If there is some similar setting in this app itself, I don't see it, though I'd love to have 1 to override the femtocell-detection availability routine.

[ghost]

Here is the cdma toast that is called when aimsicd service is started

CellTracker.java

        /* Check if it is a CDMA phone */
        if (mDevice.getPhoneID() != TelephonyManager.PHONE_TYPE_CDMA) {
            Helpers.msgShort(context, context.getString(R.string.femtocell_only_on_cdma_devices));
            return;
        }

[TPS]

Obviously, something so short & straightfoward has no chance of working in the real world.… ;)

Seriously, as I seem to have the only device anybody admits to having this problem (even from the alpha released in the last 24 hours), is there any else I can provide you serious Android coders?

Something else that I should ask: does femtocell detection require location settings to be on, like cell tracking, but not attack detection/monitoring?

[DJaeger]

@E3V3A, just eye-balling that switch-case statement you linked, I'm guessing my phone (& probably Nexuses [Nexii? ;], &c) would probably identify as both GSM & CDMA if asked correctly, but, since the GSM case comes first & then breaks, & since the overall logic assumes that a device is either GSM or CDMA, or not on any network, but has no case to catch a multi-network identifying device, my phone probably never gets a chance to identify as CDMA, & then fails a femtocell-able check elseplace.

Currently we are using getPhoneType() of TelephonyManager to determine if GSM or CDMA. It only gives one value back for either of them.

As of documentation:

Returns a constant indicating the device phone type. This indicates the type of radio used to transmit voice calls.

I think the only methode, that gives us info if multiple radios are available is getAllCellInfo(). As of documentation:

Returns all observed cell information from all radios on the device including the primary and neighboring cells. This does not cause or change the rate of PhoneStateListner#onCellInfoChanged.

The list can include one or more of CellInfoGsm, CellInfoCdma, CellInfoLte and CellInfoCdma in any combination. Specifically on devices with multiple radios it is typical to see instances of one or more of any these in the list. In addition 0, 1 or more CellInfo objects may return isRegistered() true.

So we can check if there is something in the list for the different network types.

[DJaeger]

Something like this:

        private static gsm_available;
        private static cdma_available;
        private static lte_available;
        private static wcdma_available;

        TelephonyManager tm = (TelephonyManager) context.getSystemService(Context.TELEPHONY_SERVICE);
        List<CellInfo> cellInfoList = tm.getAllCellInfo();
            if (cellInfoList != null) {
                for (final CellInfo info : cellInfoList) {
                    if (info instanceof CellInfoGsm) {
                        gsm_available = true;
                    } else if (info instanceof CellInfoCdma) {
                        cdma_available = true;
                    } else if (info instanceof CellInfoLte) {
                        lte_available = true;
                    } else if  (lCurrentApiVersion >= Build.VERSION_CODES.JELLY_BEAN_MR2 &&
                            info instanceof CellInfoWcdma) {
                        wcdma_available = true;
                    } else {
                        Log.i(TAG, "Unknown type of cell signal! "
                                + "ClassName: " + info.getClass().getSimpleName()
                                + " ToString: " + info.toString());
                    }
                }
            }

But if I understand it right, it would require, that cells of this type are available.

[E3V3A]

yes, maybe we should try that?

[TPS]

@DJaeger It is virtually certain than such actually exist, as there are many reports of the Nexus 6 on https://fi.google.com/ does precisely this. Granted, this has a special SIM, so does this in a separate manner than my cell (seems to be builtin & switches mode internally via Chameleon).

Also, no idea if these are as well-behaved as the spec says they should be, e.g., my cell showing CDMA on 1 AICD page, but still firing the toast that this issue is about! =\

Should both approaches be tried?

[DJaeger]

I'm not sure if I understand you correct.

My code sample is not equal to previous switch-case, as it looks at all available cells and sets the properties to true, if one of the available cellss is of that network type. So if a CDMA radio is available there should a CDMA cell be found and the property set to true and if a GSM cell is found the GSM property set to true and so on. If GSM and also CDMA cells are found both properties are set to true.

The current switch cases only can give a single type, as it only returns a single integer, fot that network type that is used for calls.

[DJaeger]

Am I wrong, that a cell can only be GSM or CDMA and not both? If the device has multiple radios it finds multiple cells with different network types, but each of them has only one network type, or not?

Or let me say it in another way: Can info be an instance of different classes, which are all childs of CellInfo but none of them is a child of one of the others?

[DJaeger]

To open the settings to set to "CDMA only" paste *#*#INFO#*#* into the numberfield of the keypad view of your dialer, and than click on phoneinfos.

[DJaeger]

I will create a PR to disable the preferences UI, when we have found a correct solution to detect if CDMA is available.

[E3V3A]

Am I wrong, that a cell can only be GSM or CDMA and not both?

Good question. A "cell" (tower) with a specific SID can only be CDMA, but I guess the connection could be downgraded to a GSM CID. (Wish I had CDMA device.)

[TPS]

@DJaeger As usual, in my last response, I misunderstood your (correct) definition of cell that means "network broadcast area of a particular device that connects into the cellular network" to (incorrectly) mean "a mobile device." I apologize, once & for all, for my US American misunderstanding of the various international Englishes represented here.

Now, onto the matter: does the above code test whether a mobile device identifies itself connected to certain type(s) of cellular network(s) (in which case I think I'm correct in my code comment), or querying what type a certain cell (network) that said mobile device is connected to (in which case you're certainly correct)? This seems to be different code section than the 1 @E3V3A pointed out much earlier, which I understand to identify, in general, what types of networks(s) the device has capabilities to connect &/or what types of network(s) are currently connected to.

From what AIMSICD shows me, it shows (correctly) that it's connected to a CDMA cell, but gets confused because the device doesn't actually seem to have CDMA capabilities!

Please let me know, as you all are much more familiar with the source than I am, &, the more I learn, the better I'm able to help.

@E3V3A I think you misunderstand CDMA / GSM in US context. Here, neither is an up-/downgrade from the other, but is simply a matter of which network(s) a device is provisioned for. If anything, LTE (& various flavors thereof) is turning into the accepted upgrade for both, & both seem to be on the way becoming deprecated here (due to mobile data speeds). If you ask me a more specific question, I'll do my best to answer, though I'm kind of "layperson+" in these matters. (I'm more software than hardware in my orientation. ;)

PLEASE, if there are any (other ;) US users following this discussion who're more expert/conversant on these matters, chime in — PLEASE! ☺

[DJaeger]

@TPS: US English has various differences to the english of the rest kf the world. ;-) Is Cell not the common word for "the broadcasf area..." in context of this app? :-) For better difference between words with different meaing I would switch to another one for one of them. In this context is a switch from cell to (mobile) phone or device or "a mobile device" much simpler than from cell to "network broadcast area of a particular device that connects into the cellular network". :-D

Now I don't be sure if I understood you correct. The code I posted should loop through all cells found in range of device. Each of them can only have one network type (CDMA/GSM/LTE/WCDMA). For each one found, the property (varable) for its type is set to true (no matter if it already was true from another checked cell before). This will not check if the device is registered to this cell, only if it is found by the device. As we can be sure, the device will not find a cell of a network type the device is not supporting, we can be sure all now set to true types are supported by the device. But this could be incomplete, as on the location the user is, one type could be not available (for example LTE is not available in every town/city/area).

So we can say with this code: Types set to true are supported by the device, but there could be more, but not less, than set to true.

Hope its now clear.

[TPS]

@DJaeger RE: the definition of cell in context of this app, of course, I was misunderstanding you, not vice versa.

RE: whether (network; ) cells can have only 1 type, I'm not certain this is true (LTE → CDMA or LTE → GSM downgrading due to provisioning vs hardware capabilities), but I'm far from an expert in this.

@Everyone But, I think this is far afield from the context of this bug. Can we try a quick-&-dirty override-of-femtocell-detection-capability preference (as mentioned earlier) to see whether actually using femtocell detection causes wierdness on these strange devices? What DOES happen if it's on all the time, anyhow, whether or not the device supports it? I mean, theoretically, at most, it should cause a false sense of safety from femtocells, but does it, e.g., cause app/system crashes, radio damage, &c? I guess, if I toggled that switch, I'd be willing to take a risk of the first, but not the rest, especially if I could test at a known safe/trusted femtocell immediately to check whether the detection functions on my device.

What do you all think?

[E3V3A]

Can we try a quick-&-dirty override-of-femtocell-detection-capability preference (as mentioned earlier) to see whether actually using femtocell detection causes wierdness on these strange devices?

A test round, sound good to me...

[TPS]

@E3V3A Thanks!

Anyone else, & who's willing to implement? I'll bite the bullet on testing if it seems safe enough to try?

[E3V3A]

I can build an app for you, but I'll need to know what to change...

[TPS]

@E3V3A I'd like to try what I proposed in my original comment almost a month ago:

Why not have a configurable option (defaulted auto, like now) to tell the Femtocell detection to operate in spite of whether or not CDMA is detected. I think that might help in such strange situations.

I supposed that can be a modified version of the current femtocell detection toggle.… Do you think that's workable, if safe as defined by

What DOES happen if it's on all the time, anyhow, whether or not the device supports it? I mean, theoretically, at most, it should cause a false sense of safety from femtocells, but does it, e.g., cause app/system crashes, radio damage, &c? I guess, if I toggled that switch, I'd be willing to take a risk of the first, but not the rest, especially if I could test at a known safe/trusted femtocell immediately to check whether the detection functions on my device.

Do let me know!

[SecUpwN]

What DOES happen if it's on all the time, anyhow, whether or not the device supports it?

Just to let you know, @TPS: The reason why #6 is not closed yet, is because we lack the code for GSM.

[TPS]

@SecUpwN I am aware of that, but, I figure, with the option defaulted as it is already &, hopefully, with enough UI notation, only risk-takers & bug-testers will flip that switch.

What I'm most curious about is whether femtocell detection will actually work when the device fails the current femtocell-detection ability check, or, conversely, if that check , as-is, is a reliable indicator of a CDMA device that can't detect femtocells.

I think that's worth the test, no?

[TPS]

@E3V3A @SecUpwN Do either of you know whether today's v0.1.31 release addresses anything re: this bug? I noticed some pref refactoring & am hopeful.… ☺

[SecUpwN]

@TPS, no, the current release does not address this bug yet since we have not yet come to a conclusion on what to implement since we're a little confused: This bug is essentially about that your CDMA device shows the toast Femtocell detection is available on CDMA only and you're not sure if this type of detection has been enabled properly or not, right? Reading further on, you make the statement that you'd like to enable the Femtocell Detection regardless of the device´ type, am I correct? Please clarify.

[TPS]

Reading further on, you make the statement that you'd like the option to enable the Femtocell Detection regardless of the detected device type, am I correct?

@SecUpwN I think you understand me, given the above modification. ☺

[SecUpwN]

I think you understand me, given the above modification. ☺

@TPS, I am not quite sure if it makes sense removing the toast and "obfuscating" on which devices the detection will really work - because that is in summary what you're asking for here. Currently the opetion Femtocell Detection is tickable for all devices, even GSM, which the detection does not work on. The reason, why you're getting the toast Femtocell detection is available on CDMA only can be considered a bug, but in other words I guess the detection of your device has just not worked correctly, but ticking the Femtocell detection option should in fact enable monitoring for Femtocells. If you want to further help us, you should be digging the web to find the code for GSM Femtocells. Thank you.

---

I now propose as a solution for this Issue to be implemented by @DJaeger or @banjaxbanjo:

1. Improve the toast message to not appear on supported devices, especially supported CDMA.
2. Side-solution to the request by @TPS: Do not gray out the button to enable detection (keep like is).
3. Re-check that device type detection has correctly been implemented to make that function work.

[TPS]

@SecUpwN If I understand you, this is new, truly confusing information. I think I understand you to say that, whether or not I get that toast, just as long as the Femtocell detection option is ticked on, AICD will detect femtocells — in spite of that toast?! Up 'til now, I always understood this to mean I get Femtocell detection XOR that toast!

Do confirm if this is what you mean! I'm almost tempted to travel to my nearest known femtocell just to try it.… ☺

[SecUpwN]

Do confirm if this is what you mean!

Clarification: Since you have a CDMA device, which should in fact be supported, the toast message should not be shown. And since the Femtocell Detection option can also be enabled on GSM devices (for which we currently lack the necessary detection code), the toast must be shown. Got that?

I'm almost tempted to travel to my nearest known femtocell just to try it.… ☺

You should really do that to support our development here and to actually test that function!

[TPS]

@SecUpwN I'm sorry, my confusion is still not resolved re: does whatever that produces the toast error disable / not enable Femtocell detection internally regardless of whether the option is toggled on, or does 1 actually not have to with the other (i.e., there's nothing in the code preventing detection from working in this case).

[SecUpwN]

I'm sorry, my confusion is still not resolved

Dude, you're really confusing me. Again: The Femtocell Detection should work on your device since the code we implemented is meant for CDMA. Thus, the toast you get should simply not be there. Regarding your question if the detection really works, you need to test this (and we would appreciate some feedback). Just because you're getting the warning toast, does not mean that the detection does not work on your device. I expect that the code for detecting the device type is lacking something, but since Femtocell Detection has been turned on, it should work. We need someone professional to look into this, I cannot tell you whether or not the whole thing works as expected. OP has been updated.

[TPS]

@SecUpwN Now, I'm clear: regardless of the toast, detection should work if it works at all.

I look forward to testing this on the weekend. ☺ Thanks for putting up with my lostness!

[E3V3A]

It only works on a certain type of Verizon femtocells AFACR...

[SecUpwN]

It only works on a certain type of Verizon femtocells AFACR...

@E3V3A, is there a way of making this available on all CDMA devices? If not, we should probably restructure that button to be only tickable if the device is really supported and gray it out if not.

[E3V3A]

Sure, if you can contact every CDMA femtocell producer and as them what IDs they use for their products.

[E3V3A]

Sorry, but we don't have any developers with CDMA who's able to fix it, so we won't.

[SecUpwN]

Sorry, but we don't have any developers with CDMA who's able to fix it, so we won't.

@E3V3A, please don't close Issues just because we don't have a developer fixing it yet. This Issue in specific was about something pretty simple: Ensuring that the toast Femtocell detection is available on CDMA does not get shown when the device is in fact a CDMA device. Means: This Issue should be pretty easy to solve by adding or improving the check like this: If GSM - show tiast, if CDMA - skip it.

@banjaxbanjo, please have a look at this and see why the warning toast appears even though @lop1 is using a CDMA device. Please have a look at the updated OP, if we add this, this Issue is in fact solved.

[DJaeger]

Why should we allow the user to active the feature on devices, that does not support it. We should update the code to correctly detect if it is supported (currently if CDMA is available) and allow the user only to active it then. Why should we allow the user to activate it on not supported devices. It makes no sense to allow him to activate but tell him it will not work!?

[DJaeger]

In addition: The detection should be coded in a way, that allows to easily extent the supported devices looking forward to #6.

[SecUpwN]

Why should we allow the user to active the feature on devices, that does not support it.

The thinking behind that was that if we cannot ensure that the code is definitely working on that device, let the user still activate the button to enable it even though a proper check is lacking.

We should update the code to correctly detect if it is supported (currently if CDMA is available) and allow the user only to active it then.

If you can do that, this would be great! So the new proposal (and likely the one with more sense) would be to gray out the button for non-supported devices and replace the message (currently CDMA Phones ONLY) with Your device is currently not supported If the device is supported though, then the button shall be waiting for activation and use the message Detect Femtocell connections. OP updated.

The detection should be coded in a way, that allows to easily extent the supported devices

Fully agree with that. Are you able to improve the code to solve this Issue, @DJaeger?

[E3V3A]

Actually the entire Femto-cell code as it is now, will be redundant, if we can support CDMA in general, the femtocell detection is trivial, and the current code could be dropped.