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/osmocom-net-gprs@lists.osmocom.org/.
Alexander Chemeris alexander.chemeris at gmail.comHow 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