Raw android GSM radio modem access (text/call intercept) - Networking

Hello,
DISCLAIMER: This post is solely for academic purposes. Do not try to intercept a text or call as it is generally illegal in most if not all countries. Don't play with the licensed radio frequencies.
The question is: Can we use an Android phone, without any external radio receiver, to intercept a GSM call or text not destined to our phone? How?
Overview: GSM calls and texts use mostly insecure networks, protocols and encryption algorithms, all over the air.
This means that calls and texts can be intercepted and deciphered. This has been demonstrated at various security conferences and it is documented carrier-by-carrier at gsmmap.org.
{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
Source: Decrypting GSM phone calls (Karsten Nohl)
Prequisites: To hack GSM call or text we need:
1. Processing power to run the A5/1 cracking software.
I don't know if there is any port on Android(ARM) platforms but that's probably not a real issue.
2. A programmable radio receiver to have raw access to GSM uplink and downlink frequencies digital data. That's where we DON'T want to use an external radio module, and use the phone built-in radio module.
Let's have a look at the different issues behind this question:
A. Can the phone GSM modem listen to the uplinks (phone to GSM network) of other phones?
It is normally built to listen to the GSM downlinks. But whatever, we can already intercept much with the downlink.
Moreover, antennas may use some sort of beamforming that may require the hacker phone to be in a specific zone, if using a passive intercept technique.
B. What piece of software "filters" the GSM data not destined to the phone ?
First, we need to understand how the radio data is accessed on Android.
Source: Radio Layer Interface (Android Open Source Project, Kandroid)
The GSM filtering (in terms of frequency selection or data dismiss) should either occur at the baseband level or at the RIL level. Otherwise, that would mean it's handled directly in the radio chipset (and I don't think we can do much in this latter case...).
The RIL communicates with the baseband with AT commands (specs here). These AT commands seem too be to high level commands to treat raw data streams.
So I guess the suspect is the baseband firmware but I may be wrong.
C. Can we hack the baseband to access raw GSM data not destined to the phone?
Technically, yes, it's a file flashable with ODIN. (The RIL can be flashed too).
But I've not seen on this forum any special activity on custom baseband development (it's always official baseband firmware).
The issue is that the baseband is hardware-specific and it is closed-source: "Every mobile device that is connected to a cellular network runs some kind of baseband processor with highly proprietary and closed-source firmware." (source).
Attempts to hack official baseband firmwares to develop custom baseband firmwares is still only an emerging concept, at the specification study level.
Regarding open-source software, note that "Airprobe has, for most users, since been replaced by the cheaper Osmocom phones". OsmocomBB is an Free Software / Open Source GSM Baseband software implementation. It intends to completely replace the need for a proprietary GSM baseband software". However the list of OsmocomBB compatible phones is very limited.
The help and knowledge of xda community would be much appreciated to progress on this topic :highfive:
[EDIT] Interesting links:
Decompiling baseband firmware?
HackRF external transceiver (~300$)
[FAQ] The Baseband (Optimus 2x) by sudden36
Monitor mode for Broadcom WiFi Chipsets by Omri Ildis, Yuval Ofir and Ruby Feinstein (check their RECon PPTX presentation with footnotes to see how they reverse engineered the WiFi chipset firmware based on ARM)

First of all, this thread should be moved to "Security Discussions".
Second, you'll have quite some additional reading to do...
Then you'll have to realize that the firmware on the baseband is on the order of 60 MB for Qualcomm and 12 MB for Intel (XMM) BP's.
Whats you propose is certainly possible, if not already done with some NSA devices. (Check out their product catalog!) And they a have help from QCOM and Intel etc.
Also, much of the BB code running in QCOMs modem devices, are for Hexagon cores, which are harder to decompile, because of proprietary reasons. But the type of interception you're talking about seem very difficult if you don't know PhD loads of GSM and other mobile phone technology.

Ha?!

