From alexander.chemeris at gmail.com  Fri Mar  1 06:39:26 2013
From: alexander.chemeris at gmail.com (Alexander Chemeris)
Date: Fri, 1 Mar 2013 10:39:26 +0400
Subject: problems with dissecting
In-Reply-To: <CA+QHiD9SfJwB84TE+AH9QOahctzRME2cboO3ORshF3xGXLNwpA@mail.gmail.com>
References: <512361C9.5060506@eversberg.eu>
	<CA+QHiD9SfJwB84TE+AH9QOahctzRME2cboO3ORshF3xGXLNwpA@mail.gmail.com>
Message-ID: <CABmJbFXfw6bictNYNUxGv_a27rZ-Gx5xqiAV1HNrQmv+-uhbvw@mail.gmail.com>

Ivan,

Could you please check whether this issue exists in the Wireshark dissector
as well? If yes, then we should submit a patch upstream.

Please excuse typos. Written with a touchscreen keyboard.

--
Regards,
Alexander Chemeris
CEO/Founder Fairwaves LLC
http://fairwaves.ru
On Mar 1, 2013 1:16 AM, "Ivan Kluchnikov" <Ivan.Kluchnikov at fairwaves.ru>
wrote:

> hi, andreas and steve!
>
> I fixed this problem, now decoding should work, you can check the last
> commit of master branch.
> There were problems with decoding and encoding of CSN_RECURSIVE_TARRAY,
> CSN_RECURSIVE_TARRAY_1, CSN_RECURSIVE_TARRAY_2.
>
>
> 2013/2/19 jolly <andreas at eversberg.eu>:
> > hi,
> >
> > steve and me experienced a problem with dissecting a "packet resource
> > request" at pcu. the patch i attached will show the following output:
> >
> > $ make && src/osmo-pcu
> >
> > PayloadType = 1 | spare = 0 | R = 0 | MESSAGE_TYPE = 5 |
> Exist_ACCESS_TYPE =
> > 1 | ACCESS_TYPE = 3 |  : ID | Choice PacketResourceRequestID = 1 |
> u.TLLI =
> > 0x7ee0e8fd | : End ID | Exist_MS_Radio_Access_capability = 1 |  :
> > MS_Radio_Access_capability | MS_RA_capability_value { | Choice
> > MS_RA_capability_value_Choice = 1 | u.Content length = 34 |
> > RF_Power_Capability = 4 | Exist_A5_bits = 1 | A5_bits = 96 | ES_IND = 1
> | PS
> > = 0 | VGCS = 0 | VBS = 0 | Exist_Multislot_capability = 1 |  :
> > Multislot_capability | Exist_HSCSD_multislot_class = 0 |
> > Exist_GPRS_multislot_class = 1 | GPRS_multislot_class = 10 ....
> >
> > this is all correct, but then i patched the get_ms_class_by_capability()
> > function at grps_rlcmac_data.c:
> >
> > ...
> > printf("we have = %d\n", cap->Count_MS_RA_capability_value);
> >         for (i = 0; i < cap->Count_MS_RA_capability_value; i++) {
> > printf("index=%d\n", cap->MS_RA_capability_value[i].IndexOfAccTech);
> > printf("exists multislot capability %d\n",
> > cap->MS_RA_capability_value[i].u.Content.Exist_Multislot_capability);
> > printf("exists class %d\n",
> >
> cap->MS_RA_capability_value[i].u.Content.Multislot_capability.Exist_GPRS_multislot_class);
> > printf("class %d\n",
> >
> cap->MS_RA_capability_value[i].u.Content.Multislot_capability.GPRS_multislot_class);
> > ...
> >
> > the output continues as this:
> >
> > we have = 2
> > index=2
> > exists multislot capability 0
> > exists class 1
> > class 10
> > index=0
> > exists multislot capability 0
> > exists class 0
> > class 0
> >
> > the "class 10" is correct, also it is correct that the class only exists
> in
> > the first entry of the capability array. the output of the dissector
> states
> > that multislot capability exists (Exist_Multislot_capability = 1), but
> if i
> > look at the structure, this field is not set.
> >
> > i looked at the dissector code, but don't really understand why
> > CSN_NEXT_EXIST works for some elements and not for others.
> >
> > any ideas?
> >
> > regards,
> >
> > andreas
> >
>
>
>
> --
> Regards,
> Ivan Kluchnikov.
> http://fairwaves.ru
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/osmocom-net-gprs/attachments/20130301/8db20ca9/attachment.htm>

From Ivan.Kluchnikov at fairwaves.ru  Fri Mar  1 08:45:35 2013
From: Ivan.Kluchnikov at fairwaves.ru (Ivan Kluchnikov)
Date: Fri, 1 Mar 2013 11:45:35 +0300
Subject: problems with dissecting
In-Reply-To: <CABmJbFXfw6bictNYNUxGv_a27rZ-Gx5xqiAV1HNrQmv+-uhbvw@mail.gmail.com>
References: <512361C9.5060506@eversberg.eu>
	<CA+QHiD9SfJwB84TE+AH9QOahctzRME2cboO3ORshF3xGXLNwpA@mail.gmail.com>
	<CABmJbFXfw6bictNYNUxGv_a27rZ-Gx5xqiAV1HNrQmv+-uhbvw@mail.gmail.com>
Message-ID: <CA+QHiD-8dk3vD8on2SsC1ubngsVUgwy3ZTZWnVALKYkXM4=SPg@mail.gmail.com>

Yes, this issue exists in the Wireshark too, but it is not critical
there, because dissector displays decoding of this message correct.
In any case, I will prepare a patch.

2013/3/1 Alexander Chemeris <alexander.chemeris at gmail.com>:
> Ivan,
>
> Could you please check whether this issue exists in the Wireshark dissector
> as well? If yes, then we should submit a patch upstream.
>
> Please excuse typos. Written with a touchscreen keyboard.
>
> --
> Regards,
> Alexander Chemeris
> CEO/Founder Fairwaves LLC
> http://fairwaves.ru
>
> On Mar 1, 2013 1:16 AM, "Ivan Kluchnikov" <Ivan.Kluchnikov at fairwaves.ru>
> wrote:
>>
>> hi, andreas and steve!
>>
>> I fixed this problem, now decoding should work, you can check the last
>> commit of master branch.
>> There were problems with decoding and encoding of CSN_RECURSIVE_TARRAY,
>> CSN_RECURSIVE_TARRAY_1, CSN_RECURSIVE_TARRAY_2.
>>
>>
>> 2013/2/19 jolly <andreas at eversberg.eu>:
>> > hi,
>> >
>> > steve and me experienced a problem with dissecting a "packet resource
>> > request" at pcu. the patch i attached will show the following output:
>> >
>> > $ make && src/osmo-pcu
>> >
>> > PayloadType = 1 | spare = 0 | R = 0 | MESSAGE_TYPE = 5 |
>> > Exist_ACCESS_TYPE =
>> > 1 | ACCESS_TYPE = 3 |  : ID | Choice PacketResourceRequestID = 1 |
>> > u.TLLI =
>> > 0x7ee0e8fd | : End ID | Exist_MS_Radio_Access_capability = 1 |  :
>> > MS_Radio_Access_capability | MS_RA_capability_value { | Choice
>> > MS_RA_capability_value_Choice = 1 | u.Content length = 34 |
>> > RF_Power_Capability = 4 | Exist_A5_bits = 1 | A5_bits = 96 | ES_IND = 1
>> > | PS
>> > = 0 | VGCS = 0 | VBS = 0 | Exist_Multislot_capability = 1 |  :
>> > Multislot_capability | Exist_HSCSD_multislot_class = 0 |
>> > Exist_GPRS_multislot_class = 1 | GPRS_multislot_class = 10 ....
>> >
>> > this is all correct, but then i patched the get_ms_class_by_capability()
>> > function at grps_rlcmac_data.c:
>> >
>> > ...
>> > printf("we have = %d\n", cap->Count_MS_RA_capability_value);
>> >         for (i = 0; i < cap->Count_MS_RA_capability_value; i++) {
>> > printf("index=%d\n", cap->MS_RA_capability_value[i].IndexOfAccTech);
>> > printf("exists multislot capability %d\n",
>> > cap->MS_RA_capability_value[i].u.Content.Exist_Multislot_capability);
>> > printf("exists class %d\n",
>> >
>> > cap->MS_RA_capability_value[i].u.Content.Multislot_capability.Exist_GPRS_multislot_class);
>> > printf("class %d\n",
>> >
>> > cap->MS_RA_capability_value[i].u.Content.Multislot_capability.GPRS_multislot_class);
>> > ...
>> >
>> > the output continues as this:
>> >
>> > we have = 2
>> > index=2
>> > exists multislot capability 0
>> > exists class 1
>> > class 10
>> > index=0
>> > exists multislot capability 0
>> > exists class 0
>> > class 0
>> >
>> > the "class 10" is correct, also it is correct that the class only exists
>> > in
>> > the first entry of the capability array. the output of the dissector
>> > states
>> > that multislot capability exists (Exist_Multislot_capability = 1), but
>> > if i
>> > look at the structure, this field is not set.
>> >
>> > i looked at the dissector code, but don't really understand why
>> > CSN_NEXT_EXIST works for some elements and not for others.
>> >
>> > any ideas?
>> >
>> > regards,
>> >
>> > andreas
>> >
>>
>>
>>
>> --
>> Regards,
>> Ivan Kluchnikov.
>> http://fairwaves.ru
>>
>



-- 
Regards,
Ivan Kluchnikov.
http://fairwaves.ru



From alexander.chemeris at gmail.com  Sat Mar  2 22:34:34 2013
From: alexander.chemeris at gmail.com (Alexander Chemeris)
Date: Sat, 2 Mar 2013 23:34:34 +0100
Subject: problems with dissecting
In-Reply-To: <CA+QHiD-8dk3vD8on2SsC1ubngsVUgwy3ZTZWnVALKYkXM4=SPg@mail.gmail.com>
References: <512361C9.5060506@eversberg.eu>
	<CA+QHiD9SfJwB84TE+AH9QOahctzRME2cboO3ORshF3xGXLNwpA@mail.gmail.com>
	<CABmJbFXfw6bictNYNUxGv_a27rZ-Gx5xqiAV1HNrQmv+-uhbvw@mail.gmail.com>
	<CA+QHiD-8dk3vD8on2SsC1ubngsVUgwy3ZTZWnVALKYkXM4=SPg@mail.gmail.com>
Message-ID: <CABmJbFUKod2NY8axv5HrYW_5br2B08wJ=5nk_Xq9POHK=QBtNQ@mail.gmail.com>

How could dissector display decoded message correctly if it is decoded
incorrectly?

On Fri, Mar 1, 2013 at 9:45 AM, Ivan Kluchnikov
<Ivan.Kluchnikov at fairwaves.ru> wrote:
> Yes, this issue exists in the Wireshark too, but it is not critical
> there, because dissector displays decoding of this message correct.
> In any case, I will prepare a patch.
>
> 2013/3/1 Alexander Chemeris <alexander.chemeris at gmail.com>:
>> Ivan,
>>
>> Could you please check whether this issue exists in the Wireshark dissector
>> as well? If yes, then we should submit a patch upstream.
>>
>> Please excuse typos. Written with a touchscreen keyboard.
>>
>> --
>> Regards,
>> Alexander Chemeris
>> CEO/Founder Fairwaves LLC
>> http://fairwaves.ru
>>
>> On Mar 1, 2013 1:16 AM, "Ivan Kluchnikov" <Ivan.Kluchnikov at fairwaves.ru>
>> wrote:
>>>
>>> hi, andreas and steve!
>>>
>>> I fixed this problem, now decoding should work, you can check the last
>>> commit of master branch.
>>> There were problems with decoding and encoding of CSN_RECURSIVE_TARRAY,
>>> CSN_RECURSIVE_TARRAY_1, CSN_RECURSIVE_TARRAY_2.
>>>
>>>
>>> 2013/2/19 jolly <andreas at eversberg.eu>:
>>> > hi,
>>> >
>>> > steve and me experienced a problem with dissecting a "packet resource
>>> > request" at pcu. the patch i attached will show the following output:
>>> >
>>> > $ make && src/osmo-pcu
>>> >
>>> > PayloadType = 1 | spare = 0 | R = 0 | MESSAGE_TYPE = 5 |
>>> > Exist_ACCESS_TYPE =
>>> > 1 | ACCESS_TYPE = 3 |  : ID | Choice PacketResourceRequestID = 1 |
>>> > u.TLLI =
>>> > 0x7ee0e8fd | : End ID | Exist_MS_Radio_Access_capability = 1 |  :
>>> > MS_Radio_Access_capability | MS_RA_capability_value { | Choice
>>> > MS_RA_capability_value_Choice = 1 | u.Content length = 34 |
>>> > RF_Power_Capability = 4 | Exist_A5_bits = 1 | A5_bits = 96 | ES_IND = 1
>>> > | PS
>>> > = 0 | VGCS = 0 | VBS = 0 | Exist_Multislot_capability = 1 |  :
>>> > Multislot_capability | Exist_HSCSD_multislot_class = 0 |
>>> > Exist_GPRS_multislot_class = 1 | GPRS_multislot_class = 10 ....
>>> >
>>> > this is all correct, but then i patched the get_ms_class_by_capability()
>>> > function at grps_rlcmac_data.c:
>>> >
>>> > ...
>>> > printf("we have = %d\n", cap->Count_MS_RA_capability_value);
>>> >         for (i = 0; i < cap->Count_MS_RA_capability_value; i++) {
>>> > printf("index=%d\n", cap->MS_RA_capability_value[i].IndexOfAccTech);
>>> > printf("exists multislot capability %d\n",
>>> > cap->MS_RA_capability_value[i].u.Content.Exist_Multislot_capability);
>>> > printf("exists class %d\n",
>>> >
>>> > cap->MS_RA_capability_value[i].u.Content.Multislot_capability.Exist_GPRS_multislot_class);
>>> > printf("class %d\n",
>>> >
>>> > cap->MS_RA_capability_value[i].u.Content.Multislot_capability.GPRS_multislot_class);
>>> > ...
>>> >
>>> > the output continues as this:
>>> >
>>> > we have = 2
>>> > index=2
>>> > exists multislot capability 0
>>> > exists class 1
>>> > class 10
>>> > index=0
>>> > exists multislot capability 0
>>> > exists class 0
>>> > class 0
>>> >
>>> > the "class 10" is correct, also it is correct that the class only exists
>>> > in
>>> > the first entry of the capability array. the output of the dissector
>>> > states
>>> > that multislot capability exists (Exist_Multislot_capability = 1), but
>>> > if i
>>> > look at the structure, this field is not set.
>>> >
>>> > i looked at the dissector code, but don't really understand why
>>> > CSN_NEXT_EXIST works for some elements and not for others.
>>> >
>>> > any ideas?
>>> >
>>> > regards,
>>> >
>>> > andreas
>>> >
>>>
>>>
>>>
>>> --
>>> Regards,
>>> Ivan Kluchnikov.
>>> http://fairwaves.ru
>>>
>>
>
>
>
> --
> Regards,
> Ivan Kluchnikov.
> http://fairwaves.ru



--
Regards,
Alexander Chemeris.
CEO, Fairwaves LLC / ??? ???????
http://fairwaves.ru



From hfreyther at sysmocom.de  Sat Mar 16 22:33:27 2013
From: hfreyther at sysmocom.de (Holger Hans Peter Freyther)
Date: Sat, 16 Mar 2013 23:33:27 +0100
Subject: [PATCH] main: The normal way to stop an application is to send
	SIGTERM, handle it
Message-ID: <1363473207-26273-1-git-send-email-hfreyther@sysmocom.de>

From: Holger Hans Peter Freyther <zecke at selfish.org>

Make the code handle SIGTERM. This way the pcu can be easily stopped
with a sysvinit script.
---
 src/pcu_main.cpp |    1 +
 1 file changed, 1 insertion(+)

diff --git a/src/pcu_main.cpp b/src/pcu_main.cpp
index f135cfd..4fae14b 100644
--- a/src/pcu_main.cpp
+++ b/src/pcu_main.cpp
@@ -114,6 +114,7 @@ void sighandler(int sigset)
 
 	switch (sigset) {
 	case SIGINT:
+	case SIGTERM:
 		/* If another signal is received afterwards, the program
 		 * is terminated without finishing shutdown process.
 		 */
-- 
1.7.10.4




From Ivan.Kluchnikov at fairwaves.ru  Tue Mar 19 14:40:35 2013
From: Ivan.Kluchnikov at fairwaves.ru (Ivan Kluchnikov)
Date: Tue, 19 Mar 2013 18:40:35 +0400
Subject: [PATCH] main: The normal way to stop an application is to send
	SIGTERM, handle it
In-Reply-To: <1363473207-26273-1-git-send-email-hfreyther@sysmocom.de>
References: <1363473207-26273-1-git-send-email-hfreyther@sysmocom.de>
Message-ID: <CA+QHiD994=OiW=_2q9f4ZZhhyAXVQitFRmWJMv7krmm9nhdoww@mail.gmail.com>

Patch was committed to master.

2013/3/17 Holger Hans Peter Freyther <hfreyther at sysmocom.de>:
> From: Holger Hans Peter Freyther <zecke at selfish.org>
>
> Make the code handle SIGTERM. This way the pcu can be easily stopped
> with a sysvinit script.
> ---
>  src/pcu_main.cpp |    1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/src/pcu_main.cpp b/src/pcu_main.cpp
> index f135cfd..4fae14b 100644
> --- a/src/pcu_main.cpp
> +++ b/src/pcu_main.cpp
> @@ -114,6 +114,7 @@ void sighandler(int sigset)
>
>         switch (sigset) {
>         case SIGINT:
> +       case SIGTERM:
>                 /* If another signal is received afterwards, the program
>                  * is terminated without finishing shutdown process.
>                  */
> --
> 1.7.10.4
>
>



-- 
Regards,
Ivan Kluchnikov.
http://fairwaves.ru