I have a job offer in my company for a project to research into and build defenses against over-the air attacks breaking current 2G/3G basebands. The location is in Berlin, Germany, starting soon if possible. Remote work arrangements are not an option. The project is solidly financed by a public research grant, the company is nicely profitable for many years now.
Requirements are detailed GSM knowledge, very good reverse engineering and at least decent C/C++ coding skills plus ability to work with a small team in english or german language. All research results of the project will be public and large parts of the development aspect will be on improving the open GSM / 3G tools and thus flow back to the community. Working hours are very relaxed, we are looking for someone who really dives into his work and does not just attend it.
Mail me off list if you think you fit the profile.
Thanks & Greetings from Berlin,
Frank Rieger
> * we should not try to introduce new 'hacks' but rather remove old
> ones by proper code
hi harald,
if you sync the osmocore of osmocom-bb, i could remove some "#warning"s
due to unavailable structures:
struct gsm48_frq_redef
struct gsm48_ho_cpl
struct gsm48_ho_fail
regards,
andreas
Hi,
In my sylvain/testing branch, there a a few interesting changes:
* Priority support for items in a scheduler bucket
Basically for each sched_item, there is a now a priority field and
they are executed in order.
This allows for example to ensure that a scheduled freq change is
executed before accesing the L1 parameters, or to make sure that a
control channel RX is scheduled before a RACH TX ...
For new items added into the bucket while executing itself (like
the abort), those will obviously not be able to obey the priority and
will always be executed afterwards.
* Common DSP & TPU Scenario init & end
Previously, each primitive _cmd initialized the TPU (with
network/offset) to the timeslot and also ended the tpu & dsp scenario.
This scheme doesn't work when you have several primitives that have
a TPU window to open and/or a dsp scenario to run.
(this happens when doing RACH in the same frame as reading a
CCCH/BCCH bursts, or in the case of SDCCH8[4:7]).
Now, each item specifies via some flags if he has a need for TPU
and/or DSP. If one item of the bucket needs it, then the common code
will handle. :
- Aligning the TPU (via offset/network) to the 'base' timeslot
(+3 TX offset still has to be added by the primitive)
- Restoring base TPU alignement at the end.
- Ending both TPU / DSP scenario when everything is done.
* A5 support
Andreas actually made L23 support and added a stub l1ctl_ command itself.
Dieter and I actually made the L1 work in // and not surprisingly
came up with very similar results given it's mainly:
. Load the key in DSP API NDB & set the mode.
. Set a fn parameter properly at each frame
The rest is handled inside the dsp.
I will now work on merging Dieter's work into the main branch above what I did.
- TOA regulation loop to prevent drifting
- TX power control
- TCH support
Cheers,
Sylvain Munaut
hi,
i like to add layer1 control for measurement reports. my idea is use use
normal L1CTL_DATA_REQ with SACCH channel type for sending the (updated)
report to layer1.
the protocol and message type will be decoded by layer1, so it can
detect if this is a measurement report or not. if it is a measurement
report, it will overwrite the last stored measuement report. it will be
sent whenever there is no other SACCH message in the queue of SACCH
messages. if it is not a measurement report, it will be queued as usual.
any better idea?
andreas
Hi,
> What's the easiest way to list out the API for layer1.bin? (I can start
> searching through the code myself but I thought I would ask first.)
See include/l1ctl_proto.h
But it's a pretty high level: things like
- Go camp on the bcch/ccch
- Open a dedicated channel with those parameters
- Send this L2 frame
...
PS: Make sure to answer to the list and not me.
Sylvain
> then i would suggest to expand the scheduling thing. i will see how
> complex that would be...
ok, i see that there is also a "one shot" scheduler with full frame
number range. (sched_gsmtime.c) i think that i can use this to modify
the current channel set. i have code to test it. i don't know if the
callback function of the scheduled event is called before or after the
actual transmission/reception of the burst, which also sets the right
frequency. even if not, there will be only one frame lost.
> The only function in rfch.c returns the parameter for a given time.
> It does _NOT_ and should _NOT_ make any change to the parameter
itself.
> That's left up to the caller because we need to call that function
several time.
> If you want to introduce some call that configure the channel and
make changes and stuff, put it into another function and make sure it's
called when required.
then i would suggest to expand the scheduling thing. i will see how
complex that would be...
> Using the scheduler should be relatively easy, you can simply call
> sched_gsmtime() and provide it a framenumber and a 'tdma_sched_item'.
the
> latter will contain the callback that is to be called once the current
> framenumber will reach 'fn' as specified.
what if there is already a scheduled item? in this case i must schedule
the frequency change item before any other item. also the frame number
of frequency change may be more than 255 frames ahead.
my suggestion: because hopping sequence is a function of time, the
starting time should also be included in this function (rfch.c).
Hi all,
after some days digging into the various tools around the GSM opensource
playground arena i started understanding better the various piece of
software.
It seems to me that there's a net separation between the GSM
implementation stack of OpenBTS and Osmocom, also because the projects
are born with different goals.
With the current bb implementation of Osmocom inside Calypso based
baseband processor of motorola, all the DSP logic is done directly by
the mobile phones chip, right?
Which with OpenBTS, it's OpenBTS itself that does the
modulation/demodulation along with the USRP.
Is there some project and or ideas to bring together the DSP codebase of
OpenBTS, together with OsmocomBB to make a MS terminal based on USRP1
device with RFX900 boards?
Fabio
