Rationale behind ipa_ccm_idtag_parse_off() ?

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

Holger Freyther holger at freyther.de
Mon Jul 30 22:25:47 UTC 2018



> On 30. Jul 2018, at 21:03, Harald Welte <laforge at gnumonks.org> wrote:
> 
> Hi Holger,
> 

Hey!

> I think the solution to the problem is that your test case parses the
> IDENTITY REQUESET format, which has 8bit length fields, while the function
> is normally (without the offset) used for the IDENTITY RESPONSE packets, where
> there are 16bit length fields.

nothing genius in the end just poking in the blind trying to understand a
binary protocol and getting it wrong... When looking at the traces I wondered
if they got \0 termination of strings wrong and didn't consider that
request/response would use different length fields. But 16bit length fields
seem to make sense.

Nice find! We can clean this up in the osmo-bts code as well.


> I'll look into this once I find time and make sure we have test cases for both,
> as well as fix the bug about the extraneous byte that my patch
> https://gerrit.osmocom.org/#/c/libosmocore/+/10216/ attempts to fix - and which
> is required to make external USSD entities in osmo-hlr work.

It looks like we can throw away the entire ipa_ccm_idtag_parse_off and time to
create a TLV_TYPE_L16TV?

holger


More information about the OpenBSC mailing list