Notes from the 27C3 network

[Omar Atia]

Dears ,, please help ::

Before new year !!! can we compile libosmocore on SUN solaries (done)....I'm
reaching final stages in compiling , I have compiled bsc_hack and and I'm in
ipaccess now , there is issue with 

rc = setsockopt(fd, SOL_SOCKET, SO_BINDTODEVICE, ifname,
				strlen(ifname));

and issue with linux C function cfmakeraw...

in ipaccess-find.c , can we use bind instead of setsockopt cause solaries
doesn't have SO_BINDTODEVICE defined in socket.h.

Good night ...

Thanks,
Omar Atia

-----Original Message-----
From: openbsc-bounces at lists.gnumonks.org
[mailto:openbsc-bounces at lists.gnumonks.org] On Behalf Of Jason
Sent: Thursday, December 30, 2010 6:54 PM
To: Holger Hans Peter Freyther
Cc: openbsc at lists.gnumonks.org
Subject: Re: Notes from the 27C3 network

4.  Write Holger an email congratulating him and everyone that helped
for accomplishing such a formidable challenge.

Thanks to you for your leadership and all openbsc contributers for
persisting the face of such extreme complexity.  Happy new year and
keep up the excellent work :)

Cheers,
-Jason

On Thu, Dec 30, 2010 at 3:03 AM, Holger Hans Peter Freyther
<holger at freyther.de> wrote:
> Hi all,
>
> here are some notes about bsc_hack as it ran on the 27C3. In day0 we
> discovered a nice SQL injection bug, in day1 we had plenty of segfaults,
> mostly in the error and time-out paths of the MSC (but also some in the
BSC
> API). These included crashes due clearing the channel and removing the
->lchan
> from the conn, RLL time out handling in the SMS code and some more.
>
> The network ran without segfault (only one crash due my stupidity on a new
VTY
> command) after this. The biggest issue as that SMS got stuck. Code review
has
> found some issues immediately but this didn't fix it. On more code review
an
> issue with the 'subscr_get_channel' was identified.
>
> First of all the transaction layer just stopped paging requests, e.g.
stopping
> the paging for someone else's subscr_get_channel, then the Call Control
code
> never called subscr_put_channel when it is done. I have created two band
aids
> for this situation but there is a bigger issue with the code.
>
>
> If somebody has spare time and wants to do some simple changes one can do:
>
>
> 1.) The subscriber layer passes the 'subscr' pointer to the paging layer,
it
> should pass the request to it.
> 2.) It should be possible to cancel channel requests that were not
scheduled yet.
> 3.) Once we started auth on the channel the 'request' state should be
changed
> too. It is not right now due 1.).
> 4.) ....
>
>
>