This is merely a historical archive of years 2008-2021, before the migration to mailman3.
A maintained and still updated list archive can be found at https://lists.osmocom.org/hyperkitty/list/OpenBSC@lists.osmocom.org/.
Harald Welte laforge at gnumonks.orghi Zecke,
On Wed, Jan 06, 2010 at 07:59:21AM +0100, Holger Freyther wrote:
> On Thursday 31 December 2009 11:23:00 Harald Welte wrote:
> > Hi Zecke,
>
> > > Now what happens is:
> > > 1.) some system information types structs are already bigger
> > > than the 23 bytes...
> >
> > why are they? How can that be? How can a SI message be larger than the
> > physical limitation of the MAC-Block? This sounds like the root cause
> > of the problem to me.
>
> This was bullshit...
>
> Here is the root cause:
>
> For SI5 and SI6 we have to deal with the BS11 of having left the length field
> out... What we are doing is:
>
> char output[23];
> if (is_nano_bts) {
> *output = len;
> ++output;
> }
>
> si6 = (struct si6*) output;
> memset(si6, padding, 23);
>
> And one thing I have found as well, but it seems more like I'm wrong. All
> data_len of the bitvector are one too big? Is that done on purpose?
no, that is an artefact from the 04.08 spec always claiming that an IE has
a certain length, but then icnluding the TAG, despite never sending the TAG
in front of the IE on the actual air interface.
> Patch 0001 and 0003 are of cosmetic nature, 0002 and 0004 seem to fix the stack
> corruption my system is seeing.
Please apply them, they're fine. In addition, we should probably remove the
++output from the generate_si, and have the RSL layer deal with it.
Specifically:
* include the system_information_type_header in SI5 and SI6 data structures
* make sure the buffers passed to generate_si are large enough to include
the l2_plen, maybe even check at runtime to be sure
* in the RSL layer (rsl_sacch_filling()), check the trx->bts->type and
either drop the length (BS11) or keep it (all other BTS)
Thanks in advance,
Harald
--
- Harald Welte <laforge at gnumonks.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)