libosmogsm is a new library that is distributed in the libosmocore.
Now, openbsc depends on it. This patch gets openbsc with this
change.
This patch also rewrites all include path to the new
osmocom/[gsm|core]
Signed-off-by: Pablo Neira Ayuso <pablo@gnumonks.org>
The reason for this is quite simple: We want to make sure anyone
running a customized version of OpenBSC to operate a network will
have to release all custom modifiations to the source code.
Use the start address inside the header entry, the start is relative
to the surrounding SDP record which is located in our base offset, when
writing it out also ignore four bytes of something (crc?).
* The length of the table is not at a fixed position. We will need
to read the offset, seek there, read the data, convert it to the
host endianes.
* Prepare the code to work with offsets of 0...
This library is intended to collect all generic/common funcitionality
of all Osmocom.org projects, including OpenBSC but also OsmocomBB
The library currently includes the following modules:
bitvec, comp128, gsm_utils, msgb, select, signal, statistics, talloc, timer,
tlv_parse, linuxlist
msgb allocation error debugging had to be temporarily disabled as it depends on
'debug.c' functionality which at the moment remains in OpenBSC
* text3 seems to be a version as the text content starts
with a 'v'
* move the sdp_firmware into the ipaccess.h and declare
the function. The headers are returned through a list.
* The second magic number is only a short and it is
the same for all of my cases
* This also means that the first and second header
are the same which means the unknown 8 byte are
header and file size... and the 122 bytes are
actually multiple strings (just all empty on the
outermost SDP). Adding the strings left us with 120
bytes so we have two bytes of unknown usage..
* This is now capable of parsing outer and inner SDP
files and print their header.
* The internal SDP appears to have a different magic number
than the first entry and a slightly different packet format
* There are 8 byte of binary for at the beginning and the header
ends with a table pointing to some strings and then the actual
firmware follows.
* We currently only parse the strings of that header.
The something3 points to the next start of the SDP
entry. The four bytes in front of the " SDP" are not
known and just discarded. Prepare to be able to
recursively parse the SDP header...
I must have picked in the wrong section of these
files... There are some kind of header entries
that are all 138 byte long and this is the total
length...
Pablo Neira Ayuso
Harald Welte