> One thing that keeps me from pushing (after having tested) is the
following observation. For going from layer3 to layer4 we currently have
a queue, for my patches when going from layer2 to layer3 I have a direct
callback. Should I change that to use the same queuing approach?
hi holger,
for me it is very hard to explain, but i will try...
- bsc = lower layer (signalling)
- msc = upper layer (application)
actually we need a queue in only one direction, if we link two finite
state machines. (or in our case link two instances of transactions using
mncc.c).
during an bsc-event, when a message from bsc is sent to msc, the bsc
might do some processing right after sending the message. without a
queue, the msc could reply directly to that message (with a function
call to msc) which may change the state machine of bsc, while bsc is
still processing the first event... (race condition)
an up-queue from bsc to msc will fix that problem. msc will only process
messages, if bsc has finished it's processing of events.
in case of a message from msc to bsc, we also don't have that problem,
even without a queue. if msc sends a message directly down to bsc (using
a function call), an eventually direct reply is queued in the up-queue,
so msc can finish processing the first event before processing the
message in the up-queue.
it does not matter if the queue is for messages from bsc to msc, or from
msc to bsc, but at least we need one queue.
it may happen that a message is dequeued, but the call instance is
already gone. in this case the other layer (bsc or msc) should ignore
it. this is why the call reference is used instead of a memory pointer.
also it must be unique all the (run-)time.
regards,
andreas
hi holger,
i can do that soon. part 3 just removes the if-condition. i missed to
remove it after testing. i will fix it in the forthcomming splitted
patches.
regards,
andreas
> Okay. As stupid as it might sound please split that into three
patches.
> 1.) Fixing my stupidity in gsm0408_handle_lchan_signal!!! sorry for
making you suffer from it and thanks for fixing it.
> 2.) static int rsl_rx_rll_err_ind(struct msgb *msg)
> 3.) Explain why
> +// if (msg->lchan->use_count > 0) {
> +// }
> is a good change and should be applied?
> I don't use mISDN on Linux (I use Cygwin on Windows with my custom
driver). However I had to adjust my custom driver to see the measurement
reports in bsc_hack. The reason is that the measurement reports are sent
as LAPD UI-Frames and not as LAPD I-Frames and I did not yet take care
of UI-Frames. Maybe there is a similar problem with mISDN and UI-Frames.
hi dieter,
this is indeed a good thing to check. i can enable frame debugging on
hfc-e1, so i can see every frame in hex. also i can sniff frames using
an mISDN userland tool. with that i can see if there are any frames. if
so i will check why the driver does not report UI frames in this case,
and fix it..
regards,
andreas
On Sunday 28 June 2009 18:47:31 Andreas.Eversberg wrote:
> patch 38: still i use this little hacked install patch to install
> library and include files, so other applications like LCR can use
> openbsc without refering to the openbsc source directory. i use that
> install-hook, because i don't know much about autoconf. maybe there is a
> better way to do that.
There is. Currently all the libraries are noinst libraries.. I did sent a
patch to the mailinglist you could attempt to extent and make ready?
z.
Hey,
just a small head up. I rebased the holger/msc branch and also moved the mncc
bits into the libmsc. I'm currently in Essen and should be able to test these
patches tomorrow.
One thing that keeps me from pushing (after having tested) is the following
observation. For going from layer3 to layer4 we currently have a queue, for my
patches when going from layer2 to layer3 I have a direct callback. Should I
change that to use the same queuing approach?
holger
On Sunday 28 June 2009 18:47:31 Andreas.Eversberg wrote:
> patch 41: the pointer "tall_bsc_ctx" belongs to the gsm_data.c file, not
> to include file.
seems sensible.
On Sunday 28 June 2009 18:47:31 Andreas.Eversberg wrote:
> patch 40: in case of a channel breakdown, the signal handler for
> releasing lchan is called. the wrong pointer was used as lchan. (see
> last hunk) also we don't need to check use counter of lchan, if we
> receive an "cause 22 error". the lchan gets released anyway, if use
> counter becomes 0. (see first hunk). also i think we can force channel
> release when we receive an error indication. this can easily be tested:
> remove the battery during active call, then send a message to the mobile
> station (hang up on the remote). the message cannot be delivered, so the
> BTS send us an error indication, the channels and the call process gets
> released.
Okay. As stupid as it might sound please split that into three patches.
1.) Fixing my stupidity in gsm0408_handle_lchan_signal!!! sorry for making you
suffer from it and thanks for fixing it.
2.) static int rsl_rx_rll_err_ind(struct msgb *msg)
3.) Explain why
+// if (msg->lchan->use_count > 0) {
+// }
is a good change and should be applied?
thanks
Hello Harald,
On Sun, 28 Jun 2009 23:23:01 +0200, "Harald Welte" <laforge(a)gnumonks.org> wrote:
>
> However, since Dieter has been seeing the measurement reports, I would hope he
> is able to verify wether it works for him with the current git version of
> OpenBSC, or what kind of changes he needs to make it work. Sorry :(
I tested it with the git version from yesterday. The TRX0 is
configured properly, I can see that the attributes are set as
they should. I can also see the measurement reports in my custom
traces (I set NM_ATT_BS11_RADIO_MEAS_GRAN to 0x05).
I don't use mISDN on Linux (I use Cygwin on Windows with my custom
driver). However I had to adjust my custom driver to see the
measurement reports in bsc_hack. The reason is that the measurement
reports are sent as LAPD UI-Frames and not as LAPD I-Frames and I did
not yet take care of UI-Frames. Maybe there is a similar problem with
mISDN and UI-Frames.
One other thing is that decoding the measurement report might not
yet work properly, bsc_hack says that the reports are invalid but
for the MA10 Analyzer they are fine.
Best regards,
Dieter
--
Dieter Spaar, Germany spaar(a)mirider.augusta.de
Hey,
just a small head up. I rebased the holger/msc branch and also moved the mncc
bits into the libmsc. I'm currently in Essen and should be able to test these
patches tomorrow.
One thing that keeps me from pushing (after having tested) is the following
observation. For going from layer3 to layer4 we currently have a queue, for my
patches when going from layer2 to layer3 I have a direct callback. Should I
change that to use the same queuing approach?
holger
Hello Andreas,
On Fri, 26 Jun 2009 10:38:54 +0200, "Andreas.Eversberg" <Andreas.Eversberg(a)versatel.de> wrote:
>
> i tested the suggested values:
>
> > NM_ATT_BS11_RADIO_MEAS_GRAN, 0x01, 0x05,
> > NM_ATT_BS11_RADIO_MEAS_REP, 0x01, 0x01,
>
> no measurement reports during calls, never seen one before. maybe i have
> the wrong firmware load? i also get errors after starting bsc-hack on
> the lmt. i will try to load a different firmware this weekend.
This is what I use:
Safety Load: HS010876.SWL
SW Load: HS011106.SWL
Just one other thing, I am watching the measurement reports in custom
E1 traces. I guess this should not care and bsc_hack will show them
too.
Best regards,
Dieter
--
Dieter Spaar, Germany spaar(a)mirider.augusta.de
