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.orgHi! I've updated the system_information branch. The purpose of this branch is to move away from static u_int8_t arrays that are used as templates for the SYSTEM INFORMATION messages. Thise arrays are reminiscent of the old days of bs11_init, where everything had been done this way. The current head of system_information is now managing to actually do that. The full SI1-SI4 on the BCCH as well as the SI5/SI6 on the SACCH are now created from scratch (see code in system_information.c) The content of the SI is "phase 1" content, i.e. before rest octets were introduced I've also written some code to generate the rest octets, as well as a some "rest octet encoding aware" bit vector routines that understand the meaning of 0/1/L/H. However, those rest octet routines are not yet used. They need some careful testing before use. Testing is actually quite hard, as not even wireshark has dissector for the system information messages (anyone interested in contributing on this? It's needed for airprobe, too) One interesting bit that stalled development for quite some time: If you send a SACCH FILLing with length > 18 bytes, then the nanoBTS will actually crash somewhere in the layer 2, sending you long error strings with addresses (stack?) as error reports before rebooting :) Feel free to start testing the system_information branch if you're interested. I'd be happy to hear any "master works for my phone, but system_information branch confuses my phone" kind of reports. Regards, Harald -- - 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)