Project

General

Profile

Feature #4574

Femtocell choice in 2020/06

Added by copslock 5 months ago. Updated 13 days ago.

Status:
New
Priority:
Low
Assignee:
-
Target version:
-
Start date:
06/01/2020
Due date:
% Done:

0%

Spec Reference:

Description

Recently the AT&T had shutdown its UMTS femto system,thus,result in the Cisco femtocells that operated in their network are widely available on eBay or Amazon platform,it turned out to be the DPH-151/153/154 microcell,But as the Harald noticed,these units are communicated through the Cisco URSL protocal,which is the evolution of the current 2G RSL signaling,and possible someone can add UMTS patch to it.So far it's the best available femtocell rather than the ip.access one.

brkagg-2002 .pdf View brkagg-2002 .pdf 2.03 MB Cisco femto architecture 2009 copslock, 06/02/2020 02:46 PM
att_microcell.png View att_microcell.png 1.19 MB copslock, 06/17/2020 09:06 AM
femto_new.jpg View femto_new.jpg 1.89 MB Jarobar, 07/04/2020 12:15 PM
BH_US_12_Rowley_Microcell_Bricks_WP.pdf View BH_US_12_Rowley_Microcell_Bricks_WP.pdf 1.08 MB Jarobar, 07/05/2020 09:48 AM
jtagulator_DPH153.jpg View jtagulator_DPH153.jpg 4.67 MB Jarobar, 07/05/2020 09:49 AM
S29GL512P10FFCR2_151_2.bin.gz S29GL512P10FFCR2_151_2.bin.gz 37.2 MB Jarobar, 09/24/2020 12:09 AM
Pc202-Datasheet.pdf View Pc202-Datasheet.pdf 1.43 MB Jarobar, 09/25/2020 03:58 PM
MX29LV320EBTI-70G_151_2_bymd.bin.gz MX29LV320EBTI-70G_151_2_bymd.bin.gz 3.72 MB Jarobar, 10/10/2020 11:13 PM
4205
4216
4224

History

#1 Updated by laforge 5 months ago

AFAICT, URSL was originally developed by ip.access for the early version of their "oyster3g" femtocells. Cisco had later acquired/licensed that from ip.access. At least for the ip.access oyster3g, only early firmware versions were USRL, later on they moved to standard Iuh. maybe the same is true for the cisco devices you are looking at?

In any case, USRL is a completely different protocol, so if you wanted to support it, you would have to write a IuCS+IuPS to USRL converter. Given that URSL uses no RANAP, this is likely a much more complex task than the comparatively simple osmo-hnbgw.

#2 Updated by copslock 5 months ago

laforge wrote:

AFAICT, URSL was originally developed by ip.access for the early version of their "oyster3g" femtocells. Cisco had later acquired/licensed that from ip.access. At least for the ip.access oyster3g, only early firmware versions were USRL, later on they moved to standard Iuh. maybe the same is true for the cisco devices you are looking at?

In any case, USRL is a completely different protocol, so if you wanted to support it, you would have to write a IuCS+IuPS to USRL converter. Given that URSL uses no RANAP, this is likely a much more complex task than the comparatively simple osmo-hnbgw.

Thank you for reply,Harald,had you tried to reverse-engineering these models before?As far as I know the presentation of Cisco in 2009 showed that it used the URSL stack,but in the later the ASR5000 PPTs showed it seems like support the standard Iuh interface.But don't know whether if these femtocells using the newer Iuh interface.The AT&T may had some modification.There is only one way to verify that,I have just ordered some units from eBay to find this out,if it's based on standard IuH interface,It will be much better choice than the long-disappered ip.access nano3g femotocells.By the way,I'm thinking about the support of ethernet-CPRI RRHs which is much more widely available than the eNodeBs and very chip.don't know whether if its fast enough for x86 to process those real-time I/Q data.

#3 Updated by laforge 5 months ago

On Tue, Jun 02, 2020 at 02:46:49PM +0000, copslock [REDMINE] wrote:

Thank you for reply,Harald,had you tried to reverse-engineering these models before?

