The sanitizer build used to get through to testing the PCU,
now it already fails at openbsc's sgsn test. This happens in the recently added
test_pdp_deactivation_with_pdp_ctx:
http://jenkins.osmocom.org/jenkins/job/Osmocom_Sanitizer/388/consoleFull
commit 1611df5226199da2bf2fba3d22d93cc1a6c6c777
Commit: Pravin Kumarvel <pmanohar(a)radisys.com>
CommitDate: Mon Dec 12 17:20:39 2016 +0530
Support Deactivate PDP Context Request from network
https://gerrit.osmocom.org/1262
I can reproduce the segmentation fault locally, but only when the sanitizer is
enabled. When stepping up to the failure and checking the parameters, all seems
to be in order; immediately when trying to step into sgsn_create_pdp_ctx(), the
SIGSEGV is fired. So far the actual failure is not clear to me, I haven't found
the 0x02 pointer yet that asan complains about:
==21897==ERROR: AddressSanitizer: SEGV on unknown address 0x000000000002
I found a use-after-free which isn't the cause for above asan failure:
gsm0408_gprs_access_cancelled(mm, GMM_CAUSE_GPRS_NOTALLOWED);
LOGMMCTXP(LOGL_NOTICE, mm, "No PDP context to deactivate\n");
gsm0408_gprs_access_cancelled() calls mm_ctx_cleanup_free(), and after that the
local mm is non-NULL but freed. Change the order to:
LOGMMCTXP(LOGL_NOTICE, mm, "No PDP context to deactivate\n");
gsm0408_gprs_access_cancelled(mm, GMM_CAUSE_GPRS_NOTALLOWED);
(This second issue is shown when removing test_pdp_deactivation_with_pdp_ctx()
from test_pdp_deactivation())
The cause for the asan failure shown above and in jenkins still evades me. But
I'm afraid we have to revert the patch. Please run the asan build on this patch
and re-submit when the cause is clear.
How to asan build has been discussed recently:
http://lists.osmocom.org/pipermail/openbsc/2016-November/009901.html
~N
--
- Neels Hofmeyr <nhofmeyr(a)sysmocom.de> http://www.sysmocom.de/
=======================================================================
* sysmocom - systems for mobile communications GmbH
* Alt-Moabit 93
* 10559 Berlin, Germany
* Sitz / Registered office: Berlin, HRB 134158 B
* Geschäftsführer / Managing Directors: Harald Welte
Hi,
I further implemented the base of the virtual layer with the purpose
of replacing the um-air interface with a multicast-socket solution.
This has been started by Harald Welte some time ago in the Osmobts -
laforge/virt-bts branch.
As I was not really confident enough to create an official new branch
before someone had a look on what I did, so I developed in copies of
the osmocom-bb and osmo-bts projects on my github-page
(https://github.com/BastusIII/osmocom-bb-virt/tree/stumpf/virt-um and
https://github.com/BastusIII/osmo-bts-virt/tree/stumpf/virt-bts).
If someone finds to time to have a look into them (structure, path,
implementation) and give me feedback about it, I would be glad :).
Please use the following config files that i have tested:
- https://github.com/BastusIII/osmocom-config-files/blob/master/openbsc-virtu…
- https://github.com/BastusIII/osmocom-config-files/blob/master/osmobts-virtu…
- https://github.com/BastusIII/osmocom-config-files/blob/master/osmocom-bb-mo…
What works:
BTS:
- downlink over gsmtap and a multicast socket
- OML and RSL on abis properly established and seems to work
- virtual-um connection establishment
Osmocom-bb:
- virtual-um -- l23 app connection establishment (bridging osmocon,
no serial link needed)
- BCCH downlink handling and forwarding to l23 app
- handling of some l1ctl requests from l23 (e.g. power management had
to be mocked, so l23 gets a response and is satisfied)
What not:
BTS:
- missing uplink handling
Osmocom-bb
- missing uplink routines (RACH, TCH, dedicated channels)
- handlers for l23 requests only partially implemented (missing TCH, RACH, ...
I a currently a bit overwhelmed by the mass of messages exchanged
between l23-app (used mobile, btw.) and the virtual-um and hanging
because mobile gets a sync timeout.
I am looking forward to hear from you :).
Sebastian Stumpf
hi dear...
i was spent more time on it....these days i am reading on oml 2000 ...if there new updates i will tell you....
regards
rajitha
Sent from my Mi phone
On Holger Freyther <holger(a)freyther.de>, Dec 10, 2016 8:42 PM wrote:
> On 10 Dec 2016, at 03:10, Rajitha peiris <raji.oshin(a)hotmail.com> wrote:
>
>
> Hi all..
Hi!
> Anyone have success with rbs 2308 ???
> If you have any idea pls share ...
your contribution will be very welcome! Do you think you can still spend time on improving OpenBSC in 2016?
regards
holger
The libosmocore commit aa00f99be2e4cc64ede20d8c9548b83054696581 adds a VTY item
that's missing a doc string, hence breaking the openbsc build (which actually
checks the doc strings unlike the libosmocore build job).
I pushed the fix I734b22c950242541322e902887bf779c14ba10fd and things should
light up "green" (aka blue) again.
BTW, in a RL discussion lynxis suggested that it would be good if libosmocore
commits were also checked against breaking openbsc. A point against it is that
often something in libosmocore is changed and requires a follow-up in openbsc
-- if the libosmocore build rejects commits that break openbsc, it would make
it impossible to get these changes in. The workaround could be to have a
secondary build job that merely comments on gerrit whether the openbsc build
still works, without having -V voting powers.
Anyway, so far I think it is sufficient to catch these hopefully few cases once
the regular master build on jenkins.osmocore.org goes up red, like now.
~N
--
- Neels Hofmeyr <nhofmeyr(a)sysmocom.de> http://www.sysmocom.de/
=======================================================================
* sysmocom - systems for mobile communications GmbH
* Alt-Moabit 93
* 10559 Berlin, Germany
* Sitz / Registered office: Berlin, HRB 134158 B
* Geschäftsführer / Managing Directors: Harald Welte
anyone know about rbs 2308 is supported yet or not...or still under experimental stage...
thanks
regards
rajitha peiris
sri Lanka
Sent from my Mi phone
On "openbsc-request(a)lists.osmocom.org" <openbsc-request(a)lists.osmocom.org>, Dec 7, 2016 11:11 PM wrote:
Send OpenBSC mailing list submissions to
openbsc(a)lists.osmocom.org
To subscribe or unsubscribe via the World Wide Web, visit
https://lists.osmocom.org/mailman/listinfo/openbsc
or, via email, send a message with subject or body 'help' to
openbsc-request(a)lists.osmocom.org
You can reach the person managing the list at
openbsc-owner(a)lists.osmocom.org
When replying, please edit your Subject line so it is more specific
than "Re: Contents of OpenBSC digest..."
Today's Topics:
1. Re: Paging not answered in m2m call (Holger Freyther)
2. Re: Paging not answered in m2m call (Kristian Martens)
----------------------------------------------------------------------
Message: 1
Date: Wed, 7 Dec 2016 18:13:10 +0100
From: Holger Freyther <holger(a)freyther.de>
To: Kristian Martens <kristian.martens(a)ng4t.com>
Cc: openbsc(a)lists.osmocom.org
Subject: Re: Paging not answered in m2m call
Message-ID: <D782A7D5-AD0D-4BE0-9898-2AEC6151BAB0(a)freyther.de>
Content-Type: text/plain; charset=us-ascii
> On 07 Dec 2016, at 17:52, Kristian Martens <kristian.martens(a)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
------------------------------
Message: 2
Date: Wed, 7 Dec 2016 18:41:08 +0100
From: Kristian Martens <kristian.martens(a)ng4t.com>
To: Holger Freyther <holger(a)freyther.de>
Cc: openbsc(a)lists.osmocom.org
Subject: Re: Paging not answered in m2m call
Message-ID: <9a4bcc68-e884-0f48-8a26-989b7edf5bca(a)ng4t.com>
Content-Type: text/plain; charset="utf-8"
Hi,
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(a)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/at…>
------------------------------
Subject: Digest Footer
_______________________________________________
OpenBSC mailing list
OpenBSC(a)lists.osmocom.org
https://lists.osmocom.org/mailman/listinfo/openbsc
------------------------------
End of OpenBSC Digest, Vol 26, Issue 7
**************************************
In which repo it is? I don't know of other users but I might have overlooked smth.
08.12.2016 21:10, Holger Freyther пишет:
>
> hard to say. Initially I tried to use less storage but we have other range encoding users and testcases for it? E.g. Jacob created property based testing for it. Did you have a look there?
>
> holger
>
>
--
Max Suraev <msuraev(a)sysmocom.de> http://www.sysmocom.de/
=======================================================================
* sysmocom - systems for mobile communications GmbH
* Alt-Moabit 93
* 10559 Berlin, Germany
* Sitz / Registered office: Berlin, HRB 134158 B
* Geschaeftsfuehrer / Managing Directors: Holger Freyther, Harald Welte
Hi.
I've stumbled upon situation where range1024 encoding produces weird
results - see gerrit #1373 and
http://jenkins.osmocom.org/jenkins/job/OpenBSC-gerrit/1515/IU=--disable-iu,…
right before "Wrong number of arfcns"
Is this because I call it somehow wrong or there's actually a flaw in
our implementation?
--
Max Suraev <msuraev(a)sysmocom.de> http://www.sysmocom.de/
=======================================================================
* sysmocom - systems for mobile communications GmbH
* Alt-Moabit 93
* 10559 Berlin, Germany
* Sitz / Registered office: Berlin, HRB 134158 B
* Geschaeftsfuehrer / Managing Director: Harald Welte
Hello,
I got a mobile to mobile call working for signalling only. Two RTP
channels are being established successfully. But there are only a few
pattern sent over these channels (1 byte 0x23 as UDP payload). Is there
a setting I am missing in the configuration files? Please find attached
a .zip file with pcap and cfg files.
Thanks, Kristian