Open Source Mobile Communications: Issueshttps://osmocom.org/https://osmocom.org/favicon.ico?16647414092021-11-06T08:54:54ZOpen Source Mobile Communications
Redmine BBS-Revival - Feature #5294 (Resolved): break-out board for AMR modem riserhttps://osmocom.org/issues/52942021-11-06T08:54:54Zlaforge
<p>It would be great to have a break-out board for the <a class="wiki-page" href="https://osmocom.org/projects/retro-bbs/wiki/AMR_Modem_Riser">AMR_Modem_Riser</a> so we can try to hook them up to a microcontroller emulating the AC-link interface (e.g. using SAM3S SSC).</p>
The break-out board should have:
<ul>
<li>mechanical connector for AMR card</li>
<li>expose all analog and digital signals to 2.54mm headers</li>
<li>DC input for 5V (barrel? USB Vbus?)
<ul>
<li>jumper to +5VD</li>
<li>jumper to +5Vdual</li>
</ul>
</li>
<li>onboard 5V -> 3.3V LDO
<ul>
<li>jumper to +3.3Vdual</li>
<li>jumper to +3.3VD</li>
</ul>
</li>
<li>no +/- 12V on-board power supply, but at least some way to supply it externally</li>
<li>test points for attaching [scope, logic analyzer] probes to AC-link signals</li>
</ul> Cellular Network Infrastructure - Bug #5289 (Resolved): jenkins "install" tests fail regarding os...https://osmocom.org/issues/52892021-11-03T15:25:09Zlaforge
<p>As can be seen in <a class="external" href="https://jenkins.osmocom.org/jenkins/job/Osmocom-repo-install-debian10/feed=nightly,label=repo-install-test/289/consoleFull">https://jenkins.osmocom.org/jenkins/job/Osmocom-repo-install-debian10/feed=nightly,label=repo-install-test/289/consoleFull</a> , osmo-repo-install-* tests currently fail on all tested distributions with some osmo-hnodeb related error:</p>
<pre>
+ services_feed=
osmo-bsc
osmo-bts-virtual
osmo-gbproxy
osmo-gtphub
osmo-hlr
osmo-hnbgw
osmo-mgw
osmo-msc
osmo-pcap-client
osmo-pcu
osmo-sgsn
osmo-sip-connector
osmo-stp
osmo-pcap-server
osmo-hnodeb
+ systemctl start osmo-bsc osmo-bts-virtual osmo-gbproxy osmo-gtphub osmo-hlr osmo-hnbgw osmo-mgw osmo-msc osmo-pcap-client osmo-pcu osmo-sgsn osmo-sip-connector osmo-stp osmo-pcap-server osmo-hnodeb
Failed to start osmo-hnodeb.service: Unit osmo-hnodeb.service not found.
+ ret=1
+ [ -n ]
+ docker container kill debian10-repo-install-test-nightly
debian10-repo-install-test-nightly
+ exit 1
Build step 'Execute shell' marked build as failure
Sending e-mails to: jenkins-notifications@lists.osmocom.org
Finished: FAILURE
</pre>
<p>First I thought the service file was not being packaged, but it is.</p>
<p>The problem seems to be that the step "Installing all repository packages" doesn't actually install osmo-hnodeb. Further, it seems that the package is not building, it fails on each and every distribution and architecture:<br /><a class="external" href="https://build.opensuse.org/package/show/network:osmocom:nightly/osmo-hnodeb">https://build.opensuse.org/package/show/network:osmocom:nightly/osmo-hnodeb</a></p> Cellular Network Infrastructure - Bug #5287 (Resolved): asciidoc 10 related failures on debian un...https://osmocom.org/issues/52872021-10-30T06:20:13Zlaforge
<p>Every of our package builds on Debian unstable started to fail last night as the apparently have gone through with the [I'm extremely sorry to hear] removal of asciidoc:<br /><a class="external" href="https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=895462">https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=895462</a></p>
<p>The original rational given was that it's python2-only, which is no longer true since several years, see <a class="external" href="https://github.com/asciidoc-py/asciidoc-py/pull/1">https://github.com/asciidoc-py/asciidoc-py/pull/1</a> - and even the Debian asciidoc I have installed on unstable (9.0.0~rc2-1) is python3.</p>
<p>Also, it seems still an active project, given that 10.0.1 was just released yesterday, as there were several 9.x releases last year.</p>
So now we ahve three options:
<ol>
<li>add an asciidoc package to the osmocom package repository (ideally a python3 version)</li>
<li>transition our manuals to asciidoctor (I think I tried it once years ago and asciidoc was missing many features such as the easy integration of pktgen and mscgen)</li>
<li>convince Debian not to drop the package</li>
</ol>
<p>Actually, I just found <a class="external" href="https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=980930">https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=980930</a> which at the bottom hintes that a 10.0.1 has been pushed to the debian archive. Now I'm confused. Why do our build slaves?</p>
<p>In any case, my above analysis may be wrong. Still, we have build failures on unstable like:</p>
<pre>
[ 418s] TEXINPUTS=".." \
[ 418s] a2x -vv -L --asciidoc-opts="-f ../build/mscgen-filter.conf -f ../build/diag-filter.conf -f ../build/docinfo-releaseinfo.conf -a srcdir='/usr/src/packages/BUILD/tests' -a commondir='../common'" --dblatex-opts="-s ../build/custom-dblatex.sty -P draft.mode=yes -P draft.watermark=0" -a docinfo -a revnumber="DRAFT " -a revdate="unknown" test-usermanual.adoc
[ 418s] Traceback (most recent call last):
[ 418s] File "/usr/bin/a2x", line 33, in <module>
[ 418s] sys.exit(load_entry_point('asciidoc==10.0.1', 'console_scripts', 'a2x')())
[ 418s] File "/usr/bin/a2x", line 22, in importlib_load_entry_point
[ 418s] for entry_point in distribution(dist_name).entry_points
[ 418s] File "/usr/lib/python3.9/importlib/metadata.py", line 524, in distribution
[ 418s] return Distribution.from_name(distribution_name)
[ 418s] File "/usr/lib/python3.9/importlib/metadata.py", line 187, in from_name
[ 418s] raise PackageNotFoundError(name)
[ 418s] importlib.metadata.PackageNotFoundError: asciidoc
</pre> Cellular Network Infrastructure - Bug #5054 (Resolved): network:osmocom:latest spec files missinghttps://osmocom.org/issues/50542021-02-28T20:02:52Zlaforge
<p>We now have RPM spec.in files in the latest tags of all our repositories.</p>
<p>still, <a class="external" href="https://build.opensuse.org/project/monitor/network:osmocom:latest">https://build.opensuse.org/project/monitor/network:osmocom:latest</a> doesn't show any builds for CentOS8 of libosmo*.</p>
<ul>
<li>the builds are enabled in OBS, but</li>
<li>the spec files somehow are not added to OBS, making OBS unable to build</li>
</ul> Cellular Network Infrastructure - Bug #5053 (Resolved): osmo-gsm-manuals-debian8 is not updatedhttps://osmocom.org/issues/50532021-02-28T19:55:58Zlaforge
<p>For some strange reason, <a class="external" href="https://build.opensuse.org/package/show/network:osmocom:nightly/osmo-gsm-manuals-debian8">https://build.opensuse.org/package/show/network:osmocom:nightly/osmo-gsm-manuals-debian8</a> is still at version 1.0.0.x while osmo-gsm-manuals for all other ditributions is now at 1.1.0.</p>
<p>I don't understand why that happens, as osmo_obs_checkout_copy() just copies the original repo (osmo-gsm-manuals) to osmo-gsm-manuals-debian8 and I don't see anything that would checkout some old version/branch. It only applies some patch (specifically debian/patches/build-for-debian8.patch) but should not affect the version number at all ?!?</p> Cellular Network Infrastructure - Bug #5052 (Resolved): Osmocom release tarballs jenkins job failshttps://osmocom.org/issues/50522021-02-28T09:14:15Zlaforge
<p>fails already for 5 consecutive buidlds <br /><a class="external" href="https://jenkins.osmocom.org/jenkins/view/All%20no%20Gerrit/job/Osmocom-release-tarballs/">https://jenkins.osmocom.org/jenkins/view/All%20no%20Gerrit/job/Osmocom-release-tarballs/</a></p> Cellular Network Infrastructure - Bug #5051 (Resolved): repo-install-debian10 and -debian9 latest...https://osmocom.org/issues/50512021-02-28T09:11:42Zlaforge
<p>This has been failing for 5 consecutive days already, i.e. since the last release tags were made:</p>
<p><a class="external" href="https://jenkins.osmocom.org/jenkins/view/All%20no%20Gerrit/job/Osmocom-repo-install-debian10/feed=latest,label=repo-install-test/">https://jenkins.osmocom.org/jenkins/view/All%20no%20Gerrit/job/Osmocom-repo-install-debian10/feed=latest,label=repo-install-test/</a></p> Cellular Network Infrastructure - Bug #4733 (Resolved): RPM feeds don't have conflicts between ni...https://osmocom.org/issues/47332020-08-27T18:51:50Zlaforge
<p>For the Debian package feeds, we have a mechanism in place that marks nightly conflicting with latest and next, and vice-versa. This is implemented in the osmo_obs_prepare_conflict shell function of common-obs.sh</p>
<p>This mechanism is missing from the RPM builds (it apparently was forgotten when adding RPM packages), which makes it easy to run incompatible versions of programs/libraries.</p>
<p>We need to replicate this for RPM based distributions like CentOS.</p> Cellular Network Infrastructure - Bug #4578 (New): Updated slides / presentations / videos on set...https://osmocom.org/issues/45782020-06-03T14:56:52Zlaforge
<p>I just realized that since OsmoCon was discontinued after 2018 didn't result in sufficient turn-out, and only the 2017 incarnation contained some entry-level talks, we actually only have introductory level presentations / videos about a setup that still covers OsmoNITB. (<a class="external" href="https://media.ccc.de/v/osmocon17-4002-running_a_basic_circuit_switched_osmocom_gsm_network">https://media.ccc.de/v/osmocon17-4002-running_a_basic_circuit_switched_osmocom_gsm_network</a>)</p>
<p>This may or may not be a reason why some people still want to set up OsmoNITB in 2020. While our wiki and user manuals all have deprecated OsmoNITB years ago, people who only look for videos might be mislead.</p>
<p>Also, I'm sure that several other presentation (like the one about 3G / osmo-iuh before the CNI split) would similarly benefit from an update.</p>
<p>So I think we should try to create/update some slide decks and record related lectures / tutorials at some point this year. I wouldn't bother setting up a virtual conference or some kind of remote interaction at this point. Recording some talks and/or screencasts allows us to create and release them one-by-one.</p>
<p>Let's use this issue to first collect a list of topics that we think either need an update, or topics that never have been covered so far.</p> BBS-Revival - Feature #4341 (New): setup for telnet access to legacy BBS software which doesn't h...https://osmocom.org/issues/43412020-01-01T14:06:50Zlaforge
There are plenty of legacy BBS software packages out there, made for DOS. They either directly interface the serial ports (COM1..COM4) or they use a FOSSIL driver to do so. Attaching those to<br />real serial ports with modems is possible, but not particularly attractive:
<ul>
<li>it requires one physical modem per node (and likely one USB/serial adapter)</li>
<li>it cannot provide direct IP (telnet/ssh) access</li>
<li>it cannot be combined with using a RAS server like our <a class="wiki-page" href="https://osmocom.org/projects/retro-bbs/wiki/Livingston_Portmaster_3">Livingston_Portmaster_3</a></li>
</ul>
<p>For some other OSs (Windows, OS/2) there are solutions like NetFoss to work around this. I've also found references to a DOS based telnet FOSS driver baesed on Ethernet cards with packet driver. No proper solution for a Linux based setup with qemu-kvm seems to be out there.</p>
Using the built-in serial port telnet server of qemu is one idea, but
<ul>
<li>it would mean each line (COM port) has a different telnet port</li>
<li>there doesn't seem to be any escaping for binary (0xFF, ...)</li>
</ul>
<p>One could build something based on <a class="external" href="https://github.com/freemed/tty0tty">https://github.com/freemed/tty0tty</a> (a virtual nullmodem device), so one side could be passed though qemu, and the other end could be served by some kind of custom telnet daemon. tty0tty has the advantage of at least handling the modem status/control lines properly - very uch opposed to any pty based approach.</p>
<p>The cleanest solution would probably be to implement something based on <a href="https://www.ietf.org/rfc/rfc2217.txt" class="external">RFC2217</a> (Telnet Com Port Control Option). This has the advantage that it fully supports modem control lines, and that it can also be used to interface any actual serial/terminal server hardware, if ever needed.</p>
<p>So either qemu would have to run a RFC2217 telnet server which would then accept e.g. up to 4 or 8 connections, and dispatching any of those to a virtual 8250 serial UART, or it would have to run one RFC2217 telnet client for each virtual 8250 UART.</p>
<p>In case of a <em>telnet server</em>, that server then would also have to implement something like AT command emulation, so the DOS applications think they're talking to a modem with RING/ATA/CONNECT/...</p>
In case of a qemu built-in <em>telnet client</em>, we would provide some kind of external program that provides two telnet servers:
<ol>
<li>one for the qemu side to connect to, and where we emulate a basic AT command interface</li>
<li>one for the actual users to connect to, either directly via IP or indirectly from dialup via the Portmaster</li>
</ol>
<p>I think the approach with qemu built-in telnet client with the external server makes most sense, as it offers greatest flexibility in terms of supported configurations. It also keeps things like AT command emulation out of qemu.</p>
<p><code>tnt</code> has implemented the qemu side in <a class="external" href="https://patchwork.kernel.org/patch/11149529/">https://patchwork.kernel.org/patch/11149529/</a> - but that patch unfortunately is still not yet merged, presumably due to a lack of tests and some other feedback raised by qemu developers. But with a custom qemu build, we could already use it here...</p> BBS-Revival - Feature #4242 (New): offer CCC event schedule (Fahrplan) as gopher servicehttps://osmocom.org/issues/42422019-10-28T09:22:39Zlaforge
<p>The CCC event schedules are typically availble in a machine-readable (XML) format, see <a class="external" href="https://fahrplan.events.ccc.de/congress/2018/Fahrplan/schedule.xml">https://fahrplan.events.ccc.de/congress/2018/Fahrplan/schedule.xml</a> and it would be great to have a script to parse that XML and render gopher menus from it.</p>
<p>This in turn would be a nice demonstrator for gopher with up-to-date content.</p> Cellular Network Infrastructure - Bug #4227 (Resolved): all package builds for Debian testing and...https://osmocom.org/issues/42272019-10-15T11:38:01Zlaforge
<p>See <a class="external" href="https://lists.opensuse.org/opensuse-buildservice/2019-10/msg00037.html">https://lists.opensuse.org/opensuse-buildservice/2019-10/msg00037.html</a> for my related report, quoted here:</p>
<p>all of the projects we build in network:osmocom:latest / network:osmocom:nightly<br />are failing for both Debian Unstable and Testing. All seem to somehow depend<br />on libperl5.28. This must be some implicit dependency of some other package<br />we depend on, as we're not using perl from Osmocom projects, and don't have any<br />related Depends in debian/control.</p>
<p>Does anyone else observe this problem?</p>
<p>The packages build nicely on my local Debian unstable installation. However,<br />I not that Debian unstable has meanwhile released libperl5.30, so maybe some<br />package still depends on the old 5.28?</p> Cellular Network Infrastructure - Bug #3809 (Resolved): Osmocom-Debian-install-test fails since F...https://osmocom.org/issues/38092019-02-20T08:46:12Zlaforge
<p>for the last 10 days our "Debian installation test" job is consistently failing, see <a class="external" href="https://jenkins.osmocom.org/jenkins/job/Osmocom-Debian-install-latest/">https://jenkins.osmocom.org/jenkins/job/Osmocom-Debian-install-latest/</a></p>
<p>It somehow seems to be related to soapySDR mismatching versions where we use a 0.5 package from the debian feed:</p>
<blockquote>
<p>Get:358 <a class="external" href="http://deb.debian.org/debian">http://deb.debian.org/debian</a> stretch/main amd64 libsoapysdr0.5-2 amd64 0.5.4-1 [64.4 kB]</p>
</blockquote>
<p>and mix that with a 0.7 lms7 module from our feed:</p>
<blockquote>
<p>Get:425 <a class="external" href="http://download.opensuse.org/repositories/network:/osmocom:/latest/Debian_9.0">http://download.opensuse.org/repositories/network:/osmocom:/latest/Debian_9.0</a> ./ soapysdr0.7-module-lms7 19.01.0-1 [49.9 kB]</p>
</blockquote>
<blockquote>
<p>Unpacking soapysdr0.7-module-lms7:amd64 (19.01.0-1) ...<br />dpkg: error processing archive /tmp/apt-dpkg-install-aYn9qf/398-soapysdr0.7-module-lms7_19.01.0-1_amd64.deb (--unpack):<br />trying to overwrite '/usr/lib/x86_64-linux-gnu/SoapySDR/modules0.5-2/libLMS7Support.so', which is also in package</p>
</blockquote>
<p>...</p>
<blockquote>
<p>Errors were encountered while processing: /tmp/apt-dpkg-install-aYn9qf/398-soapysdr0.7-module-lms7_19.01.0-1_amd64.deb<br />E: Sub-process /usr/bin/dpkg returned an error code (1)<br />Build step 'Execute shell' marked build as failure<br />Finished: FAILURE</p>
</blockquote>
<p>Does anyone know of any change that would have triggered this?</p> Cellular Network Infrastructure - Bug #3773 (Resolved): tcc-deb9build: scripts/osmo-deps.sh not i...https://osmocom.org/issues/37732019-01-31T09:37:39Zlaforge
<p>From <a class="external" href="https://jenkins.osmocom.org/jenkins/view/master/job/master-osmo-sysmon/257/a1=default,a2=default,a3=default,a4=default,label=osmocom-master-debian9/console">https://jenkins.osmocom.org/jenkins/view/master/job/master-osmo-sysmon/257/a1=default,a2=default,a3=default,a4=default,label=osmocom-master-debian9/console</a><br /><pre>
+ ./contrib/jenkins.sh
Error: We need to have scripts/osmo-deps.sh from http://git.osmocom.org/osmo-ci/ in PATH !
</pre></p>
<p>So somehow that was not deployed when running the ansible playbook ?!?</p> Cellular Network Infrastructure - Bug #3768 (Resolved): user manuals don't describe statsd exporterhttps://osmocom.org/issues/37682019-01-26T11:05:24Zlaforge
<p>In fact, not only is documentation for the statsd exporter missing, but also documentation for the entire "statistics item reporting" sub-system.</p>
<p>See <a class="external" href="http://ftp.osmocom.org/api/latest/libosmocore/core/html/group__stats.html#details">http://ftp.osmocom.org/api/latest/libosmocore/core/html/group__stats.html#details</a> for the related API documentation.</p> Cellular Network Infrastructure - Bug #3449 (Resolved): network:osmocom:nightly packages have VER...https://osmocom.org/issues/34492018-08-06T07:30:23Zlaforge
<p>It seems that the way the nightly packages are generated doesn't involve "make dist" and hence no ".tarball-version" file is part of the archive, which in turn menas that the pkg-config .pc files contain "UNKNOWN" as version string.</p>
<p>This is what currently happens to osmo-hlr (libosmo-gsup-client) and is why osmo-msc can not be built after migrating over to using libosmo-gsup-client.</p> Cellular Network Infrastructure - Bug #3268 (Resolved): execute TTCN3 test suites against "latest...https://osmocom.org/issues/32682018-05-15T20:01:57Zlaforge
<p>It would be good to run our test suites not only against current master builds, but also against the "latest" packages. This way we can nicely show the amount of bugs fixed (and/or regressions pending) between the latest tagged version[s] and the current master.</p>
<p>In I6a564206dd81743deb1eb27eca7081bc333d7434 of docker-playground.git I already introduced Dockerfiles:</p>
<pre>
osmo-bsc-latest
osmo-bts-latest
osmo-ggsn-latest
osmo-hlr-latest
osmo-hnbgw-latest
osmo-mgw-latest
osmo-msc-latest
osmo-sgsn-latest
osmo-sip-latest
osmo-stp-latest
</pre>
What's missing is mainly
<ul>
<li>generalization of the "jenkins.sh" scripts to either test master or latets</li>
<li>migration of ttcn3 jenkins jobs to JJB, so we can template them and duplicate them</li>
</ul>
<p>Potential problems: The tests use hard-coded IP addresses, and docker cannot have two networks with overlapping addresses, even if there's no routing between them :( We would then have to make sure that no ttcn3-bts-test-master and ttcn3-bts-test-latest jobs are running in parallel on the same build slave. A possible work-around would be to have separate build slaves for master/latest. Using different IP addresses (172.18.9.0/24 for ttcn3-bts-test-master and 172.17.9.0/24 for ttcn3-bts-test-latest) is of course desirable, but this would require different osmo-*.cfg and different TTCN-3 testsuite config files, etc :(((</p> Cellular Network Infrastructure - Bug #3176 (Resolved): osmocom debian packages are not install /...https://osmocom.org/issues/31762018-04-16T15:03:13Zlaforge
<p>We've recently seen some packaging bugs related to library version handling / package naming in both the 'nightly' and the 'latest' feeds that could have been discovered months earlier by automatic testing.</p>
This could e.g. be achieved by some dockefiles which would do things like
<ul>
<li>try to install all packages given feed (nightly or latest) from scratch on the respective base distro (debian 8/9, ...)</li>
<li>start with a docker image that has older versions of packages installed already (like nightly from a week ago, or the previous "latest" packages) and try to upgrade all packages</li>
</ul>
<p>Of course there's no need for Docker, I just think it could come in handy for related tests</p> Cellular Network Infrastructure - Bug #2845 (Resolved): Coverity-Upload broken due to alleged mis...https://osmocom.org/issues/28452018-01-20T14:58:56Zlaforge
<p>See <a class="external" href="https://jenkins.osmocom.org/jenkins/job/Coverity-Upload/label=linux_amd64_debian8/1736/console">https://jenkins.osmocom.org/jenkins/job/Coverity-Upload/label=linux_amd64_debian8/1736/console</a><br />This also seems some fall-out of seemingly backwards-incompatible changes introduced to configure.ac. Please don't make incompatible changes, it just makes tons of other things break.</p> BBS-Revival - Feature #2812 (Resolved): Build mixed ISDN / analog telephone networkhttps://osmocom.org/issues/28122018-01-01T13:28:30Zlaforge
<p>We should build a mixed ISDN = analog telephone network that we can use to interconnect the client-side modems/TAs with the BBS-side modems/TAs.</p>
<p>The network should offer analog as well as digital (S0, S2M) ports.</p>
<p>Rather than going for an old, bulky, power-hungry and proprietary PBX like the Alcatel 4400 series used by the POC, I think we could try to use a more modern approach by using LCR with E1 and quad/octo-S0 boards for the digital side, as well as some a/b adapters, as well as SIP and associated TAs.</p>
<ul>
<li>S2M / PRI is needed to connect devices like Livingston PortMaster3 or other "bulk access" devices that can handle 64k ISDN asd well as [up to] V.90 analog</li>
<li>S0 busses are needed for interfacing ISDN cards/TAs on BBSs and Clients</li>
<li>L1oIP can be used for virtual E1 trunks between LCR instances in distributed setups</li>
<li>SIP with G.711 can be used to interconnect with public SIP operators for dial-in/dial-out</li>
<li>consumer-grade PBXs like ISTEC 1003/1008/media can be used for attaching analog modems</li>
<li>SIP<->telephony voice gateways like Cisco VGxxx can possibly be integrated, offering 24/48/30 voice lines</li>
</ul>
<p>The resulting network should be mounted in some portable rack/chassis so it can be transported and set up at events, as needed.</p> BBS-Revival - Bug #2811 (Resolved): collect ISDN cards / adaptershttps://osmocom.org/issues/28112018-01-01T13:21:01Zlaforge
<p>Let's collect some active and passive ISDN cards and adapters</p> BBS-Revival - Feature #2810 (Closed): collect analog modemshttps://osmocom.org/issues/28102018-01-01T13:20:35Zlaforge
<p>let's collect various different analog modems</p> Cellular Network Infrastructure - Bug #2771 (Closed): osmo-python-tests: No script named 'osmotes...https://osmocom.org/issues/27712017-12-18T16:44:03Zlaforge
<pre>
laforge@nataraja%pts/34 (17:42) ~/projects/git/osmo-bsc > which osmotestvty.py
/usr/local/bin/osmotestvty.py
laforge@nataraja%pts/34 (17:42) ~/projects/git/osmo-bsc > osmotestvty.py
Traceback (most recent call last):
File "/usr/local/bin/osmotestvty.py", line 4, in <module>
__import__('pkg_resources').run_script('osmopython==0.0.5', 'osmotestvty.py')
File "/home/laforge/.local/lib/python2.7/site-packages/pkg_resources/__init__.py", line 742, in run_script
self.require(requires)[0].run_script(script_name, ns)
File "/home/laforge/.local/lib/python2.7/site-packages/pkg_resources/__init__.py", line 1489, in run_script
raise ResolutionError("No script named %r" % script_name)
pkg_resources.ResolutionError: No script named 'osmotestvty.py'
</pre> Cellular Network Infrastructure - Bug #2770 (Closed): osmo-python-tests fails with both python-2....https://osmocom.org/issues/27702017-12-18T07:57:14Zlaforge
<p>when using python-2.7.14:</p>
<pre>
$ python ./setup.py install
...
byte-compiling build/bdist.linux-x86_64/egg/osmopy/__init__.py to __init__.pyc
byte-compiling build/bdist.linux-x86_64/egg/osmopy/osmo_interact_common.py to osmo_interact_common.pyc
File "build/bdist.linux-x86_64/egg/osmopy/osmo_interact_common.py", line 113
print('Error while verifying transcript file %r' % transcript_file, file=sys.stderr)
^
SyntaxError: invalid syntax
</pre>
<p>and when using 3.6.4rc1:<br /><pre>
$ python3 ./setup.py install
Processing osmopython-0.0.3-py3.6.egg
removing '/usr/local/lib/python3.6/dist-packages/osmopython-0.0.3-py3.6.egg' (and everything under it)
creating /usr/local/lib/python3.6/dist-packages/osmopython-0.0.3-py3.6.egg
Extracting osmopython-0.0.3-py3.6.egg to /usr/local/lib/python3.6/dist-packages
File "/usr/local/lib/python3.6/dist-packages/osmopython-0.0.3-py3.6.egg/osmopy/obscvty.py", line 34
print '\n> %s' % what
^
SyntaxError: Missing parentheses in call to 'print'. Did you mean print(int '\n> %s' % what)?
File "/usr/local/lib/python3.6/dist-packages/osmopython-0.0.3-py3.6.egg/osmopy/osmo_ctrl.py", line 33
print "Connecting to host %s:%i" % (host, port)
^
SyntaxError: invalid syntax
File "/usr/local/lib/python3.6/dist-packages/osmopython-0.0.3-py3.6.egg/osmopy/osmodumpdoc.py", line 24
print 'generated %r' % filename
^
SyntaxError: Missing parentheses in call to 'print'. Did you mean print(int 'generated %r' % filename)?
File "/usr/local/lib/python3.6/dist-packages/osmopython-0.0.3-py3.6.egg/osmopy/osmotestconfig.py", line 55
print "Verifying %s, test %s" % (' '.join(cmd), run_test.__name__)
^
SyntaxError: invalid syntax
File "/usr/local/lib/python3.6/dist-packages/osmopython-0.0.3-py3.6.egg/osmopy/osmotestvty.py", line 39
print "Launch: %s from %s" % (' '.join(osmo_vty_cmd), os.getcwd())
^
SyntaxError: invalid syntax
File "/usr/local/lib/python3.6/dist-packages/osmopython-0.0.3-py3.6.egg/osmopy/osmoutil.py", line 33
print "Opening /dev/null"
^
SyntaxError: Missing parentheses in call to 'print'. Did you mean print(print "Opening /dev/null")?
</pre></p>
<p>This is horribly broken, and I seriously wonder who has made it end up in this state. It's not acceptable, and basically osmo-python-tests is unusable as a result, AFAICT?</p> Cellular Network Infrastructure - Feature #2642 (Resolved): Jenkins job to verify PKG_CHECK_MODUL...https://osmocom.org/issues/26422017-11-15T06:05:07Zlaforge
<p>Right before tagging a new version of a given program (e.g. osmo-bts), we would want to have a manually-triggered jenkins job that verifies the correctness of our PKG_CHECK_MODULES statements.</p>
<p>So this jenkins job would have to scan/parse configure.ac and find lines like<br /><pre>
PKG_CHECK_MODULES(LIBOSMOCORE, libosmocore >= 0.10.0)
</pre><br />and then check-out the 0.10.0 tag of libosmocore, build and install that dependency and finally attempt to do a "make check" on the program we triggered the jenkins job for (osmo-bts in the example above).</p>
The difficulties/challenges I see are:
<ul>
<li>ensure we start from a clean build system that has none of our libs installed</li>
<li>have a list of mappings between library name and git repository name so the git repo for a given project can be determied</li>
<li>find out a way to deal with the fact that we have one source repo libosmocore which installs libosmo{core,gsm,ctrl,vty,codec,coding}.
<ul>
<li>simply detect this and use the latest(newest) version required by them for checkout+build+install?</li>
<li>actually find a way how we can only do a "make install" of one of the libraries from libosmocore.git?</li>
</ul>
</li>
<li>it's sad that we'd have to have jenkins jobs for each of our projects, which seems a bit like bloat. Maybe it could also simply be a script in osmo-ci.git that we manually execute in a well-defined build environment such as a docker container? This way we wouldn't need yet another dozen of jenkins jobs.</li>
</ul> Cellular Network Infrastructure - Feature #2604 (Stalled): GSUP-to-DIAMETER converter / IWFhttps://osmocom.org/issues/26042017-10-29T23:01:06Zlaforge
<p>In order to support a single subscriber database for 2G/3G and LTE, operators normally use a single HSS. HSS is the EPC successor of the LTE.</p>
<p>Instead of MAP over SS7, HSS's speak DIAMETER over SCTP or TCP (with optional TLS). The types of procedures / transactions are pretty much the same as before, but the encoding and the protocol changed completely.</p>
<p>There are a couple of (at least minimal) HSS implementations out there, from freeDiameter to nextepc, to name some examples.</p>
<p>If we were to implement a converter between GSUP and DIAMETER, then the OsmoMSC and OsmoSGSN could access an external HSS - and that same HSS could be accessed from nextepc or even openair-cn for LTE access.</p>
<p>3GPP TS 29.305 specifies the MAP-to-DIAMETeR InterWorkingFunction (IWF), which is pretty much the same device, with the exception that we'd use GSUP instead of MAP.</p> Cellular Network Infrastructure - Bug #2602 (Resolved): Debian packages: Install configs to /etc/...https://osmocom.org/issues/26022017-10-29T11:01:20Zlaforge
<p>while working on the "osmocom:latest" builds the last few days, I noticed that some packages (notably osmo-pcu) install a config file to /etc/osmocom,<br />while most other packages simply install some example config files to /usr/share/doc/* and don't create either /etc/osmocom nor any config files<br />in it - despite the systemd jobs depending on it.</p>
<p>For sure, the behavior should be unified across all Osmocom packages, but in which way?</p>
<p>What is the best practise here? What do our users expect?</p> Cellular Network Infrastructure - Bug #2527 (Closed): osmocom:nightly package builds failhttps://osmocom.org/issues/25272017-10-03T23:55:30Zlaforge
Max last osmo-ci change breaks osmocom nightly builds from 631 onwards:
<ul>
<li><a class="external" href="http://jenkins.osmocom.org/jenkins/job/Osmocom_nightly_packages/631/display/redirect?page=changes">http://jenkins.osmocom.org/jenkins/job/Osmocom_nightly_packages/631/display/redirect?page=changes</a></li>
</ul>
<p>It seems there are some issues with the osmo-sgsn debian/copyright information, and also there is no osmo-sgsn package job in OBS: <a class="external" href="https://build.opensuse.org/project/show/network:osmocom:nightly">https://build.opensuse.org/project/show/network:osmocom:nightly</a> doesn't list one.</p> Cellular Network Infrastructure - Support #1719 (Resolved): review different 'getting started' gu...https://osmocom.org/issues/17192016-05-17T15:39:32Zlaforge
<p>There are plenty of different guides on how to compile + configure + run an OpenBSC based network. Some related to OsmoTRX based BTSs, some to nanoBTS, some ot E1 based BTSs.</p>
Let's clean this up and divided it into
<ul>
<li>sections that are common among all configurations</li>
<li>sections that are related to a specific BTS hardware (or hardware class)</li>
</ul>
<p>Also clearly indicate that building the software from source is only an optional step and refer to the OBS dpkg nightly builds as preferred method for regular users.</p> Cellular Network Infrastructure - Feature #1700 (Resolved): Update/add counter and/or vty documen...https://osmocom.org/issues/17002016-05-04T14:17:53Zlaforge
<p>there are some statistics/counters available in OsmoNITB, OsmoSGSN, OsmoBTS, OsmoPCU</p>
<p>Please identify all of them and add documentation in the respective user manual.</p>