[Openbts-discuss] 2.4 Patches, first set

[Alexander C. <ale...@gm...>]

Hi all,

I spent a night and a half of a day debugging OpenBTS and getting
more into GSM specs today. I can't say it was entirely joyful, but
at least it was interesting and somewhat productive. What I did -
I added tons of debug output and a lot of asserts which checks
that BitVectors are indeed bit vectors, i.e. contain only 0&1. This
check failed almost instantly after OpenBTS startup. With this
fixes it is now able to start, but still fails on first RACH L1 frame.
I also do a lot of valgrind runs.

Here we go.

* openbts-2.4-idlefill.diff
Minor bug. Idle Fill pattern was generated incorrectly, because of
wrong use of BitVector.

* openbts-2.4-freqlist.diff
First, no one filled those 3 bits, mentioned in the comment and this
made valgrind unhappy. I've looked at specs and found that actually
these bits should be 0-ed - one is mandatory 0 and two are spare
with recommended 0 fill. Then, pointer to spec is little bit wrong
(and the name of the class too) - it pointed to Frequency List IE,
while what is implemented is Cell Channel Description IE, though
difference is very small.

* openbts-2.4-viterbi.diff
This is not a solution, but rather a patch to exhibit a possible bug.
Valgrind correctly pointed, that here we run out of arrays boundary.
To check this by yourself - apply the patch and run BitVectorTest.
It should be killed immediately.

* SMS crash
I also have an experience that SMS crashes OpenBTS. I've spent
a good deal of time digging around and it seems that there are
a memory corruption somewhere. It crashes in TLSubmit::text(),
which is solely a debug output function, on the line
 	os << " VP=(" << mVP << ")";
without any apparent reasons. If I replace the line by one
of the following, it does not crash and phone reports me that
SMS is sent successfully (which is strange, becsuse I have
no SIMPLE server):
	os << " VP=(" << mVP;  // No Crash!
	os << " VP=(" << ")";   // No Crash!

* That's more like a question - in BitVector::bit() why do you
return "(*dp) & 0x01" instead of just *dp?

-- 
Regards,
Alexander Chemeris.