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/.

Harald Welte laforge at gnumonks.org
Sun Jul 29 10:51:47 UTC 2018


Hi Holger,

On Sun, Jul 29, 2018 at 11:11:13AM +0100, Holger Freyther wrote:
> I might not have time until next week to replicate it (and my nanobts is not
> with me right now either). IIRC (my first memory but the commit message points
> me to it as well): I struggled a lot to parse ipaccess-find (IPAC_MSGT_ID_GET)
> from the nanoBTS.

Ah. ok. I've not looked at ipaccess-find/UDP in a long time. Only at the normal
procedure at OML/RSL start-up.

> It seemed it was disobeying a reasonable TLV structure and the closest I found
> back then seemed to have been this patch? Could you check if the testcase matches
> an ipaccess-find result?

Yes, I will check for that.  The test case definitely does not match the IPA CCM
seen inside OML/RSL from a nanoBTS, not even from the first traces I have from 2010.

> I will try to find some next during the week to have a look.

I think the pointer to ipaccess-find was sufficient, thanks.

-- 
- Harald Welte <laforge at gnumonks.org>           http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
                                                  (ETSI EN 300 175-7 Ch. A6)



More information about the OpenBSC mailing list