10 Feb
2016
10 Feb
'16
7:22 p.m.
Hi,
Can someone here help me debug the failing build of libosmocore in Ubuntu?
See:
https://launchpadlibrarian.net/235791225/buildlog_ubuntu-xenial-amd64.libos…
The test case "gprs-bssgp" fails with following output:
stderr:
MESSAGE to 0x7f0000ff, msg length 12
02 00 81 01 01 82 0b 56 04 82 0b 55
All NS-VCs for NSEI 2901 are either dead or blocked!
All NS-VCs for NSEI 2901 are either dead or blocked!
BSSGP BVCI=0 Rx BVC STATUS, cause=Protocol error - unspecified
BSSGP BVCI=1234 Rx BVC STATUS, cause=Unknown BVCI
NSEI=2901/BVCI=2989 Cannot handle PDU type 34 for unknown BVCI, NS BVCI 2989
Unable to resolve NSEI 4660 to NS-VC!
Assert failed rc >= 0 gb/gprs_bssgp_test.c:234
I think it is related to the hardening option "-D_FORTIFY_SOURCE=2". What is
interesting is that it builds correctly in Debian, but not Ubuntu.
The issue has apparently been observed before:
http://comments.gmane.org/gmane.comp.mobile.osmocom.baseband.devel/4149
If this gets fixed quickly, it might go into the next Ubuntu LTS version which
has import freeze Feb 18th.
Cheers,
Ruben
10 Feb
10 Feb
8:20 p.m.
I made a litle bit progress. The problem disappears if
"-Wl,-Bsymbolic-functions" is removed from LDFLAGS.
Any idea why?
Ruben
On Wed, Feb 10, 2016 at 07:22:50PM +0100, Ruben Undheim wrote:
Hi,
Can someone here help me debug the failing build of libosmocore in Ubuntu?
See:
https://launchpadlibrarian.net/235791225/buildlog_ubuntu-xenial-amd64.libos…
The test case "gprs-bssgp" fails with following output:
stderr:
MESSAGE to 0x7f0000ff, msg length 12
02 00 81 01 01 82 0b 56 04 82 0b 55
All NS-VCs for NSEI 2901 are either dead or blocked!
All NS-VCs for NSEI 2901 are either dead or blocked!
BSSGP BVCI=0 Rx BVC STATUS, cause=Protocol error - unspecified
BSSGP BVCI=1234 Rx BVC STATUS, cause=Unknown BVCI
NSEI=2901/BVCI=2989 Cannot handle PDU type 34 for unknown BVCI, NS BVCI 2989
Unable to resolve NSEI 4660 to NS-VC!
Assert failed rc >= 0 gb/gprs_bssgp_test.c:234
I think it is related to the hardening option "-D_FORTIFY_SOURCE=2". What is
interesting is that it builds correctly in Debian, but not Ubuntu.
The issue has apparently been observed before:
http://comments.gmane.org/gmane.comp.mobile.osmocom.baseband.devel/4149
If this gets fixed quickly, it might go into the next Ubuntu LTS version which
has import freeze Feb 18th.
Cheers,
Ruben
11 Feb
11 Feb
7:48 a.m.
On 10 Feb 2016, at 20:20, Ruben Undheim
<ruben.undheim(a)gmail.com> wrote:
I made a litle bit progress. The problem disappears if
"-Wl,-Bsymbolic-functions" is removed from LDFLAGS.
Please see this commit[1]. The GPRS NetworkService (NS) has two backends, one to use GRE
and one to send using UDP. For the UDP case we try to override a symbol to see that it is
called. With the -Bsymbolic-functions approach this call doesn't go through the symbol
table so we will not see the call.
[1] http://git.osmocom.org/libosmocore/commit/?id=e7c18dd59f4f91409e8d8854eee2d…
6:35 p.m.
Perfect answer! Good to hear that it's not because of any code bug.
I've removed the flag and now it has been built on Ubuntu. This also paves the
way libosmo-abis, libosmo-netif, libosmo-sccp and openggsn which have been
"dependency-waiting" on the servers.
I notice that libosmo-sccp does not build correctly on powerpc
architectures. It fails the sccp test..
Please see here:
https://buildd.debian.org/status/fetch.php?pkg=libosmo-sccp&arch=powerp…
Maybe you have an idea? Is there maybe a struct problem again?
Best regards,
Ruben
On Thu, Feb 11, 2016 at 07:48:09AM +0100, Holger Freyther wrote:
On 10 Feb 2016, at 20:20, Ruben Undheim
<ruben.undheim(a)gmail.com> wrote:
I made a litle bit progress. The problem disappears if
"-Wl,-Bsymbolic-functions" is removed from LDFLAGS.
Please see this commit[1]. The GPRS NetworkService (NS) has two backends, one to use GRE
and one to send using UDP. For the UDP case we try to override a symbol to see that it is
called. With the -Bsymbolic-functions approach this call doesn't go through the symbol
table so we will not see the call.
[1]
http://git.osmocom.org/libosmocore/commit/?id=e7c18dd59f4f91409e8d8854eee2d…
6:38 p.m.
On 11 Feb 2016, at 18:35, Ruben Undheim
<ruben.undheim(a)gmail.com> wrote:
Please see here:
https://buildd.debian.org/status/fetch.php?pkg=libosmo-sccp&arch=powerp…
Maybe you have an idea? Is there maybe a struct problem again?
Interesting. the first/second deployment of the SCCP code has been on 32bit PowerPC code.
But most likely some 16bit is going wrong. If you have access to a PowerPC system through
the debian project. Could you first look at the tests/testsuite.dir/*/testsuite.log?
kind regards
holger
9:15 p.m.
Hi,
I don't have access to a PowerPC shell directly, but I can upload packages for
a test build, and I've modified the build script to dump testsuite.log.
See here:
http://debomatic-powerpc.debian.net/distribution#unstable/libosmo-sccp/0.7.…
This is an extract from the log:
- outgoing: dstref(196612) 1 -> 3
+ outgoing: dstref(67109632) 1 -> 3
income: 0 -> 3
Writing test data2
incoming data: 4
Returning data3
- outgoing data: dstref(196612) 4
- outgoing: dstref(196612) 3 -> 4
- outgoing: dstref(196612) 4 -> 5
+ outgoing data: dstref(67109632) 4
+ outgoing: dstref(67109632) 3 -> 4
+ outgoing: dstref(67109632) 4 -> 5
Ruben
On Thu, Feb 11, 2016 at 06:38:52PM +0100, Holger Freyther wrote:
Interesting. the first/second deployment of the SCCP code has been on 32bit PowerPC code.
But most likely some 16bit is going wrong. If you have access to a PowerPC system through
the debian project. Could you first look at the tests/testsuite.dir/*/testsuite.log?
kind regards
holger
9:21 p.m.
On 11 Feb 2016, at 21:15, Ruben Undheim
<ruben.undheim(a)gmail.com> wrote:
Hi!
I am off for today but..
This is an extract from the log:
- outgoing: dstref(196612) 1 -> 3
+ outgoing: dstref(67109632) 1 -> 3
uint32_t sccp_src_ref_to_int(struct sccp_source_reference *ref)
struct sccp_source_reference sccp_src_ref_from_int(uint32_t int_ref);
are the two candidates. You could have ntohl and htonl in them to make the format/result
predictable on LE and BE machines. Or swap it on BE machines.
holger
10 p.m.
Surely not elegant or efficient, but it makes the test pass...:
Index: libosmo-sccp/src/sccp.c
===================================================================
--- libosmo-sccp.orig/src/sccp.c 2016-02-05 16:56:35.845659264 +0100
+++ libosmo-sccp/src/sccp.c 2016-02-11 21:48:58.066093403 +0100
@@ -1392,14 +1392,26 @@
uint32_t sccp_src_ref_to_int(struct sccp_source_reference *ref)
{
uint32_t src_ref = 0;
+#if OSMO_IS_LITTLE_ENDIAN
memcpy(&src_ref, ref, sizeof(*ref));
+#elif OSMO_IS_BIG_ENDIAN
+ memcpy((((char*)(&src_ref))+3),&(ref->octet1),1);
+ memcpy((((char*)(&src_ref))+2),&(ref->octet2),1);
+ memcpy((((char*)(&src_ref))+1),&(ref->octet3),1);
+#endif
return src_ref;
}
struct sccp_source_reference sccp_src_ref_from_int(uint32_t int_ref)
{
struct sccp_source_reference ref;
+#if OSMO_IS_LITTLE_ENDIAN
memcpy(&ref, &int_ref, sizeof(ref));
+#elif OSMO_IS_BIG_ENDIAN
+ memcpy(&(ref.octet1),(((char*)(&int_ref))+3),1);
+ memcpy(&(ref.octet2),(((char*)(&int_ref))+2),1);
+ memcpy(&(ref.octet3),(((char*)(&int_ref))+1),1);
+#endif
return ref;
}
Cheers,
Ruben
On Thu, Feb 11, 2016 at 09:21:06PM +0100, Holger Freyther wrote:
On 11 Feb 2016, at 21:15, Ruben Undheim
<ruben.undheim(a)gmail.com> wrote:
Hi!
I am off for today but..
This is an extract from the log:
- outgoing: dstref(196612) 1 -> 3
+ outgoing: dstref(67109632) 1 -> 3
uint32_t sccp_src_ref_to_int(struct sccp_source_reference *ref)
struct sccp_source_reference sccp_src_ref_from_int(uint32_t int_ref);
are the two candidates. You could have ntohl and htonl in them to make the format/result
predictable on LE and BE machines. Or swap it on BE machines.
holger
3013
days inactive
3014
days old
7 comments
2 participants
participants (2)
-
Holger Freyther -
Ruben Undheim