E:V:A said:
First of all, this thread should be moved to "Security Discussions".
Second, you'll have quite some additional reading to do...
Then you'll have to realize that the firmware on the baseband is on the order of 60 MB for Qualcomm and 12 MB for Intel (XMM) BP's.
Whats you propose is certainly possible, if not already done with some NSA devices. (Check out their product catalog!) And they a have help from QCOM and Intel etc.
Also, much of the BB code running in QCOMs modem devices, are for Hexagon cores, which are harder to decompile, because of proprietary reasons. But the type of interception you're talking about seem very difficult if you don't know PhD loads of GSM and other mobile phone technology.
Click to expand...
Click to collapse
Hi E:V:A,
Thanks for the information. I've been investigating on how bcmon team performed their hack of the Broadcom 4329/4330 chipset on Galaxy S1.
I'm trying to check if we can apply something similar for the GSM radio.
WiFi monitor mode is just achieved by bypassing some checks on the DSP firmware like "is this packet for me?" (indeed they enable the built-in monitor mode flag of the firmware) and transfers all the received traffic on the MMC bus, on a test channel. The patched firmware is applied on the chipset by simply using Broadcom driver write functions that writes to the Wi-Fi chipset RAM (there are no signature check, and there are also some mechanisms to "overwrite" functions of the chipset ROM code).
Something similar may be achieved with the baseband. It will be more difficult as the RIL is closed-source. Stil, I think Replicant provides an open-source alternative, I have to check libsamsung-IPC and Samsung-RIL.
On Galaxy S1, the baseband is a XMM6160 as you pointed out in some thread. Lucky enough, this phone's too old to have a Snapgragon chipset with Hexagon DSP.
Decompiling the /radio/modem.bin in ARM mode makes me think it's indeed ARM and that we may be able to do something.
Despite I've very bad ARM decompilation skills, some parts of the code seem meaningful when decompiled using ARM archtiecture.
Here's some extract (reverse engineering is allowed to this extent under my country law):
Code:
ROM:0050FF0C aOemPsdPsd_utac DCB "[OEM PSD] PSD_UtaCallPsSetReqQos2gReq",0
ROM:005AFED0 aMifNjfAmfLimit DCB "i`j`m`Limit over:150charsline",0
ROM:005AFEF4 aSmsErrorInInit DCB "[SMS]Error in initialising SMS",0
ROM:007DA718 aCatTraceSta_36 DCB " CAT TRACE:: status IND cause = MS_PAGING_PENDING at Line:%u Fil"
ROM:007DA718 DCB "e: ",0x22,"%s",0x22," Func: ",0x22,"%s( )",0x22," ",0
ROM:0081A921 aT_resel_intra_ DCB "t_resel_intra_freq_high_mob",0
Baseband "modem.bin" ARM decompilation result (from what I understand, blue is successfully decompiled code, white is blank space and undecoded code, red is decompiled code with issues like references to ROM code that are indeed not part of the modem file):
By the way, this proprietary stuff (baseband + RIL) has a "backdoor" (the modem chipset actually have root access to the phone data, but that doesn't mean there's a GSM backdor in the actual baseband code).
[EDIT] After reviewing the GSM specs, SMS are carried over "Dedicate Control Channels" (between the base station and the mobile device), that the phone in certainly not going to listen to naturally. Moreover this channel, as effect of TDMA, is hopping between frequencies. As the baseband is closed-source, it's not going to be a simple hack to just read the raw radio-fraquency data and guess the next frequency hop; that's merely impossible practically without programmable standard hardware chipset or better, a dedicated hardware that sniffs all channels simultaneously. HackRF should be useful for that, but still not small-factor enough to use it as a mobile phone peripheral.

Related

Resetting the Modem/Radio Stack under Windows Mobile 5

