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.) ....
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@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.) ....
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@lists.gnumonks.org [mailto:openbsc-bounces@lists.gnumonks.org] On Behalf Of Jason Sent: Thursday, December 30, 2010 6:54 PM To: Holger Hans Peter Freyther Cc: openbsc@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@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.) ....
On 12/31/2010 12:30 AM, Omar Atia wrote:
Dears ,, please help ::
Dear Omar,
please do not hijack threads, start a new one instead.
in ipaccess-find.c , can we use bind instead of setsockopt cause solaries doesn't have SO_BINDTODEVICE defined in socket.h.
For ipaccess-find is sending a broadcast packet, so it is important to select the physical interface it should be send on. For the user it is more convenient to write the interface name then to remember the ip address of this interface.
Does Solaris provide another way to bind to a specific interface? What about IP_BOUND_IF? If that is not the case we could consider doing a normal bind and bind to the interface via an ip...
z.
-
Holger Hans Peter Freyther -
Jason -
Omar Atia