I once played with an Oyster3G, found out some details about URSL and then gave up, as
it's simply too far away from 3GPP stanards.

As far as I know the presentation of Cisco in 2009 showed that it used the URSL stack,but in the later the ASR5000 PPTs showed it seems like support the standard Iuh interface.But don't know whether if these femtocells using the newer Iuh interface.

I guess unless you find different software versions for your specific cell, it is impossible to know.

The AT&T may had some modification.There is only one way to verify that,I have just ordered some units from eBay to find this out,if it's based on standard IuH interface,It will be much better choice than the long-disappered ip.access nano3g femotocells.By the way,

I'm thinking about the support of ethernet-CPRI RRHs which is much
more widely available than the eNodeBs and very chip.

The problem is mainly:
  • you have to design build a CPRI physical interface card (FGPA, gateware, host drivers, ...)
  • you have to reverse engineer the proprietary, verdor/product-specific Command+Control

don't know whether if its fast enough for x86 to process those real-time I/Q data.

For sure it is possible, look at what Amarisoft is doing. It's not open
source, but they do have CPRI interface board and complete eNB / gNB in
x86 software.

#4 Updated by copslock 5 months ago

laforge wrote:

On Tue, Jun 02, 2020 at 02:46:49PM +0000, copslock [REDMINE] wrote:

Thank you for reply,Harald,had you tried to reverse-engineering these models before?

I once played with an Oyster3G, found out some details about URSL and then gave up, as
it's simply too far away from 3GPP stanards.

As far as I know the presentation of Cisco in 2009 showed that it used the URSL stack,but in the later the ASR5000 PPTs showed it seems like support the standard Iuh interface.But don't know whether if these femtocells using the newer Iuh interface.

I guess unless you find different software versions for your specific cell, it is impossible to know.

The AT&T may had some modification.There is only one way to verify that,I have just ordered some units from eBay to find this out,if it's based on standard IuH interface,It will be much better choice than the long-disappered ip.access nano3g femotocells.By the way,

I'm thinking about the support of ethernet-CPRI RRHs which is much
more widely available than the eNodeBs and very chip.

The problem is mainly:
  • you have to design build a CPRI physical interface card (FGPA, gateware, host drivers, ...)
  • you have to reverse engineer the proprietary, verdor/product-specific Command+Control

don't know whether if its fast enough for x86 to process those real-time I/Q data.

For sure it is possible, look at what Amarisoft is doing. It's not open
source, but they do have CPRI interface board and complete eNB / gNB in
x86 software.

I mean some RRHs running on the ethernet interface,and possible CPRI data capsulated in ethernet frame,and can we just using the basic PC ethernet card to communicate with the RRH?I think it might have some issue like real-time I/Q data compressing because i saw FPGA-like stuff on its board,but still it at least runs on the ethernet interface

#5 Updated by copslock 4 months ago

laforge wrote:

On Tue, Jun 02, 2020 at 02:46:49PM +0000, copslock [REDMINE] wrote:

Thank you for reply,Harald,had you tried to reverse-engineering these models before?

I once played with an Oyster3G, found out some details about URSL and then gave up, as
it's simply too far away from 3GPP stanards.

As far as I know the presentation of Cisco in 2009 showed that it used the URSL stack,but in the later the ASR5000 PPTs showed it seems like support the standard Iuh interface.But don't know whether if these femtocells using the newer Iuh interface.

I guess unless you find different software versions for your specific cell, it is impossible to know.

The AT&T may had some modification.There is only one way to verify that,I have just ordered some units from eBay to find this out,if it's based on standard IuH interface,It will be much better choice than the long-disappered ip.access nano3g femotocells.By the way,

I'm thinking about the support of ethernet-CPRI RRHs which is much
more widely available than the eNodeBs and very chip.

The problem is mainly:
  • you have to design build a CPRI physical interface card (FGPA, gateware, host drivers, ...)
  • you have to reverse engineer the proprietary, verdor/product-specific Command+Control

don't know whether if its fast enough for x86 to process those real-time I/Q data.

