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.orgOn Thu, Jul 30, 2009 at 10:55:49AM +0200, Nordin wrote: > Hi Holger, > > Thnx for your offer, there is nothing to look at it than just an > initialization process on the OML layer. > It decodes some OML messages but not all, Can you please indicate which OML messages (packet number in your pcap) are not decoded well? It looks quite fine for me here. Also, I think it should be pretty straight forward to look at the 12.21 spec and extend the packet-gsm_abis_oml.c code in wireshark. We need more people working on this than just me ;) > Harald posted me some traces for scanning neighbouring cells, which > I think is important to fill the BA List. Why would you need that? If you run your own network, then you know the neighbouring cells at the BSC and you can fill it from there. If you want to operate a rouge BTS for security research or in imsi-catcher style applications, then you probably don't want to fill neighbor cell information in the syste info messages, since that would tell the phones how to easily get away from your rogue cell (which you typically don't want) > But according to Harald these were ip.access specific messages, so > how am I suppose to interpret that? I mean which bytes indicates a > neighbouring cell, or how am I suppose to understand the meaning of > certain bytes i.e. dBm level of a certain neigbouring cell and which > ARFCN? It's like reading a piece of Frenche text without having a > dictionarry (well, I understand a little bit french :-) ). Yes, that's exactly it. That's how the samba developers first implemented the SMB protocol of windows filesharing, and that's how we write OpenBSC and wireshark code for nanoBTS. Also, the abis-oml.patch already includes support for parsing the test result messages of a nanoBTS. See dissect_ipacc_test_rep() as well as ipacc_tr_ie_chan_usage and ipacc_tr_ie_bcch() in the attached patch. > I don't know how you, Harald and others interpretted the messages > during reverse-engineering. Cause I assume you don't have any > technical documents about ip.access specific messages, except the > GSM specs and some own experience? No, we don't have other documentatio. Just our common sense :) -- - 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)