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)