For sure it is possible, look at what Amarisoft is doing. It's not open
source, but they do have CPRI interface board and complete eNB / gNB in
x86 software.

Long wait before the internation package arrive,but i found something interesting,some engs used to work with the AT&T and Cisco has described it

@Small Cell Test and Verification Engineer (contractor) for ip.access/Cisco
ip.access
Jan 2012 – Jun 2012 6 months

Redmond, WA

• Perform End2End testing of the ip.access/Cisco 3G Microcell solution in AT&T’s test bed according to the Test Object List as agreed with the customer;
• This testing was focused around HNB RAN (i.e. MM, Cell_FACH, CSG, HSPA, Admission and Power Control, Multi-RAB, Handover, etc.) and HNB-GW (IP Sec, HNBAP, RUA, HA, Iu-Flex, etc.) validation including related Statistics, KPIs and Alarms.@

What's the "Iu-Flex"???Maybe another some properitary blob again

#6 Updated by copslock 4 months ago

4205

Long wait before the internation package arrive,but i found something interesting,some engs used to work with the AT&T and Cisco has described it

@Small Cell Test and Verification Engineer (contractor) for ip.access/Cisco
ip.access
Jan 2012 – Jun 2012 6 months

Redmond, WA

• Perform End2End testing of the ip.access/Cisco 3G Microcell solution in AT&T’s test bed according to the Test Object List as agreed with the customer;
• This testing was focused around HNB RAN (i.e. MM, Cell_FACH, CSG, HSPA, Admission and Power Control, Multi-RAB, Handover, etc.) and HNB-GW (IP Sec, HNBAP, RUA, HA, Iu-Flex, etc.) validation including related Statistics, KPIs and Alarms.@

What's the "Iu-Flex"???Maybe another some properitary blob again,why ip.access called it "Oyster 3G"

#7 Updated by laforge 4 months ago

On Wed, Jun 17, 2020 at 09:06:53AM +0000, copslock [REDMINE] wrote:

What's the "Iu-Flex"???

As somewhat more dynamic/flexible/scalable way of handling the Iu interface between
RNC/HNBGW and MSC/SGSN. You should find it described in 3GPP specs. Not ip.access specific
at all.

why ip.access called it "Oyster 3G"

Because of the shape of the device? The original nanoBTS for GSM were called "rugby"

#8 Updated by Jarobar 4 months ago

4216

Hi
I disassembled the DPH153-AT unit. Caution the device contains anti-tampering jumpers!
I did not know about them. I can not turn it on now, otherwise the flash will be erased. Is the position of the jumpers the same for all units or is it dependent on the MAC / SN?
Would anyone be willing to tell me the correct jumpers position?
My unit is newer version.

#9 Updated by copslock 4 months ago

Jarobar wrote:

Hi
I disassembled the DPH153-AT unit. Caution the device contains anti-tampering jumpers!
I did not know about them. I can not turn it on now, otherwise the flash will be erased. Is the position of the jumpers the same for all units or is it dependent on the MAC / SN?

Oh my god,i guess you guys already well-acknowaged that the 151/153 have anti-tamper jumpers,i saw some tips about the jumpers before but i didnt sure whether if its random,i will take another look

Would anyone be willing to tell me the correct jumpers position?
My unit is newer version.

#10 Updated by Jarobar 4 months ago

4224

Fortunately I first looked for some information about this cell before turning it on.
I spent more time looking for information about this cell. It seems to be well researched by the community.
On this web page there are anti-tamper photos from both sides of the PCB for the older version. The photo of the newer version is only on one side unfortunately.
https://rjmendez.github.io/posts/2019/02/Indeed_CTF_Embedded_2

The cell seems to consist of a router and a radio chip. Both are separate systems. Everyone has their RAM and flash. There are also some attempts to extract the firmware from the router part. The radio part is not mentioned as an extraction success. Do you have information that someone succeeded?

#11 Updated by copslock 4 months ago

Jarobar wrote:

Fortunately I first looked for some information about this cell before turning it on.
I spent more time looking for information about this cell. It seems to be well researched by the community.
On this web page there are anti-tamper photos from both sides of the PCB for the older version. The photo of the newer version is only on one side unfortunately.
https://rjmendez.github.io/posts/2019/02/Indeed_CTF_Embedded_2

