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/.
Andreas.Eversberg Andreas.Eversberg at versatel.dehi, i did some heavy tests this weekend with many mobile stations at once. with these patches all ressources (channels / subscribers) were released cleanly. even when mobile stations request more than 4 channels at a time (the current SDCCH4 is full), there is no ressource getting stuck anymore. patch 39: the location update process did not work, if mobile station uses tmsi when comming from a different network. in this case the reject-timer must also be started, and we wait for imsi identity response. in case we can't find the subscriber or if we have an unimplemented location update, we release location update process and send a reject. patch 40: in case of a channel breakdown, the signal handler for releasing lchan is called. the wrong pointer was used as lchan. (see last hunk) also we don't need to check use counter of lchan, if we receive an "cause 22 error". the lchan gets released anyway, if use counter becomes 0. (see first hunk). also i think we can force channel release when we receive an error indication. this can easily be tested: remove the battery during active call, then send a message to the mobile station (hang up on the remote). the message cannot be delivered, so the BTS send us an error indication, the channels and the call process gets released. patch 41: the pointer "tall_bsc_ctx" belongs to the gsm_data.c file, not to include file. patch 42: again my traffic channel patch. the mobile requests a channel. in case of a location update, we deliver the requested channel type. if we receive a channel request for other reasons, i force a TCH_F channel. this is requied, because we cannot change (modify) the channel right now. also i check if we have a TCH_F channel when we want to make a call to the mobile. if so, the channel is used, if not, paging is stated as if we would have no channel. so it is possible to call a mobile during location update, when it holds not a TCH_F channel. patch 43: this small fix will not check for given subscriber/imsi here. this is already done in the next "if"-condition. patch 38: still i use this little hacked install patch to install library and include files, so other applications like LCR can use openbsc without refering to the openbsc source directory. i use that install-hook, because i don't know much about autoconf. maybe there is a better way to do that. anyway i don't get any measurement reports at all. i tried two BTS' and used the firmware as described in the wiki. regards, andreas -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20090628/805847e5/attachment.htm> -------------- next part -------------- A non-text attachment was scrubbed... Name: 43_imsi_fix.patch Type: application/octet-stream Size: 547 bytes Desc: 43_imsi_fix.patch URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20090628/805847e5/attachment.obj> -------------- next part -------------- A non-text attachment was scrubbed... Name: 38_install.patch Type: application/octet-stream Size: 2485 bytes Desc: 38_install.patch URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20090628/805847e5/attachment-0001.obj> -------------- next part -------------- A non-text attachment was scrubbed... Name: 39_loc_update.patch Type: application/octet-stream Size: 1170 bytes Desc: 39_loc_update.patch URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20090628/805847e5/attachment-0002.obj> -------------- next part -------------- A non-text attachment was scrubbed... Name: 40_lchan_release.patch Type: application/octet-stream Size: 1340 bytes Desc: 40_lchan_release.patch URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20090628/805847e5/attachment-0003.obj> -------------- next part -------------- A non-text attachment was scrubbed... Name: 41_tall_bsc_ctx.patch Type: application/octet-stream Size: 1188 bytes Desc: 41_tall_bsc_ctx.patch URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20090628/805847e5/attachment-0004.obj> -------------- next part -------------- A non-text attachment was scrubbed... Name: 42_tch_f.patch Type: application/octet-stream Size: 1074 bytes Desc: 42_tch_f.patch URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20090628/805847e5/attachment-0005.obj>