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/.
Kristian Martens kristian.martens at ng4t.comHi, I have captured a trace. Can you find something out? Thanks, Kristian Am 07.12.2016 um 18:13 schrieb Holger Freyther: >> On 07 Dec 2016, at 17:52, Kristian Martens <kristian.martens at ng4t.com> wrote: >> >> Hello, > Hi! > >> two UEs (A and B) are successfully registered in a network. Now A tries >> to call B. B is paged by the core via A interface but the sysmoBSC/BTS >> does not seem to page the UE (or UE does not answer paging). What could >> be the reason for this behaviour? How could the problem be debugged? >> Please find the attached pcap for your reference. > > nice MNC! The P-TMSI doesn't really look that random but it might be an > index into an internal data structure? > > So on A this looks right. The LAI is 262-79-1 and this is where you are > paging. In general it might be: > > * osmo-bsc doesn't translate this to actual paging. E.g. not linking/ > handling the location area identifier. You could trace the RSL protocol > and see if a paging command is being sent (periodically) to the BTS? > > * The MS still has a radio channel open. I notice that clear command is > being sent so this is unlikely to be the case. Also IMSI seems to be > match.. maybe the MS still calculates the paging group wrongly? That is > far fetched though. > > > holger -------------- next part -------------- A non-text attachment was scrubbed... Name: 20161207_nopaging.pcap Type: application/octet-stream Size: 26302 bytes Desc: not available URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20161207/dccfca29/attachment.obj>