The cell seems to consist of a router and a radio chip. Both are separate systems. Everyone has their RAM and flash. There are also some attempts to extract the firmware from the router part. The radio part is not mentioned as an extraction success. Do you have information that someone succeeded?

1.someone hackday.io had informed the jumper sets https://hackaday.com/2012/04/12/poking-at-the-femtocell-hardware-in-an-att-microcell/

croze says:
October 5, 2015 at 8:36 pm
The jumper configuration on the DPH153-AT is 0=no continuity fake jumper, 1= continuity real jumper values are read from top to bottom. Front of board side with all the components jumper location near center and offset right 0,1,1. Rear of board the side with no components jumper block in the lower left hand corner 0, 0, 1. USE a VOM sort all the jumpers and plug and play. Have fun" 

2.very early comment https://robotskirts.com/2009/12/02/att-3g-microcell-hacking/
RATSANDWICH says:
@robert

Microcell Tamper Switch Jumper Positions:

The current vodoo on this is here: http://i.imgur.com/S7vhi.jpg
and here: http://i.imgur.com/9LArj.jpg

DL pics. Notice the two little nipples on the real jumpers and the lack of any surface features on the others. Solder the nippy ones together and snip the others.
J16=top one real, bottom two fake
j15=top two real, bottom one fake

The idiots= what is top?

Top is where the the letters are Not upside down. That way you can read j15, j16 right side up.

3.basic guide into the DPH-151 which talks about the "Wizard" tool which gets you into the Ralink-side enviroment
https://fail0verflow.com/blog/2012/microcell-fail/

4.deeper exploration https://alexandercwatson.wordpress.com/2013/03/10/all-your-att-microcells-are-belong-to-us/

5.the rjmendez's one
The Ralink RT2150 is responsible for the IPSec negotiation and possible the TR-069 routine that controls the bootup parameters configuration,and it communicates with the Picochip through the Ethernet,you can try to dump the interfaces of the Ralink chip to monitor that,but i think that was useless.The main steps to utilize for OSMO-using are simple,first you should change the IPSec profile to make it connects to your SeGW,then you need to find some way to change the TR-069 server address then push enough parameters to make the NodeB connects to the HNBGW,then it will start broadcast
About the parameters ,you can reference to the Cisco's detailed guide about both basic and advanced parameters
https://www.cisco.com/c/en/us/td/docs/wireless/access_point/small_cell/rms/r4x/admin_guide/b_rms_admin_guide.pdf
https://www.cisco.com/c/dam/en/us/td/docs/wireless/access_point/small_cell/rms/r41/api_guide/BAC_CustomProperties_ReferenceSheet_R41.pdf

If you are quite anxious about the reverse-work,you can follow the guide that provided by RJMENDEZ which gets the dumpflash.bin,and uploads it here,I will try to do some analyse for you ahead.

#12 Updated by copslock 4 months ago

Jarobar wrote:

Fortunately I first looked for some information about this cell before turning it on.
I spent more time looking for information about this cell. It seems to be well researched by the community.
On this web page there are anti-tamper photos from both sides of the PCB for the older version. The photo of the newer version is only on one side unfortunately.
https://rjmendez.github.io/posts/2019/02/Indeed_CTF_Embedded_2

The cell seems to consist of a router and a radio chip. Both are separate systems. Everyone has their RAM and flash. There are also some attempts to extract the firmware from the router part. The radio part is not mentioned as an extraction success. Do you have information that someone succeeded?

You should not focus on "how to hack into the Picochip",but just find the proper way to tune up the parameters,the RRC layer codes wont help you more unless you want to do some bad stuff,but thats not the goal of this project

Jarobar wrote:

Fortunately I first looked for some information about this cell before turning it on.
I spent more time looking for information about this cell. It seems to be well researched by the community.
On this web page there are anti-tamper photos from both sides of the PCB for the older version. The photo of the newer version is only on one side unfortunately.
https://rjmendez.github.io/posts/2019/02/Indeed_CTF_Embedded_2

