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
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
Hi Keith,
My question was targeting the Osmocom stack and not the (external)
PBX. I already found some AMR patches for Asterisk (it seems it is
still not part of mainline), will try to do that.
The second half of my question was somewhat vaguely tries to ask if it
is possible to do AMR when the call is MO-MT directly, or maybe the
MGW can do transcoding, so in a nutshell: maybe there is a solution to
do GSM FR when the call is outbound from the mobile network and AMR
when it is mobile to mobile. Or the transcoding path is also an
option. Point is: about these capabilities there is very little
information available about what is supported and what is not within
the Osmocom domain.
Regards,
Csaba
Dear list,
I managed to set up my E1 based Nokia BTS, the complete Osmo-CNI
stack, SIP-connector and Asterisk. MO/MT calls do work as well as
external SIP calls to and from mobile as well. But no matter what I do
only plain FullRate calls are possible.
Under osmo-bsc.conf code support is set like this (the BTS HW do
support all of these codecs):
codec-support fr efr amr
but once I also add "codec-list fr3 fr2 fr1" to the MSC section of the
osmo-bsc.conf, the calls wont establish anymore.
I watched Neel's OsmoDevCall presentation on this topic, but it is not
very clear what codecs are supported when osmo-sip-connector and an
external PBX is used?
Regards,
Csaba
Hi all,
during recent patch review
(https://gerrit.osmocom.org/c/osmo-trx/+/33737) the topic of continuing
to maintain support for big endian machines has come up.
While traditionally I've always been a strong proponent of writing
portable code that can run also on big endian systems, it is not the
year 2003 or 2008 anymore, and PowerPC (the main big endian platform) is
dead by now, as is SPARC. Not just in newly-built processors, but also
in existing and still operating machines, at least of the class that
would run our code.
So unless somebody objects with strong arguments, I'd propose to
officially and explicitly drop supporting big endian systems from
osmocom CNI projects.
From what I can tell, this would primarily mean
* drop the struct_endianness check from the commit verification
* removing all our struct_endianness-generated or other code that
explicitly adds big endian support
* adding some kind of #warning or even #error to a common libosmocore
header file if anyone tries to build on big endian
This obviously doesn't mean we can abandon using [osmo_]{htonl,ntohl},
as network byte order is still network byte order.
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,
It's Alejandro Blanco.
I would like to disable the UST service 124 so that I connect the
smartphone to a gNB based on srsRAN.
However, there is an error after trying it. Find a screenshot below that
shows the error message.
Do you know how to fix this?
Thank you.
[image: image.png]
Best regards,
Alejandro
----------------------------------------------------------
*Alejandro Blanco Pizarro, PhD <https://alejandroblancopizarro.github.io/>*
*Post-Doc at **The University of Edinburgh*
----------------------------------------------------------
Dear Osmocom community,
while many people with a long history in FOSS development have no issues
at all with mailing lists as primary form of engaging with their
community, they have undoubtedly fallen out of fashion in favor of
various chat/messaging systems or web based forums.
In Osmocom, we've just launched an installation of the discourse forum
software available at https://discourse.osmocom.org/ providing an
alternative to our traditional mailing lists at https://lists.osmocom.org/
We're looking forward to see whether this web-based approach will
facilitate more and/or other people to engage with the Osmocom
developer/contributor community.
Feel free to join and get the discussions started. If there's a need
for more categories or sub-categories, just let one of the moderators
know and we can help with that.
The old mailing lists will continue to remain available for those who
prefer them.
--
- 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)
Hi,
So, I migrated to today's master, and tried with MNCC local to make
sure the PBX is not participating. Using an E1 based Nokia InSite and
the target codec is EFR (as the InSite does not support AMR). And the
test case is a MO - MT call.
On the BSC config:
codec-support fr efr
codec-list fr2
On the MSC config:
mncc-int
default-codec tch-f efr
default-codec tch-h hr
The BSC log say:
Tue Jul 25 21:53:45 2023 DCHAN abis_rsl.c:1291
lchan(0-0-2-TCH_F-0)[0x562876541b90]{ESTABLISHED}: (type=TCH_F)
CONNECTION FAIL (cause=Remote Transcoder Failure [ 28 ])
Tue Jul 25 21:53:45 2023 DMSC osmo_bsc_bssap.c:1465
SUBSCR_CONN(msc0-conn1_subscr-IMSI-001010101000050-TMSI-0x910bc287)[0x562876543a00]{WAIT_CLEAR_CMD}:
Event MT_DTAP not permitted
The MSC log say:
Jul 25 21:56:46 openbsc osmo-msc[759]: <0001> transaction.c:130 LCLS
disabled globally
Jul 25 21:56:47 openbsc osmo-msc[759]: <0007> mncc_builtin.c:373 (call
80000007) Message 'MNCC_RTP_CREATE' unhandled
Jul 25 21:56:47 openbsc osmo-msc[759]: <0001> transaction.c:130 LCLS
disabled globally
Jul 25 21:56:48 openbsc osmo-msc[759]: <0007> mncc_builtin.c:373 (call
7) Message 'MNCC_RTP_CREATE' unhandled
So this seems to be an issue within the Osmocom stack, the external
MNCC connection was disabled.
Regards,
Csaba
Hi all,
I deployed osmomsc in docker in open5gs on raspberry pi4b with ubuntu22.10 OS. I am able to build the oscmomsc but osmomsc is excited
having below error:
$ docker logs osmomsc
There is no such command.
Error occurred during reading the below line:
sgs
<0006> msc_main.c:572 Failed to parse the config file: '/etc/osmocom/osmo-msc.cfg'
I followed below steps in docker file to build
FROM ubuntu:focal
ENV DEBIAN_FRONTEND=noninteractive
# Install updates and dependencies
RUN apt-get update && \
apt-get -y install wget gnupg telnet
RUN wget https://downloads.osmocom.org/packages/osmocom:/latest/xUbuntu_20.04/Releas… && \
mv Release.key /etc/apt/trusted.gpg.d/osmocom-latest.asc && \
echo "deb https://downloads.osmocom.org/packages/osmocom:/latest/xUbuntu_20.04/ ./" > /etc/apt/sources.list.d/osmocom-latest.list && \
apt-get update && apt-get -y install osmo-msc
CMD /mnt/osmomsc/osmomsc_init.sh && \
rm -f /mnt/osmomsc/sms.db* && \
cd /mnt/osmomsc && /bin/osmo-msc -c /etc/osmocom/osmo-msc.cfg
Please help me to resolve the issue
Mobiveil INC., CONFIDENTIALITY NOTICE: This e-mail message, including any attachments, is for the sole use of the intended recipient(s) and may contain proprietary confidential or privileged information or otherwise be protected by law. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please notify the sender and destroy all copies and the original message.
Hi all,
this is some info for users of older Sysmocom SIM cards that came with
IMSI prefix 90170.
The ITU has withdrawn the assignment of the MCC/MNC 901/70, which was
initially assigned to "Clementvale Baltic OÜ" back in 2020.
Hence, the users of these SIM cards will no longer risk collisions with
the public operator.
(Newer cards as of 2020 come with an IMSI that starts with 99970 anyway.)
Further reading:
* https://en.wikipedia.org/wiki/Mobile_country_code#International_operators
* https://www.itu.int/pub/T-SP-OB.1240-2022
Best regards
Robert
--
RobertFalkenberg
Senior Engineer
Software Radio Systems
robert(a)srs.io <mailto:robert@srs.io>
www.srs.io <//www.srs.io>
Dortmund, Germany
twitter <https://twitter.com/srssystems>
Dear Osmocom community,
we're happy to announce the next incarnation of OsmoDevCall.
when:
July 17, 2023 at 20:00 CEST
where:
https://osmocom.org/OsmoDevCall (Big Blue Button)
This time, @laforge will be presenting on
Building wired test setups for mobile communications
Particularly in lab and test setup involving cellular technology there
is often a need for wired (coaxial) connection of cellular equipment,
such as connecting a number of UEs (phones/modems) with one or multiple
cellular base stations. For example, this is the only way to get defined
power levels and test the actual transmit power or receive sensitivity
of a device. The talk will cover how to build such test setups from
parts like coaxial cabling, attenuators, RF splitter/combiners,
duplexers, etc.
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)
Hi community,
I feel a bit frustrated by how code review is going recently at osmocom.
Let me compare two larger feature branches:
There are weeks of review on 19 patches in osmo-hnbgw/cnpool,
and <24h from submit to merge on 14 patches in osmo-msc.
That may in some situations be ok and justified, but I feel that it is not:
The cnpool patch series for osmo-hnbgw spawned huge discussions and long delays
on account of minor issues: log lines, event names and comments. I said so, yet
it droned on and even spawned offspring.
None of the important features was part of code review:
larger design choices of the API, efficiency in handling the actual signalling,
correctness of the signalling. Maybe that's because all those were mint perfect
and no bugs anywhere, but I doubt that I'm really that good =)
And at the same time I was "just now" asked to review some patches for
osmo-msc, which changes an API that I have recently added and had ideas and
reasons for. Before I get a chance to even glance, I see that all the patches
are already merged! It is now basically too late to bring in my feedback,
because the patches are in, and why spend more time on it. Suck it up, bygones.
This very API that was being changed in osmo-msc in under 24 hours was itself
under code review scrutiny for at least three years.
Also I have (in my own free time) tried to get an improved logging timestamp
into libosmocore. This is tagging along for years and years now, because every
time over it is being blocked by minor details that are matters of taste. For
years I lose precious moments every time i have to read an 'extended-timestamp'
in osmo logging and identify the boundary of hours, minutes and seconds. This I
consider important. AFAIR the reasons for blocking the patches were,
objectively, all not important.
These examples are starkly unbalanced.
I'm sure you're aware of the bikeshed phenomenon -- it is a precise description
of what is happening. It would be great if we could turn that around a bit?
http://www.catb.org/jargon/html/B/bikeshedding.html
Let's say, I know from experience that it is hard to give good code review, so
count me in on this advice.
Let's still give all the code review we can, but let's keep in mind the actual
impact the particular code change has. If it goes in the "fringe detail"
bucket, let's mention it, but just let it pass if the author disagrees.
Hope you understand my frustration and maybe even agree.
Thanks,
~N
Hello Community,
Quick question: if I have to set up a network where the BTS is
physically distant from the MSC, such that either the A link or the
Abis link has to be carried across public Internet (or inside an
encrypted tunnel running over public Internet), would it be better to
colocate OsmoBSC next to OsmoMSC, running Abis across the Internet-
based hop, or colocate OsmoBSC next to OsmoBTS and have A running
across that long hop instead?
I recall hearing that the A interface carries significantly less
traffic than Abis, and therefore the recommended config is to have
OsmoBSC next to the BTS. However, it is only a vague recollection on
my part, without certainty, hence I thought I would ask here to
confirm, before I embark on a more detailed design of the proposed
production network in this config.
TIA,
Mychaela
Hi Harald,
> Is that patch already in gerrit somewhere?
https://github.com/dchard/osmo-bsc/tree/nokia_ultrasite
I managed to get some InSite units so now I have the whole range.
I tested all units, and this is the result:
1. InSite: it does not initiate the RSL LAPD even when the unit
reports: "waiting for lapd", the BSC needs to start the RSL bootstrap.
Non the less, multi BTS operation does work (tried it with HDSL
cascade), although I have seen some weird behavior between bootstraps
(just starting the BSC does not trigger the same behavior).
2. MetroSite: this unit does start the RSL bootstrap on its own when
the TRXes reaches "waiting for lapd" state, it does not wait for the
BSC to do it. Multi TRX, RF and BB hopping works as expected.
3. UltraSite: it runs exactly the same SW version as the MetroSite,
yet this unit also does not start the RSL bootstrap on its own even
when the unit reports: "waiting for lapd", the BSC needs to start the
RSL bootstrap. Only single TRX works in this case.
Also the MetroSite does not spits out garbage on the E1, the InSite
and UltraSite does.
In general one issue is that even after the BTS reset is ACKed, the
BSC allows the RSL LAPDs to be bootstrapped while the unit is already
resetting, and that fails obviously.
But more importantly, it seems that the whole LAPD logic is not
working exactly the same across the unit types. I wonder if we should
wait more for the RSL to be triggered by the BTS itself and should not
start the RSL bootstrap after CONF_COMPLETE received. I found no info
about who should initiate the RSL bootstrap: the BTS or the BSC?
Regards,
Csaba
<openbsc-request(a)lists.osmocom.org> ezt írta (időpont: 2023. jún. 30.,
P, 14:00):
>
> Send OpenBSC mailing list submissions to
> openbsc(a)lists.osmocom.org
>
> To subscribe or unsubscribe via email, send a message with subject or
> body 'help' to
> openbsc-request(a)lists.osmocom.org
>
> You can reach the person managing the list at
> openbsc-owner(a)lists.osmocom.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of OpenBSC digest..."
>
> Today's Topics:
>
> 1. Re: Nokia Site (Ultra, Metro) (Harald Welte)
> 2. Re: code review (Harald Welte)
> 3. Re: Nokia Site (Ultra, Metro) (Harald Welte)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Fri, 30 Jun 2023 12:08:43 +0200
> From: Harald Welte <laforge(a)osmocom.org>
> Subject: Re: Nokia Site (Ultra, Metro)
> To: Sipos Csaba <dchardware(a)gmail.com>
> Cc: "openbsc-request(a)lists.osmocom.org" <openbsc(a)lists.osmocom.org>
> Message-ID: <ZJ6pq/2V9WfA3yDw@nataraja>
> Content-Type: text/plain; charset=us-ascii
>
> Hi Sipos,
>
> On Fri, Jun 23, 2023 at 11:18:35AM +0200, Sipos Csaba wrote:
> > I checked RF and BB hopping with my MetroSite with my patch added, and
> > they both seem to work, multi-TRX was tested a couple days ago, that
> > also works with 2 TRXes. Obviously I did not tested every possible
> > hopping scenarios, but in both cases the node manager reported the
> > correct hopping states and I also checked with a spectrum analyzer.
>
> This is good news. Is that patch already in gerrit somewhere?
>
> > Anyway, at this point in time I don't see any particular issues that
> > indicates a BSC problem. One feature missing is the ability to
> > configure sectors (Nokia calls a sector a "BTS" while the base station
> > is called "BCF"). My question is, do we have any BTS type that has
> > sector configuration support so I can take a look how this was done
> > (if any) ?
>
> I think we never had support for this in OsmoBSC or even before in OpenBSC.
>
> In GSM/3GPP spec language, every sector is a BTS. The fact that many networks
> use sectorized cells is nothing that reflects anywhere in the specification or
> the terminology. It's an implementation detail.
>
> I think from the OsmoBSC point of view, a typical 3-sector site would still be
> three logical BTSs (in the data model / structures). It's "just" the respective
> manufacturer OML code would have to be adjusted to accomodate a situation where
> there are managed objects that only exist once per site, while others
> exist per BTS/TRX/...
>
> We have the same situation with Ericsson OM2000 support: Right now one
> can only have a single BTS per RBS, as our OM2000 code doesn't
> distinguish between MOs that exist once per site only (CF, TF, IS, ...)
> and MOs that exist for each BTS.
>
> --
> - 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)
>
> ------------------------------
>
> Message: 2
> Date: Fri, 30 Jun 2023 12:02:11 +0200
> From: Harald Welte <laforge(a)osmocom.org>
> Subject: Re: code review
> To: Neels Hofmeyr <nhofmeyr(a)sysmocom.de>
> Cc: openbsc(a)lists.osmocom.org
> Message-ID: <ZJ6oI2u2l9wAJ2Eo@nataraja>
> Content-Type: text/plain; charset=us-ascii
>
> Hi Neels,
>
> On Wed, Jun 21, 2023 at 05:37:55AM +0200, Neels Hofmeyr wrote:
> > Let me compare two larger feature branches:
> > There are weeks of review on 19 patches in osmo-hnbgw/cnpool,
> > and <24h from submit to merge on 14 patches in osmo-msc.
>
> I'm not saying this is good, but I think the difference is likely in terms of
> complexity of the related patches. Small patches doing simple to understand
> things are easy to review and hence likely to be merged more quickly.
>
> > The cnpool patch series for osmo-hnbgw spawned huge discussions and long delays
> > on account of minor issues: log lines, event names and comments. I said so, yet
> > it droned on and even spawned offspring.
>
> It would be good to have pointers to specific gerrit patches here. I'm trying to
> look at it now, but topic:cnpool has so many patches that it's hard to find which
> ones you're referring-to exactly.
>
> https://gerrit.osmocom.org/c/osmo-hnbgw/+/33133 has a discussion about
> parsing of routing area identities and using shared code rather than
> open-coded implementations in various places. I consider that relevant
> and not cosmetic/bikeshedding
>
> https://gerrit.osmocom.org/c/osmo-hnbgw/+/33173 contains a discussion
> about naming. Naming *is* important, particularly if it uses terms
> which already have well-established meaning, such as (here) what is a
> RANAP RESET and what is a "lost link". Code in maintained software
> development projects is written not merely to execute, but for other
> developers to read and continue to develop/maintain. If terminology is
> used in a wrong way, it is likely misunderstood by other developers,
> causing problems down the road when investigating bugs or adding new
> functionality. I am seeing quite a lot of questionable naming in
> general when it comes to SS7/SIGTRAN. Also, event/state names of FSMs
> may end up in log or VTY output, where it has the potential to confuse
> not just other developers but users.
>
> https://gerrit.osmocom.org/c/osmo-hnbgw/+/33178 contains a "maybe add a
> log line" spawning a discussion with relatively verbose messages in it.
> That might be one of the cases you are referring to? To be fair it was
> a "maybe" comment, so a simple one line response might have been
> sufficient.
>
> > None of the important features was part of code review:
> > larger design choices of the API, efficiency in handling the actual signalling,
> > correctness of the signalling.
>
> tbh, if there's a series of (it feels like) 30+ patches doing lots of complex
> stuff, it's hard to assume anyone is able to grasp those from reading
> the diffs. For correctness of signalling the test cases and
> associated pcaps are probably a better resource than gerrit patch
> review.
>
> > And at the same time I was "just now" asked to review some patches for
> > osmo-msc, which changes an API that I have recently added and had ideas and
> > reasons for.
>
> again, please provide specific pointers. Without that you are expecting
> every reader of this e-mail to re-read all osmo-msc patches of the last
> few weeks just to find out which specific one[s] you are referring to.
>
> It might have been https://gerrit.osmocom.org/c/osmo-msc/+/33358/1 where
> I overlooked a *resolved* comment "Not merging this one yet to give
> Neels a chance to review as well since he wrote the codec filter stuff
> that this is now modeled after." which I didn't see as the patch and
> many following it had two positive reviews and built correctly and hence
> I merged the entire series.
>
> My workflow is usually to perform code review, and then if I'm done and
> there are series or parts of series with V+1/R+2 merge those entire
> series/chunks, particularly if there are no unresolved comments.
> I'm [obviously] not going through each and every resolved comment of
> every patch in a series. Those are *resolved*.
>
> So while it was me who merged that series, and I'm of course sorry if
> that created problems, I acted in good faith (see above).
>
> I think if anyone wants to hold back a merge for whatever reason, make
> sure you put a -1 vote in so it becomes impossible to be merged by
> accident. Or at the very least make sure there is an unresolved comment
> which will produce a warning when attempting to merge.
>
> > Before I get a chance to even glance, I see that all the patches
> > are already merged! It is now basically too late to bring in my feedback,
> > because the patches are in, and why spend more time on it. Suck it up, bygones.
>
> It's not all lost: One can always send follow-up patches? Or revert the
> original patch and replace it? No release has been made in between, so
> no stable API has been set in stone that needs to continue to be
> supported.
>
> > Also I have (in my own free time) tried to get an improved logging timestamp
> > into libosmocore. This is tagging along for years and years now, because every
> > time over it is being blocked by minor details that are matters of taste. For
> > years I lose precious moments every time i have to read an 'extended-timestamp'
> > in osmo logging and identify the boundary of hours, minutes and seconds. This I
> > consider important. AFAIR the reasons for blocking the patches were,
> > objectively, all not important.
>
> I always found it mildly fascinating how many options, choices and
> formats (I think primarily you) introduce to the libosmocore logging.
> Like file name in front or file at the end? I think osmo* is the only
> software with which I've worked where the actual *format* of the log has
> many user-configurable options. I'm not talking about sub-systems,
> levels and targets! Now we even have multiple different formats for
> timestamps, and we are growing more of them. In my opinion, most of
> this is bloat. It just adds complexity to things happening at the
> runtime of the osmo-* code for something that could just as well be
> obtained with log post-processing (like converting from a unix epoch
> timestamp to whatever human readable format the reader desires). We've
> already merged a lot of this over the years.
>
> To me, the problem with all those many options is that it becomes
> very difficult to have any software parsing/analyzing osmo* logs, as
> every deployment might be chosing a different combination of "this is my
> personal favorite of ordering the portions of a log line" or "this is my
> personal favorite of formatting a timestamp".
>
> But now introducing *timezones* into the program
> (https://gerrit.osmocom.org/c/libosmocore/+/32043) really goes over the
> top for me. Timezones are handled at the operating system level / libc.
>
> > Let's still give all the code review we can, but let's keep in mind the actual
> > impact the particular code change has. If it goes in the "fringe detail"
> > bucket, let's mention it, but just let it pass if the author disagrees.
>
> To be honest, I don't really see much of this here. I see a lot of
> optional / non-critical stuff like "typo here" or "maybe ..." but I
> rarely see "I absolutely demand that you must ...".
>
> 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)
>
> ------------------------------
>
> Message: 3
> Date: Fri, 30 Jun 2023 12:09:27 +0200
> From: Harald Welte <laforge(a)osmocom.org>
> Subject: Re: Nokia Site (Ultra, Metro)
> To: Sipos Csaba <dchardware(a)gmail.com>
> Cc: "openbsc-request(a)lists.osmocom.org" <openbsc(a)lists.osmocom.org>
> Message-ID: <ZJ6p15URO27eoMei@nataraja>
> Content-Type: text/plain; charset=us-ascii
>
> On Sun, Jun 25, 2023 at 03:08:51PM +0200, Sipos Csaba wrote:
> > I tested up to four TRX with the Metro and that works as well. Once
> > everything is tested and working I will provide example files, and try
> > to updated the Nokia specific wiki as it is quite outdated (info is
> > from the NITB era).
>
> Thanks in advance!
>
> > Will try to look at Ericsson and BS-11, maybe there are some clues
> > about sectors there.
>
> See my other mail, unfortunately it's not something implemented.
> --
> - 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)
>
> ------------------------------
>
> Subject: Digest Footer
>
> _______________________________________________
> OpenBSC mailing list -- openbsc(a)lists.osmocom.org
> To unsubscribe send an email to openbsc-leave(a)lists.osmocom.org
>
>
> ------------------------------
>
> End of OpenBSC Digest, Vol 104, Issue 8
> ***************************************