143 is actually the SSN for RNSAP. Wireshark displayed a RNSAP message type
and malformed packet warning until I fixed this to 142. Now I get the proper
RANAP and id-Paging reported.
There has been a reallocation for RANAP and RNSAP SSNs, though the old SSN for
RANAP is apparently 32 (seen in a pcap from a real 3G network). When I send 32
instead of 142, wireshark also decodes the message as valid RANAP.
---
include/osmocom/sigtran/sccp_sap.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/osmocom/sigtran/sccp_sap.h b/include/osmocom/sigtran/sccp_sap.h
index 5696b47..15aa840 100644
--- a/include/osmocom/sigtran/sccp_sap.h
+++ b/include/osmocom/sigtran/sccp_sap.h
@@ -106,7 +106,7 @@ enum osmo_sccp_ssn {
OSMO_SCCP_SSN_RES_INTL = 0x0c,
OSMO_SCCP_SSN_BISDN = 0x0d,
OSMO_SCCP_SSN_TC_TEST = 0x0e,
- OSMO_SCCP_SSN_RANAP = 143,
+ OSMO_SCCP_SSN_RANAP = 142,
};
struct osmo_sccp_gt {
--
2.1.4
Dear all,
I am growing incredibly frustrated at the fact that osmo-bts-trx is
effectively unmaintained, despite the fact that there are plenty of
users as well as even commercial users / companies (particularly
Fairwaves).
I'm not pointing Fairwaves out because I am associated with sysmocom.
I'm pointing them out as for me as Osmocom project founder and
co-maintainer, I sincerely think something is wrong here. And
particuarly commercial vendors of BTSs using the Osmocom stack should
at the very absolute minimum ensure proper maintenance of their own
hardware support in the respective Osmocom projects. They should
equally consider contributing to maintenance and developemnt of the
'core' code of those projects, too, in order to fairly share the burden
of that effort.
I explicitly asked for proper maintenance of osmo-bts-trx first in
August 2014 in this post:
http://lists.osmocom.org/pipermail/openbsc/2014-August/007657.html
Back in 2014 and the first half of 2015 I spent a lot of time in
forward-porting and cleaning up the the (fairwaves-commissioned?) l1sap
changes, as well as the associated osmo-bts-trx port. Back then, there
were several patches in related (several) branches that I could not
merge. See my mail (and follow-up mails) from
http://lists.osmocom.org/pipermail/openbsc/2015-September/000379.html
Ever since the merge in August 2015, as far as I recall, I never saw a
single message from any osmo-bts-trx user whether
a) the L1SAP merge back then works for them
b) it introduced any regressions
The same happened after the phy_link/phy_interface merge.
While some people think I sometimes write good code, I fail to believe
that all those intrusive changes didn't break anything for OsmoTRX
users. Still, no feedback and no fall-out was reported.
Like any larger project, particularly one with different hardware
support, we need somebody with essential interest in that hardware to
maintain the respective back-end. Think of device driver maintainers in
the Linux kernel as an example.
For osmo-bts-sysmo, it is clear that sysmocom has such a vital interest,
and that it is the primary hardware on whcih Holger and I are working
on. For osmo-bts-octphy, Octasic funds related maintenance work to be
done at sysmocom.
We need a sub-maintainer for osmo-bts-trx, one who
1) consistently follows the developments in master and checks for
regressiosn
2) fixes osmo-bts-trx specific bugs like the fact that GPRS measurment
values are not passed to the PCU, breaking rate/link adaption for
this platform
3) tests interoperability with OsmoTRX and other OpenBTS transceivers
out three
4) ensures that important osmo-bts-trx related patches/branches end up
in master, ensuring that master is what people use. Telling users to
use a branch different than master is *wrong* for anything but the
most bleeding edge / experiemental code which is to be merged ASAP.
I thus strongly suggest that the users and proponents of osmo-bts-trx
get together and see how they can ensure the proper maintenance of this
port. Thanks for your consideration.
Regards,
Harald
--
- Harald Welte <laforge(a)gnumonks.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
This is after the patch to libasn1c, removing str arg constness.
Note the comment added in the code.
---
src/ranap_msg_factory.c | 9 +++++++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/src/ranap_msg_factory.c b/src/ranap_msg_factory.c
index bdae92e..e87eeaf 100644
--- a/src/ranap_msg_factory.c
+++ b/src/ranap_msg_factory.c
@@ -180,8 +180,13 @@ struct msgb *ranap_new_msg_dt(uint8_t sapi, const uint8_t *nas, unsigned int nas
else
ies.sapi = RANAP_SAPI_sapi_0;
- /* Avoid copying + later freeing of OCTET STRING */
- OCTET_STRING_noalloc(&ies.nas_pdu, nas, nas_len);
+ /*
+ * Avoid copying + later freeing of OCTET STRING.
+ * To store the pointer in an OCTET_STRING_t without copying, we need
+ * to un-const *nas. Note: un-consting *nas is safe because ies.nas_pdu
+ * is only used to store the IEs in dt.
+ */
+ OCTET_STRING_noalloc(&ies.nas_pdu, (uint8_t*)nas, nas_len);
/* ies -> dt */
rc = ranap_encode_directtransferies(&dt, &ies);
--
2.1.4
Hi,
sua.c: In function 'rx_inact_tmr_cb':
sua.c:288: warning: unused variable 'conn'
sua.c: In function 'sua_rx_coref':
sua.c:908: warning: unused variable 'cause'
sua.c: In function 'sua_rx_codt':
sua.c:1059: warning: unused variable 'cur'
sua.c: In function 'sua_srv_conn_cb':
sua.c:1266: error: 'SCTP_SENDER_DRY_EVENT' undeclared (first use in this function)
sua.c:1266: error: (Each undeclared identifier is reported only once
sua.c:1266: error: for each function it appears in.)
sua.c: In function 'sua_cli_read_cb':
sua.c:1451: error: 'SCTP_SENDER_DRY_EVENT' undeclared (first use in this function)
can we make the SCTP_SENDER_DRY_EVENT optional or is a strict requirement? If it is strict then maybe we can check for this in autoconf?
holger
From: Max <msuraev(a)sysmocom.de>
Factor out 2, add 3 functions. Those functions are simple wrappers
around hex strings specific to IPA protocol. Not all of them are
utilized at the moment but they were checked with wireshark while
working on the tests. It might come in handy if we'd like to further
expand related test harness in future. The same goes for optional
verbosity argument which is not used right now but will be handy for
future debugging.
---
openbsc/tests/vty_test_runner.py | 29 +++++++++++++++++++++++++++--
1 file changed, 27 insertions(+), 2 deletions(-)
diff --git a/openbsc/tests/vty_test_runner.py b/openbsc/tests/vty_test_runner.py
index ecf5204..d574129 100644
--- a/openbsc/tests/vty_test_runner.py
+++ b/openbsc/tests/vty_test_runner.py
@@ -736,13 +736,13 @@ class TestVTYNAT(TestVTYGenericBSC):
self.assertEqual(data, "\x00\x01\xfe\x04")
print "Going to send ID_RESP response"
- res = ussdSocket.send("\x00\x07\xfe\x05\x00\x04\x01\x6b\x65\x79")
+ res = ipa_send_resp(ussdSocket, "\x6b\x65\x79")
self.assertEqual(res, 10)
# initiating PING/PONG cycle to know, that the ID_RESP message has been processed
print "Going to send PING request"
- res = ussdSocket.send("\x00\x01\xfe\x00")
+ res = ipa_send_ping(ussdSocket)
self.assertEqual(res, 4)
print "Expecting PONG response"
@@ -1007,6 +1007,31 @@ def add_nat_test(suite, workdir):
test = unittest.TestLoader().loadTestsFromTestCase(TestVTYNAT)
suite.addTest(test)
+def ipa_send_pong(x, verbose = False):
+ if (verbose):
+ print "\tBSC -> NAT: PONG!"
+ return x.send("\x00\x01\xfe\x01")
+
+def ipa_send_ping(x, verbose = False):
+ if (verbose):
+ print "\tBSC -> NAT: PING?"
+ return x.send("\x00\x01\xfe\x00")
+
+def ipa_send_ack(x, verbose = False):
+ if (verbose):
+ print "\tBSC -> NAT: IPA ID ACK"
+ return x.send("\x00\x01\xfe\x06")
+
+def ipa_send_reset(x, verbose = False):
+ if (verbose):
+ print "\tBSC -> NAT: RESET"
+ return x.send("\x00\x12\xfd\x09\x00\x03\x05\x07\x02\x42\xfe\x02\x42\xfe\x06\x00\x04\x30\x04\x01\x20")
+
+def ipa_send_resp(x, tk, verbose = False):
+ if (verbose):
+ print "\tBSC -> NAT: IPA ID RESP"
+ return x.send("\x00\x07\xfe\x05\x00\x04\x01" + tk)
+
def add_bsc_test(suite, workdir):
if not os.path.isfile(os.path.join(workdir, "src/osmo-bsc/osmo-bsc")):
print("Skipping the BSC test")
--
2.8.1
Hi,
I am trying to find a solution that enables to find the position of the phone connected to my network. Are there any GSM protocols that provide such features or is it only done on the RF level using direction finders ?
Best Regards,
Robert,