The cell seems to consist of a router and a radio chip. Both are separate systems. Everyone has their RAM and flash. There are also some attempts to extract the firmware from the router part. The radio part is not mentioned as an extraction success. Do you have information that someone succeeded?

#13 Updated by Jarobar 4 months ago

I bought the device on eBay. I did it without the knowledge of anti-manipulation. Now I am not sure that I will be able to connect the jumpers correctly. I just had the idea that I'd rather order a new piece. Desolder this radio flash then read the content then make it available to the community. Maybe it's just a stupid idea. Do you know that someone has already tried it?

#14 Updated by laforge 4 months ago

Just wanted to say I'm following this ticke with pleasure (great to see people are hacking on femtocells again!) but I don't have much to contribute. I haven't been playing with any of the devices you're looking into, sorry.

Once you get to Iuh, I'm happy to help regarding interoperability issues in osmo-iuh/msc/sgsn.

Happy hacking!

#15 Updated by copslock 4 months ago

Jarobar wrote:

I bought the device on eBay. I did it without the knowledge of anti-manipulation. Now I am not sure that I will be able to connect the jumpers correctly. I just had the idea that I'd rather order a new piece. Desolder this radio flash then read the content then make it available to the community. Maybe it's just a stupid idea. Do you know that someone has already tried it?

Above all are what i can find on the internets,no more deep researching about it,these guys,as Harald said,only thinking about how to lock down those devices to make it so-called "secure",but nobody cares about full reusing those hardware instead of becoming e-waste,If you think publish to the public is not suitable,you can send the files to my box

#16 Updated by Jarobar about 1 month ago

DPH-151 as the first
Is here somebody who can analyze this?

I hope it will be useful somehow.

#18 Updated by copslock 28 days ago

Jarobar wrote:

DPH-151 as the first
Is here somebody who can analyze this?

I hope it will be useful somehow.

Very nice,Analyse will be carried out soon.Sorry I may lost the mail you sent due to I used temporary mail for avoding advertisement.The telnet password is known now.

#19 Updated by Jarobar 14 days ago

The procedure described in Rowley Microcell Bricks is correct for DPH-151.

#20 Updated by Jarobar 14 days ago

sshd:nSCV0.l5YF7k2:0:0:root:/root:/bin/sh

Do you know the answer?

#21 Updated by laforge 14 days ago

Jarobar wrote:

sshd:nSCV0.l5YF7k2:0:0:root:/root:/bin/sh

Do you know the answer?

I don't, but this looks like a classic crypt hash that virtually anyone should be able to crack in reasonable amount of time these days, right?

#22 Updated by Jarobar 13 days ago

John says
Loaded 1 password hash (descrypt, traditional crypt(3) [DES 128/128 SSE2-16])

finished with
root:gemtekro:0:0:root:/root:/bin/sh

I can really log in with it.

copslock please what procedure do you use to get FPGA gateware?

#23 Updated by copslock 13 days ago

Jarobar wrote:

John says
Loaded 1 password hash (descrypt, traditional crypt(3) [DES 128/128 SSE2-16])

finished with
root:gemtekro:0:0:root:/root:/bin/sh

I can really log in with it.

copslock please what procedure do you use to get FPGA gateware?

What the hell is "FPGA Gateway"?The next job is to find the configuration for the femto-GW,in this case,the HNBGW address,but In the Picochip solution,the IPsec channel is mandatory before the creation of the Iuh link,but I dont sure that will be the same on Gemtek's devices.As long as you have got into the shell enviroment,you should change the IPSec deamon's configuration to make it contact well with the IPSec(e.g strongswan) gateway,make sure it gets the correct subnet,and using CWMP procedure to change the HNBGW address to the OSMO-HNBGW deamon listening interface's IP address,configure the airlink parameters,which can reference to the Cisco's configuration guide book,Then when everything be OK,you will get information from the OSMO-HNBGW gateway log output,after that the authentication and etc can be done like other procedures in OSMO GSM projects

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 48.8 MB)