Messages

1

YateBTS / Which c++ standard should we compile YateBTS with ?

« on: October 02, 2018, 05:30:18 PM »

As you might already know, YateBTS trunk does not compile with recent versions of GCC, due to a few errors related to iostream manipulations.

These errors are easy to fix in yate-bts source code (see https://forum.yate.ro/index.php?topic=1966.0).

Though, I was confused why they were not an issue for you, I mean upstream. Which version of GCC do you use ? GCC 4.x, right ?

AFAIK, without otherwise specified:

By default, g++ is equivalent to g++ -std=gnu++14 since GCC 6, and g++ -std=gnu++98 for older releases.

And actually, if I set -std=gnu++98 in the appropriate Makefile, yate-bts compiles just fine.
My concern is that -std=gnu++98 and -std=gnu++14 may be somewhat different languages, and hence, depending on the C++ features and the GNU extensions the yate-bts source code actually use, and combine, building as -std=gnu++98 or -std=gnu++14 may not generate semantically identical object code.
Which makes me think that setting -std=gnu++98 might be a more consistent fix than (just) patching MSInfo.cpp and Sgsn.cpp to remove the compilation errors. Can someone confirm this ?

IMHO, if it's somewhat important to build the source code as 1998 ISO C++ with GNU extensions, it might be a good idea to enforce this through the Makefiles: -std=gnu++14 is the default for Ubuntu since Artful 17.10 (and thus for Bionic 18.04 LTS), for Debian since stretch, and obviously for Arch, which sum to a huge Linux users base. BTW, none of these users would be able to build YateBTS out of the box.   

The same question may also apply to C code (should we enforce -std=gnu99 or something else ?).
And may be also when building yate (server) itself: it compiles fine, but should we also enforce standards there ?

Thanks in advance for your answers.

[EDIT]

• I've attached the patches I use to consistently set -std=gnu++98 as C++ standard, and -std=gnu99 as C standard for both yate and yate-bts build files. I'm not sure it's the simplest/best fix, but yate and yate-bts build with GCC 8.2 without the need to otherwise patch the source code. 
  The diff are against versions 6.1.0-1, and may apply to any 6.x.
  
• May be it still would not hurt to fix MSInfo.cpp and Sgsn.cpp, though ?

[/EDIT]

Kind regards,
spina.
 

2

YateBTS / Yate(BTS) instances as systemd services

« on: September 21, 2018, 03:48:26 PM »

Hi,

I run Arch Linux, and got into troubles trying to manage Yate(BTS) instances using the sysv-init compatibility layer of systemd. Till recently this worked quite well using the init script provided with Yate source code (though lightly patched to always exit 0).
But its seems that newer (Arch) releases of systemd are not compiled anymore with the support to auto-generate unit service files from init scripts deployed to /etc/init.d. Which makes the provided one unhelpful.

I share bellow the simple tips I applied to get Yate(BTS) running as a systemd managed service.

First, create a unit file /etc/systemd/system/<unit-name>.service:

Code: [Select]

[Unit]
Description=<unit-name> or whatever

[Service]
User=root or any user with appropriate permissions/capabilities
Type=forking
PIDFile=<path-to>/var/run/<unit-name>.pid
EnvironmentFile=<path-to>/etc/sysconfig/<unit-name>
ExecStart=<path-to>/ybts-start-unit.sh
ExecStop=<path-to>/ybts-stop-unit.sh

[Install]
WantedBy=multi-user.target

Typically:

Code: [Select]

[Unit]
Description=yate

[Service]
User=root
Type=forking
PIDFile=/var/run/<unit-name>.pid
EnvironmentFile=/etc/sysconfig/<unit-name>
ExecStart=/usr/local/bin/ybts-start-unit.sh
ExecStop=/usr/local/bin/ybts-stop-unit.sh

[Install]
WantedBy=multi-user.target

The file /etc/sysconfig/<unit-name> sets the environment variables used by the ybts-{start,stop}-unit.sh scripts, and would typically contain:

YBTS_YATE=/usr/local/bin/yate
YBTS_PIDFILE=/var/run/<unit-name>.pid
YBTS_LOGFILE=/var/log/<unit-name>
YBTS_CONF_DIR=/etc/yate
YBTS_EXTRA_DIR=/usr/local/share/yate

Once both files are written appropriately, run:

Code: [Select]

# systemctl daemon-reload to make systemd be aware of the new service, an then manage it using:

Code: [Select]

# systemctl {start,stop,status} <unit-name>.

IMHO, it's correct that the ybts-{start,stop}-unit.sh scripts always exit 0, as systemd will handle the dameon process life-cycle through its PID file, and not through the scripts exit value. Please correct me if I'm wrong.

There are other ways to achieve this, and more options available. But this might help getting started.
This pointer may also be worth reading if new to systemd:
https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/system_administrators_guide/sect-managing_services_with_systemd-unit_files

Kind regards,
spina.
 

3

YateBTS / Building YateBTS on OS X

« on: September 19, 2018, 06:02:53 AM »

I would like to build and run YateBTS on OS X, basically because I can't achieve any kind of stability with my Linux laptop regarding USB3 transport and/or power management (neither bladerf nor Yate's fault, it's my hardware), and that I can put hands on an old MacBook Air.

It seems that Yate itself (the engine, message bus, main modules, SIP proxy, etc) should build/run fine, as I've seen that YateClient is available for OS X, and it does require Yate services to run.

My concern is the YateBTS part.
Let's try with the Linux source tree. AFAIK, its few requirements are tools and libraries I could install on OS X, including the full GNU toolchain, but:
- there may be Linux oddities in the Makefiles (about filesystem layout and/or file paths, environment variables, library names, whatever)
- source code may rely upon Linux specific (non POSIX) syscalls, that OS X will obviously not implement

Or should I try the the FreeBSD source tree, which is presumably closer to OS X ?
That would be far from my comfort zone, though, since I'm a true newbie when pushed to OS X / FreeBSD.

Has anyone already tried to build/run YateBTS on OS X ? Getting started with which source tree ?

Thanks in advance for any help or suggestion.

Kind regards,
spina.

4

YateBTS / Re: Problems MCC, MNC.

« on: September 19, 2018, 04:52:43 AM »

Hi.

I'm not sure the OP was asking for a way to set the /network name/ as a string, the way it was,at some point in time, possible via the Identity.ShortName configuration key first introduced in OpenBTS, and that was later on removed from the opensource source tree of YateBTS (and probably kept in the commercial tree).
But if it actually was your question, I don't think it would be that difficult to get this feature back: digging into the OpenBTS/YateBTS SVN/git repositories history should provide you with enough material to get started.

Though, I think this does not answer your question. My 2 cents are that you configure YateBTS for an existing/legit PLMN (255 for your country, and 06 for the Life network): in that case, your phone will basically identify /your network/ to the /legit network/, and display that accordingly. Then, when you configure YateBTS with a different /non existing/ MNC, like 006, you create a /new/ network, and your phone will display it.
BTW, for testing purpose, it's recommended that you configure your BTS with the well-known test PLMN, MCC=001, MNC=01.

Kind regards,
spina.



 
 

5

YateBTS / Re: yatebts 6.0.0 multuple compilation errors

« on: July 23, 2018, 08:08:48 AM »

Actually, there are only a few compilation errors, I previously thought there were more because my console output was flooded by GCC diagnostics/candidates.

The patch bellow fix the compilation errors. I haven't tested the built yatebts yet, though. 


Index: mbts/GPRS/MSInfo.cpp
===================================================================
--- mbts/GPRS/MSInfo.cpp   (revision 666)
+++ mbts/GPRS/MSInfo.cpp   (working copy)
@@ -638,7 +638,7 @@
         if (msPCHDowns.size() > 1) {
             std::ostringstream os;
             msDumpChannels(os);
-            GPRSLOG(INFO,GPRS_MSG|GPRS_CHECK_OK) << "Multislot assignment for "<<this<<os;
+            GPRSLOG(INFO,GPRS_MSG|GPRS_CHECK_OK) << "Multislot assignment for "<<this<<os.str();
         }
 
    } else {
Index: mbts/SGSNGGSN/Sgsn.cpp
===================================================================
--- mbts/SGSNGGSN/Sgsn.cpp   (revision 666)
+++ mbts/SGSNGGSN/Sgsn.cpp   (working copy)
@@ -149,7 +149,7 @@
    clearConn(GprsConnNone,SigConnLost);
    std::ostringstream ss;
    sgsnInfoDump(this,ss);
-   SGSNLOGF(INFO,GPRS_OK|GPRS_MSG,"SGSN","Removing SgsnInfo:"<<ss);
+   SGSNLOGF(INFO,GPRS_OK|GPRS_MSG,"SGSN","Removing SgsnInfo:"<<ss.str());
    sSgsnInfoList.remove(this);
    GmmInfo *gmm = getGmm();
    if (gmm && (gmm->getSI() == this)) {
@@ -253,7 +253,7 @@
 {
    std::ostringstream ss;
    gmmInfoDump(gmm,ss,0);
-   SGSNLOGF(INFO,GPRS_OK|GPRS_MSG,"SGSN","Removing gmm:"<<ss);
+   SGSNLOGF(INFO,GPRS_OK|GPRS_MSG,"SGSN","Removing gmm:"<<ss.str());
    SgsnInfo *si;
    RN_FOR_ALL(SgsnInfoList_t,sSgsnInfoList,si) {
       // The second test here should be redundant.

6

YateBTS / yatebts 6.0.0 multuple compilation errors

« on: July 23, 2018, 07:00:10 AM »

Compiling latest yatebts releases (from SVN or tarball) fail with multiple errors related to c++ std streams manipulation.

For example:
MSInfo.cpp: In member function ‘bool GPRS::MSInfo::msAssignChannels()’:
MSInfo.cpp:641:86: error: no match for ‘operator<<’ (operand types are ‘std::ostream’ {aka ‘std::basic_ostream<char>’} and ‘std::ostringstream’ {aka ‘std::__cxx11::basic_ostringstream<char>’})
             GPRSLOG(INFO,GPRS_MSG|GPRS_CHECK_OK) << "Multislot assignment for "<<this<<os;
MSInfo.cpp:641:86: note: candidate: ‘operator<<(int, int)’ <built-in>
MSInfo.cpp:641:86: note:   no known conversion for argument 2 from ‘std::ostringstream’ {aka ‘std::__cxx11::basic_ostringstream<char>’} to ‘int’

AFAIK, this does not relate to invalid/missing dependencies, but rather to plain incorrect C++.

My build tool chain is:
Linux 4.17.6
GCC 8.1.1
libstdc++ 3.3.6

Thanks you for taking care of this issue.