import of old now defunct presentation slides svn repo

16 files changed, 1159 insertions, 0 deletions

diff --git a/2010/gsm_foss-mt2010/OBTSBM2010.jpg b/2010/gsm_foss-mt2010/OBTSBM2010.jpg
new file mode 100644
index 0000000..7759978
--- /dev/null
+++ b/2010/gsm_foss-mt2010/OBTSBM2010.jpg
diff --git a/2010/gsm_foss-mt2010/bts_tree_full.jpg b/2010/gsm_foss-mt2010/bts_tree_full.jpg
new file mode 100644
index 0000000..6b5c5e8
--- /dev/null
+++ b/2010/gsm_foss-mt2010/bts_tree_full.jpg
diff --git a/2010/gsm_foss-mt2010/c123_pcb.jpg b/2010/gsm_foss-mt2010/c123_pcb.jpg
new file mode 100644
index 0000000..a9f24fc
--- /dev/null
+++ b/2010/gsm_foss-mt2010/c123_pcb.jpg
diff --git a/2010/gsm_foss-mt2010/calypso-block.pdf b/2010/gsm_foss-mt2010/calypso-block.pdf
new file mode 100644
index 0000000..27f8be8
--- /dev/null
+++ b/2010/gsm_foss-mt2010/calypso-block.pdf
diff --git a/2010/gsm_foss-mt2010/gsm_foss.pdf b/2010/gsm_foss-mt2010/gsm_foss.pdf
new file mode 100644
index 0000000..4048816
--- /dev/null
+++ b/2010/gsm_foss-mt2010/gsm_foss.pdf
diff --git a/2010/gsm_foss-mt2010/gsm_foss.snm b/2010/gsm_foss-mt2010/gsm_foss.snm
new file mode 100644
index 0000000..e69de29
--- /dev/null
+++ b/2010/gsm_foss-mt2010/gsm_foss.snm
diff --git a/2010/gsm_foss-mt2010/gsm_foss.tex b/2010/gsm_foss-mt2010/gsm_foss.tex
new file mode 100644
index 0000000..fa26c86
--- /dev/null
+++ b/2010/gsm_foss-mt2010/gsm_foss.tex
@@ -0,0 +1,177 @@
+
+\newcommand{\degree}{\ensuremath{^\circ}}
+%\documentclass[handout]{beamer}
+\documentclass{beamer}
+
+% This file is a solution template for:
+
+% - Talk at a conference/colloquium.
+% - Talk length is about 20min.
+% - Style is ornate.
+
+
+
+% Copyright 2004 by Till Tantau <tantau@users.sourceforge.net>.
+%
+% In principle, this file can be redistributed and/or modified under
+% the terms of the GNU Public License, version 2.
+%
+% However, this file is supposed to be a template to be modified
+% for your own needs. For this reason, if you use this file as a
+% template and not specifically distribute it as part of a another
+% package/program, I grant the extra permission to freely copy and
+% modify this file as you see fit and even to delete this copyright
+% notice. 
+
+
+\mode<presentation>
+{
+  \usetheme{Warsaw}
+  % or ...
+
+  \setbeamercovered{transparent}
+  % or whatever (possibly just delete it)
+}
+
+\mode<handout>{
+	\usepackage{handoutWithNotes}
+	\pgfpagesuselayout{2 on 1 with notes landscape}[a4paper,border shrink=5mm]
+	\usecolortheme{seahorse}
+}
+
+% ensure the page number is printed in front of the author name in the footer 
+\newcommand*\oldmacro{}
+\let\oldmacro\insertshortauthor% save previous definition
+\renewcommand*\insertshortauthor{%
+  \leftskip=.3cm% before the author could be a plus1fill ...
+  \insertframenumber\,/\,\inserttotalframenumber\hfill\oldmacro}
+
+\usepackage[english]{babel}
+\usepackage[latin1]{inputenc}
+\usepackage{times}
+\usepackage[T1]{fontenc}
+
+\usepackage{subfigure}
+\usepackage{hyperref}
+\usepackage{textcomp,listings}
+%\usepackage{german}
+\lstset{basicstyle=\scriptsize\ttfamily, upquote}
+
+% \title{GSM Air Interface Security}
+\title{Free / Open Source Software for GSM} %Hashdays 2010 title
+
+%\subtitle{and other GSM related fun}
+
+\author{Harald~Welte}
+
+\institute{gnumonks.org\\OpenBSC\\airprobe.org\\osmocom.org\\hmw-consulting.de}
+
+% - Use the \inst command only if there are several affiliations.
+% - Keep it simple, no one is interested in your street address.
+
+\date[December 2010] % (optional, should be abbreviation of conference name)
+{December 2010, Taiwan}
+% - Either use conference name or its abbreviation.
+% - Not really informative to the audience, more for people (including
+%   yourself) who are reading the slides online
+
+\subject{GSM}
+% This is only inserted into the PDF information catalog. Can be left
+% out. 
+
+
+
+% If you have a file called "university-logo-filename.xxx", where xxx
+% is a graphic format that can be processed by latex or pdflatex,
+% resp., then you can add a logo as follows:
+
+% \pgfdeclareimage[height=0.5cm]{university-logo}{university-logo-filename}
+% \logo{\pgfuseimage{university-logo}}
+
+
+
+% Delete this, if you do not want the table of contents to pop up at
+% the beginning of each subsection:
+%\AtBeginSubsection[]
+%{
+%  \begin{frame}<beamer>{Outline}
+%    \tableofcontents[currentsection,currentsubsection]
+%  \end{frame}
+%}
+
+
+% If you wish to uncover everything in a step-wise fashion, uncomment
+% the following command: 
+
+%\beamerdefaultoverlayspecification{<+->}
+
+
+\begin{document}
+
+\begin{frame}
+  \titlepage
+\end{frame}
+
+
+% Structuring a talk is a difficult task and the following structure
+% may not be suitable. Here are some rules that apply for this
+% solution: 
+
+% - Exactly two or three sections (other than the summary).
+% - At *most* three subsections per section.
+% - Talk about 30s to 2min per frame. So there should be between about
+%   15 and 30 frames, all told.
+
+% - A conference audience is likely to know very little of what you
+%   are going to talk about. So *simplify*!
+% - In a 20min talk, getting the main ideas across is hard
+%   enough. Leave out details, even if it means being less precise than
+%   you think necessary.
+% - If you omit details that are vital to the proof/implementation,
+%   just say so once. Everybody will be happy with that.
+
+%\include{part-introduction}
+
+\part{Open Source GSM Tools}
+
+\begin{frame}{Part I - Open Source GSM Tools}
+\tableofcontents
+\end{frame}
+
+\include{section-openbsc}
+\include{section-openbts}
+\include{section-osmocombb}
+\include{section-wireshark}
+\include{section-simtrace}
+
+\include{part-mtk}
+
+\part{Summary}
+
+\section{Summary}
+
+\section{Further Reading}
+
+\begin{frame}{Further Reading}
+\tiny{
+\begin{itemize}
+	\item Open source Software on a GSM protocol level
+	\begin{description}[OsmocomBB]
+		\item[OpenBSC] \url{http://openbsc.osmocom.org/}
+		\item[OpenBTS] \url{http://openbts.org/}
+		\item[OsmocomBB] \url{http://bb.osmocom.org/}
+		\item[airprobe] \url{http://airprobe.org/}
+	\end{description}
+	\item A5 security related publications
+	\begin{description}[]
+		\item[A5 public] \url{http://groups.google.com/group/uk.telecom/msg/ba76615fef32ba32}
+		\item[Biham2003] \url{http://cryptome.org/gsm-crack-bbk.pdf}
+		\item[Biham2006] \url{http://www.cs.technion.ac.il/users/wwwb/cgi-bin/tr-get.cgi/2006/CS/CS-2006-07.pdf}
+		\item[HAR2009] \url{https://har2009.org/program/attachments/119_GSM.A51.Cracking.Nohl.pdf}
+		\item[rainbow tables] \url{http://reflextor.com/trac/a51/wiki}
+	\end{description}
+\end{itemize}
+}
+\end{frame}
+
+\end{document}
diff --git a/2010/gsm_foss-mt2010/gsm_foss.vrb b/2010/gsm_foss-mt2010/gsm_foss.vrb
new file mode 100644
index 0000000..d917a88
--- /dev/null
+++ b/2010/gsm_foss-mt2010/gsm_foss.vrb
@@ -0,0 +1,13 @@
+\frametitle {OpenBTS USRP Clocking}\framesubtitle {Kalibrator Example}
+\begin{block}{Example of running {\tt kal}}
+\begin{lstlisting}
+[openBTS@openBTS kal-0.2]# ./kal -f 946600000 -u
+USRP side: B
+FPGA clock: 52000000
+Decimation: 192
+Antenna: RX2
+Sample rate: 270833.343750
+average [min, max] (range, stddev) -2197.789062 [-2431, -1843] (588, 146.761444)
+\end{lstlisting}
+\end{block}
+The value {\bf -2198 should be used as FREQOFF constant in Transceiver/USRPDevice.cpp}
diff --git a/2010/gsm_foss-mt2010/openbsc_host.jpg b/2010/gsm_foss-mt2010/openbsc_host.jpg
new file mode 100644
index 0000000..10c575d
--- /dev/null
+++ b/2010/gsm_foss-mt2010/openbsc_host.jpg
diff --git a/2010/gsm_foss-mt2010/part-mtk.tex b/2010/gsm_foss-mt2010/part-mtk.tex
new file mode 100644
index 0000000..17baffc
--- /dev/null
+++ b/2010/gsm_foss-mt2010/part-mtk.tex
@@ -0,0 +1,101 @@
+% Day 2
+\part{How MTK could use GSM FOSS}
+
+\begin{frame}{Part II - MTK and Free / Open Source Software}
+\tableofcontents
+\end{frame}
+
+\section{Open Source GSM tools for Debugging + Testing}
+
+\begin{frame}{Possible use cases for OpenBSC}
+OpenBSC or OpenBTS in R\&D
+\begin{itemize}
+	\item Inexpensive simulation of GSM network for R\&D
+	\item Flexible since any aspect can be modified by altering source code
+	\item Complex and more exotic parts of GSM protocol spec can be tested
+	\item Much more functionality than CMD 55 / Racal 6103 or similar
+	\item Ability to send malformed L3 messages (fuzzing) for MTK MS stack security improvement
+\end{itemize}
+\end{frame}
+
+\begin{frame}{Other GSM tools}
+\begin{itemize}
+	\item airprobe: Tracing of Um air interface
+	\item SIMtrace: Tracing of SIM card interface
+\end{itemize}
+\end{frame}
+
+\begin{frame}{General advantages of FOSS based solution}
+\begin{itemize}
+	\item MTK has full access to source code
+	\item New features can be added on any level of the protocol stack
+	\item No dependency on a single supplier
+	\item Lower cost means available to more MTK engineers
+	\item Lower cost means available to more MTK customers (factory testing, field tests with OEM customers, ...)
+\end{itemize}
+\end{frame}
+
+\section{Single-Core Android smart phone}
+
+\begin{frame}{MTK feature phone vs. smart phone}
+\begin{itemize}
+	\item MTK's advantage so far: Low cost sigle-core feature phone
+	\begin{itemize}
+		\item Baseband processor runs Nucleus, GSM stack, UI and rich application stack (Camera, H.264, GPRS, TCP/IP, ...)
+		\item Other suppliers have to use dual core
+	\end{itemize}
+	\item However, MTKs Nucleus based OS has custom/proprietary APIs
+	\item Not many 3rd party applications can be installed on the phone
+	\item Android, iPhone, Windows Mobile have standard API / environment
+	\item Thus, MTK needs to offer 'standard' smart phone solution
+\end{itemize}
+\end{frame}
+
+\begin{frame}{Proposal: Single core Android smart phone}
+\begin{itemize}
+	\item Android, WinMobile, etc. have dual-core architecture
+	\begin{itemize}
+		\item GSM/3G protocol stack on baseband processor
+		\item UI + applications on application processor
+	\end{itemize}
+	\item If MTK now goes for Android smart phone, why go dual core?
+	\begin{itemize}
+		\item Simply port L1 code into Linux kernel (IRQ/FIQ driven)
+		\item Make sure you follow the GPL and release L1 as Open Source
+		\item Run your L2/L3/L4 as proprietary userspace process on Linux
+	\end{itemize}
+	\item Single-core Android phone has less ARM core licensing cost and less silicon size
+\end{itemize}
+\end{frame}
+
+\section{Linux development and the community}
+
+\begin{frame}{SoC vendors and Linux ports}
+\begin{itemize}
+	\item A number of SoC vendors have been used with Linux for many years
+	\item Port of Linux / BSP has originally been done by 3rd party or community
+	\item SoC vendors started to become more active in the last 5 years
+	\item Original: Create port, ship it to customer, done.
+	\item SoC customers end up with vendor-specific code
+\end{itemize}
+\end{frame}
+
+\begin{frame}{Disadvantages of vendor ports}
+\begin{itemize}
+	\item Fast progress in mainline Linux kernel development
+	\item Customers want latest kernel for latest features / performance
+	\item Vendor port (not in mainline) always behind mainline
+	\item Porting out-of-mainline vendor port into new mainline is lots of work
+	\item Customers end up with old vendor-specific code
+\end{itemize}
+\end{frame}
+
+\begin{frame}{SoC vendors need to include their port mainline}
+\begin{itemize}
+	\item Major SoC vendors now work together with mainline developers
+	\item Support SoC in latest mainline developer version
+	\item Actively submit port into mainline Linux kernel
+	\item Port in mainline stays automatically current/up-to-date
+	\item Continued maintenance effort is shared by all parties
+\end{itemize}
+\end{frame}
diff --git a/2010/gsm_foss-mt2010/part-security.tex b/2010/gsm_foss-mt2010/part-security.tex
new file mode 100644
index 0000000..d5b7fbd
--- /dev/null
+++ b/2010/gsm_foss-mt2010/part-security.tex
@@ -0,0 +1,146 @@
+% Day 2
+\part{Security Research}
+\section{Researching GSM/3G security}
+
+\subsection{An interesting observation}
+
+\begin{frame}{GSM/3G protocol level security}
+\begin{itemize}
+	\item Observation
+	\begin{itemize}
+		\item Both GSM/3G and TCP/IP protocol specs are publicly available
+		\item The Internet protocol stack (Ethernet/Wifi/TCP/IP) receives lots of scrutiny
+		\item GSM networks are as widely deployed as the Internet
+		\item Yet, GSM/3G protocols receive no such scrutiny!
+	\end{itemize}
+	\item There are reasons for that:
+	\begin{itemize}
+		\item GSM industry is extremely closed (and closed-minded)
+		\item Only about 4 closed-source protocol stack implementations
+		\item GSM chip set makers never release any hardware documentation
+	\end{itemize}
+\end{itemize}
+\end{frame}
+
+\subsection{The closed GSM industry -- Handset side}
+
+\begin{frame}{The closed GSM industry}{Handset manufacturing side}
+\begin{itemize}
+	\item Only very few companies build GSM/3.5G baseband chips today
+	\begin{itemize}
+		\item Those companies buy the operating system kernel and the protocol stack from third parties
+	\end{itemize}
+	\item Only very few handset makers are large enough to become a customer
+	\begin{itemize}
+		\item Even they only get limited access to hardware documentation
+		\item Even they never really get access to the firmware source
+	\end{itemize}
+\end{itemize}
+\end{frame}
+
+\subsection{The closed GSM industry -- Network side}
+
+\begin{frame}{The closed GSM industry}{Network manufacturing side}
+\begin{itemize}
+	\item Only very few companies build GSM network equipment
+	\begin{itemize}
+		\item Basically only Ericsson, Nokia-Siemens, Alcatel-Lucent and Huawei
+		\item Exception: Small equipment manufacturers for picocell / nanocell / femtocells / measurement devices and law enforcement equipment
+	\end{itemize}
+	\item Only operators buy equipment from them
+	\item Since the quantities are low, the prices are extremely high
+	\begin{itemize}
+		\item e.g. for a BTS, easily 10-40k EUR
+		\item minimal network using standard components definitely in the 100,000s of EUR range
+	\end{itemize}
+\end{itemize}
+\end{frame}
+
+\begin{frame}{The closed GSM industry}{Operator side}
+From my experience with Operators (prove me wrong!)
+\begin{itemize}
+	\item Operators are mainly finance + marketing today
+	\item Many operators outsources
+	\begin{itemize}
+		\item Network servicing / deployment, even planning
+		\item Other aspects of business like Billing
+	\end{itemize}
+	\item Operator just knows the closed equipment as shipped by manufacturer
+	\item Very few people at an operator have knowledge of the protocol beyond what's needed for operations and maintenance
+\end{itemize}
+\end{frame}
+
+\begin{frame}{GSM networks are victim and source of attacks on user privacy}
+\includegraphics[bb=0in 0in 12in 6in,clip,width=5.3in,page=7]{nohl-slides-14.pdf}
+\end{frame}
+
+\begin{frame}{Network operator and manufacturer can install software on a phone}
+\includegraphics[bb=0in 0in 12in 6in,clip,width=5.3in,page=8]{nohl-slides-14.pdf}
+\end{frame}
+
+\subsection{Security implications}
+
+\begin{frame}{The closed GSM industry}{Security implications}
+The security implications of the closed GSM industry are:
+\begin{itemize}
+	\item Almost no people who have detailed technical knowledge outside the protocol stack or GSM network equipment manufacturers
+	\item No independent research on protocol-level security
+	\begin{itemize}
+		\item If there's security research at all, then only theoretical (like the A5/2 and A5/1 cryptanalysis)
+		\item Or on application level (e.g. mobile malware)
+	\end{itemize}
+	\item No open source protocol implementations
+	\begin{itemize}
+		\item which are key for making more people learn about the protocols
+		\item which enable quick prototyping/testing by modifying existing code
+	\end{itemize}
+\end{itemize}
+\end{frame}
+
+\begin{frame}{Security analysis of GSM}{How would you get started?}
+If you were to start with GSM protocol level security analysis, where and
+how would you start?
+\begin{itemize}
+	\item On the handset side?
+	\begin{itemize}
+		\item Difficult since GSM firmware and protocol stacks are closed and proprietary
+		\item Even if you want to write your own protocol stack, the layer 1 hardware and signal processing is closed and undocumented, too
+		\item Known attempts
+		\begin{itemize}
+			\item The TSM30 project as part of the THC GSM project
+			\item MADos, an alternative OS for Nokia DTC3 phones
+		\end{itemize}
+		\item Since 2010 we have a new project: {\tt OsmocomBB}
+	\end{itemize}
+\end{itemize}
+\end{frame}
+
+\begin{frame}{Security analysis of GSM}{How would you get started?}
+If you were to start with GSM protocol level security analysis, where and
+how would you start?
+\begin{itemize}
+	\item On the network side?
+	\begin{itemize}
+		\item Difficult since equipment is not easily available and normally extremely expensive
+		\item However, network is very modular and has many standardized/documented interfaces
+		\item Thus, if equipment is available, much easier/faster progress
+		\item Also, using SDR (software defined radio) approach, special-purpose / closed hardware can be avoided
+	\end{itemize}
+\end{itemize}
+\end{frame}
+
+\begin{frame}{Security analysis of GSM}{The bootstrapping process}
+\begin{itemize}
+	\item Read GSM specs day and night (> 1000 PDF documents)
+	\item Gradually grow knowledge about the protocols
+	\begin{itemize}
+		\item OpenBSC: Obtain actual GSM network equipment (BTS)
+		\item OpenBTS: Develop SDR based GSM Um Layer 1
+	\end{itemize}
+	\item Try to get actual protocol traces as examples
+	\item Start a complete protocol stack implementation from scratch
+	\item Finally, go and play with GSM protocol security
+\end{itemize}
+\end{frame}
+
+
diff --git a/2010/gsm_foss-mt2010/section-openbsc.tex b/2010/gsm_foss-mt2010/section-openbsc.tex
new file mode 100644
index 0000000..0c1b9f4
--- /dev/null
+++ b/2010/gsm_foss-mt2010/section-openbsc.tex
@@ -0,0 +1,200 @@
+\section{OpenBSC}
+
+%\subsection{OpenBSC Introduction}
+
+\begin{frame}{OpenBSC software}
+OpenBSC is a Open Source implementation of (not only) the BSC features
+of a GSM network.
+\begin{itemize}
+	\item Support A-bis interface over E1 and IP
+	\item Support for BTS vendor/model is modular, currently Siemens BS-11 and ip.access nanoBTS
+	\item Multiple BTS models/vendorrs can be mixed!
+	\item Can work as a {\em pure BSC} or as a full {\em network in a box}
+	\item Supports mobility management, authentication, intra-BSC hand-over, SMS, voice calls (FR/EFR/AMR)
+	\item GPRS + EDGE support if combined with OsmoSGSN and OpenGGSN
+\end{itemize}
+\end{frame}
+
+\begin{frame}{OpenBSC}
+\begin{itemize}
+	\item Supports Siemens BS-11 BTS (E1) and ip.access nanoBTS (IP based)
+	\item Has classic 2G signalling, voice and SMS support
+	\item Implements various GSM protocols like
+	\begin{itemize}
+		\item A-bis RSL (TS 08.58) and OML (TS 12.21)
+		\item TS 04.08 Radio Resource, Mobility Management, Call Control
+		\item TS 04.11 Short Message Service
+	\end{itemize}
+	\item Telnet console with Cisco-style interface
+\end{itemize}
+\end{frame}
+
+\begin{frame}{OpenBSC software architecture}
+\begin{itemize}
+	\item Implemented in pure C, similarities to Linux kernel
+	\begin{itemize}
+		\item Linked List handling, Timer API, coding style
+	\end{itemize}
+	\item Single-threaded event-loop / state machine design
+	\item Telnet based command line interface {\em Cisco-style}
+	\item Input driver abstraction (mISDN, Abis-over-IP)
+\end{itemize}
+\end{frame}
+
+\begin{frame}{OpenBSC: GSM network protocols}{The A-bis interface}
+  \begin{description}[Layer 4+]
+    \item[Layer 1] Typically E1 line, TS 08.54
+    \item[Layer 2] A variant of ISDN LAPD with fixed TEI's, TS 08.56
+    \item[Layer 3] OML (Organization and Maintenance Layer, TS 12.21)
+    \item[Layer 3] RSL (Radio Signalling Link, TS 08.58)
+    \item[Layer 4+] transparent messages that are sent to the MS via Um
+  \end{description}
+\end{frame}
+
+%\begin{frame}{OpenBSC: How it all started}
+%\begin{itemize}
+%	\item In 2006, I bought a Siemens BS-11 microBTS on eBay
+%	\begin{itemize}
+%		\item This is GSM900 BTS with 2 TRX at 2W output power (each)
+%		\item A 48kg monster with attached antenna
+%		\item 200W power consumption, passive cooling
+%		\item E1 physical interface
+%	\end{itemize}
+%	\item I didn't have much time at the time (day job at Openmoko)
+%	\item Started to read up on GSM specs whenever I could
+%	\item Bought a HFC-E1 based PCI E1 controller, has mISDN kernel support
+%	\item Found somebody in the GSM industry who provided protocol traces
+%\end{itemize}
+%\end{frame}
+
+%\begin{frame}{OpenBSC: Timeline}
+%\begin{itemize}
+%	\item In November 2008, I started the development of OpenBSC
+%	\item In December 2008, we did a first demo at 25C3
+%	\item In January 2009, we had full voice call support
+%	\item In June 2009, I started with actual security related stuff
+%	\item In August 2009, we had the first field test with 2BTS and > 860 phones
+%\end{itemize}
+%\end{frame}
+
+\begin{frame}{OpenBSC: Field Test at HAR2009}
+\begin{figure}[h]
+\subfigure{\includegraphics[width=5cm]{bts_tree_full.jpg}}
+\subfigure{\includegraphics[width=5cm]{openbsc_host.jpg}}
+\end{figure}
+\end{frame}
+
+
+\subsection{OpenBSC Network In The Box}
+
+\begin{frame}{OpenBSC in NITB mode}{Network In a Box Mode}
+The {\tt bsc\_hack} program
+\begin{itemize}
+	\item implements the A-bis interface towards any number of BTS
+	\item provides most typical features of a GSM network in one software
+	\item no need for MSC, AuC, HLR, VLR, EIR, ...
+	\begin{itemize}
+		\item HLR/VLR as SQLite3 table
+		\item Authentication + Ciphering support
+		\item GSM voice calls, MO/MT SMS
+		\item Hand-over between all BTS
+		\item Multiple Location Areas within one BSC
+	\end{itemize}
+\end{itemize}
+\end{frame}
+
+\begin{frame}{OpenBSC NITB features}
+OpenBSC NITB features
+\begin{itemize}
+	\item Run a small GSM network with 1-n BTS and OpenBSC
+	\item No need for MSC/HLR/AUC/...
+	\item No need for your own SIM cards (unless crypto/auth rqd)
+	\item Establish signalling and voice channels 
+	\item Make incoming and outgoing voice calls between phones
+	\item Send/receive SMS between phones
+	\item Connect to ISDN PBX or public ISDN via Linux Call Router
+\end{itemize}
+\end{frame}
+
+\begin{frame}{OpenBSC in NITB mode}{Network In a Box Mode}
+The {\tt bsc\_hack} program
+\begin{itemize}
+	\item does not implement any other GSM interfaces apart from A-bis
+	\item no SS7 / TCAP / MAP based protocols
+	\item no integration (roaming) with existing traditional GSM networks
+	\item wired telephony interfacing with ISDN PBX {\tt lcr} (Linux Call Router)
+	\item Has been tested with up to 800 subscribers on 5 BTS
+	\item Intended for R\&D use or private PBX systems
+\end{itemize}
+\end{frame}
+
+\begin{frame}{OpenBSC LCR integration}{Interfacing with wired telephony}
+OpenBSC (NITB mode) can be linked into Linux Call Router ({\tt lcr})
+\begin{itemize}
+	\item OpenBSC is compiled as libbsc.a
+	\item libbsc.a includes full OpenBSC NITB mod code
+	\item linking the library into {\tt lcr} results in GSM {\em line interfaces} to become available inside {\tt lcr}
+	\item OpenBSC no longer takes care of call control, but simply hands everything off to {\tt lcr}
+	\item Dialling plan, etc. is now configure in {\tt lcr} like for any other wired phones
+\end{itemize}
+\end{frame}
+
+\subsection{OpenBSC BSC-only mode}
+
+\begin{frame}{OpenBSC in BSC-only mode}
+The {\tt osmo-bsc} program
+\begin{itemize}
+	\item behaves like a classic GSM BSC
+	\item uses SCCP-Lite (ip.access multipex) to any SoftMSC like ADC
+	\item used in production/commercial deployments (~ 75 BSCs)
+	\item mainly intended to replace proprietary BSC in traditional GSM networks
+\end{itemize}
+\end{frame}
+
+\begin{frame}<handout:0>{OpenBSC}
+        Demonstration
+\end{frame}
+
+\subsection{OpenBSC GPRS support}
+
+\begin{frame}{GPRS and OpenBSC}
+\begin{itemize}
+	\item The BSC doesn't really do anything related to GPRS
+	\item GPRS implemented in separate SGSN and GGSN nodes
+	\item GPRS uses its own Gb interface to RAN, independent of A-bis
+	\item OpenBSC can configure the nanoBTS for GPRS+EDGE support via OML
+	\item Actual SGSN and GGSN implemented as OsmoSGSN and OpenGGSN programs
+\end{itemize}
+\end{frame}
+
+\begin{frame}{OsmoSGSN}
+The Osmocom SGSN program implements
+\begin{itemize}
+	\item basic/minimal SGSN functionality
+	\item the Gb interface (NS/BSSGP/LLC/SNDCP)
+	\item mobility management, session management
+\end{itemize}
+It's a work in progress, many missing features
+\begin{itemize}
+	\item no HLR integration yet
+	\item no paging coordination with MSC/BSC
+	\item no encryption support yet
+\end{itemize}
+\end{frame}
+
+\begin{frame}{OpenGGSN}
+\begin{itemize}
+	\item GPL licensed Linux program implementing GGSN node
+	\item Implements GTP-U protocol between SGSN and GGSN
+	\item User-configurable range/pool of IPv4 addresses for MS
+	\item Uses {\tt tun} device for terminating IP tunnel from MS
+	\item provides GTP implementation as libgtp
+	\item Experimental patches for IPv6 support
+\end{itemize}
+\end{frame}
+
+%\begin{frame}<handout:0>{OpenBSC + OpenGGSN + OsmoSGSN}
+%        Demonstration
+%\end{frame}
+
+% FIXME: include slide showing full OpenBSC+OsmoSGSN+OpenGGSN network
diff --git a/2010/gsm_foss-mt2010/section-openbts.tex b/2010/gsm_foss-mt2010/section-openbts.tex
new file mode 100644
index 0000000..3675e85
--- /dev/null
+++ b/2010/gsm_foss-mt2010/section-openbts.tex
@@ -0,0 +1,140 @@
+\subsection{OpenBTS}
+
+\begin{frame}{What is OpenBTS?}
+\begin{itemize}
+	\item is {\em NOT} a BTS in the typical GSM sense
+	\item is better described as a GSM-Um to SIP gateway
+	\item implements the GSM Um (air interface) as SDR
+	\item uses the USRP hardware as RF interface
+	\item does not implement any of BSC, MSC, HLR, etc.
+	\item bridges the GSM Layer3 protocol onto SIP
+	\item uses SIP switch (like Asterisk) for switching calls + SMS
+	\item is developed as C++ program and runs on Linux + MacOS
+\end{itemize}
+\end{frame}
+
+\begin{frame}{What is OpenBTS?}
+\begin{itemize}
+	\item Open implementation of Um L1 \& L2, an all-software BTS.
+	\item L1/L2 design based on an object-oriented dataflow approach.
+	\item Includes L3 RR functions normally found in BSC.
+	\item Uses SIP PBX for MM and CC functions, eliminating the conventional GSM network.  L3 is like an ISDN/SIP gateway.
+	\item Intended for use in low-cost and rapidly-deployed communications networks, but can be used for experiments (including by Chris Pagent at Def Con).
+\end{itemize}
+\end{frame}
+
+\begin{frame}{OpenBTS Hardware}
+OpenBTS supports the following SDR hardware
+\begin{itemize}
+	\item Ettus USRP(1) with two RFX 900 or RFX 1800 daughter boards
+	\begin{itemize}
+		\item Modification for external clock input recommended
+		\item External 52 MHz precision clock recommended
+	\end{itemize}
+	\item Kestrel Signal Processing / Range Networks custom radio
+	\item Close Haul Communications / GAPfiller (work in progress)
+	\item Ported to other radios by other clients.
+\end{itemize}
+\end{frame}
+
+
+\begin{frame}{OpenBTS History + Tests}
+\begin{itemize}
+	\item Started work in Aug 2007, first call in Jan 2008, first SMS in Dec 2008.
+	\item First public release in September 2008, assigned to FSF in Oct 2008.
+	\item Ran 3-sector 3-TRX system with 10,000-20,000 handsets at Sept 2009 Burning Man event in Nevada.
+	\item Ran 2-sector 5-TRX system with 40,000 handsets at Sept 2010 Burning Man event in Nevada.
+	\item Release 2.5 is about 13k lines of C++.
+	\item Part of GNU Radio project, distributed under AGPLv3.
+	\item Range Networks launched in Sept 2010 to produce commercial products and distributions.
+\end{itemize}
+\end{frame}
+
+
+\begin{frame}{Burning Man 2010 Tower Base}
+\begin{figure}[h]
+	\centering
+	\includegraphics[width=85mm]{OBTSBM2010.jpg}
+\end{figure}
+\end{frame}
+
+%\subsection{Clocking}
+%
+%\begin{frame}{OpenBTS USRP Clocking}{Clock Stability}
+%\begin{itemize}
+%	\item USRP has regular XO (Crystal Oscillator) with 20ppm accuracy
+%	\item GSM requires 20ppb carrier clock accuracy
+%	\item possible solutions
+%	\begin{itemize}
+%		\item use external VCTCXO clocking module 
+%		\item use external OCXO clocking module
+%		\item use a software calibration program comparing USRP XO with real GSM BTS carrier clocks
+%	\end{itemize}
+%	\item due to clock multiplication, absolute error in GSM1800 is higher than in GSM900
+%\end{itemize}
+%\end{frame}
+
+
+%\begin{frame}{OpenBTS USRP Clocking}{64 MHz vs. 52 MHz clock}
+%\begin{itemize}
+%	\item The USRP master clock is 64 Mhz
+%	\item In GSM, all clocks are derived from 13 MHz
+%	\item Thus, a poly-phase re-sampler is part of SDR software
+%	\item Alternative: use 52 MHz (13 MHz * 4) external clock
+%	\item OpenBTS has two transceiver programs, one for each 64 MHz and 52 MHz
+%	\begin{itemize}
+%		\item Make sure to never use the wrong transceiver for your clock!
+%	\end{itemize}
+%\end{itemize}
+%\end{frame}
+
+%\begin{frame}{OpenBTS USRP Clocking}{Software Calibration}
+%Basic idea: Use real GSM cell as clock source
+%\begin{itemize}
+%	\item Implemented by the {\em Kalibrator} ({\tt kal}) program
+%	\item Acquire the FCCH burst of a real GSM cell
+%	\item Measure the clock difference between USRP XO and that cell
+%	\item Use the computed error as offset to USRP up/downconverter
+%	\item However, temperature and other drift will make clocks go out of sync over time
+%	\item Can only be used if a real-world GSM network is within range
+%\end{itemize}
+%\end{frame}
+
+%\begin{frame}[fragile]{OpenBTS USRP Clocking}{Kalibrator Example}
+%\begin{block}{Example of running {\tt kal}}
+%\begin{lstlisting}
+%[openBTS@openBTS kal-0.2]# ./kal -f 946600000 -u
+%USRP side: B
+%FPGA clock: 52000000
+%Decimation: 192
+%Antenna: RX2
+%Sample rate: 270833.343750
+%average [min, max] (range, stddev) -2197.789062 [-2431, -1843] (588, 146.761444)
+%\end{lstlisting}
+%\end{block}
+%The value {\bf -2198 should be used as FREQOFF constant in Transceiver/USRPDevice.cpp}
+%\end{frame}
+
+
+%\begin{frame}<handout:0>{OpenBTS}
+%        Demonstration
+%\end{frame}
+
+
+%\begin{frame}{OpenMS}
+%\begin{itemize}
+%	\item Subscriber side stack based on OpenBTS.
+%	\item Called MS, but just a BTS stack with data flows reversed and a different RR control logic.
+%	\item Behavior is more like a passive interceptor that can also transmit.
+%	\item Release 1.0 supports non-hopping multi-ARFCN networks.
+%	\item Most L3 control logic provided by the end user.
+%	\item A platform for
+%	\begin{itemize}
+%		\item passive interceptors
+%		\item custom subscriber-side applications
+%		\item environment analysis
+%		\item intelligent jamming
+%	\end{itemize}
+%\end{itemize}
+%\end{frame}
+
diff --git a/2010/gsm_foss-mt2010/section-osmocombb.tex b/2010/gsm_foss-mt2010/section-osmocombb.tex
new file mode 100644
index 0000000..07ff2f4
--- /dev/null
+++ b/2010/gsm_foss-mt2010/section-osmocombb.tex
@@ -0,0 +1,282 @@
+\section{OsmocomBB Project}
+
+%\begin{frame}{A GSM phone baseband processor}
+%\begin{itemize}
+%	\item GSM protocol stack always runs in a so-called baseband processor (BP)
+%	\item What is the baseband processor
+%	\begin{itemize}
+%		\item Typically ARM7 (2G/2.5G phones) or ARM9 (3G/3.5G phones)
+%		\begin{itemize}
+%			\item Runs some RTOS (often Nucleus, sometimes L4)
+%			\item No memory protection between tasks
+%		\end{itemize}
+%		\item Some kind of DSP, model depends on vendor
+%		\begin{itemize}
+%			\item Runs the digital signal processing for the RF Layer 1
+%			\item Has hardware peripherals for A5 encryption
+%		\end{itemize}
+%	\end{itemize}
+%	\item The software stack on the baseband processor
+%	\begin{itemize}
+%		\item is written in C and assembly
+%		\item lacks any modern security features (stack protection, non-executable pages, address space randomization, ..)
+%	\end{itemize}
+%\end{itemize}
+%\end{frame}
+
+%\begin{frame}{A GSM Baseband Chipset}
+%  \begin{figure}[h]
+%  \centering
+%  \includegraphics[width=100mm]{calypso-block.pdf}
+%  \end{figure}
+%  \url{http://laforge.gnumonks.org/papers/gsm_phone-anatomy-latest.pdf}
+%\end{frame}
+
+\begin{frame}{Requirements for GSM security analysis}
+What do we need for protocol-level security analysis?
+\begin{itemize}
+	\item A GSM MS-side baseband chipset under our control
+	\item A Layer1 that we can use to generate arbitrary L1 frames
+	\item A Layer2 protocol implementation that we can use + modify
+	\item A Layer3 protocol implementation that we can use + modify
+\end{itemize}
+None of those components existed, so we need to create them!
+\end{frame}
+
+\begin{frame}{A GSM baseband under our control}
+The two different DIY approaches
+\begin{itemize}
+	\item Build something using generic components (DSP, CPU, ADC, FPGA)
+	\begin{itemize}
+		\item No reverse engineering required
+		\item A lot of work in hardware design + debugging
+		\item Hardware will be low-quantity and thus expensive
+	\end{itemize}
+	\item Build something using existing baseband chipset
+	\begin{itemize}
+		\item Reverse engineering or leaked documents required
+		\item Less work on the 'Layer 0'
+		\item Still, custom hardware in low quantity
+	\end{itemize}
+\end{itemize}
+\end{frame}
+
+\begin{frame}{A GSM baseband under our control}
+Alternative 'lazy' approach
+\begin{itemize}
+	\item Re-purpose existing mobile phone
+	\begin{itemize}
+		\item Hardware is known to be working
+		\item No prototyping, hardware revisions, etc.
+		\item Reverse engineering required
+		\item Hardware drivers need to be written
+		\item But: More time to focus on the actual job: Protocol software
+	\end{itemize}
+	\item Searching for suitable phones
+	\begin{itemize}
+		\item As cheap as possible
+		\item Readily available: Many people can play with it
+		\item As old/simple as possible to keep complexity low
+		\item Baseband chipset with lots of leaked information
+	\end{itemize}
+\end{itemize}
+\end{frame}
+
+\begin{frame}{Baseband chips with leaked information}
+\begin{itemize}
+	\item Texas Instruments Calypso
+	\begin{itemize}
+		\item DBB Documentation on cryptome.org and other sites
+		\item ABB Documentation on Chinese phone developer websites
+		\item Source code of GSM stack / drivers was on sf.net (tsm30 project)
+		\item End of life, no new phones with Calypso since about 2008
+		\item No cryptographic checks in bootloader
+	\end{itemize}
+	\item Mediatek MT622x chipsets
+	\begin{itemize}
+		\item Lots of Documentation on Chinese sites
+		\item SDK with binary-only GSM stack libraries on Chinese sites
+		\item 95 million produced/sold in Q1/2010
+	\end{itemize}
+\end{itemize}
+Initial choice: TI Calypso (GSM stack source available)
+\end{frame}
+
+
+\subsection{OsmocomBB Introduction}
+
+\begin{frame}{OsmocomBB Introduction}
+\begin{itemize}
+	\item Project was started only in January 2010 (9 months ago!)
+	\item Implementing a GSM baseband software from scratch
+	\item This includes
+	\begin{itemize}
+		\item GSM MS-side protocol stack from Layer 1 through Layer 3
+		\item Hardware drivers for GSM Baseband chipset
+		\item Simple User Interface on the phone itself
+		\item Verbose User Interface on the PC
+	\end{itemize}
+	\item Note about the strange project name
+	\begin{itemize}
+		\item Osmocom = Open Source MObile COMmunication
+		\item BB = Base Band
+	\end{itemize}
+\end{itemize}
+\end{frame}
+
+\begin{frame}{OsmocomBB Software Architecture}
+\begin{itemize}
+	\item Reuse code from OpenBSC where possible (libosmocore)
+	\begin{itemize}
+		\item We build libosmocore both for phone firmware and PC
+	\end{itemize}
+	\item Initially run as little software in the phone
+	\begin{itemize}
+		\item Debugging code on your host PC is so much easier
+		\item You have much more screen real-estate
+		\item Hardware drivers and Layer1 run in the phone
+		\item Layer2, 3 and actual phone application / MMI on PC
+		\item Later, L2 and L3 can me moved to the phone
+	\end{itemize}
+\end{itemize}
+\end{frame}
+
+\begin{frame}{OsmocomBB Software Interfaces}
+\begin{itemize}
+	\item Interface between Layer1 and Layer2 called L1CTL
+	\begin{itemize}
+		\item Fully custom protocol as there is no standard
+		\item Implemented as message based protocol over Sercomm/HDLC/RS232
+	\end{itemize}
+	\item Interface between Layer2 and Layer3 called RSLms
+	\begin{itemize}
+		\item In the GSM network, Um Layer2 terminates at the BTS but is controlled  by the BSC
+		\item Reuse this GSM 08.58 Radio Signalling Link
+		\item Extend it where needed for the MS case
+	\end{itemize}
+\end{itemize}
+\end{frame}
+
+\subsection{OsmocomBB Software}
+
+\begin{frame}{OsmocomBB Target Firmware}
+\begin{itemize}
+	\item Firmware includes software like
+	\begin{itemize}
+		\item Drivers for the Ti Calypso Digital Baseband (DBB)
+		\item Drivers for the Ti Iota TWL3025 Analog Baseband (ABB)
+		\item Drivers for the Ti Rita TRF6151 RF Transceiver
+		\item Drivers for the LCD/LCM of a number of phones
+		\item CFI flash driver for NOR flash
+		\item GSM Layer1 synchronous/asynchronous part
+		\item Sercomm - A HDLC based multiplexer for the RS232 to host PC
+	\end{itemize}
+\end{itemize}
+\end{frame}
+
+\begin{frame}{OsmocomBB Host Software}
+\begin{itemize}
+	\item Current working name: layer23
+	\item Includes
+	\begin{itemize}
+		\item Layer 1 Control (L1CTL) protocol API
+		\item GSM Layer2 implementation (LAPDm)
+		\item GSM Layer3 implementation (RR/MM/CC)
+		\item GSM Cell (re)selection
+		\item SIM Card emulation
+		\item Supports various 'apps' depending on purpose
+	\end{itemize}
+\end{itemize}
+\end{frame}
+
+\subsection{OsmocomBB Hardware Support}
+
+\begin{frame}{OsmocomBB Supported Hardware}
+\begin{itemize}
+	\item Baseband Chipsets
+	\begin{itemize}
+		\item TI Calypso/Iota/Rita
+		\item Some early research being done on Mediatek (MTK) MT622x
+	\end{itemize}
+	\item Actual Phones
+	\begin{itemize}
+		\item Compal/Motorola C11x, C12x, C13x, C14x and C15x models
+		\item Most development/testing on C123 and C155
+		\item GSM modem part of Openmoko Neo1973 and Freerunner
+	\end{itemize}
+	\item All those phones are simple feature phones built on a ARM7TDMI based DBB
+\end{itemize}
+\end{frame}
+
+\begin{frame}{The Motorola/Compal C123}
+ \begin{figure}[h]
+  \centering
+  \includegraphics[width=100mm]{c123_pcb.jpg}
+  \end{figure}
+\end{frame}
+
+
+\subsection{OsmocomBB Project Status}
+
+\begin{frame}{OsmocomBB Project Status: Working}
+\begin{itemize}
+	\item Hardware Drivers for Calypso/Iota/Rita very complete
+	\item Drivers for Audio/Voice signal path
+	\item Layer1 
+	\begin{itemize}
+		\item Power measurements 
+		\item Carrier/bit/TDMA synchronization
+		\item Receive and transmit of normal bursts on SDCCH
+		\item Transmit of RACH bursts
+		\item Automatic Rx gain control (AGC)
+		\item Frequency Hopping
+	\end{itemize}
+	\item Layer2 UI/SABM/UA frames and ABM mode
+	\item Layer3 Messages for RR / MM / CC
+	\item Cell (re)selection according GSM 03.22
+\end{itemize}
+\end{frame}
+
+\begin{frame}{OsmocomBB Project Status: Working (2/2)}
+OsmocomBB can now do GSM Voice calls (08/2010)
+\begin{itemize}
+	\item Very Early Assignment + Late Assignment
+	\item A3/A8 Authentication of SIM
+	\item A5/1 + A5/2 Encryption
+	\item Full Rate (FR) and Enhanced Full Rate (EFR) codec
+\end{itemize}
+\end{frame}
+
+\begin{frame}{OsmocomBB Project Status: Not working}
+\begin{itemize}
+	\item Fully-fledged SIM card reader inside phone (WIP)
+	\item Layer1 
+	\begin{itemize}
+		\item Neighbor Cell Measurements
+		\item In-call hand-over to other cells
+	\end{itemize}
+	\item Actual UI on the phone
+	\item Circuit Switched Data (CSD) calls
+	\item GPRS (packet data)
+\end{itemize}
+\end{frame}
+
+\begin{frame}{OsmocomBB Project Status: Executive Summary}
+\begin{itemize}
+	\item We can establish control/signalling channels to both hopping and non-hopping GSM cells
+	\begin{itemize}
+		\item Control over synthesizer means we can even go to GSM-R band
+	\end{itemize}
+	\item We can send arbitrary data on those control channels
+	\begin{itemize}
+		\item RR messages to BSC
+		\item MM/CC messages to MSC
+		\item SMS messages to MSC/SMSC
+	\end{itemize}
+	\item TCH (Traffic Channel) support for voice calls
+	\begin{itemize}
+		\item Dieter Spaar and Andreas Eversberg have made multiple 20 minute call with current master branch
+		\item Some people have tried alpha code on real networks for real 30+ minute calls!
+	\end{itemize}
+\end{itemize}
+\end{frame}
diff --git a/2010/gsm_foss-mt2010/section-simtrace.tex b/2010/gsm_foss-mt2010/section-simtrace.tex
new file mode 100644
index 0000000..75aed46
--- /dev/null
+++ b/2010/gsm_foss-mt2010/section-simtrace.tex
@@ -0,0 +1,39 @@
+\section{Osmocom SIMtrace}
+
+\subsection{Debugging SIM drivers and STK apps}
+
+\begin{frame}{Debugging SIM toolkit applications is hard}
+\begin{itemize}
+	\item Regular end-user phone does not give much debugging
+	\item SIM card itself has no debug interface for printing error messages, warnings, etc.
+	\item However, as SIM-ME interface is unencrypted, sniffing / tracing is possible
+	\item Commercial / proprietary solutions exist, but are expensive
+\end{itemize}
+\end{frame}
+
+\subsection{Osmocom SIMtrace Introduction}
+
+\begin{frame}{Introducing Osmocom SIMtrace}
+\begin{itemize}
+	\item Osmocom SIMtrace is a passive (U)SIM-ME communication sniffer
+	\item Insert SIM adapter into actual phone
+	\item Insert (U)SIM into SIMtrace hardware
+	\item SIMtrace hardware provides USB interface to host PC
+	\item {\tt simtrace} program on PC encapsulates APDU in GSMTAP
+	\item GSMTAP is sent via UDP to localhost
+	\item wireshark dissector for GSM TS 11.11 decodes APDUs
+\end{itemize}
+\end{frame}
+
+\subsection{Osmocom SIMtrace Hardware}
+
+\begin{frame}{Osmocom SIMtrace Hardware}
+\begin{itemize}
+	\item Hardware is based around AT91SAM7S controller
+	\item SAM7S Offers two ISO 7816-3 compatible USARTs
+	\item USARTs can be clock master (SIM reader) or slave (SIM card)
+	\item Open Source Firmware on SAM7S implementing APDU sniffing
+	\item Auto-bauding depending CLK signal, PPS supported
+	\item Only prototype hardware right, but will be manufactured in Q1/2011
+\end{itemize}
+\end{frame}
diff --git a/2010/gsm_foss-mt2010/section-wireshark.tex b/2010/gsm_foss-mt2010/section-wireshark.tex
new file mode 100644
index 0000000..588b4ab
--- /dev/null
+++ b/2010/gsm_foss-mt2010/section-wireshark.tex
@@ -0,0 +1,61 @@
+\section{wireshark Protocol Analyzer}
+
+\begin{frame}{The wireshark protocol analyzer}
+\begin{itemize}
+	\item Software protocol analyzer for plethora of protocols
+	\item Portable, works on most flavors of Unix and Windows
+	\item Decode, display, search and filter packets with configurable level of detail
+	\item Over 1000 protocol decoders
+	\item Over 86000 display filters
+	\item Live capturing from many different network media
+	\item Import files from other capture programs
+	\item Used to be called ethereal, but is now called wireshark
+\item \url{http://www.wireshark.org/}
+\item \url{http://www.wireshark.org/download/docs/user-guide-a4.pdf}
+\end{itemize}
+\end{frame}
+
+\begin{frame}{The wireshark protocol analyzer}
+GSM protocol dissectors in wireshark
+\begin{itemize}
+	\item TCP/IP (transport layer for Abis/IP)
+	\item E1 Layer 2 (LAPD)
+	\item GSM Um Layer 2 (LAPDm)
+	\item GSM Layer 3 (RR, MM, CC)
+        \item A-bis Layer 3 (RSL)
+	\begin{itemize}
+		\item A-bis OML for Siemens and ip.access in OpenBSC git
+	\end{itemize}
+	\item GSMTAP pseudo-header (airprobe, OpenBTS, OsmocomBB)
+\end{itemize}
+\end{frame}
+
+\begin{frame}{wireshark integration in OsmocomBB}
+\begin{itemize}
+	\item OsmocomBB L1 runs on phone
+	\item OsmocomBB L23 runs on host PC
+	\item OsmocomBB L23 encapsulates 23byte L2 message in GSMTAP
+	\item GSMTAP includes information not present in L2, such as
+	\begin{itemize}
+		\item ARFCN, Timeslot
+		\item GSM Frame Number
+		\item Rx Signal Level / SNR
+	\end{itemize}
+	\item OsmocomBB L23 sends GSMTAP message over UDP socket
+	\item wireshark captures UDP packet like any UDP/IP
+\end{itemize}
+\end{frame}
+
+\begin{frame}{wireshark integration in OpenBTS and airprobe}
+\begin{itemize}
+	\item airprobe software runs on host PC
+	\item implements Rx-only GSM L1 as SDR
+	\item airprobe L23 encapsulates 23byte L2 message in GSMTAP
+	\item wireshark captures UDP packet like any UDP/IP
+	\item OpenBTS wireshark intergration similar, but for Rx + Tx
+\end{itemize}
+\end{frame}
+
+\begin{frame}<handout:0>{The wireshark protocol analyzer}
+        Demonstration
+\end{frame}