7 Jan
2010
7 Jan
'10
10:19 a.m.
hi 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:
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.
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. 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(a)gnumonks.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)