ISM868 bands that are located adjacent to the GSM 850/900 frequency
allocations.
My initial investigations and enquiries indicate that this should be
possible by creative programming of the baseband processor in many
models of phones. The trick, as I suspect you well know, is the
difficulty in getting the information and tools required to reprogram
these radios.
I am now in a position to potentially fund further work on this.
So, as the open-source group with the most experience reprogramming
baseband radios, what is the feasibility of creating a
proof-of-concept using the types of phones you already work with to
send and receive arbitrary data packets without reliance on a cell
tower (even for time synchronisation)?
I know there are a lot of constraints and problems, but I am most
interested in creative solutions that can get us to a working
prototype, however crude, that can be used to demonstrate the
feasibility of what I am proposing.
If this discussion is off-topic here, I am happy to hold the
conversation at the serval-project-developers google group, but I am
equally comfortable with it continuing here.
Thanks in advance,
Paul Gardner-Stephen.
Shuttleworth Telecommunications Fellow at Flinders University.
* it tries to stay as close to POSIX and other Unix APIs as possible
* you can actually have executable programs in the file system
* it contains a small interactive shell
* the changelog is verbose and releases are frequent
* there's a test suite
* there are already ports to other ARM7TDMI microcontrollers
* there is a small UI framework and the notion of drivers for SPI-
attached LCDs (with 1/2/4 bpp)
* it has tasks and threads, pre-emptive and with priorities
* it has posix message queues, which we could use for passing around
primitives between elements in the stack
* it can be used on Unix-like and Windows/Cygwin host OS
* it has its own scripts to generate toolchains, which means we
could possibly standardize on one of those toolchains
Of course, not everything is perfect
* there seems to be no writeable FS we can put in NOR flash
* it has no scripting language integration (like lua) yet
* i didn't find any memory allocator optimized for pools of objects
of the same size (like 'struct msgb' or the like). Something with
an API [not implementation!] of the SLAB/SLUB in Linux would probably
be a good start.
I've done some example compile runs for arm7, including the shell and
the graphics support (nx example). I end up with an object code size of
something like 70 kilobytes, which is pretty good!
So unless anyone raises major objections, I think we should move ahead
with Nuttx. Who is interested in working on the calypso port?
Let's use this list for coordinating the effort.
As for where to put the code: I already have a git-svn clone of Nuttx,
and will push that to a soon-to-be-created nuttx.git repository on
git.osmocom.org. The core calypso support (irq, uart, spi, etc.) should
all go in that tree. Meanwhile we will figure out how it would be
possibel to keep the gsm related 'application' code out-of-tree from
the nuttx code base.
Regards,
Harald
--
- Harald Welte <laforge(a)gnumonks.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
Sure, it would be a nice addition, but it's not something that I consider
extremely important. With regard to 'near future': I would say that in
something like six months the osmo-bts (BTS-side A-bis) code will have matured,
and is ready for an relaatively painless integration with OpenBTS.
I personally think the USRP hardware cost is still way too high, and I would
rather want to work on something that puts the financial entrance barrier to
private BTS ownership much lower.
Most of the people using OpenBSC today either use it commercially (and can
afford the nanoBTS units), or they use it private and either with a very
cheap second hand nanoBTS, or with a inexpensive BS-11. The recent work
on supporting the RBS2308 that can be found for < 1000 USD goes into the
same direction.
I think whatever hardware will be affordable to hackers will see OpenBSC
support - just as well as any hardware where we have a commercial customer
will get OpenBSC support.
> > This is where I don't get you. All that needs to be removed is the L3-to-SIP
> > bridge. It doesn't make the vast majority of OpenBTS code disappear,
> > and it does not render that latter part useless. A full-blown GSM network with
> > all its components brings a lot of complexity. The stand-alone OpenBTS is
> > much more simple. And why would you want all the complexity if you don't
> > need to interoperate with legacy GSM?
>
> Well, because the the osmocom-integrated version will be, before or
> later, more full-featured than OpenBTS standalone.
>
> Features such as multi-arfcn, handover, maybe GPRS/EDGE will be usable
> only jointly with Osmocom integration but not by the opensource OpenBTS
> standalone version.
If you use the USRP hardware (or any other SDR hardware), you cannot use
GPRS/EDGE whether you use Osmocom + OpenBTS or OpenBTS standalone. As for
hand-over, you may be right, but I don't know the OpenBTS plans here.
Multi-ARFCN: This is an aspect of the radio-modem. So again, on the same
hardware any OpenBTS/OpenBSC integration will not change this.
> Obviously the community will then use the OpenBTS/OpenBSC integration
> that would reach more features than just OpenBTS in the opensource edition.
well, but you loose the important 'simplicity' feature. Right now I doubt
there are that many people in our community who understand OpenBSC and the
GSM/GPRS network architecture enough to deploy a network (like the burning man
or CCC event networks) with it. We have close to zero documentation, and
unless you know GSM protocol details, you are lost. VoIP is much better
understood in the FOSS and Internet community!
> So the integrated code will grow while the "OpenBTS commercial code"
> will leave behind with less features and more buggy code (because less
> used).
you are making assumptions here. Do you have evidence or at least some
other indication that bug fixes are not being propagated from the commercial
to the free version?
> Osmocom and it's possible future changes to the market of GSM
> technologies could be defined as "the WikiLeaks of the GSM Industry" :-)
I think this is a very bad comparison. We do not leak any proprietary/secret
information. We just break the ignorance of the Free Software community to
ever implement any of those openly-specified protocols. Not different from
Free Software entering any other area of technology.
And while we're doing that, we of course also like to challenge the ridiculous
claims of hundred-man-year efforts that allegedly went into some proprietary
GSM protocol stack implementations, which are often claimed by the existing
carrier equipment industry.
Regards,
Harald
--
- Harald Welte <laforge(a)gnumonks.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
> Meanwhile, Andreas Eversberg has been working on a BTS-side A-bis implementation
> for the OsmocomBB-BTS (idea: using 2 heavily modified phones to run a
> simplistic BTS), and I have started to split that code out into a separate
> repository at http://cgit.osmocom.org/cgit/osmo-bts/
>
> This code should eventually be used with the OpenBTS, and potentially other
> BTS types, too.
That's cool!!!!
>
>> With that approach the 'GSM-um' interface would be a very simplified
>> module of the overall system and osmocom would completely replace
>> OpenBTS all-in-one project.
>
> This is where I don't get you. All that needs to be removed is the L3-to-SIP
> bridge. It doesn't make the vast majority of OpenBTS code disappear,
> and it does not render that latter part useless. A full-blown GSM network with
> all its components brings a lot of complexity. The stand-alone OpenBTS is
> much more simple. And why would you want all the complexity if you don't
> need to interoperate with legacy GSM?
Well, because the the osmocom-integrated version will be, before or
later, more full-featured than OpenBTS standalone.
Features such as multi-arfcn, handover, maybe GPRS/EDGE will be usable
only jointly with Osmocom integration but not by the opensource OpenBTS
standalone version.
Obviously the community will then use the OpenBTS/OpenBSC integration
that would reach more features than just OpenBTS in the opensource edition.
That means that in few times only the "integrated code" will works
better, because it will attract more user and will start getting used in
"production environment".
So the integrated code will grow while the "OpenBTS commercial code"
will leave behind with less features and more buggy code (because less
used).
That's why i just think that the destinity of OpenBTS is to integrate
(directly or just some piece) with OpenBSC, but doing that it will loose
several important value of the "OpenBTS commercial edition" and people
will start using what can be used for free instead of paying.
That's what usually happen within the opensource environment, before or
later.
It could reasonably happen also with that opensource gsm environment.
My comments was just consideration on this to stimulate the
considerations on this by the various project players.
I am just an opensource advocacy troll that like telephony stuff and
perceive very valuable the achievement of the hacking community in
opening a closed technology like GSM.
Osmocom and it's possible future changes to the market of GSM
technologies could be defined as "the WikiLeaks of the GSM Industry" :-)
-naif
p.s. i have no commercial interests of any kind in that stuff
all the powerfull eye-candy apps. But that takes processing power. So
SoC provider would separate processing on two cores, puting stack on
the other core. Since this other core do not demand any application
except PS, you would like to run some nice lightweight OS like eCos,
or similar that have good RT performances to assure timing
requirements for L1 and inter-CPU communication.
If there would be satisfying performance on one core, there would
certanly be interest to save money by rejecting the other. And to
figure out how to separate closed source, how to keep legacy RTOS and
RT apps, etc... And since more powerful cores are appearing, L4 comes
into play on big doors (not to mention that it's the worlds first
formally verified kernel).
BR,
Drasko
main_simtrace.bin, using dfu-util from http://dfu-util.gnumonks.org
--
- Harald Welte <laforge(a)gnumonks.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
patience" is a really good guess.
Let me explain how this works: In Shenzhen there is a huge electronics
area. Thousands of shops and companies, hundreds of thousands of people
working and trading there.
I have a small collection of pictures so you get the idea...
http://en.qi-hardware.com/wiki/Shenzhen_markets
(this stretches over an area of at least 1x1 km, with dozens of 8+ level
buildings, some higher like the 70-floor office tower :-))
Basically you can walk up to any PCB shop (there are at least 50 I would
say). I went to one I used before with 2 Sciphone Dream G2 boards,
and they accepted the job for 600 RMB (=ca. 90 USD). I got the pictures
4 days later. I got them as .bmp files, then I did some post-processing
to make nice horizontally aligned, contrast-enriched PNGs out of them,
and a big PDF too to easily flip through the layers (PDF readers tend
to be quite powerful and efficient in scaling and flipping, so this
seems to work well).
I am not an electronics guy, so I need feedback to do this kind of
work better in the future. For example, I don't know the exact names
of the layers. Can someone who knows what they are add subtitles
to the wiki? Copper layer, ground layer, via, whatever? (I just don't
know...) Or reply here and I'll annotate the wiki.
Anything else I should do to make this better next time?
This is all background info I have, one day I will convince them to
let me take some pictures of the actual work :-)
Wolfgang
\subsection{How to synchronize the GSM TDMA multiplex}
As part of the BCCH, the BTS not only sends the FCCH but also the
Synchronization CHannel (SCH). The Synchronization channel indicates the
current GSM time / frame number (skipping the 3 least significant bits).
By using this received GSM time and incrementing it every time the GSM bit-clock
timer wraps at the beginning of a new TDMA frame, the GSM time is synchronized.
Understanding the multiple layers of time multiplex such as the 26/51
multiframe, superframe and hyperframe, the L1 can multiplex and demultiplex all
the logical channels of GSM.
\section{Miscellaneous Topics}
\subsection{GPRS}
GPRS was the first packet switched extension to GSM. In fact, it is much more
its entirely own mobile network, independent of GSM. The only parts shared are
the GSM modulation scheme (GMSK) and time multiplex, in order to ensure peaceful
coexistence between them.
The L1 and L2 protocols are very different (and much more complex) than GSM.
So while the phone baseband hardware did not need any modifications for a basic
GPRS enabled phone, the software needed to be extended quite a lot.
\subsection{EDGE}
EDGE is a very small incremental step to GPRS. It reuses all of the time
multiplex and protocol stack, but introduces a new modulation: Offset
8-PSK instead of GMSK to increase the bandwidth that can be transmitted.
Offset 8-PSK is used (as opposed to simple 8-PSK) to avoid
zero-crossings in the modulator output.
So while the software modifications from GPRS to EDGE are minimal, the 8PSK
modulation scheme has a significant impact on the DSP, ABB and even RF
PA design.
\subsection{UMTS}
UMTS (sometimes called WCDMA) is an entirely separate cellular network
technology. Its physical layer, modulation schemes, encoding, frequency
bands, channel spacing are entirely different, as is the Layer1.
UMTS Layer2 has some resemblance to the GPRS Layer2.
UMTS Layer3 for Mobility Management and Call Control are very similar to GSM.
Given the vast physical layer and L1 differences, a UMTS phone hardware design
significantly differs from what has been described in this document.
Notwithstanding, all known commercial UMTS phone chipsets as of today still
include a full GSM modem in hardware and software to remain
backwards-compatible.
\subsection{Dual-SIM and Triple-SIM phones}
In recent years, a large number of so-called {\em Dual-SIM} or even {\em
Triple-SIM} phones have entered the market, particularly in China and other
parts of East Asia.
Those phones come in various flavours. Some of them simply have a multiplexer
that allows electrical switching between multiple SIM card slots. This is
similar to replacing the SIM card in a phone, just without the manual process
of mechanically removing/inserting the card. As a result, you can only use one
of the two SIMs at any time.
The more sophisticated Dual-SIM phones have two complete phones in one case. Yes,
that's right! They contain two full GSM phone chipsets, i.e. 2 antennas, 2 rf
frontends, 2 analog basebands, 2 digital basebands, ...
However, they use the same trick as smartphones: One of the two basebands does
not have keypad or display and is simply a GSM modem connected via serial line
to the other baseband processor.
So if a smartphone (as defined in this document) is a GSM modem connected to a
PDA in one case, a Dual-SIM phone is a GSM modem connected to a feature phone
in one case.
Triple-SIM phones often combine the two approaches, i.e. they contain two
complete GSM baseband chips, but three SIM slots that can be switched among
the base bands. Only two SIMs can be active at the same time.
\subsection{Powerful feature phones}
Feature phones are becoming more and more powerful. However, their
comparatively lower market price cannot afford a full-blown smartphone design
with its two independent processors and the associated design complexity.
Thus, more and more hardware peripherals are added to the only processor left
in the phone: The baseband processor. Such peripherals include sophisticated
camera interfaces, high-resolution color display controllers, TV output,
touchscreen controllers, audio and video codecs and even interfaces for mobile
TV reception.
However, all of those features are still implemented on a fairly weak ARM7 or
ARM9 CPU core (compared to ARM11 and Cortex-A8 in the smartphone market). They
also lack a real operating system and still run on top of a real-time
microkernel intended for much less complex systems. They almost always lack
any form of memory protection or multiple address spaces. This makes them
more prone to security issues as there is no privilege separation between
the GSM protocol stack and the applications, or between the applications
themselves.
\subsection{Security features}
There are several (sometimes conflicting) security requirements that
apply to mobile phones. Interestingly, the security features are
typically used to protect some industry interest against the interest of
the customer. There are very few security features in a phone that are
meant to protect the user or his interests.
\subsubsection{IMEI - The hardware serial number}
The International Mobile Equipment Identifier (IMEI) uniquely identifies
a GSM phone. It is a globally unique serial number which is programmed
into the phone non-volatile memory (Flash or EEPROM) during the
production process. There are no particular security features used to
store the IMEI. Once you are able to write to flash and have found it,
it can be changed.
\subsubsection{The SIM Card}
The SIM card is a cryptographic smart card that stores the secret key
used for authenticating the user to the GSM network (Ki). The Ki is
never released by the card, and as such copying (cloning) of the SIM
is prevented.
Furthermore, the SIM stores the International Mobile Subscriber Identity
(ISMI). The IMSI is not encrypted or protected in some way.
There is no security channel on the connection between the SIM card and
the baseband MCU. Furthermore, there is no way how the MCU can securely
identify/authenticate the SIM itself. Physical access to the SIM card
slot allows sniffing and/or modification of the communication between
MCU and SIM.
\subsubsection{SIM or Operator Locking}
GSM is an international standard. This ensures interoperability, i.e.
any phone can be used on any network.
However, in some cases, the vendors of a GSM phone want to restrict this
interoperability and lock a phone to one specific network, or even lock
it to a particular SIM.
Those locks are implemented by software only, i.e. the MCU software will
instruct the GSM protocol stack not to register with a network unless
its network operator code is a certain factory-programmed network number.
As such, techniques for circumventing those locks have become
commonplace. It's somewhat of an ongoing race between the phone makers
and the phone-unlockers. The industry invents ever more complex methods
of obfuscating their locks in the software, while the phone-unlockers
reverse engineer those bits for each and every phone model after some
time.
\subsubsection{DBB firmware signatures}
In order to protect the operator and phone manufacturers peculiar
business models based on SIM or operator locking, some vendors
extended their baseband software with cryptographic signatures. Only
if the correct signature is present in a software update, the bootloader
program will accept the new software.
However, there are more or less invasive hardware-related approaches in
circumventing those signature checks, such as hardware debugging
interfaces like JTAG, or replacing the external flash memory components.
More recently, GSM chipset vendors introduced features such as
hardware-assisted software signature checks. In this case a master key
hash might be present in DBB-internal fuses, together with a
signature-verifying boot loader in DBB-internal mask ROM. As the root
of the chain of trust is moving deeper into the hardware, it becomes
more difficult for anyone to make software modifications to the DBB.
Especially with tighter integration, where RAM and FLASH are no longer
present as discrete components but part of a multi-chip-package, the
number of options are becoming more limited.
On the other hand, an ever more complex baseband software stack is
opening up many more options for exploiting software vulnerabilities.
Given the lack of a proper/modern operating system with privilege
separation and virtual memory, such exploits immediately give away
full access to all aspects of the respective DBB.
\section{Personal rant on the closedness of the GSM industry}
The GSM industry is one of the most closed areas of computing that I've
encountered so far. It is very hard to get any hard technical
information out of them. All they like to spread is high-level
marketing information, but they're very reluctant when it comes down to
hard technical facts on their products.
If you want to build a phone, you need to buy a GSM chipset for your
product. There are only very few companies that offer such chipsets.
The classic suppliers are Infineon, Texas Instruments, ST/Ericsson, ADI
(now MediaTek) and Freescale.
The GSM handset products they sell are not generally available and
distributed like other electronic component they manufacture. If you
need a Microcontroller/SoC, a power management IC, a Wifi or Bluetooth
chip, RFID reader ASIC, you simply approach the respective distributors
and order them. You get your samples directly from Digikey.
This is impossible for GSM (or other cellphone) chipsets. For some
reason those chips are sold only to hand-picked manufacturers. If you
want to qualify, you have to subscribe to at least six-digit annual
purchasing quantities. And in order for them to believe you, you have
to cough up a significant NRE (non-refundable engineering fee). This
has been reported as high as a seven-digit US\$ amount and is to make
sure that even if you end up buying less chips than you indicate, the
chipset maker will still have your upfront NRE money and keep it.
And if you buy your way into that select club of cellphone makers, what
you get from the chipset maker is typically not all too impressive
either. The documentation you get is incomplete, i.e. it alone would
not enable you as a cellphone maker to make any use of the hardware,
unless you license the software (drivers, GSM protocol stack, ...) from
the chipset maker, too.
On the software side, most of the technologically interesting bits (like
the protocol stack) are provided as binary-only libraries, you only get
source code to some parts of the systems, i.e. some hardware drivers
that might need modification for your particular phone electrical
design.
That GSM protocol stack was not written by the chipset maker either.
They simply license a stack from one of the estimated 4 or 5
organizations who have ever implemented a commercial GSM protocol stack.
It is not like the GSM protocols were some kind of military secret.
They are a published international standard, freely accessible for
anyone. So why does everybody in that industry think that there is
a need to be so secretive?
Having spent a significant part of the last 6 years with reverse
engineering of various aspects of mobile phones in order to understand
them better and do write software tools for security analysis, I still
don't understand this secrecy.
All the various vendors do more or less the same. The fundamental
architecture of a GSM baseband chip is the same, whether you buy it from
TI, Infineon or from MediaTek. {\em They all cook with water}, like we
Germans tend to say. The details like the particular DSP vendor or
whether you use a traditional IF, zero-IF or low-IF analog baseband
differ. But from whom do they want to hide it? If people like myself
with a personal interest in the technical aspects of mobile phones can
figure it out in a relatively short time, then I'm sure the competiton
of those chipset makers can, too. In much less time, if they actually
care.
This closedness of the cellular industry is one of the reasons why there
has been very little innovation in the baseband firmware throughout the
last decades. Innovation can only happen by very few players. Source
code bugs can only be found and fixed by very few developers at even
fewer large corporations. No chance for a small start-up to innovate,
like they can in the sphere of the internet.
It is fundamentally also the reason why the traditional phone makers
have been losing market share to newcomers to the mobile sphere like
Apple with its iPhone or Google with its Android platform.
Those innovations really only happened on the application processor on
high-end smartphones. The closed GSM baseband processor had to be
accompanied by an independent application processor running a real
operating system, with real processes, memory management, shared
libraries, memory protection, virtual memory spaces, user-installable
applications, etc.
They still don't happen on the baseband processor, which is as closed as
it was 15 years ago.
\end{document}
--3V7upXqbjpZ4EhLz--
\subsection{How to synchronize the GSM TDMA multiplex}
As part of the BCCH, the BTS not only sends the FCCH but also the
Synchronization CHannel (SCH). The Synchronization channel indicates the
current GSM time / frame number (skipping the 3 least significant bits).
By using this received GSM time and incrementing it every time the GSM bit-clock
timer wraps at the beginning of a new TDMA frame, the GSM time is synchronized.
Understanding the multiple layers of time multiplex such as the 26/51
multiframe, superframe and hyperframe, the L1 can multiplex and demultiplex all
the logical channels of GSM.
\section{Miscellaneous Topics}
\subsection{GPRS}
GPRS was the first packet switched extension to GSM. In fact, it is much more
its entirely own mobile network, independent of GSM. The only parts shared are
the GSM modulation scheme (GMSK) and time multiplex, in order to ensure peaceful
coexistence between them.
The L1 and L2 protocols are very different (and much more complex) than GSM.
So while the phone baseband hardware did not need any modifications for a basic
GPRS enabled phone, the software needed to be extended quite a lot.
\subsection{EDGE}
EDGE is a very small incremental step to GPRS. It reuses all of the time
multiplex and protocol stack, but introduces a new modulation: 8PSK instead
of GMSK to increase the bandwidth that can be transmitted.
So while the software modifications from GPRS to EDGE are minimal, the 8PSK
modulation scheme has a significant impact on the DSP, ABB and even RF
Frontend (especially the RF Amplifier).
\subsection{UMTS}
UMTS (sometimes called WCDMA) is an entirely separate cellular network
technology. Its physical layer, modulation schemes, encoding, frequency
bands, channel spacing are entirely different, as is the Layer1.
UMTS Layer2 has some resemblance to the GPRS Layer2.
UMTS Layer3 for Mobility Management and Call Control are very similar to GSM.
Given the vast physical layer and L1 differences, a UMTS phone hardware design
significantly differs from what has been described in this document.
Notwithstanding, all known commercial UMTS phone chipsets as of today still
include a full GSM modem in hardware and software to remain
backwards-compatible.
\subsection{Dual-SIM and Triple-SIM phones}
In recent years, a large number of so-called {\em Dual-SIM} or even {\em
Triple-SIM} phones have entered the market, particularly in China and other
parts of East Asia.
Those phones come in various flavours. Some of them simply have a multiplexer
that allows electrical switching between multiple SIM card slots. This is
similar to replacing the SIM card in a phone, just without the manual process
of mechanically removing/inserting the card. As a result, you can only use one
of the two SIMs at any time.
The more sophisticated Dual-SIM phones have two complete phones in one case. Yes,
that's right! They contain two full GSM phoen chipsets, i.e. 2 antennas, 2 rf
frontends, 2 analog basebands, 2 digital basebands, ...
However, they use the same trick as smartphones: One of the two baesbands does
not have keypad or display and is simply a GSM modem connected via serial line
to the other baseband processor.
So if a smartphone (as defined in this document) is a GSM modem connected to a
PDA in one case, a Dual-SIM phone is a GSM modem connected to a feature phone
in one case.
Triple-SIM phones often combine the two approaches, i.e. they contain two
complete GSM baesband chips, but three SIM slots that can be switched among
the base bands. Only two SIMs can be active at the same time.
\subsection{Powerful feature phones}
Feature phones are becoming more and more powerful. However, their
comparatively lower market price cannot afford a full-blown smartphone design
with its two independent processors and the associated design complexity.
Thus, more and more hardware peripherals are added to the only processor left
in the phone: The baseband processor. Such peripherals include sophisticated
camera interfaces, high-resolution color display controllers, TV output,
touchscreen controllers, audio and video codecs and even interfaces for mobile
TV reception.
However, all of those features are still implemented on a fairly weak ARM7 or
ARM9 CPU core (compared to ARM11 and Cortex-A8 in the smartphone market). They
also lack a real operating system and still run on top of a real-time
microkernel intended for much less complex systems. They almost always lack
any form of memory protection or multiple address spaces. This makes them
more prone to security issues as there is no privilege separation between
the GSM protocol stack and the applications, or between the applications
themselves.
\section{Personal rant on the closedness of the GSM industry}
The GSM industry is one of the most closed areas of computing that I've
encountered so far. It is very hard to get any hard technical
information out of them. All they like to spread is high-level
marketing information, but they're very reluctant when it comes down to
hard technical facts on their products.
If you want to build a phone, you need to buy a GSM chipset for your
product. There are only very few companies that offer such chipsets.
The classic suppliers are Infineon, Texas Instruments, ST/Ericsson, ADI
(now MediaTek) and Freescale.
The GSM handset products they sell are not generally available and
distributed like other electronic component they manufacture. If you
need a Microcontroller/SoC, a power management IC, a Wifi or Bluetooth
chip, RFID reader ASIC, you simply approach the respective distributors
and order them. You get your samples directly from Digikey.
This is impossible for GSM (or other cellphone) chipsets. For some
reason those chips are sold only to hand-picked manufacturers. If you
want to qualify, you have to subscribe to at least six-digit annual
purchasing quantities. And in order for them to believe you, you have
to cough up a significant NRE (non-refundable engineering fee). This
has been reported as high as a seven-digit US\$ amount and is to make
sure that even if you end up buying less chips than you indicate, the
chipset maker will still have your upfront NRE money and keep it.
And if you buy your way into that select club of cellphone makers, what
you get from the chipset maker is typically not all too impressive
either. The documentation you get is incomplete, i.e. it alone would
not enable you as a cellphone maker to make any use of the hardware,
unless you license the software (drivers, GSM protocol stack, ...) from
the chipset maker, too.
On the software side, most of the technologically interesting bits (like
the protocol stack) are provided as binary-only libraries, you only get
source code to some parts of the systems, i.e. some hardware drivers
that might need modification for your particular phone electrical
design.
That GSM protocol stack was not written by the chipset maker either.
They simply license a stack from one of the estimated 4 or 5
organizations who have ever implemented a commercial GSM protocol stack.
It is not like the GSM protocols were some kidn of military secret.
They are a published international standard, freely accessible for
anyone. So why does everybody in that industry think that there is
a need to be so secretive?
Having spent a significant part of the last 6 years with reverse
engineering of various aspects of mobile phones in order to understand
them better and do write software tools for security analysis, I still
don't understand this secrecy.
All the various vendors do more or less the same. The fundamental
architecture of a GSM baseband chip is the same, whether you buy it from
TI, Infineon or from MediaTek. {\em They all cook with water}, like we
Germans tend to say. The details like the particular DSP vendor or
whether you use a traditional IF, zero-IF or low-IF analog baseband
differ. But from whom do they want to hide it? If people like myself
with a personal interest in the technical aspects of mobile phones can
figure it out in a relatively short time, then I'm sure the competiton
of those chipset makers can, too. In much less time, if they actually
care.
This closedness of the cellular industry is one of the reasons why there
has been very little innovation in the baseband firmware throughout the
last decades. Innovation can only happen by very few players. Source
code bugs can only be found and fixed by very few developers at even
fever large corporations. No chance for a small start-up to innovate,
like they can in the sphere of the internet.
It is fundamentally also the reason why the traditional phone makers
have been loosing market share to newcomers to the mobile sphere like
Apple with its iPhone or Google with its Android platform.
Those innovations really only happened on the application processor on
high-end smartphones. The closed GSM baseband processor had to be
accompanied by an independent application processor running a real
operating system, with real processes, memory management, shared
libraries, memory protection, virtual memory spaces, user-installable
applications, etc.
They still don't happen on the baseband processor, which is as closed as
it was 15 years ago.
\end{document}
--0ntfKIWw70PvrIHh--
or 6225 CPUs (need to look for documentation):
--- MT6225BA
CECT V8
TianShiDa TS822
--- MT6225/6225A
CECT 388
CECT 98
CECT 2618
CECT N95i
ChangHong 868
ChuangWei T508
DaXian X889
DaXian X769
GaoXinQi D808
Hantai HT622
Hantai HT6868
JingLi H9 (some H9 also have MT6226)
JinPeng A918
JinPeng 858
JinPeng A9
JinPeng S3506
JinPeng 2298
JinPeng L818
JinPeng A608
TianYu D170
TianYu B898
TianYu A930
TianYu B926
TianYu A908
ZTC 6988
ZTC 598
ZTC 1118
ZTE ZTLV900
ZTE ZT688 (note MT6205 versions also exist)
--- MT6223PA
TianYu B5010
CECT D1088
Next steps for me: Scan the schematics stuff and put it online. Find some
6223/6225 based phones that are cheap & suitable for hacking, i.e. ideally
with some nice test points or JTAG.
Other common MTK chips are 6205, 6217, 6218, 6219, 6226, 6228.
One word of caution - the above lists, and documentation we start digging
up, may give a false impression of predictability. In reality the brand
names and model numbers are a total mess in China. Typos everywhere. All
sorts of things are printed on cases & boxes, chips are changed without
anybody noticing or caring. There are endless smaller Chinese brands making
phones with 6223 or 6225 chips, but I think it will be very hard to use
them as a stable source, to get phones with the same chips over time. So
I think it's better to focus on the somewhat bigger Chinese brands as
listed above.
Wolfgang
not always 100% perfect (it depends on the phone and the cable), so
moving the phone during the download may cause the connection to be
interrupted. I have not yet looked at the serial signal with an
oscilloscope to see if there are problems with the signal itself.
Best regards,
Dieter
--
Dieter Spaar, Germany spaar(a)mirider.augusta.de
stage. Any ideas?
If I boot the phone and use 57600bps I get some prints and then AT
returns OK, no other AT commands work.
In case it is too broken I have ordered a C121 from germany as well.
/Erik
without having to go through the real layer1 or at least without having<br>
to go through the air.<br>
<br>
But without a clear path to later porting this on a real physical<br>
layer1, there would be little motivation of doing all that work.<br></block=
quote><div><br>I'd like to get involved in that, however these are my p=
roblems:<br>- I have no running system that I could debug and <br>=A0 there=
by learn how GSM works.<br>
-=A0 To=A0 get a running system I would need to implement a software<br>=A0=
=A0 only system, however, I cannot implement that without knowledge <br>=A0=
=A0 of GSM<br>=A0That is kindof a deadlock. <br><br>Therefore I wonder wea=
ther the expert of GSM would share their <br>
knowledge in the obove described way:<br>Having=A0 <br>=A0 - a flow diagram=
<br>=A0 - the etsi standard pages (or simple rewrites of it)<br>=A0 - the h=
tml parsed imlemention of a real TSM30 stack implement.<br>and linking that=
all together to get a way for a newbie to <br>
get started.<br>=A0</div><blockquote class=3D"gmail_quote" style=3D"border-=
left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left=
: 1ex;">
<br>
I think what makes OsmocomBB special is the very fact that we do not<br>
have to rely on simulation, but can do the "real thing".<br>
<br>
Nonetheleess, if somebody was interested in implementing what I've<br>
described, I'd be more than happy to help any such project and<br>
include the neccessary support in OpenBSC and/or OsmocomBB.<br>
<div><div></div><div class=3D"h5"><br>
--<br>
- Harald Welte <<a href=3D"mailto:laforge@gnumonks.org">laforge@gnumonks=
.org</a>> =A0 =A0 =A0 =A0 =A0 <a href=3D"http://laforge.gnumonks.org/" t=
arget=3D"_blank">http://laforge.gnumonks.org/</a><br>
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D<br>
"Privacy in residential applications is a desirable marketing option.&=
quot;<br>
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0 =A0 =A0(ETSI EN 300 175-7 Ch. A6)<br>
</div></div></blockquote></div><br>
--0016e65ae6825c4265048170c62d--
without having to go through the real layer1 or at least without having
to go through the air.
But without a clear path to later porting this on a real physical
layer1, there would be little motivation of doing all that work.
I think what makes OsmocomBB special is the very fact that we do not
have to rely on simulation, but can do the "real thing".
Nonetheleess, if somebody was interested in implementing what I've
described, I'd be more than happy to help any such project and
include the neccessary support in OpenBSC and/or OsmocomBB.
--
- Harald Welte <laforge(a)gnumonks.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
data to the network by using the RSL RLL DATA REQUEST primitive.
Also, while we are tuned to any BCCH/CCCH, the L3 frames are sent from
L2 to L3 in RSL RLL UNIT DATA INDICATION messages.
What is not as simple is the non-RLL part, i.e. sending the first RACH
request, ...
For those, we will have to invent our own new RSLms message types,
possibly reusing as many RSL information elements as possible - meaning
we can share more code/structure with what we already have in
libosmocore/openbsc
> is there a better (simpler) way?
The RSLms approach might not be the simplest one, but I think it would
be a very nice/orthogonal approach. Plus: In this model, we can
eventually move the L2 implementation into the MS firmware, while
talking RSLms over HLDC to L3 on the PC.
Regards,
Harald
--
- Harald Welte <laforge(a)gnumonks.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
Dear Osmocom community,
It's my pleasure to announce the next OsmoDevCall at
December 10, 2021 at 20:00 CET
at
https://meeting4.franken.de/b/har-xbc-bsx-wvs
This meeting will have the following schedule:
20:00 meet + greet
20:10 presentation "osmo-dev and running Osmocom TTCN3 tests suites locally" by osmith
21:00 unstructured supplementary social event [*]
Attendance is free of charge and open to anyone with an interest
in Osmocom or open source cellular technologies.
More information about OsmoDevCall, including the schedule
for further upcoming events can be found at
https://osmocom.org/projects/osmo-dev-con/wiki/OsmoDevCall
Looking forward to meeting you on Friday.
Best regards,
Harald
[*] this is how we started to call the "unstructured" part of osmocom
developer conferences in the past, basically where anyone can talk about
anything, no formal schedule or structure.
--
- Harald Welte <laforge(a)osmocom.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
Dear Osmocom community,
It's my pleasure to announce the next OsmoDevCall at
November 25, 2021 at 20:00 CET (yes, Thursday instead of Friday this time!)
at
https://meeting4.franken.de/b/har-xbc-bsx-wvs
This meeting will have the following schedule:
20:00 meet + greet
20:10 presentation "Control/User Plane Separation (CUPS) + PFCP" by laforge
21:00 unstructured supplementary social event [*]
Attendance is free of charge and open to anyone with an interest
in Osmocom or open source cellular technologies.
More information about OsmoDevCall, including the schedule
for further upcoming events can be found at
https://osmocom.org/projects/osmo-dev-con/wiki/OsmoDevCall
Looking forward to meeting you on Friday.
Best regards,
Harald
[*] this is how we started to call the "unstructured" part of osmocom
developer conferences in the past, basically where anyone can talk about
anything, no formal schedule or structure.
--
- Harald Welte <laforge(a)osmocom.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
Dear Osmocom community,
It's my pleasure to announce the next OsmoDevCall at
November 12, 2021 at 20:00 CET
at
https://meeting4.franken.de/b/har-xbc-bsx-wvs
This meeting will have the following schedule:
20:00 meet + greet
20:10 presentation "E1 / TDM / PDH / SDH basics" by laforge
20:30 presentation "icE1usb in practice" by tnt
later USSE: unstructured supplementary social event [*]
Attendance is free of charge and open to anyone with an interest
in Osmocom.
More information about OsmoDevCall, including the schedule
for further upcoming events can be found at
https://osmocom.org/projects/osmo-dev-con/wiki/OsmoDevCall
Looking forward to meeting you on Friday.
Best regards,
Harald
[*] this is how we started to call the "unstructured" part of osmocom
developer conferences in the past, basically where anyone can talk about
anything, no formal schedule or structure.
--
- Harald Welte <laforge(a)osmocom.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
Hi Kevin,
On Fri, Nov 05, 2021 at 02:18:14PM +0100, Kévin Redon wrote:
> I'm also happy to help with the recording and streaming of the public talks for those not able to join on site.
thanks for that, as usual.
--
- Harald Welte <laforge(a)osmocom.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
> requiring vaccination to attend by default. Maybe with the option for attendees
> to request attendance despite no vaccination, and then see whether we can
> unanimously agree on that?
I'd like to add that I find it should also be sufficient to have recovered from
COVID. This is a common rule in schools in Berlin that does relieve teachers
from the need to test regularly (called 2G, incidentally).
Another question is whether we play by RKI rules and not accept certain
vaccines.
I guess we should first see whether anyone would be refused attendance based on
these rules and take it from there?
Here is a dudle to anonymously figure out the current vaccination status. Feel
free to enter your current status, especially if you're not fully vaccinated
and would like to attend. This is just to get a basis for discussion:
https://dudle.inf.tu-dresden.de/w93G6NPqfA/
I guess we need to repeat such poll in early '22.
Dear All,
I am running a GSM stack:
osmo-stp
smo-msc
osmo-hlr
osmo-bsc
osmo-bts-trx
osmo-trx-lms
It seems that my transmitter is emitting radio-waves into air (osmo-bts-trx and osmo-trx-lms communicate with each other through ports 5702 / 5802 — pls see attached printscreen), however i could not make GSMTAP tracing. Osmo-bts-trx does not send GSMTAP messages to port 4729.
In most recent version of osmo-bts, GSMTAP tracing is arranged through config file:
bts 0
gsmtap-remote-host 127.0.0.1
gsmtap-sapi ccch
I could not run the GSMTAP tracing even in previous verions of osmo-bts where you have to specify in synopsis when you call a program:
/usr/bin/osmo-bts-trx -s -c /etc/osmocom/osmo-bts-trx.cfg --gsmtap-ip 127.0.0.1
I thought may be i am having some issues in stack components behind osmo-bts for example in osmo-bsc or behind and i tried to run virtual bts.
When i tried to run osmo-bts-virtual GSMTAP messages were visible in wireshark (please see attached file osmo-bts-virtual), therefore bts-bsc communication is good.
However I still could not figure out why my osmo-bts-trx does not send GSMTAP messages.
Or would you advise what log might be helpful to see what i am doing wrong ….
Thank you for your always helpful assistance
--
Mario Lucas
When i try to run osmo-bts-trx i am getting following log in osmo-bsc
abis_rsl.c:142 (bts=0,trx=0,ts=0,pchan_from_config=CCCH+SDCCH4,state=NOT_INITIALIZED) Abis RSL rx CCHAN: mismatching chan_nr=0x90
I tried to find out in bugs:
https://osmocom.org/issues/4872 but could not understand …
i am using
osmo-bsc 1.7.1 and osmo-bts-trx 1.3.3
Could you pls advise me briefly whats happening and how to sort it out ?
--
Mario Lucas
Dear All,
I am having following error during ‘make’ osmocombb:
libmobile.a(mncc_sock.o): In function `mncc_sock_accept':
/home/ubuntu/Desktop/OsmocomBB/master/src/host/layer23/src/mobile/mncc_sock.c:229: undefined reference to `osmo_fd_read_disable'
libmobile.a(mncc_sock.o): In function `mncc_sock_close':
/home/ubuntu/Desktop/OsmocomBB/master/src/host/layer23/src/mobile/mncc_sock.c:95: undefined reference to `osmo_fd_read_enable'
libmobile.a(mncc_sock.o): In function `mncc_sock_write':
/home/ubuntu/Desktop/OsmocomBB/master/src/host/layer23/src/mobile/mncc_sock.c:159: undefined reference to `osmo_fd_write_disable'
/home/ubuntu/Desktop/OsmocomBB/master/src/host/layer23/src/mobile/mncc_sock.c:174: undefined reference to `osmo_fd_write_enable'
libmobile.a(mncc_sock.o): In function `mncc_sock_from_cc':
/home/ubuntu/Desktop/OsmocomBB/master/src/host/layer23/src/mobile/mncc_sock.c:75: undefined reference to `osmo_fd_write_enable'
libmobile.a(mncc_sock.o): In function `mncc_sock_write_pending':
/home/ubuntu/Desktop/OsmocomBB/master/src/host/layer23/src/mobile/mncc_sock.c:81: undefined reference to `osmo_fd_write_enable'
collect2: error: ld returned 1 exit status
Makefile:394: recipe for target 'mobile' failed
make[3]: *** [mobile] Error 1
make[3]: Leaving directory '/home/ubuntu/Desktop/OsmocomBB/master/src/host/layer23/src/mobile'
Makefile:325: recipe for target 'all-recursive' failed
make[2]: *** [all-recursive] Error 1
make[2]: Leaving directory '/home/ubuntu/Desktop/OsmocomBB/master/src/host/layer23/src'
Makefile:351: recipe for target 'all-recursive' failed
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory '/home/ubuntu/Desktop/OsmocomBB/master/src/host/layer23'
Makefile:97: recipe for target 'host/layer23/layer23' failed
make: *** [host/layer23/layer23] Error 2
My
arm-elf-gcc is gcc version 4.5.2 (GCC)
libosmocore 1.4.1
I believe it is something with libraries but could not figure out ….
--
Mario Lucas
Dear Osmocom community,
It's my pleasure to announce the next OsmoDevCall at
September 24, 2021 at 20:00 CEST
at
https://meeting4.franken.de/b/har-xbc-bsx-wvs
This meeting will have the following schedule:
20:00 meet + greet
20:15 presentation on "ISO 7816 smart card interface FPGA softcore" by tnt
21:00 USSE: unstructured supplementary social event [*]
22:00 close of call
Attendance is free of charge and open to anyone with an interest
in Osmocom.
More information about OsmoDevCall, including the schedule
for further upcoming events can be found at
https://osmocom.org/projects/osmo-dev-con/wiki/OsmoDevCall
Looking forward to meeting you on Friday.
Best regards,
Harald
[*] this is how we started to call the "unstructured" part of osmocom
developer conferences in the past, basically where anyone can talk about
anything, no formal schedule or structure.
--
- Harald Welte <laforge(a)osmocom.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
Dear Forum members i am not sure this question directly relates to Osmocom, but I don’t know where I can post it else …. If you know some active / alive technical forum which relates to GSM side (frequencies, modulations, GMSK etc etc) it would be very great if you could advise me …..
Meanwhile I ll continue with my question….
51 TDMA multiframe starts with a FCCH which carries frequency correction burst on TS0.
Due to nature of GMSK modulation and initial zeros of frequency correction burst the aired signal (signal that GSM modulator emits into air) as I understand is nothing but sine wave of an approximately 67Khz on top of the carrier frequency. Once mobile finds the frequency correction burst on some frequency it subtracts 67 Khz and precisely gets / sits on beacon frequency. So when it is said that upon switching the mobile phone on - it is looking for frequency correction bursts means in different words that it is looking for sine wave in GSM frequency interval it can work. Let’s say if my phone can work only in E-GSM900 interval (925 - 960 Mhz) it is looking for sine wave (frequency correction burst) and once finds it will subtract 67 Khz and it will be precisely the carrier frequency of beacon channel ?
So if I use my rtl-sdr and software that analyzes RF spectrum (something like only oscilloscope) in 925 960 Mhz interval and I notice sine waves with periodic occurrence - as many times as FCCH appears in 51 multiframe - can I say that got frequency correction burst and subtracting 67 Khz I got beacon frequency ?
--
Mario Lucas
Dear All,
Could you please advise me based on what logic (how) can i decompose logical channel configuration CCCH+SDCCH4 which is mapped on TS0… ?
So my understanding is as follows:
There are 51 TDMA frames in multiframe, therefore i am having 51 consecutive TS0 slots. So CCCH+SDCCH4 should be redistributed in these 51 slots.
SDCCH4 means that there are 4 SDCCH blocks, each block is having 4 bursts or 4 timeslots in another words (as i understand to transmit SDCCH «unit data» it is needed 4 burts), so 16 slots are occupied by SDCCH.
Does it mean 51-16 = 35 slots to be occupied by CCCH ?
If i use following notation CCCH=C, SDCCH1=S1, SDCCH2=S2, SDCCH3=S3 and SDCCH4=S4 does the decomposition looks like:
CCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCC S1S1S1S1 S2S2S2S2 S3S3S3S3 S4S4S4S4
If so should not there be an idle slots … ?
Thank you so much.
--
Mario Lucas
Dear All,
I try to run a virtual BTS:
systemctl start osmo-stp
systemctl start osmo-hlr
systemctl start osmo-msc
systemctl start osmo-bsc
and finally i run osmo-bts-virtual…. but i am getting following outcome:
DOML <0001> oml.c:91 OC=GPRS-CELL INST=(00,ff,ff): Sending PCU version report to BSC: PCU socket has LOST connection
DPCU <0009> pcu_sock.c:1084 PCU socket connected to external PCU
DPCU <0009> pcu_sock.c:967 Received 212 bytes on PCU Socket, but primitive size is 1006, discarding
DPCU <0009> pcu_sock.c:895 PCU socket has LOST connection
I tried to run osmo-pcu (I thought may be this will resole above issue) but it keeps saying:
<000b> gprs_ns.c:322 NSVCI=65534 Creating NS-VC with Signal weight 1, Data weight 1
<000e> telnet_interface.c:104 Available via telnet 127.0.0.1 4240
<0001> osmobts_sock.cpp:224 Opening OsmoPCU L1 interface to OsmoBTS
<0001> osmobts_sock.cpp:248 osmo-bts PCU socket /tmp/pcu_bts has been connected
<0001> pcu_l1_if.cpp:114 Sending 0.8.0 TXT as PCU_VERSION to BTS
PCU interface version number of BTS (10) is different (9).
Please re-compile!
I have
OsmoPCU version 0.8.0
OsmoBTS version 1.2.0.307-6e27
Would you kindly advise whats going on please….
As i understand osmo-pcu is to implement GPRS into my GSM network… ok but if i dont want GPRS implemented thus i dont need PCU …. can i run virtual bts without this PCU things ?
pls help …..
--
Mario Lucas
Dear All,
I have a running BTS (based on SDR) and i can connect my phone to my network… do / learn some operations…
I have a couple of sim cards and each time i want to connect to network with different sim i have to switch of mobile remove previous sim put new one etc etc ….
Is there an application that will be running on PC and connected to my phone which will a kind of simulate sim and connect my phone to my network ? Avoiding me each time physically remove previous sim put new one etc etc …
Would you be so kind and advise me please…
Also another question — is there a «search» option in the archives :
http://lists.osmocom.org/pipermail/openbsc/http://lists.osmocom.org/pipermail/baseband-devel/
just not to post questions which already could have been answered….
--
Mario Lucas
Dear Osmocom community,
It's my pleasure to announce the next OsmoDevCall at
August 27, 2021 at 20:00 CEST
at
https://meeting4.franken.de/b/har-xbc-bsx-wvs
This meeting will have the following schedule:
20:00 meet + greet
20:15 presentation on "osmo-remsim in practice"
21:00 USSE: unstructured supplementary social event [*]
22:00 close of call
Attendance is free of charge and open to anyone with an interest
in Osmocom.
More information about OsmoDevCall, including the schedule
for further upcoming events can be found at
https://osmocom.org/projects/osmo-dev-con/wiki/OsmoDevCall
Looking forward to meeting you on Friday.
Best regards,
Harald
[*] this is how we started to call the "unstructured" part of osmocom
developer conferences in the past, basically where anyone can talk about
anything, no formal schedule or structure.
--
- Harald Welte <laforge(a)osmocom.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
Dear Osmocom community,
It's my pleasure to announce the next OsmoDevCall at
August 13, 2021 at 20:00 CEST
at
https://meeting4.franken.de/b/har-xbc-bsx-wvs
This meeting will have the following schedule:
20:00 meet + greet
20:15 presentation on "GSM-R and its differences to GSM"
21:00 USSE: unstructured supplementary social event [*]
22:00 close of call
Attendance is free of charge and open to anyone with an interest
in Osmocom.
More information about OsmoDevCall, including the schedule
for further upcoming events can be found at
https://osmocom.org/projects/osmo-dev-con/wiki/OsmoDevCall
Looking forward to meeting you on Friday.
Best regards,
Harald
[*] this is how we started to call the "unstructured" part of osmocom
developer conferences in the past, basically where anyone can talk about
anything, no formal schedule or structure.
--
- Harald Welte <laforge(a)osmocom.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
Hello,
I'm trying to run CalypsoBTS as described here:
https://osmocom.org/projects/baseband/wiki/CalypsoBTS
I'm using a single Motorola C123 phone and in my openbsc.conf, i have
only one CCCH+SDCCH4 channel on timeslot 0:
timeslot 0
phys_chan_config CCCH+SDCCH4
hopping enabled 0
I'm using the fixeria/trx branch with recent OsmoBTS.
First, i load the trx firmware on the phone, and then i start the
transceiver host app to sync with a known ARFCN. The syncing goes
without any issues.
Then, i start OpenBSC through OsmoNITB like that:
osmo-nitb -c ~/.osmocom/openbsc.cfg -l ~/.osmocom/hlr.sqlite3 -P -C
--debug=DRLL:DCC:DMM:DRR:DRSL:DNM
--yes-i-really-want-to-run-prehistoric-software
And OsmoBTS:
osmo-bts-trx -c ~/.osmocom/osmo-bts.cfg
OsmoBTS fails almost instantly with:
<0012> input/ipaccess.c:898 received ID_GET for unit ID 1801/0/0
<000b> trx_if.c:701 phy0.0: Response message 'RSP ERR 1 ' does not
match command message 'CMD RFMUTE 1' <000b> trx_if.c:645 phy0.0:
transceiver rejected TRX command with response: 'ERR 1' <0001>
oml.c:221 (bts=0,trx=0): O&M Get Attributes [0], Manufacturer Dependent
State is unsupported by TRX. <000b> trx_if.c:134 phy0.0: Ignoring CLOCK
IND 2061832, TRX not yet powered on
The last message repeats until i terminate the application.
On the OsmoNITB side, i get:
<0005> abis_nm.c:550 OC=BTS(01) INST=(00,ff,ff) Get Attributes Response
for BTS0 <0005> abis_nm.c:463 BTS0 Get Attributes Response Info: 72
bytes total with 0 unreported attributes <0005> abis_nm.c:497 BTS0 Get
Attributes Response: reported unexpectedly long (3 bytes) feature
vector - most likely it was compiled against newer BSC headers.
Consider upgrading your BSC to later version. <0005> abis_nm.c:507 BTS0
feature 'Frequency Hopping' reported via OML does not match statically
set feature: 1 != 0. Please fix. <0005> abis_nm.c:507 BTS0 feature
'Multi-TSC' reported via OML does not match statically set feature:
1 != 0. Please fix. <0005> abis_nm.c:507 BTS0 feature 'OML Alerts'
reported via OML does not match statically set feature: 1 != 0. Please
fix. <0005> abis_nm.c:507 BTS0 feature 'CBCH' reported via OML does not
match statically set feature: 1 != 0. Please fix. <0005> abis_nm.c:577
BTS0: failed to parse SW-Config part of Get Attribute Response Info:
Invalid argument <0005> abis_nm.c:550 OC=BASEBAND-TRANSCEIVER(04)
INST=(00,00,ff) Get Attributes Response for BTS0 <0005> abis_nm.c:463
BTS0 Get Attributes Response Info: 34 bytes total with 1 unreported
attributes <0005> abis_nm.c:468 BTS0 Attribute Manufacturer Dependent
State is unreported <0005> abis_nm.c:577 BTS0: failed to parse
SW-Config part of Get Attribute Response Info: Invalid argument <0005>
abis_nm.c:771 OC=SITE-MANAGER(00) INST=(ff,ff,ff) Opstart ACK <0005>
abis_nm.c:381 OC=SITE-MANAGER(00) INST=(ff,ff,ff) STATE CHG:
OP_STATE=Enabled AVAIL=OK(ff) ADM=Locked <0005> abis_nm.c:1938
OC=SITE-MANAGER(00) INST=(ff,ff,ff) Sending OPSTART <0005>
abis_nm.c:771 OC=SITE-MANAGER(00) INST=(ff,ff,ff) Opstart ACK
And on the transceiver side, between the successful CLK Indication
messages, i get:
<0011> trx.c:509 [!] No handlers found for command 'RFMUTE'. Empty
response <0011> trx.c:226 TRX Control send: |RSP ERR 1 |
Is this issue due to the unimplemented in the transceiver command
"RFMUTE" or what really fails is:
<0005> abis_nm.c:577 BTS0: failed to parse SW-Config part of Get
Attribute Response Info: Invalid argument
?
I also tried using components from their circa-2017-2018 revisions but
there are so many changes in core Osmocom libraries that they always
fail to compile and fixing them is hardly worth it, given the amount of
work it is.
I know OsmoNITB is abandoned since 2017, but currently this is the only
way for a beginner to experiment with BTS based on cheap Calypso
phones, as it is not implemented in the new Oscomcom stack.
Hi
I would like to emulate a R&S Test-SIM.
For that, I need a38 XOR Algorithm.
Would this be possible with SoftSIM and Osmocom-BB?
How do I put /calculate the Ki in the SIM.xml file?
Theres just RAND,SRES,Kc field.
Thanks.
Hello,
I'm trying to build the transceiver branch for Calypso phones. I
installed all OsmocomBB dependencies (including libosmocore) and i
sucessfully built and installed libosmo-dsp from the Git repo. My ARM
toolchain is from here:
https://developer.arm.com/tools-and-software/open-source-software/developer… .
When building, however, the compiler fails with:
arm-none-eabi-ld:
comm/libcomm.a(msgb.o):~/trx/src/target/firmware/comm/msgb.c:35:
multiple definition of
`tall_msgb_ctx'; ../../shared/libosmocore/build-target/src/.libs/libosmocore.a(msgb.o):(.bss+0x0):
first defined here Makefile.inc:135: recipe for target
'board/compal_e88/hello_world.highram.elf' failed
I tried both sylvain/testing and jolly/testing branches.
What seems to be the problem?
Thanks!
Dear Osmocom community,
It's my pleasure to announce the next OsmoDevCall at
July 23, 2021 at 20:00 CEST
at
https://meeting4.franken.de/b/har-xbc-bsx-wvs
This meeting will have the following schedule:
20:00 meet + greet
20:15 presentation on "high-level overview on IMS, VoLTE, VoWiFi"
21:00 USSE: unstructured supplementary social event [*]
22:00 close of call
Attendance is free of charge and open to anyone with an interest
in Osmocom.
More information about OsmoDevCall, including the schedule
for further upcoming events can be found at
https://osmocom.org/projects/osmo-dev-con/wiki/OsmoDevCall
Looking forward to meeting you on Friday.
Best regards,
Harald
[*] this is how we started to call the "unstructured" part of osmocom
developer conferences in the past, basically where anyone can talk about
anything, no formal schedule or structure.
--
- Harald Welte <laforge(a)osmocom.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
Dear Osmocom community,
It's my pleasure to announce the next OsmoDevCall at
July 9, 2021 at 20:00 CEST
at
https://meeting4.franken.de/b/har-xbc-bsx-wvs
This meeting will have the following schedule:
20:00 meet + greet
20:15 hands-on tutorial by miaoski: Setting up open5gs
21:00 USSE: unstructured supplementary social event [*]
22:00 close of call
Attendance is free of charge and open to anyone with an interest
in Osmocom.
More information about OsmoDevCall, including the schedule
for further upcoming events can be found at
https://osmocom.org/projects/osmo-dev-con/wiki/OsmoDevCall
Looking forward to meeting you on Friday.
Best regards,
Harald
[*] this is how we started to call the "unstructured" part of osmocom
developer conferences in the past, basically where anyone can talk about
anything, no formal schedule or structure.
--
- Harald Welte <laforge(a)osmocom.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
Dear Osmocom community,
It's my pleasure to announce the next OsmoDevCall at
June 11, 2021 at 20:00 CEST
at
https://meeting4.franken.de/b/har-xbc-bsx-wvs
This meeting will have the following schedule:
20:00 meet + greet
20:15 presentation by keith: "Screen Sharing peek at TIC A.C. infrastructure in Oaxaca"
21:00 USSE: unstructured supplementary social event [*]
22:00 close of call
TIC A.C. is an operator of Osmocom based community cellular networks in
indigenous communities of the Mexican state of Oaxaca. Keith works with
Rhizomatica and TIC A.C. and will give us some live insight into how
they operate
Attendance is free of charge and open to anyone with an interest
in Osmocom.
More information about OsmoDevCall, including the schedule
for further upcoming events can be found at
https://osmocom.org/projects/osmo-dev-con/wiki/OsmoDevCall
Looking forward to meeting you on Friday.
Best regards,
Harald
[*] this is how we started to call the "unstructured" part of osmocom
developer conferences in the past, basically where anyone can talk about
anything, no formal schedule or structure.
--
- Harald Welte <laforge(a)osmocom.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
Dear Osmocom community,
It's my pleasure to announce the next OsmoDevCall at
May 28, 2021 at 20:00 CEST
at
https://meeting4.franken.de/b/har-xbc-bsx-wvs
This meeting will have the following schedule:
20:00 meet + greet
20:15 presentation by fixeria: "Hacking binary protocols with Pycrate"
21:00 USSE: unstructured supplementary social event [*]
22:00 close of call
Attendance is free of charge and open to anyone with an interest
in Osmocom.
More information about OsmoDevCall, including the schedule
for further upcoming events can be found at
https://osmocom.org/projects/osmo-dev-con/wiki/OsmoDevCall
Looking forward to meeting you on Friday.
Best regards,
Harald
[*] this is how we started to call the "unstructured" part of osmocom
developer conferences in the past, basically where anyone can talk about
anything, no formal schedule or structure.
--
- Harald Welte <laforge(a)osmocom.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
Dear Osmocom community,
It's my pleasure to announce the next OsmoDevCall at
May 14, 2021 at 20:00 CEST
at
https://meeting4.franken.de/b/har-xbc-bsx-wvs
This meeting will have the following schedule:
20:00 meet + greet
20:15 presentation by laforge: "SS7 and SIGTRAN in 2G/3G networks"
21:00 USSE: unstructured supplementary social event [*]
22:00 close of call
Presentation Abstract:
This talk will cover some classic circuit-switched SS7 basics as
well as SIGTRAN (SS7 over IP) and how this is used as underlying
transport for a variety of interfaces in the 2G (GSM) and 3G
(UMTS) cellular networks even today.
Attendance is free of charge and open to anyone with an interest
in Osmocom.
More information about OsmoDevCall, including the schedule
for further upcoming events can be found at
https://osmocom.org/projects/osmo-dev-con/wiki/OsmoDevCall
Looking forward to meeting you on Friday.
Best regards,
Harald
[*] this is how we started to call the "unstructured" part of osmocom
developer conferences in the past, basically where anyone can talk about
anything, no formal schedule or structure.
--
- Harald Welte <laforge(a)osmocom.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
Dear Osmocom community,
It's my pleasure to announce the next OsmoDevCall at
April 23, 2021 at 20:00 CEST
at
https://meeting4.franken.de/b/har-xbc-bsx-wvs
This meeting will have the following schedule:
20:00 meet + greet
20:15 presentation by horiz0n: "YIG & YANG (Yet ANother yiG driver)"
21:00 USSE: unstructured supplementary social event [*]
22:00 close of call
Presentation Abstract:
This talk will briefly introduce the working principles of YIG
(Yttrium Iron Garnet) microwave circuits, their applications and
finally conclude with a presentation of a recently developed driver
circuit.
Attendance is free of charge and open to anyone with an interest
in Osmocom.
More information about OsmoDevCall, including the schedule
for further upcoming events can be found at
https://osmocom.org/projects/osmo-dev-con/wiki/OsmoDevCall
Looking forward to meeting you on Friday.
Best regards,
Harald
[*] this is how we started to call the "unstructured" part of osmocom
developer conferences in the past, basically where anyone can talk about
anything, no formal schedule or structure.
--
- Harald Welte <laforge(a)osmocom.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
Dear Osmocom community,
It's my pleasure to announce the next OsmoDevCall at
April 9, 2021 at 20:00 CET
at
https://meeting4.franken.de/b/har-xbc-bsx-wvs
This meeting will have the following schedule:
20:00 meet + greet
20:15 presentation: pySim-shell - the next generation of pySim
21:00 USSE: unstructured supplementary social event [*]
22:00 close of call
Presentation Abstract:
For more than a decade, pySim-prog has been the tool to
configure/program SIM cards in research/lab/private cellular
networks. Originally designed for very simplistic GSM-only SIM
Cards, it was extended again and again to cover more use cases
and parameters. There is a limit as to how far one can go with
stuffing everything into command line arguments.
In 2021, pySim-shell was created as the next generation tool. It
features interactive navigation around the file system, editing
capabilities, backup and restore of all [known] files, ...
Attendance is free of charge and open to anyone with an interest
in Osmocom.
More information about OsmoDevCall, including the schedule
for further upcoming events can be found at
https://osmocom.org/projects/osmo-dev-con/wiki/OsmoDevCall
Looking forward to meeting you on Friday.
Best regards,
Harald
[*] this is how we started to call the "unstructured" part of osmocom
developer conferences in the past, basically where anyone can talk about
anything, no formal schedule or structure.
--
- Harald Welte <laforge(a)osmocom.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
Hi I am trying to build osmocombb on Ubuntu 18.04 with GCC-4.9 & arm-elf-gcc-4.5.2, I am getting the following error, how do I fix this issued.
Making all in mobilemake[3]: Entering directory '/root/trx/src/host/layer23/src/mobile' CCLD mobilelibmobile.a(gsm322.o): In function `memset':/usr/include/x86_64-linux-gnu/bits/string_fortified.h:67: undefined reference to `__warn_memset_zero_len'collect2: error: ld returned 1 exit statusMakefile:379: recipe for target 'mobile' failedmake[3]: *** [mobile] Error 1make[3]: Leaving directory '/root/trx/src/host/layer23/src/mobile'Makefile:325: recipe for target 'all-recursive' failedmake[2]: *** [all-recursive] Error 1make[2]: Leaving directory '/root/trx/src/host/layer23/src'Makefile:350: recipe for target 'all-recursive' failedmake[1]: *** [all-recursive] Error 1make[1]: Leaving directory '/root/trx/src/host/layer23'Makefile:51: recipe for target 'layer23' failedmake: *** [layer23] Error 2
Regards
Babar Ali
Hi all,
I am facing problem while compiling osmocombb on Ubuntu 18.04, i have tried libosmocore 0.9.0 / 1.1.0 but no luck, i have also tried to switch between gcc 4.9, 5, 7, all the time i have received same error, any idea to fix this issue,
I have attached error log for reference, please.
Regards
Babar Ali
Dear Osmocom community,
as the pandemic continues and physical meetings are out of the question
for the forseeable future, it would be a good idea to have a periodic
virtual online meeting of the interested Osmocom community.
I was thinking of a format where we would serve two major purposes:
1) technical talks about osmocom relevant topics - ideally
current/recent developments
* can be pre-recorded to avoid any problems with technical setup,
streaming, ...
* should ideally have a Q+A session at their initial "airing" during
one OsmoDevCall
2) unstructured solicited social event (USSE)
* random chat in audio (optionally video)
* not recorded, obviously
The recording of the technical presentation should then be permanently
made available (like the presentations of our prior OsmoCon /
OsmoDevCon).
Not every OsmoDevCall would neccessarily need the two parts, but I think
it would be great if we can make that happen. We could also have e.g. a
two-weekly schedule for the USSE and a monthly schedule for the
technical presentation.
We'd need somebody to volunteer to "manage" the "broadcast" side of
this, preferably somebody with at least some prior exposure to online
events (like the c3voc).
I'm using https://osmocom.org/issues/4928 to collect a tentative list
of topics. Feel free to add your ideas there, as well as any comment/
feedback you may have.
Regards,
Harald
--
- Harald Welte <laforge(a)osmocom.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
Dear Osmocom community,
This topic has been past due for way too many years by now:
A re-organization of our major mailing lists.
I would like to propose the following changes. Pleas let me know if you
have any comments or feedback. I'm aware that renaming will mean people
have to update their mail filter rules, but I think we're long past the
point where the names of some of our lists started to confuse users.
== openbsc(a)lists.osmocom.org ==
* openbsc doesn't exist anymore since OsmoNITB, which is also obsolete
* does already cover anything "Osmocom CNI" related
* Proposed new name: osmocom-cni(a)lists.osmocom.org
== osmocom-net-gprs(a)lists.osmocom.org ==
This date back to when GPRS was a highly experimental add-on to our GSM
code base. This list should simply be merged with openbsc@ as osmocom-cni(a)lists.osmocom.org
== simtrace(a)lists.osmocom.org ==
Historically was created to cover only the simtrace project.
We should rename this to osmocom-simcard(a)lists.osmocom.org or something
along those lines.
I would like to suggest it covers
* SIMtrace / SIMtrace2 hardware + firmware
* pySim and related tools for working with SIM/USIM/UICC cards
* any other information / discussion related to SIM/USIM/UICC cards,
like OTA, ARA-M, ...
== osmodevcon(a)lists.osmocom.org ==
This has been a private list for people attending OsmoDevCon
I would like to open up list membership to the general public, and ensure
it also covers the new OsmoDevCall. We could then have discussions regarding
feedback, topics, scheduling, etc. on that list.
Maybe rename it to osmocom-events(a)lists.osmocom.org instead?
To differentiate: osmocom-event-orga(a)lists.osmocom.org should remain a
private list related to organizational / administrative topics of those
involved with organizing future events.
== nextepc(a)lists.osmocom.org ==
Should have been renamed to open5gs(a)lists.osmocom.org quite some time
ago, I simply forgot about it. My apologies.
--
- Harald Welte <laforge(a)osmocom.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
Dear Osmocom community,
today marks the 11th birthday of OsmocomBB, which had originally been
announced on February 19, 2010 in the following mailing list post:
https://lists.osmocom.org/pipermail/baseband-devel/2010-February/000142.html
As we missed to properly celebrate the 10th anniversary, I'd like to
use the off-by-one occasion to invite anyone interested to a spontaneous
online birthday party tonight.
As the original announcement was at 19:02:04 UTC, the online meeting
today will also start at
19:02:04 UTC (that's roughly 8pm CET for those of us in the EU)
at
https://meet.sysmocom.de/OsmocomBB (password: Calypso)
I know it's very shot notice, but I still thought it's a good idea, let's
see whom of the past or current developers and users will be joining.
There's no structure, presentation or anything. Just some USSE
(Unstructured Supplementary Social Event).
Regards,
Harald
--
- Harald Welte <laforge(a)osmocom.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
Dear forum,
I am setting / running GSM network with LimeSdr and Osmo-packgaes:
osmo-bts-trx
osmo-bsc
osmo-hlr
osmo-msc
osmo-pcu
osmo-stp
osmo-trx-lms
and as i understand the only option to vary / set up output power is through the → osmo-bsc →
trx 0
nominal power 23
! to use full TRX power, set max_power_red 0
max_power_red 20
So does this mean that 23-20=3 dbm?
With this set up i instruct LimeSDRmini to transmit 3dbm signal into the air? If so — when i brought phone just into the very vicinity of LimeSDR antena (touching phone and SDR antena) on my smartphone screen i got signal -60 dbm …why did i get such a low figure ?
Also if you know is there any supporting application / software that can tell at what dBm LimeSDRmini is sending RF into air?
--
Mario Lucas