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
Dear fellow Osmcoom developers,
it is my pleasure to finally announce the date + venue of OsmoDevCon
2013:
Date: April 04 through April 07, 2013
Place: IN-Berlin, Lehrter Str. 53, Berlin
Like last year, this is an event for developers of the various Osmocom
proejects. Reservation and confirmation of reservation is required.
The event is free of charge. The Room is made available by IN-Berlin
e.V., an Internet related non-profit organization. Lunch catering will
be sponsored (so far by sysmocom GmbH, but if any other sponsors come
up, we are happy to share the cost).
So all you have to cover is your own travel + accomodation costs, as
well as breakfast and dinner. If you are an active developer and cannot
afford travel/accomodation, please let me know and I'll see if we can do
something about it.
If you would like to attend, please send a message to
laforge(a)gnumonks.org applying for registration of the event. The
registration deadline is March 5, i.e. one week from now.
There is no detailed schedule of talks yet. I will start a separate
discussion suggesting / collecting topics in the next couple of days.
More information is (and will be made) available at
http://openbsc.osmocom.org/trac/wiki/OsmoDevCon2013
Further discussion regarding the event should be directed at the
osmocom-event-orga(a)lists.osmocom.org mailing list, to avoid
cross-posting over the various project-specific lists.
Best regards and happy hacking,
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)
Hi,
I noticed a bug in the dissector, which seems to happen when then
Exist_A5_bits field is set to 0, and results in the following fields
(Exist_Multislot_capability/Exist_GPRS_multislot_class) being decoded
incorrectly. Thus, get_ms_class_by_capability() is returning NULL
instead of the GPRS_multislot_class, which is interestingly dissected
correctly.
This is one of the messages where this happens:
4017dfb83a3f628a7045500898f28109100297e0080b2b
If I add it to the RLCMACTest it fails, so I propose it should be added
;)
My quite recent version of Wireshark (1.8.2) is decoding this message
fine, see the attachment. I've gone through the recent changes on
packet-gsm_rlcmac.c and packet-csn1.c in Wireshark, but couldn't spot
the commit that fixed it so far.
Regards,
Steve
