Getting Neighboring Cells info
E3V3A opened this issue · 26 comments
There is some issue with some phones in using getNeighboringCells() and getting info. This is apparently especially true for Samsung phones as user @rtreffer states:
Sorry for the noise, it is used by Android-IMSI-Catcher-Detector, at least for the Neighboring Cells fragment. This won't work as implemented though, as the call to getNeighboringCells may return an empty result (although it works well on my Nexus 4 after some time). I've created a pull request that calls the getNeighboringCells more aggressively. Note that Samsung devices are known to ignore the call. The pull request makes it possible to see neighboring cells directly after bootup (after a short lag).
Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.
@rtreffer Do you also know why Samsungs doesn't provide neighboring cell info properly? Do you have the possibility to investigate?
It looks like they never bothered to implement it in their ril. Which is shitty but OKish: getNeighboringCells returns data "if available". It is ok to declare it's never available on your platform.
Replicant does not know how to implement it either, I guess they would be happy if they could get a workaround.
I guess it's likely to improve in future versions of samsung devices as google now uses this API. Which should increase the pressure to implement it.
I'm not sure you where here then, but we used @illarionov's multi-ril client, on the Galaxy S2 (GT-I9100) to get neighboring cells, but we haven't gotten this to work on later Galaxies using Qualcomm modems (or on other phones for that matter), although it's possible we didn't give it a proper try. I can't see why it shouldn't work as long as the phone supports the multi-ril concept.
@E3V3A I do not have a QC phone... I'll try to get the information on my old galaxy nexus. It would be awesome if this would work with the replicant rild....
@rtreffer Did you try it? Any news? What we need to do is trying to modify the multi-client-ril component so that it can handle more XMM based Samsung phones... Should be possible.
Hello. I have the same issue on my Xperia J (Android 4.1.2) - no neighboring cells info.
Here is my logcat:
I/ActivityManager( 901): START {act=android.intent.action.MAIN cat=[android.intent.category.LAUNCHER] flg=0x10200000 cmp=com.SecUpwN.AIMSICD/.AIMSICD u=0} from pid 1131
I/ActivityManager( 901): Start proc com.SecUpwN.AIMSICD for activity com.SecUpwN.AIMSICD/.AIMSICD: pid=4946 uid=10053 gids={1015, 1028, 3003}
W/ActivityThread( 4946): Application com.SecUpwN.AIMSICD can be debugged on port 8100...
I/dalvikvm( 4946): DexOpt: illegal method access (call Landroid/content/res/TypedArray;.<init> (Landroid/content/res/Resources;[I[II)V from Landroid/content/res/XResources$XTypedArray;)
I/dalvikvm( 4946): Could not find method android.content.res.TypedArray.<init>, referenced from method android.content.res.XResources$XTypedArray.<init>
W/dalvikvm( 4946): VFY: unable to resolve direct method 82: Landroid/content/res/TypedArray;.<init> (Landroid/content/res/Resources;[I[II)V
D/dalvikvm( 4946): VFY: replacing opcode 0x70 at 0x0002
E/MultiRil( 4946): Samsung Multiclient RIL not available: Multiclient socket is not available
E/MultiRil( 4946): gsm.version.ril-impl = Qualcomm RIL 1.0
D/PhoneStatusBar( 975): addNotification score=0
I/AIMSICD_Service( 4946): Service launched successfully.
D/SizeAdaptiveLayout( 975): com.android.internal.widget.SizeAdaptiveLayout@411eab88child view android.widget.FrameLayout@41216410 measured out of bounds at 95px clamped to 96px
D/libEGL ( 4946): loaded /system/lib/egl/libEGL_adreno200.so
D/libEGL ( 4946): loaded /system/lib/egl/libGLESv1_CM_adreno200.so
D/libEGL ( 4946): loaded /system/lib/egl/libGLESv2_adreno200.so
I/Adreno200-EGL( 4946): <qeglDrvAPI_eglInitialize:294>: EGL 1.4 QUALCOMM build: AU_LINUX_ANDROID_JB.04.01.01.00.036_msm8960_JB_CL2644550_release_AU (CL2644550)
I/Adreno200-EGL( 4946): Build Date: 07/31/12 Tue
I/Adreno200-EGL( 4946): Local Branch:
I/Adreno200-EGL( 4946): Remote Branch: quic/master
I/Adreno200-EGL( 4946): Local Patches: NONE
I/Adreno200-EGL( 4946): Reconstruct Branch: AU_LINUX_ANDROID_JB.04.01.01.00.036 + NOTHING
D/OpenGLRenderer( 4946): Enabling debug mode 0
I/Choreographer( 4946): Skipped 47 frames! The application may be doing too much work on its main thread.
I/ActivityManager( 901): Displayed com.SecUpwN.AIMSICD/.AIMSICD: +1s734ms
I/CellTracker( 4946): neighbouringCellInfo empty - start polling
I/CellTracker( 4946): neighbouringCellInfo empty - try 0
I/CellTracker( 4946): neighbouringCellInfo empty - try 1
D/SizeAdaptiveLayout( 975): com.android.internal.widget.SizeAdaptiveLayout@411eab88child view android.widget.FrameLayout@41216410 measured out of bounds at 95px clamped to 96px
W/InputMethodManagerService( 901): Window already focused, ignoring focus gain of: com.android.internal.view.IInputMethodClient$Stub$Proxy@4124f020 attribute=null
I/CellTracker( 4946): neighbouringCellInfo empty - try 2
I/CellTracker( 4946): neighbouringCellInfo empty - try 3
D/nav ( 4946): selected Item Cell Information
D/dalvikvm( 4946): JIT code cache reset in 0 ms (41484 bytes 4/0)
D/dalvikvm( 4946): GC_CONCURRENT freed 1725K, 41% free 6115K/10243K, paused 5ms+14ms, total 98ms
D/dalvikvm( 4946): WAIT_FOR_CONCURRENT_GC blocked 30ms
I/CellTracker( 4946): neighbouringCellInfo empty - try 4
I/CellTracker( 4946): neighbouringCellInfo empty - try 5
I/CellTracker( 4946): neighbouringCellInfo empty - try 6
I/CellTracker( 4946): neighbouringCellInfo empty - try 7
I/CellTracker( 4946): neighbouringCellInfo empty - try 8
I/CellTracker( 4946): neighbouringCellInfo empty - try 9
I/CellTracker( 4946): neighbouringCellInfo Size - 0
I/CellTracker( 4946): neighbouringCellInfo empty - start polling
I/CellTracker( 4946): neighbouringCellInfo empty - try 0
I/CellTracker( 4946): neighbouringCellInfo empty - try 1
D/dalvikvm( 901): GC_CONCURRENT freed 1716K, 35% free 15522K/23815K, paused 4ms+9ms, total 98ms
I/CellTracker( 4946): neighbouringCellInfo empty - try 2
I/CellTracker( 4946): neighbouringCellInfo empty - try 3
I/CellTracker( 4946): neighbouringCellInfo empty - try 4
I/CellTracker( 4946): neighbouringCellInfo empty - try 5
I/CellTracker( 4946): neighbouringCellInfo empty - try 6
I/CellTracker( 4946): neighbouringCellInfo empty - try 7
I/CellTracker( 4946): neighbouringCellInfo empty - try 8
I/CellTracker( 4946): neighbouringCellInfo empty - try 9
I/CellTracker( 4946): neighbouringCellInfo Size - 0
I/CellTracker( 4946): neighbouringCellInfo empty - start polling
I/CellTracker( 4946): neighbouringCellInfo empty - try 0
I/CellTracker( 4946): neighbouringCellInfo empty - try 1
Thanks @Narengoyn for testing and providing logs. We're aware of this issue and it is probably an AOS issue. Until we find a more reliable method to do this, this issue will remain open.
Many phones are not supporting the AOS Neighboring Cells API. Samsungs in particular. Please check your phone on this list.
Thanks, that was very helpful information. Probably, you need to add this list to webpage of your project. But, if I have a smartphone, which does not support the Neighboring Cells API, can your software still determine my security status on my smartphone? Or do I just need a new phone for that?
No, you don't need a new phone. We cannot depend on the OEM messed up AOS API calls for this. Once we have QMI, RIL debug, or AT interface access, we can get this info in other ways, directly from baseband.
right now there is this detection: #91 But we are still debugging and testing it.
We have another 2-3 detection methods we can implement that work with the standard API calls.
Great. I like my phone. Thanks for explaining. I'll just wait for some update then.
This issue was filed already back in 2012. issue 24136. The last post there says:
On my Motorola Moto G (2013 - first gen) getNeighboringCellInfo() doesn't work too. Looks like there is no permission ACCESS_COARSE_UPDATES, which getNeighboringCellInfo is required.
But I've found that new method getAllCellInfo() from API 17 works fine at first glance. I had to choose 2G only in settings to get properly data (mcc/mnc/lac/cid/rssi) from cell towers.
So I suggest 3 things:
- Get this permission ACCESS_COARSE_UPDATES into our App, if not already there.
- Set the phone to use 2G only when actively "tracking" with AIMSICD. (This should be an optional setting as we need also 3/4G for better tracking.)
- Make sure we also check with getAllCellInfo() .
@E3V3A, thanks for this valuable Information! I will add permission ACCESS_COARSE_UPDATES into our App now. How to best add getAllCellInfo()? Please post some detailed instructions here. As for number 3 and 4, those sound great, can you craft a proper pull request for this, please?
I am carefully thinking ahead and want to simplify development and debugging of our App. Therefore, I would like to prioritize #164, which will be essential to check the detection mechanisms in the near future.
Fresh off the printing press:
The RAT iterator is preferred since each RAT NC list usually doesn't supply more than ~6 NC, even if up to 32 is supposed to be supported by 3GPP specifications. This is really an interfacing problem between AOS (AP) and RTOS (BP). So if we don't know how to use it, we set the unsupported flag, until we can learn how to use it. In addition the "Choose Retrieval Method" should probably be coded into a separate process function, that can be re-used by other detection methods, to get any data from various interfaces. Perhaps call it something like RetrievalInterface or InterFetch?
There is a small error in this diagram as it is missing the SIM interface block between SM and Hack.
@E3V3A, great draft! Just a quick question, didn't you want to rename Neighboring Cells?
Hi @SecUpwN - and welcome back :) in the meanwhile i updated my fork and i am working my way through the code. I found out that this are the Neighboring Cells! I already updated the technical overview . So everything is fine like this...
A well written comment about PSC from StackOverflow:
In UMTS, the PSC is a kind of local cell identifier. It is "locally" unique in that all neighboring cell, as well as all neighbors of these cells, are guaranteed to have a different PSC than the current cell. It also means that you will not ever encounter two neighboring cells with the same PSC. However, there may well be cells with the same PSC located in different parts of the country.
The NeighboringCellInfo for a UMTS cell will only have the PSC set while all other fields (MCC, MNC, LAC, CID) will be invalid. The only way to find out these parameters would be to store all fields (MCC, MNC, LAC, CID as well as PSC) for every cell you encounter, then upon getting an "unknown" PSC look it up in the stored data. (You would need to filter for neighbors of the serving cell, as the PSC is only a locally unique ID, not a globally unique one).
As an alternative, the PSC of a cell along with the MCC/MNC/LAC/CID tuple of one of its neighbors is also a globally unique ID that you could use. Be aware, however, that each cell would have multiple such identifiers (one for each neighbor).
This complicates the collection of NC data when on UMTS networks... It may also explain # 208.
Is anyone currently working on this one? In v0.1.27-alpha-b00 the neighboring cells list stays empty.
Yes, this should be looked into again. Since most people think NC list is not working when in fact it is, only that all fields apart PSC are empty or the decimal equivalent to 0xFFF FFFF, since they're redundant. (At least this seem to be the common scenario on most Samsucks.)
We need to look at what neighboring cells returns, if AOS API is ok like above we can parse it directly, if not we can parse the radio logcat as I suggested here.
Please re-test this issue now. (Using Buildozer build >= 211)
Tested with Buildozer Build B-528 (Git SHA-Hash 78400ae) again and this seems fixed.