Change in libosmocore[master]: gsm_04_08: add parser for Mobile Station Classmark 3

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/gerrit-log@lists.osmocom.org/.

dexter gerrit-no-reply at lists.osmocom.org
Mon Nov 9 17:44:36 UTC 2020


dexter has posted comments on this change. ( https://gerrit.osmocom.org/c/libosmocore/+/21083 )

Change subject: gsm_04_08: add parser for Mobile Station Classmark 3
......................................................................


Patch Set 2:

(4 comments)

Thanks for reviewing. Looks like my idea with the extra buffer did not work out. The reason for this is that there are checks later in the code and those will fail. I need to check the returncode of each bitvec_get_uint(), which is not so nice. Unfortunately after release 4, they added new files with each release.

https://gerrit.osmocom.org/c/libosmocore/+/21083/1/src/gsm/gsm48_ie.c 
File src/gsm/gsm48_ie.c:

https://gerrit.osmocom.org/c/libosmocore/+/21083/1/src/gsm/gsm48_ie.c@1318 
PS1, Line 1318: classmark3_len > sizeof(data
> How is this possible given that typeof(classmark3_len) is 'uint8_t' and thus the maximum is 255? […]
Done


https://gerrit.osmocom.org/c/libosmocore/+/21083/1/src/gsm/gsm48_ie.c@1326 
PS1, Line 1326: 	bv.data = (uint8_t*) data;
> Without 'const' before the bitvec definition, since you're relying on the 'current_bit'.
(the reason has nothing to do with const)

I copy classmark3 to a memory that is pre-initalized with zeros to get some buffer. This way I can ensure that even if the IE has ended, the parser can safely continue to parse the bitvector. Otherwise I might overrun the buffer. One could argue that I could count the parsed bits, or check the return codes - which I see now is necessary. My code wouln't work with release 5 for example.

Classmark3 is very problematic when it comes to length. Througout the 3gpp releases there were multiple versions specified because they added more and more fields.


https://gerrit.osmocom.org/c/libosmocore/+/21083/1/tests/gsm0408/gsm0408_test.c 
File tests/gsm0408/gsm0408_test.c:

https://gerrit.osmocom.org/c/libosmocore/+/21083/1/tests/gsm0408/gsm0408_test.c@330 
PS1, Line 330: void dump_cm3(struct gsm48_classmark3 *cm3)
> static
Done


https://gerrit.osmocom.org/c/libosmocore/+/21083/1/tests/gsm0408/gsm0408_test.c@507 
PS1, Line 507: uint8_t
> const
Done



-- 
To view, visit https://gerrit.osmocom.org/c/libosmocore/+/21083
To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings

Gerrit-Project: libosmocore
Gerrit-Branch: master
Gerrit-Change-Id: Ic8b2bfd00330235f5bed00771e421588abfaac1f
Gerrit-Change-Number: 21083
Gerrit-PatchSet: 2
Gerrit-Owner: dexter <pmaier at sysmocom.de>
Gerrit-Reviewer: Jenkins Builder
Gerrit-Reviewer: pespin <pespin at sysmocom.de>
Gerrit-CC: fixeria <vyanitskiy at sysmocom.de>
Gerrit-Comment-Date: Mon, 09 Nov 2020 17:44:36 +0000
Gerrit-HasComments: Yes
Gerrit-Has-Labels: No
Comment-In-Reply-To: fixeria <vyanitskiy at sysmocom.de>
Comment-In-Reply-To: pespin <pespin at sysmocom.de>
Gerrit-MessageType: comment
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/gerrit-log/attachments/20201109/e6850b49/attachment.htm>


More information about the gerrit-log mailing list