Hi all,
I'm making a talk about tips and tools for doing more effective Osmocom
related development.
Some ideas I have for it currently:
* how to build your own (deb, rpm) packages with OBS
* how to run CI stuff (like the checkpatch linter) locally
* running tcpdump over SSH and piping it into wireshark
* finding what regression caused a ttcn-3 failure systematically
Is there anything (within this list or other ideas) you would find
particularly interesting, or boring?
If you have a couple of tips or tools to share, and would like to
present them yourself: let me know as well, then we could turn this into
a quick lightning talk series with multiple presenters.
Best,
Oliver
--
- Oliver Smith <osmith(a)sysmocom.de> https://www.sysmocom.de/
=======================================================================
* sysmocom - systems for mobile communications GmbH
* Siemensstr. 26a
* 10551 Berlin, Germany
* Sitz / Registered office: Berlin, HRB 134158 B
* Geschaeftsfuehrer / Managing Director: Harald Welte
Dear experts
We try to configure osmo-bsc / osmo-mgw to be able to communicate with ERICSSON MSC/MGW.
The UE is well registered but we don't know how to well configure bsc.
We have this config file osmo-bsc.cfg:
- 172.20.10.10 is a local BSC address to communicate to STP, MSC, MGW
osmo-bsc
mgw 0
local-ip 172.20.10.10
local-port 2427
remote-ip 172.20.10.10
remote-port 2727
reset-endpoint rtpbridge/*
We have on the BSC a local mgw, and here is the osmo-mgw.cfg file:
172.20.10.19 is another address on the BSC towards the osmo-bts-trx.
osmo-mgw
mgcp
domain mgw
bind ip 172.20.10.10
bind port 2727
rtp port-range 4002 16001
rtp bind-ip 172.20.10.19
rtp ip-probing
rtp ip-dscp 0
rtp keep-alive once
rtcp-omit
rtp-patch ssrc
rtp-patch timestamp
no rtp-patch rfc5993hr
sdp audio-payload send-ptime
sdp audio-payload send-name
number endpoints 512
osmux off
Sure we made errors and misunderstood.
During test call, we can see in the trace, a Call proceeding, then a BSSMAP Assignment Request followed by a BSSMAP Assignment Complete.
The problem is that the IP choosen as AoIP Transport Layer Address is the OAM address of the BSC (seen in In GSM A-I/F BSSMAP Assignment Complete trace section - UDP port 4004).
How to change this in order to set 172.20.10.10 as the AoIP Transport Layer Address ?
Many thanks in advance,
best regards
Jean-Marc
Dear Sandeep,
> checking for LIBOSMOCORE... no
> configure: error: Package requirements (libosmocore >= 1.9.0) were not met:
>
> Package 'libosmocore', required by 'virtual:world', not found
I'm sorry to say, but if that message is not specific/helpful enough, then
you do not appear to be a Linux software developer with sufficient background
to build software packages from source code. Nothing about this is
osmocom speficic.
In this case I'd strongly advise to simply use the pre-built binary
packages we release, exactly for users who are users and not developers.
See https://osmocom.org/projects/cellular-infrastructure/wiki/Binary_Packages
Thanks for your understanding,
Harald
--
- Harald Welte <laforge(a)gnumonks.org> https://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
Dera Team,
I am facing this error.
[root@ip-172-31-27-63 libosmo-sccp]# ./configure.ac
./configure.ac: line 1: dnl: command not found
./configure.ac: line 2: syntax error near unexpected token `[libosmo-sccp],'
./configure.ac: line 2: `AC_INIT([libosmo-sccp],'
[root@ip-172-31-27-63 libosmo-sccp]#
Kindly help here . Thanks .
Regards,
Sandeep Malik
Hello,
How can I utilize the iCE40 E1 USB adapter to transition from E1 to IP in a
GSM network, connecting a physical Siemens BSC (which has a BTS
connected) to OsmoMSC?
Only the BTS and BSC are physical. I already have osmo-e1d installed.
Should I use osmo-e1d or dahdi version for this transition?
What would be the best approach to begin the process?
Regards,
Alina
Hi,
I am trying to setup a simple Network In The Box 2G network. I am only interested in CS capabilities (voice calls, SMS, USSD). I am currently running the following elements with the default configurations:
- osmo-bts-trx (connecting to osmo-trx-uhd driving a USRP B205mini-i)
- osmo-bsc
- osmo-msc
- osmo-hlr
- osmo-mgw
- osmo-stp
I built all the programs from source on Ubuntu 22.04. Everything is running locally on one machine.
Everything seems to function correctly at first, but I noticed that sometimes when I try to execute an USSD code or make a call, my Channel Requests are not being responded. I noticed when this happens, osmo-bts shows the following notice:
DPCU notice PCU socket not connected, dropping message (pcu_sock.c:1018)
As I understand from the documentation (https://osmocom.org/projects/cellular-infrastructure/wiki/Osmocom_Network_I…), this component is not required for circuit switched services as the ones I am requesting, so I do not understand why this is happening. I assume something in the configuration files is telling the BTS or some network element that the PS side of the network is active, but I haven't found anything related to PCU in any of configuration files.
Dear Osmocom developers,
In our project we have been using the gsmtap pseudo-header to store UMTS and LTE signalling traces in pcapng format. This is very efficient compared to our previous implementation based on DLT_USER, and thanks to the gsmtap dissector, it allows any *shark app to read our output file.
When looking for the proper type and sub_type for NR signalling traces, I discovered they are not yet part of the standard. I found several threads of discussion about this, from about 2017 onwards, and I understand it is a matter of time and resources if the version 3 of GSMTAP has not been released.
The most interesting feature I have read about is the ability to extend the header with a TLV approach. EARFCN, eNodeB-ID, PCI, are useful metadata we would like to add to our traces.
In an ideal world, I would like things to be put in motion so that a new version of GSMTAP could see the light. More humbly, I ask you what kind of help is needed. Are you waiting for a draft specification? Are all requirements well known?
I suppose that LTE and NR are not the main focus today for liboscmocore development, but there are many projects out there waiting for the GSMTAP format to be updated.
Thanks!
Mauro
While I'm here looking at the mailing list, I have been thinking about
asking about the following, and no need to delay it, I suppose -
Upcoming OsmoDevCon attendees may have noticed the proposed and
scheduled session on CSFB testing.
Well, since - and sort of because that session was accepted, (and also
an iPhone 6 that supports the band of an eNB I have at home dropped into
my possession) - I've been prompted to advance my knowledge and
understanding of issues, and the iPhone (6 at least) is now doing MO
CSFB perfectly, and I think I see what some other observed issues are about.
I'm still happy if there's interest to do the session of course,
although maybe some might question whether it is more productive to just
file tickets/issues and work them out the usual way.
This email is not to suggest in any way to cancel the session, but
rather to ask if maybe we might expand the scope.
I'm thinking for example also testing 2G data. The older basic 2G + GPRS
"chocolate bar" type phones I have don't work anymore, they used to.
(not sure what one might actually do with such a device and GPRS these
days, but that's not the point, right?)
Someone (vadim?) brought a 2G (was it a credit card?) terminal once to
devcon. Does it work? that kind of thing. So thinking about all this,
I'm asking the question of whether there is interest to have a kind of
events style setup during the conference. lynxis I think has a server
for that, or maybe it's only a VM?
I don't mean a distracting always-on setup, and I don't mean to put
emphasis on cellular projects. But if we did want to have something
multi RAT, available for anybody who might want to glance in that
direction (during a USSE for example), then some (small) amount of
logistics preparation is necessary, no?
Thanks.
k.
Hi all,
While working with open5gs + kamailio, one traditionally always needed two HSS:
* the open5gs one with its mongodb and nodejs hell
* the FHoSS one for the kamailio IMS core
For some time there's now PyHSS, which supports both EPS and IMS subscriptions, which
is of course nice. docker_open5gs meanwhile also has switched to using it as default.
The big problem is that it doesn't actually state which license it is
under, which makes it legally impossible to [re]distribute it, or to even make a fork
of the repository, as that would be a violation of copyright. At least German users
are abel to legally use it, as under German copyright law you don't need
a license from the copyright holder to use a program that you have obtained legally.
In order to automatize the steps described in the open5gs_docker to create
subscribers, I've just hacked up a small tool, see
https://gitea.osmocom.org/laforge/pyhss-tool/src/branch/master/pyhss-tool.py
Using that tool, it's as easy as
pyhss-tool.py subscriber-create --imsi 001011111111111 --msisdn 1111 --k 000102030405060708090a0b0c0d0e0f --opc 00000000000000000000000000000000
or
pyhss-tool.py subscriber-delete --imsi 001011111111111
to add/remove subscribers. You will still need to manually create the
internet and ims APNs via the REST interface; I'll probably also add
that capability to the tool.
Once it's a bit more tested, I also would like to contribute it
upstream, at least once that is possible. To do that I'd have to make a
pull request, and making that pull request requires me to create a fork,
which is a copyright violation. wtf.
If that legal situation has cleared up, it might be worth considering either adding
native GSUP support to PyHSS (so it can be used by osmo-{msc,sgsn}, or to have
a converter like osmo_gsup2dia (the inverse of the existing osmo_dia2gsup).
Regards,
Harald
--
- Harald Welte <laforge(a)osmocom.org> https://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
Ace your NURS FPX 4000 assessments with our expert tutors! Get personalized, online assessment help for NURS FPX 4000 Assessment 1 to 4 and complete your BSN and MSN in one billing cycle. High-quality tutoring designed for success.
Introduction to NURS FPX 4000 Series Assessments
Embarking on the NURS FPX 4000 series can be a pivotal step in your nursing career. These assessments are crucial for understanding complex healthcare concepts, developing critical thinking, and applying knowledge practically. Whether you're tackling NURS FPX 4000 Assessment 1 or moving forward to NURS FPX 4000 Assessment 4, each step is an opportunity to excel and prove your competency in the nursing field.
Why Choose Our Services for Your Nursing Assessments?
Our online tutoring platform specializes in guiding nursing students through their BSN and MSN programs with ease and efficiency. If you aim to complete your nursing program within one billing cycle, our expert tutors are here to provide you with the support and resources you need. From NURS FPX 4000 Assessment 2 to the comprehensive NURS FPX 4000 Assessment 3, we cover all bases.
Personalized Tutoring Approach
We understand that each student has unique learning needs. That's why our tutoring service is personalized, focusing on the specific requirements of assessments like NURS FPX 4000 Assessment 4. Our approach ensures that you not only meet but exceed the expectations set by these rigorous assessments.
Expert Tutors at Your Service
Our team consists of experienced tutors who are not just experts in their field but are also intimately familiar with the structure and demands of the NURS FPX series. Whether you're looking for "Hire assessment help writer" or need someone to "Take my Assessment," our professionals are equipped to assist you in navigating through NURS FPX 4000 Assessment 1 and beyond.
Achieve Your Goals in One Billing Cycle
The journey to completing your BSN and MSN program is challenging but rewarding. With our focused tutoring for the NURS FPX 4000 series, including targeted help for NURS FPX 4000 Assessment 2 and NURS FPX 4000 Assessment 3, we make it possible to achieve your academic goals swiftly. Our strategy includes intensive review sessions, practical application exercises, and comprehensive support materials that prepare you for success.
Comprehensive Support for All Assessments
Understanding the depth of knowledge required for assessments like NURS FPX 4000 Assessment 4 is crucial. Our services offer detailed guidance for each assessment in the series, ensuring you're well-prepared for every challenge. From "Online assessment help" to "Write my assessment," we provide a range of services designed to support your academic journey.
Your Pathway to Success in Nursing
Choosing our tutoring services for your NURS FPX 4000 series assessments is more than just academic support; it's an investment in your future. With our expert guidance, personalized tutoring, and comprehensive resources, completing your BSN and MSN program in one billing cycle is within reach. Start your journey toward nursing excellence today and take the first step towards a successful career with confidence.
Don't let the challenges of NURS FPX 4000 assessments hold you back. Hire an assessment help writer today and unlock your potential in the nursing field. Contact us to learn more about how we can help you achieve your goals.
Excel in NURS FPX 4010 Assessments with Our Expert Online Tutoring
Dominate your NURS FPX 4010 assessments with our specialized tutoring services. From Assessment 1 to 4, we provide comprehensive support to complete your nursing program with top grades. Start your success story today!
Introduction to NURS FPX 4010 Series Assessments
The NURS FPX 4010 series represents a significant milestone in the journey of nursing students. It challenges students to apply their knowledge in real-world scenarios, enhancing their clinical reasoning and decision-making skills. Whether you're just starting with NURS FPX 4010 Assessment 1 or gearing up for NURS FPX 4010 Assessment 4, each assessment is a step closer to achieving your academic and professional goals in nursing.
Why Our Tutoring Services Are Essential for Your Success
Navigating through the NURS FPX 4010 series requires more than just hard work; it demands strategic study plans and insights from experienced professionals. Our tutoring services are designed to guide you through each assessment, including NURS FPX 4010 Assessment 2 and NURS FPX 4010 Assessment 3, ensuring you grasp the core concepts and apply them effectively.
Customized Learning for Maximum Impact
We believe in a personalized approach to learning, recognizing that each student has unique strengths and challenges. Our tutors tailor their teaching methods to suit your individual needs, focusing on areas that require additional attention, such as NURS FPX 4010 Assessment 4, to maximize your learning outcome.
Expert Tutors Ready to Assist You
Our team comprises seasoned nursing educators who excel in their respective fields. They bring a wealth of knowledge and practical experience, providing invaluable insights into successfully completing assessments like NURS FPX 4010 Assessment 1. With our experts, you're not just preparing for an exam; you're gearing up for a successful career in nursing.
Achieve Excellence in One Billing Cycle
Our goal is to help you complete your BSN and MSN programs efficiently, without compromising the depth of learning. By focusing on crucial assessments, including NURS FPX 4010 Assessment 2 and NURS FPX 4010 Assessment 3, we streamline your study process to ensure you're exam-ready in the shortest possible time.
Comprehensive Support Tailored to Your Needs
From "Write my assessment" to "Online assessment help," we offer a range of services to support your academic journey. Our comprehensive tutoring package includes review sessions, practice questions, and personalized feedback, covering every aspect of the NURS FPX 4010 Assessment 4 and beyond.
Your Partner in Nursing Education
Choosing our tutoring services for the NURS FPX 4010 series is a step towards academic excellence and professional mastery. With our personalized support, expert guidance, and comprehensive resources, you'll be well-equipped to tackle each assessment with confidence and achieve your goals in the competitive field of nursing.
Elevate your nursing education with our expert tutors. Contact us now to learn how we can help you excel in the NURS FPX 4010 series and advance your career with confidence.
Excel in NURS FPX 4010 Assessments with Our Expert Online Tutoring
Dominate your NURS FPX 4010 assessments with our specialized tutoring services. From Assessment 1 to 4, we provide comprehensive support to complete your nursing program with top grades. Start your success story today!
Introduction to NURS FPX 4010 Series Assessments
The NURS FPX 4010 series represents a significant milestone in the journey of nursing students. It challenges students to apply their knowledge in real-world scenarios, enhancing their clinical reasoning and decision-making skills. Whether you're just starting with NURS FPX 4010 Assessment 1 or gearing up for <a href=https://www.etutors.us/assessment-4-stakeholder-presentation/> NURS FPX 4010 Assessment 4</a>. , each assessment is a step closer to achieving your academic and professional goals in nursing.
Why Our Tutoring Services Are Essential for Your Success
Navigating through the NURS FPX 4010 series requires more than just hard work; it demands strategic study plans and insights from experienced professionals. Our tutoring services are designed to guide you through each assessment, including NURS FPX 4010 Assessment 2 and for <a href=https://www.etutors.us/nurs-fpx4010-assessment-3/>NURS FPX 4010 Assessment 3</a>. , ensuring you grasp the core concepts and apply them effectively.
Customized Learning for Maximum Impact
We believe in a personalized approach to learning, recognizing that each student has unique strengths and challenges. Our tutors tailor their teaching methods to suit your individual needs, focusing on areas that require additional attention, such as NURS FPX 4010 Assessment 4, to maximize your learning outcome.
Expert Tutors Ready to Assist You
Our team comprises seasoned nursing educators who excel in their respective fields. They bring a wealth of knowledge and practical experience, providing invaluable insights into successfully completing assessments like <a href=https://www.etutors.us/nurs-fpx4010-assessment-1-collaboration/>NURS FPX 4010</a>. . With our experts, you're not just preparing for an exam; you're gearing up for a successful career in nursing.
Achieve Excellence in One Billing Cycle
Our goal is to help you complete your BSN and MSN programs efficiently, without compromising the depth of learning. By focusing on crucial assessments, including <a href=https://www.etutors.us/nurs-fpx-4010-assessment-2//>NURS FPX 4010 Assessment 2</a>. and NURS FPX 4010 Assessment 3, we streamline your study process to ensure you're exam-ready in the shortest possible time.
Comprehensive Support Tailored to Your Needs
From "Write my assessment" to "Online assessment help," we offer a range of services to support your academic journey. Our comprehensive tutoring package includes review sessions, practice questions, and personalized feedback, covering every aspect of the NURS FPX 4010 Assessment 4 and beyond.
<a href=https://www.etutors.us/nurs-fpx-4010/>Partner in Nursing Education</a>.
Choosing our tutoring services for the NURS FPX 4010 series is a step towards academic excellence and professional mastery. With our personalized support, expert guidance, and comprehensive resources, you'll be well-equipped to tackle each assessment with confidence and achieve your goals in the competitive field of nursing.
Elevate your nursing education with our expert tutors. Contact us now to learn how we can help you excel in the NURS FPX 4010 series and advance your career with confidence.
Excel in NURS FPX 4010 Assessments with Our Expert Online Tutoring
Dominate your NURS FPX 4010 assessments with our specialized tutoring services. From Assessment 1 to 4, we provide comprehensive support to complete your nursing program with top grades. Start your success story today!
Introduction to NURS FPX 4010 Series Assessments
The NURS FPX 4010 series represents a significant milestone in the journey of nursing students. It challenges students to apply their knowledge in real-world scenarios, enhancing their clinical reasoning and decision-making skills. Whether you're just starting with NURS FPX 4010 Assessment 1 or gearing up for <a href=https://www.etutors.us/assessment-4-stakeholder-presentation/> NURS FPX 4010 Assessment 4</a>. , each assessment is a step closer to achieving your academic and professional goals in nursing.
Why Our Tutoring Services Are Essential for Your Success
Navigating through the NURS FPX 4010 series requires more than just hard work; it demands strategic study plans and insights from experienced professionals. Our tutoring services are designed to guide you through each assessment, including NURS FPX 4010 Assessment 2 and for <a href=https://www.etutors.us/nurs-fpx4010-assessment-3/>NURS FPX 4010 Assessment 3</a>. , ensuring you grasp the core concepts and apply them effectively.
Customized Learning for Maximum Impact
We believe in a personalized approach to learning, recognizing that each student has unique strengths and challenges. Our tutors tailor their teaching methods to suit your individual needs, focusing on areas that require additional attention, such as NURS FPX 4010 Assessment 4, to maximize your learning outcome.
Expert Tutors Ready to Assist You
Our team comprises seasoned nursing educators who excel in their respective fields. They bring a wealth of knowledge and practical experience, providing invaluable insights into successfully completing assessments like <a href=https://www.etutors.us/nurs-fpx4010-assessment-1-collaboration/>NURS FPX 4010</a>. . With our experts, you're not just preparing for an exam; you're gearing up for a successful career in nursing.
Achieve Excellence in One Billing Cycle
Our goal is to help you complete your BSN and MSN programs efficiently, without compromising the depth of learning. By focusing on crucial assessments, including <a href=https://www.etutors.us/nurs-fpx-4010-assessment-2//>NURS FPX 4010 Assessment 2</a>. and NURS FPX 4010 Assessment 3, we streamline your study process to ensure you're exam-ready in the shortest possible time.
Comprehensive Support Tailored to Your Needs
From "Write my assessment" to "Online assessment help," we offer a range of services to support your academic journey. Our comprehensive tutoring package includes review sessions, practice questions, and personalized feedback, covering every aspect of the NURS FPX 4010 Assessment 4 and beyond.
<a href=https://www.etutors.us/nurs-fpx-4010/>Partner in Nursing Education</a>.
Choosing our tutoring services for the NURS FPX 4010 series is a step towards academic excellence and professional mastery. With our personalized support, expert guidance, and comprehensive resources, you'll be well-equipped to tackle each assessment with confidence and achieve your goals in the competitive field of nursing.
Elevate your nursing education with our expert tutors. Contact us now to learn how we can help you excel in the NURS FPX 4010 series and advance your career with confidence.
Hi
Many thanks Harald for you answer
Yes, Ericsson SGSN MKX uses Classic mode (not ip-sns), and the osmo-pcu is configured with this line: gb-dialect classic.
We took the time to check the SGSN, BSC & network configuration and all seems well configured.
We continue to check and test but no way for now to correct this NS initialization step, and this error: NS_STATUS, Cause PROTOCOL ERROR - unspecified.
So, if you have other ideas of what could be the problem, you're welcome.
In addition, if you know someone who had set up this configuration, we would be very interested by he way of BSC and BTS, SGSN were configured.
Best regards
Jean-Marc
Orange Restricted
____________________________________________________________________________________________________________
Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.
Dear experts,
We are trying to connect an osmocom platform to an Ericsson platform, and are trying to make funtional 2G.
We use a VM for OSMO-BSC, a VM for OSMO-BTS-TRX + OSMO-PCU, and a Raspberry PI (trx-lms)
Concerning the Gb, we connected the OSMO-PCU to an MKX Ericsson, and we have an error at the NS setup step.
The communication between the SGSN Ericsson and the OSMO-PCU seems ok (IP / routing OK)
We hope that the Ericsson MKX SGSN is well configured.
We can see some packets: OSMO-PCU ---> SGSN : NS_RESET, Cause: P&M intervention, NS VCI: 0x1388, NSEI: 5000
and a response from the SGSN: NS_STATUS, Cause PROTOCOL ERROR - unspecified.
What could be the problem ? timers ? ns-vci, nsvc 1, encapsulation,...
Did someone test this: OSMOCOM with an ERICSSON SGSN ?
One point is that the nsvci is only defined on the BSC (not on the SGSN)
Many thanks in advance,
Best regards
Hoping that you could help us
Jean-Marc
-----------------------
BSC CONFIGURATION
-----------------------
bts 0
type osmo-bts
description LimeSDR Based BTS
band GSM900
cell_identity 41023
location_area_code 390
base_station_id_code 63
ms max power 15
cell reselection hysteresis 4
rxlev access min 0
radio-link-timeout 32
channel allocator mode chan-req ascending
channel allocator mode assignment ascending
channel allocator mode handover ascending
channel allocator mode vgcs-vbs ascending
rach tx integer 9
rach max transmission 7
rach max-delay 63
channel-description attach 1
channel-description bs-pa-mfrms 5
channel-description bs-ag-blks-res 1
no nch-position
no access-control-class-ramping
early-classmark-sending forbidden
early-classmark-sending-3g allowed
ipa unit-id 901 0
oml ipa stream-id 255 line 0
neighbor-list mode automatic
codec-support fr
gprs ns timer tns-block 3
gprs ns timer tns-block-retries 3
gprs ns timer tns-reset 3
gprs ns timer tns-reset-retries 3
gprs ns timer tns-test 30
gprs ns timer tns-alive 3
gprs ns timer tns-alive-retries 10
gprs nsei 5000
gprs nsvc 0 nsvci 5000
gprs nsvc 0 local udp port 23001
gprs nsvc 0 remote ip 172.20.168.220
gprs nsvc 0 remote udp port 2157
...
-----------------------
PCU CONFIGURATION
-----------------------
ns
timer tns-block 3
timer tns-block-retries 3
timer tns-reset 3
timer tns-reset-retries 3
timer tns-test 30
timer tns-alive 3
timer tns-alive-retries 10
timer tsns-prov 3
timer tsns-size-retries 3
timer tsns-config-retries 3
timer tsns-procedures-retries 3
pcu
flow-control-interval 10
cs 2
cs max 4
cs threshold 10 33
cs downgrade-threshold 200
cs link-quality-ranges cs1 6 cs2 5 8 cs3 7 13 cs4 12
mcs link-quality-ranges mcs1 6 mcs2 5 8 mcs3 7 13 mcs4 12 15 mcs5 14 17 mcs6 16 18 mcs7 17 20 mcs8 19 24 mcs9 23
mcs max 9
window-size 64 0
queue idle-ack-delay 10
queue codel
Hi all,
Just wanted to share an issue and a quick workaround I found for it in case
anyone else has the same problem. I believe a cmd2 update is causing
pySim-shell to fail. After installing it on a fresh install of Ubuntu
Server 20.04 and getting the following error when I run "python3
pySim-shell -p0":
>Using PC/SC reader interface
>Autodetected card type: sysmoUSIM-SJS1
>AIDs on card:
> USIM: a0000000871002ffffffff8907090000
>Traceback (most recent call last):
> File "pySim-shell.py", line 512, in <module>
> app = PysimApp(card, rs, opts.script)
> File "pySim-shell.py", line 59, in __init__
> super().__init__(persistent_history_file='~/.pysim_shell_history',
allow_cli_args=False, use_ipython=True, auto_load_commands=False,
command_sets=basic_commands, >startup_script=script)
>TypeError: __init__() got an unexpected keyword argument 'use_ipython'
If you run into this you can fix it by uninstalling cmd2 and reinstalling
cmd2 with "pip3 install cmd2==1.5".
Best,
Bryan
Hello everyone,
Could any of you please review the merge request "GSMTAP: check version field" [1]?
The purpose is to check the content of the 'version' field in gsmtap header and act in case of unknown versions.
Cheers,
Mauro
[1] https://gitlab.com/wireshark/wireshark/-/merge_requests/14623
Dear osmocom developpers,
This is just to let you know that the Python library pycrate has a new home
: https://github.com/pycrate-org/pycrate. The packages on Pypi are now
feeded from there. This library can be used in many cases dealing with
mobile signalling.
I wanted to let you know, as even if I am not aware of any osmocom projects
depending on it, some of you may use the library from time to time, or
could have local applications depending on it.
Best Regards
Benoit
Hi all,
I'm currently working on 2G to 3G TrFO voice negotiation. In practice, that
means, to be able to negotiate a set of AMR rates via SDP. And that, in turn,
means that we handle fmtp properly in SDP strings.
SDP is not only used in SIP to the other call leg, but also in the MGCP to the
media gateway.
- So we have a bunch of SDP and fmtp related code in osmo-mgw.git.
- Separately, we have an SDP implementation in osmo-msc.git, because the SDP
code in osmo-mgw.git was too tightly coupled with other code to be able to
reuse it for MNCC->SIP.
For fmtp negotiation, I now want similar things in both mgw and msc.
What I want to do now, is move the SDP implementation from osmo-msc.git to
osmo-mgw.git/libosmo-mgcp-client and make it public API: a common place that
will also enable all other MGCP clients to work with AMR fmtp.
All of this was just the intro =) the question I would like to put out there is
about API design: static or dynamic, and opaque or transparent.
Am I overthinking this? Or would you like to overthink it with me?
== static or dynamic ==
In osmo-msc.git, the SDP structs so far are fully static and self-contained.
The cool thing is that they can be copied around quite easily and there is no
need for passing talloc ctx pointers, no need to worry about ownership,
memleaks and double frees. But it also means that it uses fixed sizes:
- char encoding_name[16],
- char fmtp[256],
- struct sdp_audio_codec codecs[32]
and so on.
Unfortunately, RFC-8866 does not define any limits whatsoever on number of
characters or number of codecs in an SDP message. Quoting:
"although no length limit is given, it is recommended that they be short"
Thanks for nothing! >:(
So for static API design, we need to now pick a good size for every single item
in advance.
When fmtp has max 256 bytes and codec lists have max 32 entries, even an empty
list will use 32 * 256+ bytes: lots of heap allocations.
And the limits are hard: anyone wanting to correctly express more than 32
different codec variants can simply not use this library.
Dynamic seems a much better fit for RFC-8866.
There is practically no limit at all on string length / list length.
Also the caller allocates not one byte more memory than is actually needed.
The argument has been going back and forth in my head for weeks. Static makes
things so much simpler. But what sizes should we dictate. Ok then dynamic. But
these days we have "infinite" memory, the bottleneck is CPU time, so if we can
be static, we are gracious on very cheap real estate (memory) while saving a
lot of the precious stuff (cycles). Ok then static. But with all those AMR
variants that are coming up, I want to at least be able to represent all of
them in one list, so I need at least 64 entries. And let's allow long fmtp
strings, who knows. Then we'll end up with ~20kb of data that every codec list
out there will use up, even if it is empty. Even if it is just a temporary
local variable. Even if it is just dragged along for a rare use case and never
actually needed. Is it really faster to allocate 100 times more memory
statically versus allocating just enough but dynamically?
In the end I decided for dynamic allocation.
When I started adding talloc ctx args, I wanted the API to be simple, so every
single part of the puzzle is now its own dynamic allocation:
struct osmo_sdp_msg {
char *username; // talloc_strdup()
char *session_name; // talloc_strdup()
[...]
struct osmo_sdp_codec_list *codecs; // osmo_sdp_codec_list_alloc()
// llist_head
// -> osmo_sdp_codec_alloc()
// \___ char *encoding_name -> talloc_strdup()
// _ char *fmtp -> talloc_strdup()
// -next-> osmo_sdp_codec_alloc()
// \___ ...
// -next-> osmo_sdp_codec_alloc()
// \___ ...
};
All of this used to be just a single self-contained struct.
You might ask, why is 'codecs', which is just the llist_head, a separate
allocation? Because I want the API to trivially figure out the talloc parent
context to allocate items from:
osmo_codec_list_add(my_list, my_codec);
and not have to worry about the individual code paths' parent context to
allocate new entries from:
osmo_codec_list_add(&my_obj->my_list, my_obj->backpointer.backpointer.ctx, my_codec);
So the only functions with a talloc ctx argument are
osmo_codec_alloc(ctx) and
osmo_codec_list_alloc(ctx)
This style has a tendency to spread:
Now I want to also make osmo-msc's struct codec_filter a dynamic allocation,
because the codec_filter_foo() currently have no ctx argument; they still use
the static SDP structs. When the codec_filter pointer itself is the neat
logical talloc parent of the codec lists it uses, then I don't need to add a
separate ctx arg everywhere now.
Am I taking this too far now?
Am I overthinking it and either way is fine?
== opaque vs transparent ==
I can either have the full struct definition in the .h file = transparent, or I
can hide the struct in the .c file and provide lots of getter and setter
functions = opaque.
Both ways have a major advantage over the other:
- opaque means that we can freely extend the API without any ABI breakage,
ever.
- transparent means that callers can easily define const arrays of data
structures. In my case, I want to keep const lists of const codecs for e.g.
test data in unit tests, for listing known codecs in codec_mapping.c, for
defining default codec configuration.
transparent allows:
const struct osmo_sdp_codec ran_defaults = {
{ .encoding_name = "AMR", .rate = 8000, .fmtp = "octet-align=1;mode-set=0,2,4,7", .payload_type = 112, },
{ .encoding_name = "AMR", .rate = 8000, .fmtp = "octet-align=1;mode-set=0,2,4", .payload_type = 112, },
{ .encoding_name = "AMR", .rate = 8000, .fmtp = "mode-set=0,2,4,7", .payload_type = 112, },
{ .encoding_name = "AMR", .rate = 8000, .fmtp = "mode-set=0,2,4", .payload_type = 112, },
{ .encoding_name = "GSM-EFR", .rate = 8000, .payload_type = 110, },
{ .encoding_name = "GSM", .rate = 8000, .payload_type = 3, },
{ .encoding_name = "GSM-HR-08", .rate = 8000, .payload_type = 111, },
};
int i;
for (i = 0; i < ARRAY_SIZE(ran_defaults); i++)
osmo_sdp_codec_list_add(g_ran_codecs_cfg, &defaults[i])
printf("%s", codec->encoding_name);
if (!strcmp(codec->encoding_name, "AMR"))
printf(":%s", codec->fmtp);
same in opaque:
osmo_sdp_codec_list_add(g_ran_codecs_cfg, "AMR", 8000, "octet-align=1;mode-set=0,2,4,7", 112);
osmo_sdp_codec_list_add(g_ran_codecs_cfg, "AMR", 8000, "octet-align=1;mode-set=0,2,4", 112);
osmo_sdp_codec_list_add(g_ran_codecs_cfg, "AMR", 8000, "mode-set=0,2,4,7", 112);
osmo_sdp_codec_list_add(g_ran_codecs_cfg, "AMR", 8000, "mode-set=0,2,4", 112);
osmo_sdp_codec_list_add(g_ran_codecs_cfg, "GSM-EFR", 8000, NULL, 110);
osmo_sdp_codec_list_add(g_ran_codecs_cfg, "GSM", 8000, NULL, 3);
osmo_sdp_codec_list_add(g_ran_codecs_cfg, "GSM-HR-08", 8000, NULL, 111);
printf("%s", osmo_sdp_codec_get_encoding_name(codec));
if (!strcmp(osmo_sdp_codec_get_encoding_name(codec), "AMR"))
printf(":%s", osmo_sdp_codec_get_ftmp(codec));
The opaque looks alright in comparison, but
- being able to enlist a struct osmo_sdp_codec in a const array is powerful,
allowing the paradigm to replace code complexity by good data structures.
So used in codec_mapping.c in osmo-msc.
- requiring getters and setters for each end every member creates a long list
of API functions: 'get' and 'set' for each orthogonal member; we might be
tempted to "dupe" many llist_*() functions for osmo_sdp_codec_list.
- having to call functions for each end every member makes the code a lot more
noisy.
- it forces all allocation decisions down onto the caller = only using the API
author's favorite dynamic allocation, hello memleaks etc.
IMHO, opaque APIs are often lots of code with very low density of actually
important stuff.
/* This function gets foo. */
struct foo *get_foo(x)
{
return x->foo;
}
This is so plump and boring!!
Currently I am following the transparent way,
and putting 'bool v2;' extension flags for a distant future in the structs'
ends.
But there has been a discussion here that the truly good APIs are opaque.
talloc, libSDL, libsndfile come to mind.
== both ==
Finally, these two aspects are interdependent:
An opaque API *has* to be dynamic.
So far, I am moving from the transparent+static implementation to
transparent+dynamic.
Should I also go the "next" step to opaque+dynamic? I don't really want to...
I've had these considerations many times in my life, and there never seems to
be the one best way.
Thanks for your thoughts!
If you need more code reference for what I am talking about:
old static:
https://cgit.osmocom.org/osmo-msc/tree/include/osmocom/msc/sdp_msg.h?id=1b1…https://cgit.osmocom.org/osmo-msc/tree/src/libmsc/sdp_msg.c?id=1b1a39bea1c5…
new dynamic+transparent:
https://cgit.osmocom.org/osmo-mgw/tree/include/osmocom/sdp?h=neels/sdp&id=2…https://cgit.osmocom.org/osmo-mgw/tree/src/libosmo-sdp?h=neels/sdp&id=24c09…
~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 hope this is the place to ask this, if not I will delete this post. I am trying to run my own 2G network for researching purposes. I am running the following elements:
- osmo-bts-trx (connecting to osmo-trx-uhd driving a USRP B205mini-i)
- osmo-bsc
- osmo-msc
- osmo-hlr
- osmo-mgw
I built all the programs from source on Ubuntu 22.04. Everything is running locally on one machine.
Everything seems to be running OK. I was able to register two different subscribers by IMSI (without providing K and OPc) and assign MSISDN tothem. They can use the default USSD codes for seeing their IMSI and their MSISDN and I can make voice calls between both subscribers. I am mostly using the default config files provided with the installation, the only changes I made to them was to point IPs to 127.0.0.1 to run everything on the same machine.
But when starting osmo-bsc and osmo-msc I get the same error on both:
jonathan@em680:~/tfg/osmo/config$ osmo-msc -c osmo-msc.cfg
DLGLOBAL NOTICE Available via telnet 127.0.0.1 4254 (telnet_interface.c:88)
DLCTRL NOTICE CTRL at 127.0.0.1 4255 (control_if.c:1014)
DLGSUP NOTICE GSUP connecting to 127.0.0.1:4222 (gsup_client.c:74)
DDB NOTICE Init database connection to 'sms.db' using SQLite3 lib version 3.37.2 (db.c:521)
DLMGCP NOTICE MGW(mgw) MGCP client: using endpoint domain '@mgw' (mgcp_client.c:933)
DMSC NOTICE MGW pool with 1 pool members configured, (ignoring MGW configuration in VTY node 'msc'). (msc_main.c:596)
DLSCCP NOTICE OsmoMSC-A: Creating SS7 instance (sccp_user.c:536)
DLSCCP NOTICE OsmoMSC-A: Using SS7 instance 0, pc:0.23.1 (sccp_user.c:563)
DLSCCP NOTICE OsmoMSC-A: Creating AS instance (sccp_user.c:570)
DLSCCP NOTICE OsmoMSC-A: Using AS instance as-clnt-OsmoMSC-A (sccp_user.c:581)
DLSCCP NOTICE OsmoMSC-A: Creating default route (sccp_user.c:587)
DLSCCP NOTICE OsmoMSC-A: No unassociated ASP for m3ua, creating new ASP asp-clnt-OsmoMSC-A (sccp_user.c:626)
DLGLOBAL ERROR Trying to dispatch event 17 to non-existent FSM instance! (osmo_ss7_as.c:118)
DLGLOBAL ERROR backtrace() returned 11 addresses (backtrace.c:42)
DLGLOBAL ERROR /usr/local/lib/libosmocore.so.21(osmo_log_backtrace+0x24) [0x7fc1ddd9fdcc] (backtrace.c:53)
DLGLOBAL ERROR /usr/local/lib/libosmocore.so.21(_osmo_fsm_inst_dispatch+0x144) [0x7fc1dddaade7] (backtrace.c:53)
DLGLOBAL ERROR /usr/local/lib/libosmo-sigtran.so.9(osmo_ss7_as_add_asp+0x1f9) [0x7fc1ddcfb80c] (backtrace.c:53)
DLGLOBAL ERROR /usr/local/lib/libosmo-sigtran.so.9(osmo_sccp_simple_client_on_ss7_id+0xa48) [0x7fc1ddd1dd5e] (backtrace.c:53)
DLGLOBAL ERROR osmo-msc(+0x26fd8) [0x55fa5388bfd8] (backtrace.c:53)
DLGLOBAL ERROR osmo-msc(+0x27043) [0x55fa5388c043] (backtrace.c:53)
DLGLOBAL ERROR osmo-msc(+0x27bed) [0x55fa5388cbed] (backtrace.c:53)
DLGLOBAL ERROR /lib/x86_64-linux-gnu/libc.so.6(+0x29d90) [0x7fc1dd95fd90] (backtrace.c:53)
DLGLOBAL ERROR /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0x80) [0x7fc1dd95fe40] (backtrace.c:53)
DLGLOBAL ERROR osmo-msc(+0x26565) [0x55fa5388b565] (backtrace.c:53)
DLSCCP NOTICE OsmoMSC-A: Using ASP instance asp-clnt-OsmoMSC-A (sccp_user.c:695)
DLSS7 NOTICE 0: Creating SCCP instance (osmo_ss7.c:408)
DSGS NOTICE SGs socket bound to r=NULL<->l=0.0.0.0:29118 (sgs_server.c:186)
DMSC NOTICE A-interface: SCCP user OsmoMSC-A:RI=SSN_PC,PC=(no PC),SSN=BSSAP, cs7-instance 0 ((null)) (msc_main.c:806)
DLINP NOTICE 127.0.0.1:4222 connection done (ipa.c:141)
DLINP NOTICE received ID_GET for unit ID 0/0/0 (ipaccess.c:919)
DLM3UA NOTICE 0: asp-asp-clnt-OsmoMSC-A: Received NOTIFY Type State Change:AS Inactive () (m3ua.c:625)
DLSS7 NOTICE xua_default_lm(asp-clnt-OsmoMSC-A)[0x55fa542bb080]{ACTIVE}: Ignoring primitive M-ASP_ACTIVE.confirm (xua_default_lm_fsm.c:400)
DLM3UA NOTICE 0: asp-asp-clnt-OsmoMSC-A: Received NOTIFY Type State Change:AS Active () (m3ua.c:625)
DLM3UA NOTICE 0: asp-asp-clnt-OsmoMSC-A: Rx DAVA() for 0.23.3/0, (xua_snm.c:403)
...
jonathan@em680:~/tfg/osmo/config$ osmo-bsc -c osmo-bsc.cfg
DLGLOBAL NOTICE Available via telnet 127.0.0.1 4242 (telnet_interface.c:88)
DLINP NOTICE enabling ipaccess BSC mode on 0.0.0.0 with OML 3002 and RSL 3003 TCP ports (ipaccess.c:1055)
DLCTRL NOTICE CTRL at 127.0.0.1 4249 (control_if.c:1014)
DLMGCP NOTICE MGW(mgw) MGCP client: using endpoint domain '@mgw' (mgcp_client.c:933)
DNM NOTICE MGW pool with 1 pool members configured, (ignoring MGW configuration in VTY node 'msc'). (osmo_bsc_main.c:889)
DMSC NOTICE To auto-configure msc 0, creating cs7 instance 0 implicitly (osmo_bsc_sigtran.c:600)
DMSC NOTICE Initializing SCCP connection for A/m3ua on cs7 instance 0 (osmo_bsc_sigtran.c:647)
DLSCCP ERROR SS7 instance 0: no primary point-code set, using default point-code (sccp_user.c:557)
DLSCCP NOTICE A-0-m3ua: Using SS7 instance 0, pc:0.23.3 (sccp_user.c:563)
DLSCCP NOTICE A-0-m3ua: Creating AS instance (sccp_user.c:570)
DLSCCP NOTICE A-0-m3ua: Using AS instance as-clnt-A-0-m3ua (sccp_user.c:581)
DLSCCP NOTICE A-0-m3ua: Creating default route (sccp_user.c:587)
DLSCCP NOTICE A-0-m3ua: No unassociated ASP for m3ua, creating new ASP asp-clnt-A-0-m3ua (sccp_user.c:626)
DLGLOBAL ERROR Trying to dispatch event 17 to non-existent FSM instance! (osmo_ss7_as.c:118)
DLGLOBAL ERROR backtrace() returned 10 addresses (backtrace.c:42)
DLGLOBAL ERROR /usr/local/lib/libosmocore.so.21(osmo_log_backtrace+0x24) [0x7f990ff0ddcc] (backtrace.c:53)
DLGLOBAL ERROR /usr/local/lib/libosmocore.so.21(_osmo_fsm_inst_dispatch+0x144) [0x7f990ff18de7] (backtrace.c:53)
DLGLOBAL ERROR /usr/local/lib/libosmo-sigtran.so.9(osmo_ss7_as_add_asp+0x1f9) [0x7f990fe9380c] (backtrace.c:53)
DLGLOBAL ERROR /usr/local/lib/libosmo-sigtran.so.9(osmo_sccp_simple_client_on_ss7_id+0xa48) [0x7f990feb5d5e] (backtrace.c:53)
DLGLOBAL ERROR osmo-bsc(+0x144035) [0x556b310d7035] (backtrace.c:53)
DLGLOBAL ERROR osmo-bsc(+0x2aef0) [0x556b30fbdef0] (backtrace.c:53)
DLGLOBAL ERROR /lib/x86_64-linux-gnu/libc.so.6(+0x29d90) [0x7f990fc55d90] (backtrace.c:53)
DLGLOBAL ERROR /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0x80) [0x7f990fc55e40] (backtrace.c:53)
DLGLOBAL ERROR osmo-bsc(+0x28265) [0x556b30fbb265] (backtrace.c:53)
DLSCCP NOTICE A-0-m3ua: Using ASP instance asp-clnt-A-0-m3ua (sccp_user.c:695)
DLSS7 NOTICE 0: Creating SCCP instance (osmo_ss7.c:408)
DMSC NOTICE A-0-m3ua msc-0: local (BSC) SCCP address: RI=SSN_PC,PC=0.23.3,SSN=BSSAP (osmo_bsc_sigtran.c:703)
DMSC NOTICE A-0-m3ua msc-0: remote (MSC) SCCP address: RI=SSN_PC,PC=0.23.1,SSN=BSSAP (osmo_bsc_sigtran.c:705)
DMSC NOTICE A-0-m3ua msc-0: binding SCCP user (osmo_bsc_sigtran.c:710)
DLSS7 ERROR XUA_AS(as-clnt-A-0-m3ua)[0x556b31b42cc0]{AS_INACTIVE}: Event AS-TRANSFER.req not permitted (m3ua.c:510)
DLM3UA NOTICE 0: asp-asp-clnt-A-0-m3ua: Received NOTIFY Type State Change:AS Inactive () (m3ua.c:625)
DLSS7 NOTICE xua_default_lm(asp-clnt-A-0-m3ua)[0x556b31b445c0]{ACTIVE}: Ignoring primitive M-ASP_ACTIVE.confirm (xua_default_lm_fsm.c:400)
DLM3UA NOTICE 0: asp-asp-clnt-A-0-m3ua: Received NOTIFY Type State Change:AS Active () (m3ua.c:625)
DMSC NOTICE RESET ACK from MSC: RI=SSN_PC,PC=0.23.1,SSN=BSSAP (osmo_bsc_bssap.c:84)
DRESET NOTICE bssmap_reset(msc-0)[0x556b31b45790]{CONNECTED}: link up (bssmap_reset.c:83)
DMSC NOTICE (msc0) BSSMAP association is up (a_reset.c:45)
DLINP NOTICE 0.0.0.0:3002 accept()ed new link from 127.0.0.1:38477 (ipa.c:318)
DLINP NOTICE Keepalive is set: 0 (ipaccess.c:612)
DNM NOTICE OC=BTS(01) INST=(00,ff,ff): Get Attributes Response: feature 'GPRS' is supported (abis_nm.c:599)
DNM NOTICE OC=BTS(01) INST=(00,ff,ff): Get Attributes Response: feature 'EGPRS' is supported (abis_nm.c:599)
DNM NOTICE OC=BTS(01) INST=(00,ff,ff): Get Attributes Response: feature 'HOPPING' is supported (abis_nm.c:599)
DNM NOTICE OC=BTS(01) INST=(00,ff,ff): Get Attributes Response: feature 'MULTI_TSC' is supported (abis_nm.c:599)
DNM NOTICE OC=BTS(01) INST=(00,ff,ff): Get Attributes Response: feature 'OML_ALERTS' is supported (abis_nm.c:599)
DNM NOTICE OC=BTS(01) INST=(00,ff,ff): Get Attributes Response: feature 'CBCH' is supported (abis_nm.c:599)
DNM NOTICE OC=BTS(01) INST=(00,ff,ff): Get Attributes Response: feature 'SPEECH_F_V1' is supported (abis_nm.c:599)
DNM NOTICE OC=BTS(01) INST=(00,ff,ff): Get Attributes Response: feature 'SPEECH_H_V1' is supported (abis_nm.c:599)
DNM NOTICE OC=BTS(01) INST=(00,ff,ff): Get Attributes Response: feature 'SPEECH_F_EFR' is supported (abis_nm.c:599)
DNM NOTICE OC=BTS(01) INST=(00,ff,ff): Get Attributes Response: feature 'SPEECH_F_AMR' is supported (abis_nm.c:599)
DNM NOTICE OC=BTS(01) INST=(00,ff,ff): Get Attributes Response: feature 'SPEECH_H_AMR' is supported (abis_nm.c:599)
DNM NOTICE OC=BTS(01) INST=(00,ff,ff): Get Attributes Response: feature 'ETWS_PN' is supported (abis_nm.c:599)
DNM NOTICE OC=BTS(01) INST=(00,ff,ff): Get Attributes Response: feature 'PAGING_COORDINATION' is supported (abis_nm.c:599)
DNM NOTICE OC=BTS(01) INST=(00,ff,ff): Get Attributes Response: feature 'IPV6_NSVC' is supported (abis_nm.c:599)
DNM NOTICE OC=BTS(01) INST=(00,ff,ff): Get Attributes Response: feature 'ACCH_REP' is supported (abis_nm.c:599)
DNM NOTICE OC=BTS(01) INST=(00,ff,ff): Get Attributes Response: feature 'CCN' is supported (abis_nm.c:599)
DNM NOTICE OC=BTS(01) INST=(00,ff,ff): Get Attributes Response: feature 'VAMOS' is supported (abis_nm.c:599)
DNM NOTICE OC=BTS(01) INST=(00,ff,ff): Get Attributes Response: feature 'ABIS_OSMO_PCU' is supported (abis_nm.c:599)
DNM NOTICE OC=BTS(01) INST=(00,ff,ff): Get Attributes Response: feature 'BCCH_PWR_RED' is supported (abis_nm.c:599)
DNM NOTICE OC=BTS(01) INST=(00,ff,ff): Get Attributes Response: feature 'DYN_TS_SDCCH8' is supported (abis_nm.c:599)
DNM NOTICE OC=BTS(01) INST=(00,ff,ff): Get Attributes Response: feature 'ACCH_TEMP_OVP' is supported (abis_nm.c:599)
DNM NOTICE OC=BTS(01) INST=(00,ff,ff): Get Attributes Response: feature 'VBS' is supported (abis_nm.c:599)
DNM NOTICE OC=BTS(01) INST=(00,ff,ff): Get Attributes Response: feature 'VGCS' is supported (abis_nm.c:599)
DNM NOTICE OC=BTS(01) INST=(00,ff,ff): ARI reported sw[0/2]: osmobts is 1.7.0.54-82a2 (abis_nm.c:652)
DNM NOTICE OC=BTS(01) INST=(00,ff,ff): Reported variant: osmo-bts-trx (abis_nm.c:534)
DNM ERROR OC=RADIO-CARRIER(02) INST=(00,00,ff): Attribute SW Configuration is unreported (abis_nm.c:557)
DNM ERROR OC=BASEBAND-TRANSCEIVER(04) INST=(00,00,ff): Attribute Manufacturer Dependent State is unreported (abis_nm.c:557)
DNM NOTICE OC=BASEBAND-TRANSCEIVER(04) INST=(00,00,ff): ARI reported sw[0/1]: TRX_PHY_VERSION is Unknown (abis_nm.c:652)
DLINP NOTICE 0.0.0.0:3003 accept()ed new link from 127.0.0.1:37491 (ipa.c:318)
DLINP NOTICE Keepalive is set: 0 (ipaccess.c:612)
...
Is it something I should worry about?
Thanks
Empower your journey in customer relationship management (CRM) with our comprehensive support services. Our team specializes in providing expert guidance and assistance tailored to your CRM assignment needs. From analyzing customer data to implementing effective strategies, our CRM Assignment Help ensures you're equipped with the knowledge and skills to excel. Trust us to be your partner in success as you navigate the complexities. Let our expertise be at your fingertips, guiding you toward academic achievement and more visit our website Now.https://reportwritinghelp.com/assignment/consumer-behavior-assignment-h…
Hi,
I had a problem placing MO GSM calls from a Siemens S11E: The calls
were dropped immediately; Osmo-MSC reports "Cannot compose Channel
Type from bearer capabilities"
After investigating the SETUP request from the S11E, the phone does
not use octet 3a (no extension bit set in IE 3). Wireshark decodes the
radio channel requirement as "Full rate support only MS/fullrate
speech version 1 supported", so I added a condition to the gsm48_ie.c
function of libosmocore to include at least GSM FR in the list of
available speech_ver in case octet 3 has no extension.
Attached to this message are the Abis-IP PCAP traces of MO calls, and
the patch for gsm48_ie.c.
Regards,
Lennart
Hi,
My name is Brackley Cassinga Form DRC, we run a community network called
pamoja net where we offer gsm services using osmocom open source software
and OC Base station.
Recently I have tried to install another base station as the same installed
but I could not find any resource guiding through all the steps to take to
run NIB on a base station.
I'm currently running Ubuntu and I will appreciate if you could guide me on
the installation of BSC,hlr,MSC , in order to run a basic gsm network.
Thank you. Regards
--
*Ir Brackley heshima Casinga **Pacifique*
*CEO and Founder of kwanzatechnologie*
KwanzaTechnologies ,GlobalElectronics
+243977265291 | +243977265291 | Pcassinga(a)gmail.com/
brackley(a)ensemblepourladifference.org
www.kwantechnologies.jimdosite.com <http://www.kwantechnologies.com/> |
Skype: Brackley cassinga <https://webapp.wisestamp.com/#>
Av Semliki N 43
Hello Osmocom community,
I have a contact in Australia who reached out to me with a desire to
set up his own personal GSM/2G network. Australia is a nasty anti-
retrotechnology country, even worse than USA, where all official 2G
networks were shut down back in 2018. As most of you know, I run my
own pirate-radio GSM cell in USA, and I tried reaching out to other
Vintage Mobile Phone communities, promoting the idea that people can
run their own networks using Osmocom CNI plus suitable hw plus my
ThemWi add-ons for outside PSTN interconnection, and offering to teach
others how to copy what I am doing. When I made the latter offer to
the community, I was expecting people from other parts of USA - but
right now the only person with an active interest is in Australia.
I am currently teaching my Australian contact the "pure physics"
aspects of running your own GSM network: what frequencies are usable
for GSM, dB and dBm units of measurements, how to use a handheld
spectrum analyzer etc. These are all "physics" topics that are
independent of where one happens to be geopolitically. But there is
another key aspect which I feel he needs to know, but which I won't be
able to teach him: country-specific spectrum-political aspects.
I know the spectrum-political landscape in USA: how FCC has divvied up
PCS1900 and GSM850 bands (or B2 & B5 in modern parlance) between
carriers, which spots in these bands are completely unused and thus
reasonably safe to squat in, and how one can exploit the overlap
between EGSM900 DL and USA ISM band to run a BTS with low probability
of getting into trouble. But I have absolutely no such knowledge for
any other country in the world, let alone one as remote and foreign to
me as Australia.
Is there anyone in this community who is based in Australia and knows
this topic? I would greatly appreciate any advice from an AU-knowing
person that I could pass to my GSM-enthusiast contact: out of the 4
frequency bands that are in-principle suitable for GSM, which is the
safest one to squat in for a pirate operator, and which ARFCN range(s)?
Obviously I will teach my contact that he needs to pick a spot where
the spectrum analyzer shows nothing but noise floor, but just because
a spot "looks blank" on an SA doesn't mean that the spot is safe to
squat on, without knowing anything at all about the country's
spectrum-political landscape...
TIA,
Mychaela
Dear all
We have a questions for you, experts.
Has anyone managed to get Osmocom with limesdr Mini 2.0 ? (USB)
We have stability issues, so if someone has tried and can share configuration for osmocom-bsc and osmocom-trx-lms, it woud be great !
Many thanks in advance,
Best regards
Good Morning,
My name is Tanya and was referred to this email regarding open source
involvement. I am genuinely interested in sysmocom and am open to exploring
various ways I can support your team. If there are any upcoming
opportunities or specific areas where my skills could be of value in a
volunteer capacity, I would be grateful for the chance to discuss them
further.
Please take a look at my GitHub profile: https://github.com/wonntann
Thank you again for your consideration. I look forward to the possibility
of contributing to sysmocom and will continue to follow your updates.
Best,
Tanya
Hello Osmocom community,
I have a question about TCP port number assignment for programs using
libosmovty. Every Osmo-official server program gets official port
number assignments listed in the wiki, in PDF manuals etc - so far, so
good. But what about non-Osmo-official 3rd-party programs that wish
to use common Osmocom libraries, including the vty facility? Suppose
that an operator of an Osmocom-based cellular network needs to develop
some additional programs to satisfy some operational need, and some of
these additional programs are long-lived server processes for which an
Osmocom-style vty interface would be very useful. But implementing
such a telnet vty i/f requires a TCP port number...
Has anyone thought about designating an official range of TCP port
numbers which would be recommended for vty/ctrl/etc ports of processes
that use Osmocom libraries and extend Osmocom CNI in various ways, but
aren't official Osmocom projects?
M~
Hi all!
[cross-post to make sure everyone knows about it, please follow-up-to
the osmodevcon(a)lists.osmocom.org mailing list for further discussion]
As I mentioned several times at different occasions, I really think we
should put together a OsmoDevCon again. In case you don't know what that
is, please see https://osmocom.org/projects/osmo-dev-con/wiki/OsmoDevCon
We should have restarted already in 2023, but I really was too busy and
it was a somewhat difficult year for me at times, sorry.
Date
----
In terms of timing, I am thinking about "after April but before the main
summer holiday season (June-August)". That leaves May.
Given that May has the whitsunday weekend as well as GPN
(Gulaschprogrammiernacht, a CCC event that will likely conflict
of interest with some people interested at attending OsmoDevCon), I'm
currently considering the following candidate dates:
* May 3 to 6
* May 24 to 27
This is as usual a friday-to-monday timeframe, allowing people who don't
work professionally on osmocom to attend just the two weekendd days,
while others can attend the full 4 days.
Venue
-----
In terms of venue, I'm hoping we can move to a slightly different
arrangement where the whole group stays together for the whole duration
of the event - as opposed to everyone staying at different hotels and
having to commute from hotel to venue and back every day. So something
like a hotel with a sufficiently large meeting room, hotels and catering
all day. And all of that ideally at a nice venue with some kind of park /
outdoor area, not downtown at the city center. Yes, that will obviously
come at a higher price tag than we're used to - but I'm confident we can
get that covered between sponsors and sysmocom.
Do you guys think this is a good idea? Or would you prefer the
traditional ad-hoc approach at IN-Berlin?
Regards,
Harald
--
- Harald Welte <laforge(a)gnumonks.org> https://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
Hi all,
does anyone have feedback on this dubious libosmo-mgcp-devel we publish in our
osmo-mgw.spec?
More detail in https://osmocom.org/issues/6300
Thanks!
~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 all,
I'd like to drop the 'sdp audio fmtp-extra ...' cfg option from osmo-mgw.
If this option needs to stay, I'd like to hear about that.
There is more context in https://osmocom.org/issues/6313
Thanks!
~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
Dear mailing list,
I'm looking into releasing a new osmo-pcu version to finish up OS#6198,
and to have a release with the fix for OS#6191. Apparently that fix
requires a new PCUIF version. And osmo-pcu master now has a check that
requires the *exact* PCUIF version:
https://cgit.osmocom.org/osmo-pcu/commit/?id=46140948d9800bca6a7b4299f08b25…
pcu_i1_if.cpp:
} else if (info_ind->version != PCU_IF_VERSION) {
fprintf(stderr, "PCU interface version number of BTS/BSC (%u) is
different (%u).\nPlease use a BTS/BSC with a compatble interface!\n",
info_ind->version, PCU_IF_VERSION);
exit(-1);
}
So we will need to create releases of osmo-bts and osmo-bsc with the new
PCUIF version as well. As this is a breaking change, I think we should
bump the major version, and that in turn makes more sense with tagging
current master instead of cherry picking a few patches.
So I propose to do the following:
* tag a new libosmocore patch release with the few patches required for
osmo-pcu, osmo-bts and osmo-bsc master (see their TODO-RELEASE).
* tag major releases of osmo-pcu, osmo-bts and osmo-bsc from their
current master
Does that make sense?
Best regards,
Oliver
--
- Oliver Smith <osmith(a)sysmocom.de> https://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
Hi Nick,
I just read your post
https://nickvsnetworking.com/tales-from-the-trenches-mode-set-in-amr/
and just when it really gets interesting, the article ends =)
I'm working at osmocom.org and am currently figuring out how TH we are supposed
to communicate the AMR mode sets across 2G + 3G mobile networking on the one
side and SDP/SIP+RTP on the other side.
My plan was to do it like choosing codecs: One side sends all its capabilities,
the other responds with the own capabilites removing unsupported entries.
Now I read in your post that mode-set is take-it-or-leave-it.
The interesting part is the practical problem that arises from it: e.g. on a 2G
mobile network, i'm allowed to choose up to four AMR rates, no more. When on a
half-rate channel, then specific rates (12k2, 10k2) are not supported.
Otherwise I can tell the 2G BTS and the phone to pick various mode-set
combinations. So why not send a full mode-set of 0,1,2,3,4,5,6,7 and the other
call leg can then say "i'll pick these four", or something like that.
With your spec references, it means that now I need to pick specific mode-set
combinations in advance, and assign a different payload type number to each of
them.
The extreme example would be:
a rtpmap:110 AMR/8000/1
a fmtp:110 mode-set=0
a rtpmap:111 AMR/8000/1
a fmtp:111 mode-set=1
a rtpmap:112 AMR/8000/1
a fmtp:112 mode-set=2
...
a fmtp:117 mode-set=7
a fmtp:118 mode-set=0,1
a fmtp:119 mode-set=0,2
a fmtp:120 mode-set=0,3
a fmtp:121 mode-set=0,4
...
a fmtp:99999998 mode-set=0,1,2,3,4,5,6
a fmtp:99999999 mode-set=0,1,2,3,4,5,6,7
Obviously nonsense, but you catch my drift.
So what is the solution then?
In 2G GSM I have half-rate and full-rate channels; AMR-FR and AMR-HR should be
able to interop. So if one FR side offers mode-set=0,2,4,7 then the HR side may
return mode-set=0,2,4 to leave only HR compatible rates. Well, no.
If not that, then:
I probably need to create one RTPMAP entry for full-rate compatible operation
and another entry for half-rate compatible operation.
111:mode-set=0,2,4,7 112:mode-set=0,2,4
Also some hardware supports only 12k2, so then I need to add an extra entry for
only 12k2. But I have to so not only on the side that has the 12k2 limit, but
on the side that wants to interop with it! Because if the peer doesn't offer a
single "mode-set=7", then the only-12k2 supporting side must reject the entire
call.
111:mode-set=0,2,4,7 112:mode-set=0,2,4 113:mode-set=7
The question is, were the specs in good intentions, but in practicality it is
mayhem of exploding nr of permutations, and maybe your MGW made a sane choice
of not diving into this madness?
Thanks for your feedback on this!
~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 all,
I have a request for comments regarding osmo-mgw,
particularly the fmtp for AMR octet-align mode and the two GSM-HR variants.
We are currently reviewing/writing patches to allow flexible use of fmtp in
libosmo-mgcp-client. The plan is to be able to indicate which GSM-HR variant
(RFC5993 or 3GPP TS 101.318) is in use.
Also we are fixing the ability to indicate AMR mode (octet-align=1 vs 0)
properly, per payload type nr instead of once per SDP body.
Example of MGCP with SDP, showing two codecs, AMR as 112 and GSM-HR as 111,
each with a fmtp as I'm discussing now:
CRCX 2 7@mgw MGCP 1.0
C: 2
v=0
c=IN IP4 123.12.12.123
m=audio 5904 RTP/AVP 112 111
a=rtpmap:112 AMR/8000/1
a=fmtp:112 octet-align=1
a=rtpmap:111 GSM-HR-08/8000/1
a=fmtp:111 gsm-hr-format=3gpp-ts-101.318
a=ptime:20
That means that each MGW client tells osmo-mgw exactly what AMR and HR formats
to send to the RTP peer, and also restricts exactly which format to expect from
that RTP peer. So BSC and MSC need to know things about BTS and BSS, in advance:
- the BSC needs configured knowledge of each BTS's octet-align and gsm-hr-format.
- the MSC needs configured knowledge of what the BSC will do.
- what if there are divergent formats in different BTS of a BSS, does MSC need to know that too?
There is certainly no way to indicate octet-align nor HR variant in standard A interface proto.
So far so complex, BUT:
In practical testing, I see from logging that osmo-mgw is already quite capable
of detecting which AMR octet-align mode and which HR format is actually
arriving from the RTP peer (from the BTS...).
I see this log line:
DRTP NOTICE (rtpbridge/1@bsc0 I:FA1F785D) rx_rtp(44 bytes): Expected RTP AMR octet-aligned=1 but got octet-aligned=0. check the config of your call-agent! (mgcp_network.c:1525)
And I'm thinking, where is the problem, just do what you need to do; all the
information it needs to do the right thing is already available to osmo-mgw.
So why even the need to configure {AMR octet-align|GSM-HR mode} in SDP?
Idea:
- the first RTP packet arriving is examined, and from then on the peer is
known to use that format.
- when later, an RTP needs to be forwarded back to that peer, we convert to the
format that the peer uses, iff it is necessary.
- for sanity we could hold back forwarding RTP before the details of the
recipient are known, i.e. wait for each peer to send the first RTP to MGW.
Example for an RTP stream in GSM-HR format:
A MGW B
|--HR(3gpp)-->|--x drop | (don't know B's preference yet, cannot send)
| [3gpp]| | (now know A uses the 3gpp format)
| |<--HR(rfc)--|
| |[rfc] | (now know B uses the RFC format)
| [convert] |
|<--HR(3gpp)--| |
|--HR(3gpp)-->|--HR(rfc)-->|
|<--HR(3gpp)--|<--HR(rfc)--|
There is an important difference between AMR octet-align and GSM-HR:
- 'octet-align=(0|1)' is a defined standard fmtp that already exists, and it
may be necessary to forward this accurately to PBX. We may not get around
having to explicitly set this.
- GSM-HR format is a new fmtp we are inventing now. So the idea is most
relevant here: if we can always just autodetect the right thing to do, then
why introduce a non-standard fmtp? (plus all the MGW client vty cfg needed)
What do you think?
Thanks!
~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
Hello various Osmocom mailing lists,
the official Osmocom binary packages will not be built anymore for the
following distributions starting at 2024-02:
* Raspberry Pi OS 64-bit (use Debian_12 etc. instead)
* Ubuntu 23.04 (Ubuntu 23.10 and LTS 20.04/22.04 feeds are available)
* openSUSE 15.4 (openSUSE Tumbleweed feed is available)
* Debian Testing (Debian Unstable and 12-10 feeds are available)
For Raspberry Pi OS 64-bit users, make sure to adjust your
/etc/apt/sources.list.d as described here to switch to a Debian
aarch64 feed:
https://osmocom.org/projects/cellular-infrastructure/wiki/Latest_Builds
See the new linux distributions article for information on how long we
plan to keep building packages for each distribution:
https://osmocom.org/projects/cellular-infrastructure/wiki/Linux_distributio…
Let me know if you have questions.
Best regards,
Oliver
--
- Oliver Smith <osmith(a)sysmocom.de> https://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
Hi
We set up a full Osmocom platform, with an Ettus USRP for SDR. All works
well. Congratulations to Osmocom developers !
But now we want to use "real" nodes concerning MSC, MGW, HLR, SGSN & GGSN.
Do you think it is possible ?
Concerning the BSC-MSC association, do we need to use an SG (osmo-stp) ? or
could we establish a Point To Point BSC-MSC ? SUA ?
Concerning MGW, is there a way to use our MGW ? At this time, with Osmocom
corposants, we can see RTP traffic between BTS-TRX and MGW, and some MGCP
traffic between (BSC - local MGW) and MGW, and some MGCP traffic between
osmo-MGW and osmo-MSC. Is there a way to have a "more standard"
architecture: no traffic between BTS and MGW, and MGW controlled by MSC ? Do
we have to more study TRAU, AoIP ?
Concerning the Gb, do you think that it 'll work if we configure the Gb on a
real SGSN connected to the osmo-pcu, hosted on the osmo-bts-trx?
Many thanks in advance,
Best regards
Jean-Marc
Orange Restricted
It is my pleasure to inform that I have a WIP patch for OsmoMSC that allows,
for the first time, full MO<->MT codecs negotiation to flexibly achieve TFO
(Transcoding-Free Operation).
It would be great if OsmoMSC users could give the patch a spin (in a setup that
is allowed to fail because of the patch) and see if 2G calls now adjust the MO
call leg to MT's codecs limitations for you. Looking forward to feedback!
This task was idling on my list because I assumed it would be a big effort, but
now I realized that it is actually simple, not even a new FSM state required.
So I could no longer resist to finally complete this long long quest.
The result is this WIP patch:
https://gerrit.osmocom.org/c/osmo-msc/+/35051
Related patch series, uncluding ttcn3 test:
https://gerrit.osmocom.org/q/topic:reass
This patch requires full SDP on MNCC, so if using osmo-sip-connector, it should
be current master -- the relevant patch was merged but is not released yet:
https://gerrit.osmocom.org/c/osmo-sip-connector/+/16222
Before this patch, MO was eternally stuck on the initially assigned codec. Now
we adjust MO's codec if MT needs it. (MT already intelligently chooses codecs
before this patch.)
For example, if MO is AMR capable and MT is not,
- the MO side will start out with assigning an AMR codec (not matching).
- Once MT responds (MNCC_ALERT_REQ), the MO side notices that MT does not
support the assigned codec. It sends another Assignment Command to the BSC,
offering only the codecs that MT supports.
- If MO has at least one matching codec (say GSM-FR), the result is a TFO call
using a matching codec.
We still need to check:
- does OsmoBSC play along nicely with the re-assignment (it should AFAICT).
- effects on MGCP: there may now be more codecs than just the assigned one in
the MGCP towards the MGW. See if that checks out.
- effects on 3G: make sure the feature doesn't confuse IuUP handling.
The patch passes all MSC_Tests.ttcn for me (but that doesn't necessarily imply
proper codecs choices, the tests are not very strict there it seems).
~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
Dear Osmocom community,
we're happy to announce the next incarnation of OsmoDevCall.
when:
(today) November 15, 2023 at 20:00 CET
where:
https://osmocom.org/OsmoDevCall (Big Blue Button)
This time, @falconia will be presenting on
Calypso chipset history and development boards, from TI to FreeCalypso
This meeting will have the following schedule:
20:00 meet + greet
20:10 topic as outlined above
21:00 unstructured supplementary social event [*]
Attendance is free of charge and open to anyone with an interest
in Osmocom or open source cellular technologies.
More information about OsmoDevCall, including the schedule
for further upcoming events can be found at
https://osmocom.org/projects/osmo-dev-con/wiki/OsmoDevCall
Looking forward to meeting you soon!
Best regards,
Harald
[*] this is how we started to call the "unstructured" part of osmocom
developer conferences in the past, basically where anyone can talk about
anything, no formal schedule or structure.
--
- Harald Welte <laforge(a)osmocom.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
Dear List,
I tried to set up Osmo-CBC with a Nokia MetroSite BTS according to the
wiki. But every time the CBSP clinet of the BSC connects to the CBC
server, the BSC log indicates:
DCBS cbsp_link.c:150 CBSP Client connected to CBC:
(r=127.0.0.1:48049<->l=127.0.0.1:46133)
DCBS smscb.c:805 (bts=0) Rx CBSP RESET: clearing all state; disabling broadcast
Same time on the CBC:
<0002> cbsp_link.c:265 New CBSP link connection from 127.0.0.1:46133
<0002> cbsp_link_fsm.c:181 local-bsc: RESTART (CBS) but re-sending not
implemented yet
The BTS is configured with CCCH+SDCCH4+CBCH, and these are the
relevant sections:
osmo-cbc.cfg:
cbc
unknown-peers reject
ecbe
local-ip 127.0.0.1
local-port 12345
cbsp
local-ip 127.0.0.1
local-port 48049
sbcap
local-ip 127.0.0.1
local-port 29168
peer cbsp local-bsc
mode server
remote-port 46133
remote-ip 127.0.0.1
osmo-bsc.cfg:
cbc
mode client
client
remote-ip 127.0.0.1
local-ip 127.0.0.1
local-port 46133
Every other CS service is working fine on the BTS.
Is there anything else I might have missed?
Regards,
Csaba
Dear Osmocom community,
we're happy to announce the next incarnation of OsmoDevCall.
when:
September 20, 2023 at 20:00 CEST
where:
https://osmocom.org/OsmoDevCall (Big Blue Button)
This time, @falconia will be presenting on
Themyscira Wireless: a case study in interconnecting an Osmocom GSM network to USA PSTN
This meeting will have the following schedule:
20:00 meet + greet
20:10 topic as outlined above
21:00 unstructured supplementary social event [*]
Attendance is free of charge and open to anyone with an interest
in Osmocom or open source cellular technologies.
More information about OsmoDevCall, including the schedule
for further upcoming events can be found at
https://osmocom.org/projects/osmo-dev-con/wiki/OsmoDevCall
Looking forward to meeting you soon!
Best regards,
Harald
[*] this is how we started to call the "unstructured" part of osmocom
developer conferences in the past, basically where anyone can talk about
anything, no formal schedule or structure.
--
- Harald Welte <laforge(a)osmocom.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
I just noticed that a release was made,
ignoring this remark in osmo-msc's TODO-RELEASE:
MNCC osmo-sip-connector should do full SDP via MNCC and be released at the same time as the next osmo-msc, ask neels, thanks
https://gerrit.osmocom.org/c/osmo-msc/+/34386
There is no full SDP support in current osmo-sip-connector.
In fact the patch for that is just now becoming ready for merge:
https://gerrit.osmocom.org/c/osmo-sip-connector/+/16222
I guess we should get the sipcon patch merged, and follow up with another
sipcon release.
~N
Dear list,
I built an icE1USB device so I can provide stable clock to my legacy Nokia BTS.
I have not found any information about how to bring up a completely
empty device, so I just took the icE1usb-202210-5890f3e4.bin file and
flashed it to the SPI flash, yet the device is not booting. Maybe
something else is missing (like a boot block), or the binary has to be
flashed with an offset? The device takes 80mA in this state, USB
device is not recognized on the host.
Thanks!
Hi all,
I am happy to announce that a new version 202309 of the Osmocom CNI
(Cellular Network Infrastructure) software has been released this week.
For further information, please visit: https://osmocom.org/news/220
Regards,
Pau
--
- Pau Espin Pedrol <pespin(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
Hi Vadim,
You are probably correct, in the mean time I recompiled everything, so
it works now, but most likely the *-dev packages were missing. Thanks
for pointing that out!
Another question I have is about displaying the Osmo-BSC logs:
I am working on a museum setup and would be nice to show the BSC log
output on the screen when there is activity. I wonder if there is a
practical way to do that without altering the systemd part.
Regards,
Csaba
Dear List,
I face the problem that when I am in general using the nightly builds
on Ubuntu 20.04, but I want to compile a specific project (Osmo-BSC in
this case), the configure script is not able to find the Osmocom
libraries which are already installed and available.
Output of the configure script:
configure: error: Package requirements (libosmocore >= 1.8.0) were not met:
Package 'libosmocore', required by 'virtual:world', not found
Libosmocore is available on the system:
root@openbsc:~/osmo-bsc_bootstrap_mod/osmo-bsc# ldconfig -v|grep libosmocore
/sbin/ldconfig.real: Can't stat /usr/local/lib/i386-linux-gnu: No such
file or directory
/sbin/ldconfig.real: Path `/usr/lib/i386-linux-gnu' given more than once
/sbin/ldconfig.real: Can't stat /usr/local/lib/i686-linux-gnu: No such
file or directory
/sbin/ldconfig.real: Can't stat /lib/i686-linux-gnu: No such file or directory
/sbin/ldconfig.real: Can't stat /usr/lib/i686-linux-gnu: No such file
or directory
/sbin/ldconfig.real: Can't stat /usr/local/lib/x86_64-linux-gnu: No
such file or directory
/sbin/ldconfig.real: Path `/usr/lib/x86_64-linux-gnu' given more than once
/sbin/ldconfig.real: Path `/lib/x86_64-linux-gnu' given more than once
/sbin/ldconfig.real: Path `/usr/lib/x86_64-linux-gnu' given more than once
/sbin/ldconfig.real: Path `/usr/lib' given more than once
/sbin/ldconfig.real: /lib/i386-linux-gnu/ld-2.31.so is the dynamic
linker, ignoring
/sbin/ldconfig.real: /lib/x86_64-linux-gnu/ld-2.31.so is the dynamic
linker, ignoring
libosmocore.so.20 -> libosmocore.so.20.0.0
Can someone help me with what kind of flags do I need to provide to
the configure script and how?
Much appreciate the help!
Regards,
Csaba
Hi all-
I'm trying to get a GPRS network set up to serve a few old phones I have, but I don't really need anything beyond that. There's a daunting array of choices and scant documentation out there, so I just thought I'd ask, does anyone have any recommendations for what the least expensive hardware solution to implement GPRS would be? In particular though, I'd like to go with commercial non-SDR hardware, and I'd rather spend a tiny bit more if it would get something smaller... Are there any good GPRS-capable femtocells that work well with the Osmo stack?
I'm looking at some old Ericsson gear but hoping for something more compact.
Thanks in advance!
-Ben
Dear Osmocom community,
Can I build my own GMR satellite/base station and core network based on open-source
software (e.g. osmo-bts) and SDR?
GMR is mentioned in the Osmo-bts user manual, but it doesn't say if it is implemented
and how to configure it.
If Osmo-bts doesn't work, is there any other project to build my own GMR base station
and establish a connection with a GMR device?
Best regards,
Wei
Hello. I am working on setting up an osmoTRX based base station. Where I
am in the US, between 902 and 928 MHz is part of the ISM spectrum, and
unregulated. Therefore, I would like to configure my base station to use
both an uplink and down link frequency within this range. However, none
of the pre-existing ARFCN options have both the uplink and downlink
frequencies within this band. Is it possible to manually shift the
frequency used by the base station, or manually select the up/down
frequencies so that both remain within this range?
Thank you for your help,
Enzo Damato