Under Pocket PC 2003, we found that there was a rare issue that arose with the devices and networks that meant that the only solution was to basically turn flight mode on and then off again (resetting the modem and radio stack in the process). The trick was to be able to do this programmatically so that the user did not have to manually do anything.
I tried several approaches to the problem but found very little help in the MS ConnectionManager and found that sending a reset command (ATZ) direct to the modem had a slightly erratic effect (sometimes working and other times not).
After a fair bit of research, I eventually found the solution to this to be the use of the DeviceIOControl command (detailed below - This code was available on the web, not created by me):
HANDLE hRil= CreateFile(L"RIL1:",GENERIC_READ|GENERIC_WRITE,0,0,OPEN_EXISTING,0,0);
if (hRil==NULL || hRil==INVALID_HANDLE_VALUE)
{
hRil= NULL;
return -1;
}
DWORD rildevresult=0,nReturned=0;
DeviceIoControl(hRil, 0x03000314L,0,0, &rildevresult, sizeof(DWORD), &nReturned,0);
HANDLE Ev=CreateEvent(NULL,TRUE,0,L"RILDrv_DataMode");
SetEvent(Ev);
rildevresult = 0;
DeviceIoControl(hRil, 0x03000318L,0,0, &rildevresult, sizeof(DWORD), &nReturned,0);
ResetEvent(Ev);
CloseHandle(Ev);
CloseHandle(hRil);
return 0;
Now for the problem: This series of commands does not work properly on WM5.
I do not have enough knowledge to know why, but the radio stack and modem get into a bit of a mess once this is run and the device has to be soft reset.
If anyone has another method of resetting the modem and is willing to share it, I would be most grateful.
Many thanks,
Graham.
I have been "playing" with this problem for a while now.
There are articles around that suggest that under Windows CE you need to unbind from NDS0: before you can power off an ethernet adapter (not entirely sure that this is what I want to do, but it does not seem to work anyway - probably a difference in the OS).
http://wiki.xda-developers.com/index.php?pagename=UniversalWM5Devices
shows the drivers for the Universal device (which is what I currently have in front of me). The RIL1: driver seems to be the correct one that I need to turn off, but it is definitely not working the way it should.
I believe that it might be a different IO control needs to be passed through (or possibly an extra one?) but I have so far completely failed to find out how to do this.
If anyone does have any information about this, I would appreciate it.
Further information regarding some of this can be found here:
http://rburdick.blogspot.com/2005/05/programatically-turning-pocket-pc-wlan.html
The problem here is that the code needed some adjustment before I could use it as a lot of the includes were missing and so forth. It did lead me to locate a lot of the IOCTL definitions in various include files, but RIL1 does not appear to use the standard codes.
Maimach posted this:
http://www.codecomments.com/archive421-2005-6-504006.html
I have seen this posted elsewhere but it does contain the code to turn flight mode on and off prior to WM5.
Graham.
/bump
Seemed editing my other post did not change the last post date.
Graham.
Graham - you're talking about flight mode, not wifi, so Robert Burdick's is not really what you're after, and in any event if you are interested in wifi, read his own follow up comments where he states that he's wrong with that code. It is in any event useful code, but it's not universally applicable wifi code.
The modem in the Universal is different to previous HTC devices AFAIK, and most of us have suffered some consternation getting the modem under control in WM5. It is possible, but the IOCTLs are very different now - try decompiling the wireless modem app to get a better idea.
However, this may all be, as Joey from Friends would say, a "moo point"
{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
If you're merely trying to go into flight mode, why are you doing it like this? Does your app/problem work when you manually toggle flight mode (eg from the start bar at the top of the screen).
And if so, does VJVolublis's flight mode control work in the same way?
V
vijay555 said:
Graham - you're talking about flight mode, not wifi, so Robert Burdick's is not really what you're after, and in any event if you are interested in wifi, read his own follow up comments where he states that he's wrong with that code. It is in any event useful code, but it's not universally applicable wifi code.
The modem in the Universal is different to previous HTC devices AFAIK, and most of us have suffered some consternation getting the modem under control in WM5. It is possible, but the IOCTLs are very different now - try decompiling the wireless modem app to get a better idea.
However, this may all be, as Joey from Friends would say, a "moo point"
If you're merely trying to go into flight mode, why are you doing it like this? Does your app/problem work when you manually toggle flight mode (eg from the start bar at the top of the screen).
And if so, does VJVolublis's flight mode control work in the same way?
V
Click to expand...
Click to collapse
Thanks for the response.
I was aware that Robert Burdick's code was not meant for using to turn flight mode on and off, it was simply another source of investigation as I had hit a dead end (I thought it might inspire someone else somewhere, so I put in the link).
I have never decompiled an app before. Any pointers on where to start with that would be helpful as it may help provide an insight (and which wireless modem app too?)
Turning flight mode on/off was the only effective way of clearing the radio stack on the device when it was getting into a buggy situation where the device (and network it turns out after some investigation involving the network operators) thought that the device had a connection, but it was not transmitting any data. This problem may or may not have been resolved on the newer devices, but we are reluctant to take that risk and so we are trying to get this to work on the WM5 (Universal) device.
It works fine when done from the start bar, but not programmatically.
I have not come across "VJVolublis's flight mode control". A quick look on the web did not turn up anything either. If you have a link to this or some such, I would appreciate it.
Thanks for the help,
Graham.
Hi Graham!
Just search for VJVolublis, or check it out on my webpage (look in my sig).
Let me know if the flight mode control works in VJVolubilis; PM me to discuss.
V
Thanks for the assistance on this V.
After a certain amount of messing around it has become evident that the T-Mobile ROM needed upgrading for V's radio reset software to work correctly (so a nice little radio/rom error in there somewhere).
I upgraded the T-Mobile MDA Pro ROM from:
ROM - 1.20.32
Radio - 1.06.00
Protocol - 42.40.P8
Ext ROM - 1.20.120
to:
ROM - 1.30.114
Radio - 1.10.03
Protocol - 42.44.P8
Ext ROM - 1.30.232
and now V's reset works correctly. The download is available from the following link:
http://t-mobile.iris-global.com/download_manager_mda_pro.html
I have not tested the RIL version of the reset to see if it too is resolved, but frankly, V's reset is the better way to go, so I'll stick with that. I'm not posting details of V's reset here as it is his to give away if he decides to.
Graham.
Bah, Humbug
The code does not work
Initially, V's code appeared to work, but after a single radio off/on, any subsequent attempts jammed the device as before.
After some messing around, it appeared that the best solution was:
Turn radio off
Reset the RIL1 (as in OP)
Turn radio on
This too has turned out to be an erratic solution at best. I have managed to reset the modem up to 7 times in a row with this solution but sometimes I manage only 1 or 2, after which it jams the connection management. After jamming, the only solution is to soft reset the device.
V suggested looking at unloading the relevant device driver, which I also tried, but to no avail.
If anyone else has any thoughts on how this might be solved then please help.
Graham.
P.S. I have an XDA Exec coming soon as we want to check whether the issue is one specific to the T-Mobile devices.

direct GSM access?

I am particularly interested in the wizard, however on a fundamental level WM will most likely operate the same across most models in respect to this issue (or at least that is the theory).
I realize that most GSM boards have processors on them which do things like channel syncing (which is fairly time sensitive since its tdma&fdma), a5, gsm framing, and all that. You more or less connect a sim, speaker and mic, and treat the gsm rf board as a black box.
I am hoping that somewhere someone has unearthed something that allows more direct control over the gsm board on these phones. I am aware of engineering mode, however that is not quite what I wanted.
I would like to be able to at the very least set the call parameters before a call goes out. For example, lets say that I want to disable A5, sinec there are 3 standard levels one being no encryption, and the tower and the phone negotiate and agree upon the highest common, something in the phone somewhere has to say that it supports encryption.
I am just uncertain if all that is burried away in a 'black box' somewhere and its not a software problem from within WM.
If anyone has any ideas I would greatly appreciate it, even if they are pointers to research material that may help me out a bit.
On WinMobile GSM part is isolated from the windows part, like in normal PCs modem hardware is isolated from mainboard. GSM part has its own CPU, RAM, ROM, operating system, and communicates with Windows via COM-port (or USB port in Universal). For example Universal has Qualcomm MSM6250 chip with some proprietary OS. HTC Himalaya had a different chip (I don't remember it now), and OS was based on nucleus RTOS. Anextek SP200 communicator had Siemens MC45 modem inside.
GSM hardware is a black box for WinMobile OS. MS specifies only some recomendations for OEMs, and controlling encryption is not among them. You can control it if GSM vendor supports some AT command, or some other proprietary method (maybe via dev_specific RIL command).
In the case of Universal, its GSM can be controlled from a PC with the usual Qualcomm diagnostic software (QXDM, QPST, etc), when you setup the device as a pass-through bridge between PC and GSM module. But I don't know any methods of doing the same from inside WinMobile.
mamaich said:
GSM hardware is a black box for WinMobile OS.
...
You can control it if GSM vendor supports some AT command, or some other proprietary method (maybe via dev_specific RIL command).
In the case of Universal, its GSM can be controlled from a PC with the usual Qualcomm diagnostic software (QXDM, QPST, etc), when you setup the device as a pass-through bridge between PC and GSM module. But I don't know any methods of doing the same from inside WinMobile.
Click to expand...
Click to collapse
That is what I was afraid of. Most of the GSM radio boards (or individual chips) are set up to act that way, and since its faster and cheaper I really dont know of anyone that hasnt done that in any phone that was made in the last few years.
At any rate, is there any documentation that discusses how to locate which com port or other method is used to access the GSM device within a wizard (or any other htc model, odds are many of them are similar, if not identical with this subcomponent).
Are there any known AT commands? my first project is to write something similar to the gsm engineer mode program, obtaining BTS information. I am unsure if this is obtained only via AT commands or if its something more involved, but welcome any information on this.
Found what appears the be half the answer at http://wiki.xda-developers.com/index.php?pagename=RIL While that gives me access to the radio for some stuff (location data app that can work with gsmloc.org for example) it does not appear to enable me to set any parameters for a new call.
So if anyone knows of any tricks that would help say for example disable a5 crypto (on a per call basis idealy) or something similar to the setup of a call I would still appreciate hearing about that.
I know that Typhoon ( spv c500 / i-mate sp3 /Dopod 565) memory block with gsm info data. I am trying to find it in Magican - but no results. I dont know how Typhoon place this info in mem.

Speed testing and RIL settings

So I felt like doing some testing with a couple different radio versions and RIL settings to see if I actually did get any differences in speed or latency.
Phone is running CM6 Nightly 09192010. I did 8 tests on each state. Tests were done from 12a-1a so virtually no load on the network. After changing settings, I rebooted twice. All 8 speed tests were done by the SpeedTest.net app. I checked radio signal strength in Settings>About>Status and waited roughly 10 seconds for it to stabilize at the lowest value. I am located in Tempe, AZ. T-Mobile has not officially enabled HSPA+ but the download speeds reflect it. I hit 6.1mbps a couple times The phone was not moved at all for the entire process. To see the exact RIL settings I used, links are in the spreadsheet.
I have attached my excel file for ****s and giggles
Here are my results:
{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
Green and positive means it was an increase with respect to the baseline. Red and negative means a decrease with respect to the baseline.
The "5.10 Error" is strange. I tried to flash 5.10 (see link in spreadsheet). It kept erroring in fastboot. Tried in recovery and it looked like it worked, but the bootloader was reporting 5.08. I did the tests anyway and I got different results which is strange.
In case you like numbers:
http://spreadsheets.google.com/ccc?key=0AmKcnlXnO3h6dExGSUlIdUtvSG56X2lvVHAwSlpSSlE&hl=en
PLEASE take these with a grain of salt! There are MANY variables I can not control that will affect signal strength, through put, etc. etc.
Also, one thing I noticed with 5.08U+Tweaks is the download was much more consistent. The standard deviation was much lower than the others.
Where are these radios of which you speak? (particularly 5.8+Tweaks)
Links are in the spreadsheet.
Since 5.10 is a desire radio, it won't flash unless you have a "PVT SHIP S-OFF" nexus.... those are usually engineering samples where the SPL allows you to flash literally ANYTHING...
This was discussed earlier in the 5.08 radio thread.... I'll try and find the exact posts when I get home later, but IIRC, the one person who was able to flash the desire radio did notice increased speeds.... but since its not quite the same phone AFAIK your chances of bricking the phone are exponentially higher....
That being said, phenomenal breakdown of the build.prop settings! I'll have to look around and see if I can contribute anything later, but great job!
Sent from my Nexus One
Breakdown
Okay, found it here:
http://forum.xda-developers.com/showthread.php?t=723839&page=42&postcount=413
From that page forward is the discussion I was referring to earlier...sorry it's somewhat long, but I think they covered the desire radio question thoroughly there...
Okay, I apologize in advance for the following post, I know it's rather long-winded, so feel free to flame away if you disagree with anything I'm saying here or any of it is blatantly incorrect (I apologize if it is)
And these are just my thoughts and observations of what works for me, I'm not recommending you settle on anything here before figuring out what works for you...
OP, I'm sure you know this already based on your research here, but here's a breakdown of the "H" and "U" 'versions' of the radio for others who might be reading this thread and are interested in "tweaking the radio"
H - as in 32.36.00.28H_4.06.00.12_7 or 32.41.00.32H_5.08.00.04
Means that ro.ril.hsxpa = 1 (in the build.prop) is set, putting the radio in HSDPA mode rather than just plain old UMTS
U- as in 32.36.00.28U_4.06.00.12_7 or 32.41.00.32U_5.08.00.04
Means that ro.ril.hsxpa = 2 (in the build.prop) is set, which enables HSUPA
Now, not having these values set in build.prop doesn't necessarily mean that you won't get the HSDPA goodness (AFAIK AOSP ROMs are usually preset to hsxpa = 1 and Sense ROMs are usually preset to hsxpa = 2) because I believe that Android (or at least the radio) is hard-coded to jump up to the higher speed connection if available, but having these settings in build.prop just means that the phone will try making an HSDPA connection sooner than it would otherwise...
The OP has compiled an EXCELLENT breakdown of both speed tests/ping times/signal strength....that's outstanding work....
Sorry I'm making this post a little drawn out, and I'm not trying to hijack the thread here, but I'll share my 2 cents on what works for me if anyone is interested. Also, I apologize in advance for not having as much hard data as the OP, as these are merely my observations....
Ultimately, there is not one way of specifying these settings that will work for everyone....they are HIGHLY dependent on location, signal strength, radio version, ROM, service provider, number of applications running, clock speed, kernel type and version, maintenance on the cell towers.....etc....I could go on for a while here....
So what I'm trying to say here is that THERE IS NOT ONE SOLUTION THAT WILL WORK THE SAME FOR EVERYONE....
For reference, I'm living in Chicago, on T-Mobile, running eVIL's NXSense Desire Rom v1.20 with the network fix described in the second post (of that thread) applied (it replaces libhtc_ril.so and libhtc_acoustic.so because of connectivity issues when waking up the phone from standby, sorry, I don't know enough about how those executables work to give a better explanation) so I'm sure that makes a bit of a difference...
I'm also using the 4.06.00.12_7 radio (Official Froyo OTA), I tried the 5.08.00.04 radio for a while and I felt like it got slightly faster speeds and ping times (could be just placebo) but I ultimately switched back because it did seem to cause noticeably increased battery drain and my girlfriend repeatedly complained about my voice sounding "digitally mangled" during calls...
Though I agree with the OP's statement that the 5.08 radio did provide much more consistent speeds....with the 4.06 radio I've hit 5.2mbps (same situation with HSPA+, not officially turned on in Chicago) and then I'll be lucky if I can get 1mbps a couple tests later.... I did notice that ping times were also much more consistent with the 5.08 radio (usually around 90ms-160ms) and that unlike the 4.06 radio, did not usually require a "warm-up" test (usually the first speed test was garbage because the speed only kicked in about half-way through when radio/software/network realized that it needed to switch into HSDPA mode, this happens CONSIDERABLY more often with the 4.06 radio)
Okay, sorry, I don't mean to turn this into a discussion on radio versions....back on topic...
There seem to be some settings that work globally across both areas and providers, but most of what works well is limited to your location and your service provider.
It seems that setting ro.ril.gprsclass = 12 should work universally, from what I've read in other threads there hasn't been any negative reaction to this setting, as it just adjusts the number of GPRS timeslots requested by the phone. A quick glance at wikipedia reveals that UMTS (and by extension HSDPA) is still based on the GPRS core network, and while the nexus one's official specifications stated that it only supports GPRS class 10, I did notice a slight improvement with Class 12 set compared to without.
From what I've read during my time lurking on XDA, it seems that setting ro.ril.hsxpa is a bit of a mixed bag...some people are reporting that when it is set to = 1 they see dramatic differences in speed compared to = 2 or not being set at all....though some report that = 2 seems to work better and more quickly than = 1....like I said earlier, AOSP ROMs (Cyanogen, etc...) usually have it set to = 1, and that seems to work for most people using those particular ROMs....on the other hand, Sense ROMs (like any Desire Port) usually have it set to = 2, which also seems to work well for most users of those ROMs
What I've noticed when I have it set to ro.ril.hsxpa = 2, upload speeds seem to double from hsxpa = 1 regardless of location....
Also, these are not mentioned by the OP, but setting ro.ril.hsdpa.category = 8 and ro.ril.hsupa.category = 5 seem to increase the speed slightly from not having either set (look up "HSPA" on Wikipedia for more information on HSDPA/HSUPA categories and what they usually mean)
Since HSDPA category 8 is the highest speed the chipset in the nexus will support, there isn't really any reason to set it higher, though setting it lower could potentially increase speeds for those living in areas that haven't been upgraded to HSDPA 3.6 or 7.2... Same thing for HSUPA category 5, it's the highest the nexus will support, but not having it enabled would probably help in areas where your service provider has not enabled HSUPA...
Setting ro.telephony.default_network = 3 is the same thing as setting the preferred network type (in the *#*#4636#*#* testing menu) to GSM Auto (PRL), whereas setting it to = 0 would be the same as setting it to WCDMA Preferred....I'm not sure what setting 1 or 2 would do here, as this is just what I learned from my build.prop
Ever since I got my nexus I had it set to WCDMA Preferred, though when I switched to eVIL's NXSense about a month ago and found the default setting to be GSM Auto (PRL), I ran with it and it seems to be faster that way....or I'm at least getting less instances where it will randomly lose signal....but this could also be due to T-Mobile upgrading the network in the Chicago area (HSPA+ here we come! )
Okay, so that's about it....sorry again about that being so long winded, I just wanted to share what has been working for me and hopefully clear up any confusion for those reading this thread....
I'm sure there's some things I've left out of this or stated incorrectly, it wasn't meant to be exhaustive or authoritative, just merely my observations on the matter....
And thanks again for the OP for starting this topic and putting up their findings in spreadsheet form (I'm a statistics geek ) it is very well compiled and organized....I hope I didn't clutter up the thread too much here....
Radio Interface Description
If anyone is interested, I found a more detailed explanation (from Google themselves!) on how the Radio Stack works...
http://source.android.com/porting/telephony.html
It gets into technical details that are a little over my head and it doesn't have a ton of information in regards to what is in question here, but I think it is still somewhat relevant and, if you have time, is a very informative read...
I'm not so concerned with blaaazing speed, as I am with sensitivity of the radio. I need reception in outlying areas, and I suspect this would help with speed as well, getting HSDPA sooner.

Mesh cell phone network = Walkie Talkie

Good day every one
Really long time ago I had an idea! But few other people had the same idea Other projects use WIFI for a connection but I am talking about actual cellular network (GSM).
The idea is: add a feature to an open source cell phone to be able to make calls without a network provider. The design will look like a computer mesh network.
{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
Think of every cellphone like a Cisco network router with dynamic routing enabled.
Each phone will be aware of the presence of other phones and will have route table to every single one. There is no centralized server sort of like peer to peer.
When a user wants to make a call, then the cellphone will display the devices that are online and can be reached.
Look at the picture above and notice that there are more than one route to each device. Having many phones like that will increase the coverage!
Now does anyone know how to implement a such thing?
Maybe use android phones? Since OS is open source maybe it is possible to add this into it?
What do you think?
Reading materials:
http://www.cisco.com/en/US/docs/wireless/technology/mesh/7.0/design/guide/MeshAP_70.html
http://en.wikipedia.org/wiki/Mesh_networking
http://www.opencellphone.org/index.php?title=Main_Page
http://ipod-iphone.blogspot.com/2008/07/neo-freerunner.html
http://www.physorg.com/news198298057.html
http://www.servalproject.org/
http://bigthink.com/ideas/26480
http://www.freekorea.us/2011/02/20/...y-to-bring-cell-phone-service-to-north-korea/
http://www.psfk.com/2010/07/cell_phone_network_that_doesnt_need_towers.html
I dont think its practically feasible..
And moreover You cant use Service Provider's cellular network just like that ( and that also free)
man u realy want to learn how cdma, gsm,edge,2-4.5 g networkz work. and whatz a mobile handset realy do when its connected to a network.
send from my hd2 @ dorimanx v.3.0.0.rom,with 2way rec kernal.
I think Serval Mesh is what you want
EDIT : oups, already in your list...
amritpal2489 said:
You cant use Service Provider's cellular network just like that ( and that also free)
Click to expand...
Click to collapse
The idea here is to create an independant cellular network, using only the GSM equipment of phones, without using the service provider network.
sounds like a great idea, i would want something like this for sure. but the only down side is that you could only make a call for as far as the network broad casts which means in a small town it would really suck.
Nice idea but very costly.
Sent from my Galaxy Ace using Tapatalk
That's an interesting concept, but from what I understand, to make a call without an operator, both phones will have to be connected to the mesh network, right?
That situation would be rather rare, it's like making a video call between two iPod touch (that don't have a cellular network). If the other side is not connected to WiFi at the moment, the call won't go through.
Also something to think about is the battery life. If other people's calls would be routed through your phone all the time, it would drain the battery very fast.
The unfortunate bit to this idea is that, barring hardware,privacy, and feasibility constraints...If you implemented such a network, there would be no guarantee that you would be within the bounds of the network at any time. With current providers, there are rough estimates as to the coverage area that are fairly accurate, depending on exact conditions.
With this system, if a couple people in your neighborhood leave the town or country, suddenly, you have no service, or slow service.
It'd just fluctuate too much and wouldn't be reliable.
Phones hardware and closed-source software isn't designed to ad-hoc networking. IMO the closest available solution for that is this:
http://openbsc.osmocom.org/trac/
It is definitely an interesting idea, sorta makes me thing of "Ad-Hoc Networking for Phones". The only problem is, the phones would be limited to calls in their "network", so if you had 3 people in a desert, they could call each-other, but would be otherwise sunk
The problem though lies in that it would basically use your phone to power everyone else's phone service, and that would mean that your precious phone would be crunching data all day long, and eating batteries like they are going out of style (Not that it doesn't already).
So while in-theory you could get cellphones to all link up in a row and make a cell-to-cell network, latency would increase exponentially the more phones you have to "hop", and battery life would decrease.
Good thinking, but you would be better off starting your own cell network, and not charge outrageous prices. I am sure that we would all be happy to switch if you had good coverage and reasonable service
Nice idea hoping network providers would agree to implement such network feature.
But on the other side, it's far way impossible. For sure network providers would not allow that because it's some sort of a hacking over there frequency.
Not like Walkie-Talkies or CB Radios (Civilian Band Radios) where they operate at there own frequency with there own cell site for CB Radios.
I think the only way to make it possible is to hack the phones frequency and make it adjustable and add a unique ID for each phone. i.e. just like how the SIM Cards work. Once the frequency is hacked, then it is possible to control the transmitter.
Anyway, this is just my own IDEA, correct me if im wrong.
Nice idea,
How about openBTS ..? openbts,sourceforge,net
what different..?
I really have been thinking anout the same thing.somehow its gonna crack.
neat idea. although i agree with above posts,
battery would be an issue.
what if someones phone dies?
also, i see privacy being an issue. sure you could encrypt the call or text, but you would have direct access to every device in between point a and b. what would stop some smart guy from finding a way to invade your device. or write some malware that would run across the mesh. maybe i don't understand mesh networks well but it seems like a concern that would be valid.
biggest issue i can see is reliability. there are way to many variables for this to work out of heavily populated areas.
some kind of closed demonstration would be cool though
The problem with this is the modem/radio firmware is closed. It would be totally possible if we can get proper source for the modem/radio for each targeted device.
The battery drain would be tremendous. however this may be implemented in the form of an app or a function in android which can be switched off when not needed. This would also address the network congestion issues in crowded places. The more handsets the better.
It's an interesting idea, but has limits
If we thought about creating a new phone for this new network so that we weren't restricted by current cellular standards or architecture, it could be a good idea. The number of clients that the network could support via RF would be limited, however, because of the amount of signalling necessary between peers in a P2P environment and the fact that RF is broadcast, not point-to-point. Therefore, in order for peers to be able to hear each other over a reasonable distance, there would need to be a limit on the density of the mesh's population. In the current cellular topology, this limit is quite high because each handset only needs to communicate with one tower at any one time. In a mesh topology, each handset would have to communicate with a bunch of others in order to maintain the mesh and do the work of moving data through it.
So, this sort of topology is well-suited for low-density environments, but not so low-density that a handset can't communicate with at least a couple of other handsets. Also, at least one of the handsets would need to be able to communicate with a base station so that the whole mesh has access to the global comms network.
It's possible.. but impractical in a few cases.
I could understand in a densely populated city.
But what would the effects have on the radio usage?
"there by also the effects on battery life"
You'll find a nice video introduction into creating your own GSM network when Googling "CCC gsm network" and look at the 3rd link (I'm not allowed to post outside links). This should allow you to understand some of the GSM related technical terms on the OpenBSC page. I'm not sure if the guys from the video are the same people running OpenBSC.
I think that VoIP would be more interesting for you. Since it's really easy (NAT-ing can be nasty if you use multiple clients) to implement and you can use it over WiFi (generally internet).
So you could install a VoIP server at home accepting phone calls and forward the calls first to your mobile phone via WiFi when the phone is connected to your WiFi, otherwise the call can be forwarded via WiFi. You should even be able to use your VoIP Server at home to forward a call from your mobile phone over the internet to another phone number.
I think this is one of those pie in the sky ideas. While it sounds great there are some huge challenges. First and foremost the radio in your cell phone is locked down and you don't have the access that you need to be able to do that. The second issue is security. Routing voice would be fine but routing data, you pretty much have the worlds easiest man in the middle attack. The third issue is spectrum. Cell phones use RF spectrum that is bought and paid for, as in we can't use it otherwise the FCC could fine us lots and lots of cash money. And like others have said battery life would be awful.
I think there is a potential solution here though. Purpose built hardware. I know that some of the Ham bands are pretty close to the cell phone bands (close enough to work with cell phones). We could design a piece of hardware to act as a tower and we could start our own network. Using the internet as a backbone.

A2017U dual stream / antenna AC wifi - 866mbps connection

Is there any way we can enable dual stream AC (5ghz) connection on A2017U Axon 7? There were some discussions here on xda and also on zte forums but nothing clear. It seems that the phone and hw is capable as it seems some A2017G users were able to connect via two streams (866mbps), showing screenshots, instead of one stream (433mbps). It was also a suggestion that the US rom is limited somehow, while the International (G) rom has this enabled. While looking for G rom, latest seems B09 which is Android 6.0.1 based, as I wanted to install the international rom on US Axon 7 to check.
Perhaps @DrakenFX and @Unjustified Dev may know more.
Any thoughts? Thanks
Edit:
https://zteusa.jiveon.com/thread/12163 :
"This is an issue, and it should be an easy fix as the global version's software allows 866Mbps. "
https://forum.xda-developers.com/axon-7/review/wifi-strength-range-throughput-t3430742/page3
"- Axon 7 only connects at 433Mbps due to the lower Qualcomm WiFi version in the soc.
- That's not true. I have an Axon 7 and it connects Up to 866mbps (A2017G)."
{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
"There are two Qualcomm VIVE chipset that can be paired with the 820 -- https://www.qualcomm.com/products/vive/chipsets -- scroll down to the chipsets for devices. One tops out at 433 and the other tops out at 866. It going to depend on which version of the chip they used. My guess for a "budget flagship", they used the lower of the two chipsets."
https://forum.xda-developers.com/axon-7/review/wifi-strength-range-throughput-t3430742/page4
"It's been confirmed already. People have flashed the global rom onto the US model, and it completely fixes the wifi speed."
https://www.qualcomm.com/products/vive/devices
"ZTE Axon 7 - 2x2 stream"
dr3am_r said:
While looking for G rom, latest seems B09 which is Android 6.0.1 based, as I wanted to install the international rom on US Axon 7 to check.
Click to expand...
Click to collapse
Don't know about everything else, but B09 is ancient now. There's B10 and B11 for marshmallow, and B01, 02, 03, 04, 05 for Nougat 7.0 and 7.1.1. And you can install these on an A2017U with a lot of care not to flash anything with a non-hlos.bin inside
Choose an username... said:
Don't know about everything else, but B09 is ancient now. There's B10 and B11 for marshmallow, and B01, 02, 03, 04, 05 for Nougat 7.0 and 7.1.1. And you can install these on an A2017U with a lot of care not to flash anything with a non-hlos.bin inside
Click to expand...
Click to collapse
Thanks for the feedback, I installed G Rom B05 7.1.1 aaaand connection still 433 on AC, not 866. Wonder if there is a difference between A2017U and G of wifi chipset used.
Still awaiting some feedback from any that would know how to diagnose current issue at least to have a clear picture of how things are...
dr3am_r said:
Thanks for the feedback, I installed G Rom B05 7.1.1 aaaand connection still 433 on AC, not 866. Wonder if there is a difference between A2017U and G of wifi chipset used.
Still awaiting some feedback from any that would know how to diagnose current issue at least to have a clear picture of how things are...
Click to expand...
Click to collapse
i'm pretty sure it won't work, but you could try the magisk module for OP3 and 3T. I installed it once but never tested it really. Since the 3 and 3T are SD820 and 821 phones there's a big chance that the module will work, otherwise it won't do anything and you can just uninstall it (in other words, you just can' brick your phone with it)
Choose an username... said:
i'm pretty sure it won't work, but you could try the magisk module for OP3 and 3T. I installed it once but never tested it really. Since the 3 and 3T are SD820 and 821 phones there's a big chance that the module will work, otherwise it won't do anything and you can just uninstall it (in other words, you just can' brick your phone with it)
Click to expand...
Click to collapse
@choose an username what Magisk module are speaking of? And what does it (supposed) do?
Choose an username... said:
i'm pretty sure it won't work, but you could try the magisk module for OP3 and 3T. I installed it once but never tested it really. Since the 3 and 3T are SD820 and 821 phones there's a big chance that the module will work, otherwise it won't do anything and you can just uninstall it (in other words, you just can' brick your phone with it)
Click to expand...
Click to collapse
@Choose an username... what Magisk module are you speaking of? And what does it (supposed) do?
dr3am_r said:
Thanks for the feedback, I installed G Rom B05 7.1.1 aaaand connection still 433 on AC, not 866. Wonder if there is a difference between A2017U and G of wifi chipset used.
Still awaiting some feedback from any that would know how to diagnose current issue at least to have a clear picture of how things are...
Click to expand...
Click to collapse
They are supposed to have the same wifi chip, and the wifi chip is supposed to support 866. However, there is a chance they bought a lower binned version from QC to make up for the extra licenses needed for the US LTE bands. There is also the liklihood that it's controlled by the modem firmware, since the wifi is controlled as part of the SoC. Both are speculation.
dr3am_r said:
@Choose an username... what Magisk module are you speaking of? And what does it (supposed) do?
Click to expand...
Click to collapse
I don't know the name but it is pretty obvious anyways (you can download it from magisk manager, and it says for OP3/OP3T in the name).
It enables dial band wifi from what the description says
Choose an username... said:
I don't know the name but it is pretty obvious anyways (you can download it from magisk manager, and it says for OP3/OP3T in the name).
It enables dial band wifi from what the description says
Click to expand...
Click to collapse
If you are referring to bellow module then it has nothing do do with what I am looking:
"OP3/3T WiFi Channel Bonding Enabler
OnePlus 3(T) devices do ship with channel bonding enabled for 5GHz band only. This mod will adjust a config file to turn on channel bonding (40MHz instead of 20MHz) for 2.4GHz band as well."
I am looking to have dual stream on the 5ghz AC wifi => 866mbps connection, not enable 40mhz channel on the 2.4ghz N wifi.
Hi @DrakenFX and @Unjustified Dev can you comment on current question / issue ? Do you have more information in regards to the number of streams / antennas Axon 7 A2017U has ?
Got response from @celoxocis on the Lineage 14.1 forum:
"here is some info for those curious of you about the 5Ghz capabilities/limitations of the Axon7.
while working on the wifi settings and testing them thoroughly on my home lab env.
i came across the discovery that even though the 5Ghz are advertised as 866Mbps you will never reach those speeds.
because ZTE has been cheap. the axon7 has two wifi antennas.
only one of the antennas is a dual-band antenna (2.4Ghz/5Ghz).
the second one is a 2.4Ghz antenna.
so the axon7 is 2.4Ghz 2x2 MU-MIMO capable.
but for 5Ghz its only 1x1 no MIMO.
i came to the conclusion while working on the chainmasks and antenna diversity.
i tried to push it beyond 265mbps (WPA2 encryption) and discovered if i switched to the second antenna
and run the 5GHz from that antenna (which is an 2.4GHz antenna) the bandwidth did not just suffer... it was a joke.
i suspected a wrong antenna diversity but that was not the case. that second antenna is only capable of 2.4Ghz."

Categories

Resources