From hwelte at sysmocom.de  Fri Oct  2 07:59:55 2020
From: hwelte at sysmocom.de (Harald Welte)
Date: Fri, 2 Oct 2020 09:59:55 +0200
Subject: Application specific VTY attributes
In-Reply-To: <20200923135831.GA20875@my.box>
References: <b79fc27a-e7e5-86c1-01a5-fd7828b3f8e8@sysmocom.de>
 <20200923135831.GA20875@my.box>
Message-ID: <20201002075955.GK7064@nataraja>

Sorry for the late response,

On Wed, Sep 23, 2020 at 03:58:31PM +0200, Neels Hofmeyr wrote:
> On Wed, Sep 23, 2020 at 05:40:39PM +0700, Vadim Yanitskiy wrote:
> >   struct cmd_node foo_node = {
> >     .usrattr = (1 << FOO_VTY_ATTR_RESTART_FULL),  // (!)
> >   };
> 
> this way we could no longer see that a newly added command failed to set the
> correct user attribute. i.e. I add a new DEFUN, I fail to remember setting
> attributes, and thus it shows some attribute which is wrong. If each command
> gets explicit attributes, errors like that are unlikely: If I add a DEFUN and
> forget to set the right attribute, there will be no attribute, and a user
> reading the vty reference will ask us to fix, without the need to try and fail
> first.

we could have a checker script that issues warnings, similar to the value_string
checker?  We could indeed also deprecate DEFUN (make it print a warning for now)
while things are migrated to those with attributes...

> libosmocore defined attrs would be useful. 

ACK.

> I know that the VTY code disregards osmo_ completely, but I'd still favor
> prepending OSMO_* to new enum values.

I'm -as usual - in favor of consistency.  So if the old code has no prefix, any
additions should also not have prefixes.

> btw, each and every osmo_fsm caller and now also each and every vty attribute
> defining code defines a left-shift macro like
> 
> 	#define S(x) (1 << (x))
> 
> it's a bit silly to repeat this definition all over the place.
> Added to libosmocore, it would have to be called OSMO_S()...
> makes everything longer. maybe nevermind, just thinking aloud.
> }

Yes, that is a known issue..

> > dexter wrote:
> > > Maybe we could have some standard letters defined in libosmocore
> > > for standard situations:
> > > F = Full restart required
> > > I = Applied Immediately
> > 
> > ACK.  We can also agree that generic (pre-defined) attributes use upper
> > case letters, while the application specific ones use lower case?

I like that approach

> Then again, 'F' should mean the same thing in various osmo-* programs?

yes.

> But consider, having attributes of upper case and lower case of the same letter
> could be somewhat confusing to users. 

Well, given that in iptables, lowercase are matches and uppercase are targets, I guess
it's clear I don't share such a concern.  But maybe it is confusing to Windows users
who are taught for decades that there is no distinction between upper and lower case?
I'm willing to accept that there is a concern.

> libosmocore assigns letters, applications assign numbers and special
> characters??

I would go for the other way around, as I would expect libosmocore to define
fewer 'common' attributes, while applications may have more different flags.
So as there are fewer numbers than lstters, I'd go for libosmocore=numbers.

Please note that in the end it's not just libosmcoore, but also
libosmogb, libosmo-abis, libosmo-sccp, ...

Regards,
	Harald
-- 
- Harald Welte <hwelte at 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


From vyanitskiy at sysmocom.de  Sat Oct  3 10:27:54 2020
From: vyanitskiy at sysmocom.de (Vadim Yanitskiy)
Date: Sat, 3 Oct 2020 17:27:54 +0700
Subject: Application specific VTY attributes
In-Reply-To: <20201002075955.GK7064@nataraja>
References: <b79fc27a-e7e5-86c1-01a5-fd7828b3f8e8@sysmocom.de>
 <20200923135831.GA20875@my.box> <20201002075955.GK7064@nataraja>
Message-ID: <520d9a52-616c-615e-ca53-013788dc1339@sysmocom.de>

Hi all,

On 10/2/20 2:59 PM, Harald Welte wrote:

> On Wed, Sep 23, 2020 at 03:58:31PM +0200, Neels Hofmeyr wrote:
>> On Wed, Sep 23, 2020 at 05:40:39PM +0700, Vadim Yanitskiy wrote:
>>>   struct cmd_node foo_node = {
>>>     .usrattr = (1 << FOO_VTY_ATTR_RESTART_FULL),  // (!)
>>>   };
>> this way we could no longer see that a newly added command failed to set the
>> correct user attribute. i.e. I add a new DEFUN, I fail to remember setting
>> attributes, and thus it shows some attribute which is wrong. If each command
>> gets explicit attributes, errors like that are unlikely: If I add a DEFUN and
>> forget to set the right attribute, there will be no attribute, and a user
>> reading the vty reference will ask us to fix, without the need to try and fail
>> first.
> we could have a checker script that issues warnings, similar to the value_string
> checker?  We could indeed also deprecate DEFUN (make it print a warning for now)
> while things are migrated to those with attributes...

in general, I agree with Neels.  This approach would also require us to
break ABI, so osmo-* binaries compiled against an old libosmocore
version might 'acquire' unexpected attributes due to mismatching size of
struct cmd_node.

Deprecating DEFUN does not sound like a reasonable way to me, as we're
just introducing a new feature.  Imagine what compilation logs of
unmaintained projects like osmocom-bb would turn into; they already
contain lots of deprecation warnings :/

After a productive discussion with Philipp, we decided that it does not
make sense to have FOO_VTY_ATTR_RESTART_FULL at all.  It's obvious that
all commands apply on full program restart, right?  Instead, we took the
opposite approach: let's state in the VTY reference that "all VTY
commands take effect on full program restart, unless stated otherwise",
and introduce a global attribute indicating that a given command applies
immediately (CMD_ATTR_IMMEDIATE).

>> libosmocore defined attrs would be useful. 
> ACK.

See https://gerrit.osmocom.org/c/libosmocore/+/20309/1 and
https://gerrit.osmocom.org/c/libosmocore/+/19577.

Here is a brief summary:

 * if a given command applies on application specific event (e.g.
OML/RSL link [re]establishment), then assign application specific
attributes;
 * if a given command applies immediately, then assign global attribute
CMD_ATTR_IMMEDIATE (defined in libosmocore);
 * if a given command applies on full program restart, then there is no
need to assign attributes - it's implicit default.

>> I know that the VTY code disregards osmo_ completely, but I'd still favor
>> prepending OSMO_* to new enum values.
> I'm -as usual - in favor of consistency.  So if the old code has no prefix, any
> additions should also not have prefixes.

ACK.

>>> dexter wrote:
>>>> Maybe we could have some standard letters defined in libosmocore
>>>> for standard situations:
>>>> F = Full restart required
>>>> I = Applied Immediately
>>> ACK.  We can also agree that generic (pre-defined) attributes use upper
>>> case letters, while the application specific ones use lower case?
> I like that approach

This should eventually be stated in the VTY reference / documentation.

We can even add a check to libosmocore, so vty_init() would at least
print a warning if an upper-case letter is used in the application
specific attributes.  I already submitted duplicate detection check:

https://gerrit.osmocom.org/c/libosmocore/+/20411

> I would go for the other way around, as I would expect libosmocore to define
> fewer 'common' attributes, while applications may have more different flags.
> So as there are fewer numbers than lstters, I'd go for libosmocore=numbers.
> 
> Please note that in the end it's not just libosmcoore, but also
> libosmogb, libosmo-abis, libosmo-sccp, ...

This will be discussed in a follow-up E-mail.

Best regards,
Vadim.

-- 
- Vadim Yanitskiy <vyanitskiy at 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


From vyanitskiy at sysmocom.de  Sat Oct  3 12:52:14 2020
From: vyanitskiy at sysmocom.de (Vadim Yanitskiy)
Date: Sat, 3 Oct 2020 19:52:14 +0700
Subject: [Proposal] VTY attributes in libraries
In-Reply-To: <520d9a52-616c-615e-ca53-013788dc1339@sysmocom.de>
References: <b79fc27a-e7e5-86c1-01a5-fd7828b3f8e8@sysmocom.de>
 <20200923135831.GA20875@my.box> <20201002075955.GK7064@nataraja>
 <520d9a52-616c-615e-ca53-013788dc1339@sysmocom.de>
Message-ID: <ab61d9b8-065f-43c6-eca1-146b371e9458@sysmocom.de>

Hi all again,

this is a follow-up post continuing discussion on the VTY attributes.
Yesterday Philipp reached me out regarding adding 'when it applies'
attributes to VTY commands registered by our shared libraries, i.e.
libosmo-*.  The problem is that the current API does not allow to
register description and flag letters for such commands.

My initial idea was to introduce a simple function that would merge a
given set of library specific attributes into the application specific
attributes provided by the API user (see struct vty_app_info).  However,
this is not a solution, because there can be multiple libraries an
application dynamically links to, and there can be collisions not only
between attributes defined by a library and the application itself, but
what's even more problematic, between different libraries too.

        +----------+
    +---| LIB CORE |-----+
    |   +----------+     |
    |       |            |
    |   +---x---+    +---x---+
    |   | LIB A |    | LIB B |
    |   +-------+    +-------+
    |       |            |
    |   +---x------------x---+
    +---x    APPLICATION     |
        +--------------------+

This illustrates a typical situation when not only the 'APPLICATION'
itself defines its own VTY commands, and thus its own VTY attributes,
but also the libraries it is dynamically linked to optionally register
VTY commands and the related attributes.

Given that a single VTY command may store up to 32 unique attributes
(because it's a bit-mask based on unsigned int), we somehow need to
ensure that there is no clashes between the attributes and their
associated flag letters.

I also thought about reserving 16 LSBs of the bit-mask for attributes
defined by libraries, so this way all libosmo-* would need to somehow
share these reserved 16 bits, but...  Given that a VTY command can
either be an application's command *or* a library's command, splitting
the bit-mask does not make that much sense.

After a bit of brainstorming, I came up with a proposal:

a) applications are allowed to register up to 32 unique attributes with
optional flags: some symbols (to be discussed), numbers, or lowercase
letters;

b) libraries get their own *global* bit-space for attributes with
optional flags: some symbols (to be discussed) or uppercase letters;

c) all libraries *share* 32 unique attributes (and thus flags), because
an application may be using VTY commands of several libraries at the
same time;
c1) in other words, if let's say libosmo-abis defines attribute (1 <<
0), then none of the other libraries is allowed to redefine it;

d) all attributes belonging to libraries, together with their
description and optional flag letters, to be defined in a centralized
place - libosmocore (more precisely, libosmovty);
d1) this way we ensure that there are no clashes: neither between the
attribute values, nor between their flag letters.

A downside of this approach is that libosmovty would need to distinguish
VTY commands belonging to an application from commands registered by the
libraries it depends on.  This way it would be possible to pick the
correct attribute description (from struct vty_app_info or from
libosmocore) when generating the VTY documentation.  I propose:

e) to introduce one more global attribute CMD_ATTR_LIBCMD, and 'equip'
all VTY commands registered by libraries with it;
e1) in order to avoid mangling all existing DEFUNs, we can introduce
special install_element_lib() / install_element_ve_lib() wrappers and
use them.

I hope I have not forgotten anything.
Looking forward to know your opinion.

Best regards,
Vadim.

-- 
- Vadim Yanitskiy <vyanitskiy at 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


From laforge at gnumonks.org  Sat Oct  3 16:05:34 2020
From: laforge at gnumonks.org (Harald Welte)
Date: Sat, 3 Oct 2020 18:05:34 +0200
Subject: gerrit upgade / new syntax for push to topics
Message-ID: <20201003160534.GF3994@nataraja>

Dear all,

I did a major upgrade from the (unsupported) 2.16.x gerrit version to the latest
3.2.x series.

For a detailed list of changes, please see the documentation / changelog.

At least one change affects our day-to-day usage: How to push to a 'tpopic'.

While in the past we would have done something like

	git push gerrit HEAD:refs/for/master/fr

we now need to write

	git push gerrit HEAD:refs/for/master%topic=fr

Don't ask me why that change was made...

Regards,
	Harald
-- 
- Harald Welte <laforge at gnumonks.org>           http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
                                                  (ETSI EN 300 175-7 Ch. A6)


From pmaier at sysmocom.de  Mon Oct  5 15:17:18 2020
From: pmaier at sysmocom.de (Philipp Maier)
Date: Mon, 5 Oct 2020 17:17:18 +0200
Subject: [Proposal] VTY attributes in libraries
In-Reply-To: <ab61d9b8-065f-43c6-eca1-146b371e9458@sysmocom.de>
References: <b79fc27a-e7e5-86c1-01a5-fd7828b3f8e8@sysmocom.de>
 <20200923135831.GA20875@my.box> <20201002075955.GK7064@nataraja>
 <520d9a52-616c-615e-ca53-013788dc1339@sysmocom.de>
 <ab61d9b8-065f-43c6-eca1-146b371e9458@sysmocom.de>
Message-ID: <9779145f-13e5-0b03-89bf-cfc135ef53d5@sysmocom.de>

Hello Vadim,

I understand a,b,c,c1,d,d1 but I am a bit lost at e and e1.

In d you suggest to define the attributes in a centralized place to 
avoid clashes. I think this is fine. If we look at 
include/osmocom/vty/command.h than in enum node_type the node ids for 
libosmo-abis and libosmo-sccp are stored. Given that I think it would be 
acceptable to add the flags we need for libosmo-sccp and libosmo-abis in 
the enum next to CMD_ATTR_IMMEDIATE.

btw.: In libosmo-sccp there is one situation where the changes take 
effect when the VTY node is exited. At least this is generic enough to 
justify a CMD_ATTR_NODEEXIT.

best regards,
Philipp

-- 
Philipp Maier <pmaier at 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


From vyanitskiy at sysmocom.de  Mon Oct  5 17:12:44 2020
From: vyanitskiy at sysmocom.de (Vadim Yanitskiy)
Date: Tue, 6 Oct 2020 00:12:44 +0700
Subject: [Proposal] VTY attributes in libraries
In-Reply-To: <9779145f-13e5-0b03-89bf-cfc135ef53d5@sysmocom.de>
References: <b79fc27a-e7e5-86c1-01a5-fd7828b3f8e8@sysmocom.de>
 <20200923135831.GA20875@my.box> <20201002075955.GK7064@nataraja>
 <520d9a52-616c-615e-ca53-013788dc1339@sysmocom.de>
 <ab61d9b8-065f-43c6-eca1-146b371e9458@sysmocom.de>
 <9779145f-13e5-0b03-89bf-cfc135ef53d5@sysmocom.de>
Message-ID: <60cf8154-0e08-d3d2-d42e-3f66e81ff0b0@sysmocom.de>

Hi Philipp,

On 10/5/20 10:17 PM, Philipp Maier wrote:

> I understand a,b,c,c1,d,d1 but I am a bit lost at e and e1.

it's just an implementation detail that should not affect the process of
adding attributes.  I came up with the implementation, maybe it would be
easier to understand looking at the code:

https://gerrit.osmocom.org/c/libosmocore/+/20440 vty/command: add
CMD_ATTR_LIB_COMMAND and install() API wrappers
https://gerrit.osmocom.org/c/libosmocore/+/20447 vty: introduce API for
the library specific attributes

In other words, vty_dump_element() needs to know whether a given command
is a library command or it belongs to an application.  Thanks to
CMD_ATTR_LIB_COMMAND, this function can print proper attribute
description and flag letter (if present).

We don't want to equip each DEFUN() in libraries with this attribute
*manually*, so that's why I came up with install_lib_element() and
install_lib_element_ve().  Patches are in Gerrit.

> btw.: In libosmo-sccp there is one situation where the changes take
> effect when the VTY node is exited. At least this is generic enough to
> justify a CMD_ATTR_NODEEXIT.

ACK, I'll add this one as a global attribute.  I am pretty sure we can
benefit from having this attribute globally some day.

Best regards,
Vadim.

-- 
- Vadim Yanitskiy <vyanitskiy at 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


From nhofmeyr at sysmocom.de  Mon Oct  5 18:40:09 2020
From: nhofmeyr at sysmocom.de (Neels Hofmeyr)
Date: Mon, 5 Oct 2020 20:40:09 +0200
Subject: Application specific VTY attributes
In-Reply-To: <520d9a52-616c-615e-ca53-013788dc1339@sysmocom.de>
References: <b79fc27a-e7e5-86c1-01a5-fd7828b3f8e8@sysmocom.de>
 <20200923135831.GA20875@my.box> <20201002075955.GK7064@nataraja>
 <520d9a52-616c-615e-ca53-013788dc1339@sysmocom.de>
Message-ID: <20201005184009.GC31668@my.box>

On Sat, Oct 03, 2020 at 05:27:54PM +0700, Vadim Yanitskiy wrote:
> [...] it does not
> make sense to have FOO_VTY_ATTR_RESTART_FULL at all.  It's obvious that
> all commands apply on full program restart, right?  Instead, we took the

Depends on how you read this. I thought this indicates the *minimum*
requirement to get a config to take effect. If a config has the attribute
"ATTR_RESTART_FULL" it means there is no way to apply this config unless i
actually restart the program. From that aspect it could be more elegant to
leave config items without attributes until someone looked at it and determined
the minimum requirement. Otherwise we'd tag commands as "RESTART_FULL" which
don't actually require a full restart.

> > I'm -as usual - in favor of consistency.  So if the old code has no prefix, any
> > additions should also not have prefixes.

And me as usual in favor of throwing out silly quirks that exist only "because
we always did it that way". I'd favor the approach that everything in
libosmocore should have the "osmo_"/"OSMO_" prefix.
But I can accept that I disagree and think it's quirky and strange, but am
not going to get my way there. See the recent bssmap_le patches...

~N


From pmaier at sysmocom.de  Mon Oct  5 19:28:20 2020
From: pmaier at sysmocom.de (Philipp Maier)
Date: Mon, 5 Oct 2020 21:28:20 +0200
Subject: [Proposal] VTY attributes in libraries
In-Reply-To: <60cf8154-0e08-d3d2-d42e-3f66e81ff0b0@sysmocom.de>
References: <b79fc27a-e7e5-86c1-01a5-fd7828b3f8e8@sysmocom.de>
 <20200923135831.GA20875@my.box> <20201002075955.GK7064@nataraja>
 <520d9a52-616c-615e-ca53-013788dc1339@sysmocom.de>
 <ab61d9b8-065f-43c6-eca1-146b371e9458@sysmocom.de>
 <9779145f-13e5-0b03-89bf-cfc135ef53d5@sysmocom.de>
 <60cf8154-0e08-d3d2-d42e-3f66e81ff0b0@sysmocom.de>
Message-ID: <a1d24070-2b1e-fc64-d9a0-8dcafa2442ff@sysmocom.de>

Hello Vadim,

> it's just an implementation detail that should not affect the process of
> adding attributes.  I came up with the implementation, maybe it would be
> easier to understand looking at the code:

Thanks for pointing at the code. I have read through and I think I 
understand it now. I have uploaded a patch on how I would add a new 
attribute:

https://gerrit.osmocom.org/c/libosmocore/+/20460

There is also still the open question on how we should tag commands that 
perform a node change, like this one here: 
https://gerrit.osmocom.org/c/osmo-trx/+/20319/1/CommonLibs/trx_vty.c#100

While going through all the commands of osmo-bsc, osmo-mgw, osmo-bts, 
osmo-trx and osmo-pcu I have always CMD_ATTR_IMMEDIATE on commands that 
change the VTY node, even when the command does nothing except changing 
the VTY node (which indeed applies immediately).

In my opinion the VTY commands that change the nodes should be excluded 
from the attributes, maybe by puting a CMD_ATTR_EXCLUDE on them. The 
reason for this is because those commands are used to walk through the 
VTY, they do not set any config value. This is comparable to a tree 
structure, where only the leafs are actually of interest.

When looking deeper into this one can find that the things are not as 
simple as they may seem. There are VTY commands out there that change 
the node and at the same time they allocate an object. Like the trunk 
command in osmo-mgw. What should we do with those. If the trunk already 
exists, then it is put in the VTY context and the node is changed, 
basically nothing happens. There may be commands behind the node where 
some apply immediately and where some do require a full restart. What 
kind of attribute would we assign the the trunk command? Als here I 
would argue to exclude it. In the end the commands perform the 
configuration and even if the object is allocated immediately, it still 
requires to get configured by the commands and here the final decision 
is made whether a full restart is required or not.

best regards.
Philipp

-- 
Philipp Maier <pmaier at 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


From ivan.babanov at gmail.com  Wed Oct  7 22:14:03 2020
From: ivan.babanov at gmail.com (Ivan Babanov)
Date: Thu, 8 Oct 2020 01:14:03 +0300
Subject: E1 line debug L1/L2
Message-ID: <CACWjWChT4q-bDB+SuR6CiWe8A1Hg+TQWMSpdBbN5y9HUg67Tcw@mail.gmail.com>

Hello all,

Brief question. Is it possible to debug E1 line by connecting it to the 2nd
port of the same NIC making a wired loop? Is it enough to open->ioctl->read
from /dev/dahdi/channel to get a stream of LAPD SABME messages transmitted
by BSC?

A bit more details for those interested

I'm still trying to bring up BTS Nokia Flexi with OSMO-BSC.
I'm using an E1 card Digium TE405P on the server side.
OSMO-BSC is connected with Nokia BTS via a single E1 line.
Looks like on Level1 everything is ok because BTS can detect the link and
raise an alarm if the wire is getting disconnected.
I can observe some data from timeslots on BTS side and if some channel is
configured as D-Channel in /etc/dahdi/system I see transmission of block
"01111110".
But the problem is that LAPD link is not establishing. I can't find any
tries on BTS side and BSC does not receive anything from BTS, just set of
SABME messages in PCAP file.
T200 expires and so on. I tried various T200 values. So, now it looks for
me like L1 does not receive anything from L2 on BSC side and nothing is
transmitted over the wire to BTS.

dahdi_tool shows status "OK"

So, my nearest plan to check data transmission over wired loopback.

Thank you
Babanov Ivan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20201008/ce5ed6d5/attachment.htm>

From 246tnt at gmail.com  Thu Oct  8 12:06:54 2020
From: 246tnt at gmail.com (Sylvain Munaut)
Date: Thu, 8 Oct 2020 14:06:54 +0200
Subject: E1 line debug L1/L2
In-Reply-To: <CACWjWChT4q-bDB+SuR6CiWe8A1Hg+TQWMSpdBbN5y9HUg67Tcw@mail.gmail.com>
References: <CACWjWChT4q-bDB+SuR6CiWe8A1Hg+TQWMSpdBbN5y9HUg67Tcw@mail.gmail.com>
Message-ID: <CAHL+j0_m3iv9XOM8-WSRZzXSkQiZDsvLHjTWHtr1aX+qSM1h=Q@mail.gmail.com>

Recent osmo-bsc accept a 'pcap' argument under the e1_input config.

e1_input
 pcap /tmp/e1.pcap
 e1_line 0 driver dahdi

This will record all E1 traffic in that pcap for analysis with wireshark.

Cheers,

   Sylvain


From laforge at osmocom.org  Thu Oct  8 17:29:34 2020
From: laforge at osmocom.org (Harald Welte)
Date: Thu, 8 Oct 2020 19:29:34 +0200
Subject: E1 line debug L1/L2
In-Reply-To: <CACWjWChT4q-bDB+SuR6CiWe8A1Hg+TQWMSpdBbN5y9HUg67Tcw@mail.gmail.com>
References: <CACWjWChT4q-bDB+SuR6CiWe8A1Hg+TQWMSpdBbN5y9HUg67Tcw@mail.gmail.com>
Message-ID: <20201008172934.GA3994@nataraja>

Hi Ivan,

On Thu, Oct 08, 2020 at 01:14:03AM +0300, Ivan Babanov wrote:
> Brief question. Is it possible to debug E1 line by connecting it to the 2nd
> port of the same NIC making a wired loop? 

well, you would normally need a series resistor for the tapping port, you cannot
just put them in parallel without signal degradation.

You can check https://osmocom.org/projects/e1-tap/wiki for a small OSHW
device that has the series resistors built in, and which provides two tap
ports (one for each direction).  For full-duplex sniffing of one E1 line, you
obviously need two other ports.

> Is it enough to open->ioctl->read
> from /dev/dahdi/channel to get a stream of LAPD SABME messages transmitted
> by BSC?

not /dev/dahdi/channel.  On that device you need a special ioctl.

you could look into osmo-e1-recorder, if you wanted to do tracing with DAHDI
ports behind a osmo-e1-tap.

> I'm still trying to bring up BTS Nokia Flexi with OSMO-BSC.

great.

> I'm using an E1 card Digium TE405P on the server side.
> OSMO-BSC is connected with Nokia BTS via a single E1 line.
> Looks like on Level1 everything is ok because BTS can detect the link and
> raise an alarm if the wire is getting disconnected.

great.

> I can observe some data from timeslots on BTS side and if some channel is
> configured as D-Channel in /etc/dahdi/system I see transmission of block
> "01111110".

that's the flag octets

> But the problem is that LAPD link is not establishing. I can't find any
> tries on BTS side and BSC does not receive anything from BTS, just set of
> SABME messages in PCAP file.

That's somewhat of a contradiction.

* SABME is the first frame used to establish a LAPD data link
* it should be sent from BTS to BSC
* the BSC responds with UA

> T200 expires and so on. I tried various T200 values. So, now it looks for
> me like L1 does not receive anything from L2 on BSC side and nothing is
> transmitted over the wire to BTS.

it would be useful to see your configs. I would guess most likely you
didn't select the same timeslot for
signaling on both sides.

-- 
- Harald Welte <laforge at osmocom.org>            http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
                                                  (ETSI EN 300 175-7 Ch. A6)


From ivan.babanov at gmail.com  Fri Oct  9 19:51:02 2020
From: ivan.babanov at gmail.com (Ivan Babanov)
Date: Fri, 9 Oct 2020 22:51:02 +0300
Subject: E1 line debug L1/L2
In-Reply-To: <20201008172934.GA3994@nataraja>
References: <CACWjWChT4q-bDB+SuR6CiWe8A1Hg+TQWMSpdBbN5y9HUg67Tcw@mail.gmail.com>
 <20201008172934.GA3994@nataraja>
Message-ID: <CACWjWCgafiGjrQOMVRdLB9sbSHEy+0BDKYtYGqv22y-Usja_MA@mail.gmail.com>

Hello Harald, I'm attaching config and pcap. Hopefully mailserver allows
attachments.
Regarding SABME message it's correct behaviour, I checked twice, BSC
initializes link establishment and BTS responds with UA

Today I was digging in dahdi-linux docs again and I see that it uses BKL
mechanisms in the kernel. Is it still valid? Because BKL was removed from
kernels starting from 2.6.39
Looks like I need to re-build kernel with BKL enabled (if it's possible.
Not sure if it's possible). Other solution is to install CentOS6 it uses
kernels 2.6.x
What linux kernel do you use on your server with dadhi E1 adapters?

Thank you
Babanov Ivan

??, 8 ???. 2020 ?. ? 20:30, Harald Welte <laforge at osmocom.org>:

> Hi Ivan,
>
> On Thu, Oct 08, 2020 at 01:14:03AM +0300, Ivan Babanov wrote:
> > Brief question. Is it possible to debug E1 line by connecting it to the
> 2nd
> > port of the same NIC making a wired loop?
>
> well, you would normally need a series resistor for the tapping port, you
> cannot
> just put them in parallel without signal degradation.
>
> You can check https://osmocom.org/projects/e1-tap/wiki for a small OSHW
> device that has the series resistors built in, and which provides two tap
> ports (one for each direction).  For full-duplex sniffing of one E1 line,
> you
> obviously need two other ports.
>
> > Is it enough to open->ioctl->read
> > from /dev/dahdi/channel to get a stream of LAPD SABME messages
> transmitted
> > by BSC?
>
> not /dev/dahdi/channel.  On that device you need a special ioctl.
>
> you could look into osmo-e1-recorder, if you wanted to do tracing with
> DAHDI
> ports behind a osmo-e1-tap.
>
> > I'm still trying to bring up BTS Nokia Flexi with OSMO-BSC.
>
> great.
>
> > I'm using an E1 card Digium TE405P on the server side.
> > OSMO-BSC is connected with Nokia BTS via a single E1 line.
> > Looks like on Level1 everything is ok because BTS can detect the link and
> > raise an alarm if the wire is getting disconnected.
>
> great.
>
> > I can observe some data from timeslots on BTS side and if some channel is
> > configured as D-Channel in /etc/dahdi/system I see transmission of block
> > "01111110".
>
> that's the flag octets
>
> > But the problem is that LAPD link is not establishing. I can't find any
> > tries on BTS side and BSC does not receive anything from BTS, just set of
> > SABME messages in PCAP file.
>
> That's somewhat of a contradiction.
>
> * SABME is the first frame used to establish a LAPD data link
> * it should be sent from BTS to BSC
> * the BSC responds with UA
>
> > T200 expires and so on. I tried various T200 values. So, now it looks for
> > me like L1 does not receive anything from L2 on BSC side and nothing is
> > transmitted over the wire to BTS.
>
> it would be useful to see your configs. I would guess most likely you
> didn't select the same timeslot for
> signaling on both sides.
>
> --
> - Harald Welte <laforge at osmocom.org>
> http://laforge.gnumonks.org/
>
> ============================================================================
> "Privacy in residential applications is a desirable marketing option."
>                                                   (ETSI EN 300 175-7 Ch.
> A6)
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20201009/e867b671/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: osmo-bsc.insite.cfg
Type: application/octet-stream
Size: 1393 bytes
Desc: not available
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20201009/e867b671/attachment.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 2020005-insite.pcap
Type: application/octet-stream
Size: 4819 bytes
Desc: not available
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20201009/e867b671/attachment-0001.obj>

From radiarisainanasitraka at yahoo.fr  Sat Oct 10 11:22:45 2020
From: radiarisainanasitraka at yahoo.fr (Radiarisainana Sitraka)
Date: Sat, 10 Oct 2020 11:22:45 +0000 (UTC)
Subject: Osmocom Phone forcing encryption
In-Reply-To: <mailman.7.1602244800.43875.openbsc@lists.osmocom.org>
References: <mailman.7.1602244800.43875.openbsc@lists.osmocom.org>
Message-ID: <355681344.115399.1602328965160@mail.yahoo.com>

Hello,i would like to ask if it's possible to forcing the encryption of osmcom phone like A5/1 or A5/2 or A5/3? 
How to process it?



Chears,
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20201010/7314a8a6/attachment.htm>

From djks74 at gmail.com  Sat Oct 10 11:29:51 2020
From: djks74 at gmail.com (Pasar Segar)
Date: Sat, 10 Oct 2020 18:29:51 +0700
Subject: Osmocom Phone forcing encryption
In-Reply-To: <355681344.115399.1602328965160@mail.yahoo.com>
References: <mailman.7.1602244800.43875.openbsc@lists.osmocom.org>
 <355681344.115399.1602328965160@mail.yahoo.com>
Message-ID: <CANWiJYh9sWmeQ-Pq8cNY7JpPrt-Y_sgqXUJjg8mhooPDLnZHtw@mail.gmail.com>

Your question is abit confusing, please more specific,
osmocom BB phone? or using osmocom stacks?

osmocom stack you can set to any encryption on the config.

On Sat, Oct 10, 2020 at 6:23 PM Radiarisainana Sitraka <
radiarisainanasitraka at yahoo.fr> wrote:

> Hello,
> i would like to ask if it's possible to forcing the encryption of osmcom
> phone like A5/1 or A5/2 or A5/3?
> How to process it?
>
>
>
>
> Chears,
>


-- 
Best Regards,
Sandi
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20201010/7c92cfff/attachment.htm>

From laforge at gnumonks.org  Sat Oct 10 15:48:26 2020
From: laforge at gnumonks.org (Harald Welte)
Date: Sat, 10 Oct 2020 17:48:26 +0200
Subject: E1 line debug L1/L2
In-Reply-To: <CACWjWCgafiGjrQOMVRdLB9sbSHEy+0BDKYtYGqv22y-Usja_MA@mail.gmail.com>
References: <CACWjWChT4q-bDB+SuR6CiWe8A1Hg+TQWMSpdBbN5y9HUg67Tcw@mail.gmail.com>
 <20201008172934.GA3994@nataraja>
 <CACWjWCgafiGjrQOMVRdLB9sbSHEy+0BDKYtYGqv22y-Usja_MA@mail.gmail.com>
Message-ID: <20201010154826.GI843576@nataraja>

The pcap file shows that OsmoBSC is sending SABME requests but that the BTS
never responds to any of them.  I would assume that somehow the timeslot
configuration on BTS and BSC side don't agree, i.e. you're sending the SABME
on a timeslot that the BTS doesn't expect it on.

I remember that the E1 related configuration on the Noika BTS (at least the InSite)
is relatively complex.  Might be best to check all related settings.

-- 
- Harald Welte <laforge at gnumonks.org>           http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
                                                  (ETSI EN 300 175-7 Ch. A6)


From laforge at gnumonks.org  Sat Oct 10 15:43:12 2020
From: laforge at gnumonks.org (Harald Welte)
Date: Sat, 10 Oct 2020 17:43:12 +0200
Subject: E1 line debug L1/L2
In-Reply-To: <CACWjWCgafiGjrQOMVRdLB9sbSHEy+0BDKYtYGqv22y-Usja_MA@mail.gmail.com>
References: <CACWjWChT4q-bDB+SuR6CiWe8A1Hg+TQWMSpdBbN5y9HUg67Tcw@mail.gmail.com>
 <20201008172934.GA3994@nataraja>
 <CACWjWCgafiGjrQOMVRdLB9sbSHEy+0BDKYtYGqv22y-Usja_MA@mail.gmail.com>
Message-ID: <20201010154312.GG843576@nataraja>

Hi Ivan,

On Fri, Oct 09, 2020 at 10:51:02PM +0300, Ivan Babanov wrote:
> Regarding SABME message it's correct behaviour, I checked twice, BSC
> initializes link establishment and BTS responds with UA

I never worked a lot with Nokia, so you may be right.  In the 3GPP specs
(and as implemented in Siemens), the BTS initiates the data link to the BSC.

> Today I was digging in dahdi-linux docs again and I see that it uses BKL
> mechanisms in the kernel. Is it still valid? Because BKL was removed from
> kernels starting from 2.6.39

I'm not sure what you are referring to.  I have kernels up to 5.8.0 running
with DAHDI without any problems.

> What linux kernel do you use on your server with dadhi E1 adapters?

mostly whatever version Debian 10 (amd64) ships. I then build DAHDI for that
kernel from source.  https://github.com/osmocom/dahdi-linux has a few
fixes for recent kernel versions that upstream doesn't yet have merged to
master.  But if upstream compiles on your kernel, you don't need those patches.

-- 
- Harald Welte <laforge at gnumonks.org>           http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
                                                  (ETSI EN 300 175-7 Ch. A6)


From laforge at gnumonks.org  Sat Oct 10 15:46:14 2020
From: laforge at gnumonks.org (Harald Welte)
Date: Sat, 10 Oct 2020 17:46:14 +0200
Subject: E1 line debug L1/L2
In-Reply-To: <CACWjWCgafiGjrQOMVRdLB9sbSHEy+0BDKYtYGqv22y-Usja_MA@mail.gmail.com>
References: <CACWjWChT4q-bDB+SuR6CiWe8A1Hg+TQWMSpdBbN5y9HUg67Tcw@mail.gmail.com>
 <20201008172934.GA3994@nataraja>
 <CACWjWCgafiGjrQOMVRdLB9sbSHEy+0BDKYtYGqv22y-Usja_MA@mail.gmail.com>
Message-ID: <20201010154614.GH843576@nataraja>

Hi Ivan,

from your config:

   timeslot 0
    phys_chan_config CCCH+SDCCH4
    e1 line 0 timeslot 2 sub-slot full
   timeslot 1
    phys_chan_config SDCCH8
    e1 line 0 timeslot 2 sub-slot 1
   timeslot 2
    phys_chan_config TCH/F
    e1 line 0 timeslot 2 sub-slot 2
   timeslot 3
    phys_chan_config TCH/F
    e1 line 0 timeslot 2 sub-slot 3
   timeslot 4
    phys_chan_config TCH/F


you cannot use e1 line 0 timeslot 2 as a full slot for signaling,
and at the same time use it as 16k channelized sub-slots.  That's clearly
wrong.  I just realized that the example config also does that.  I guess
we simply never use the 'e1 line ...' setting for a CCCH+SDCCH slot, as
they always go via the RSL link configured in the TRX.

-- 
- Harald Welte <laforge at gnumonks.org>           http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
                                                  (ETSI EN 300 175-7 Ch. A6)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: osmo-bsc.insite.cfg
Type: application/octet-stream
Size: 1393 bytes
Desc: not available
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20201010/17688e39/attachment.obj>

From ivan.babanov at gmail.com  Sun Oct 11 21:26:22 2020
From: ivan.babanov at gmail.com (Ivan Babanov)
Date: Mon, 12 Oct 2020 00:26:22 +0300
Subject: E1 line debug L1/L2
In-Reply-To: <20201010154826.GI843576@nataraja>
References: <CACWjWChT4q-bDB+SuR6CiWe8A1Hg+TQWMSpdBbN5y9HUg67Tcw@mail.gmail.com>
 <20201008172934.GA3994@nataraja>
 <CACWjWCgafiGjrQOMVRdLB9sbSHEy+0BDKYtYGqv22y-Usja_MA@mail.gmail.com>
 <20201010154826.GI843576@nataraja>
Message-ID: <CACWjWCgWNCwi6L7tDq8TywkuoZ=b412L5=xmNme8jAmUUz8sfQ@mail.gmail.com>

Hello Harald,

Thank you for your responses. I'll change configs with slot-overlapping but
looks like I'm quite far from getting it to work.
Today I found that I have "kernel: wct4xxp 0000:03:02.0: Interrupts not
detected." in syslog. This line was visible only if I load modules manually
(not via systemctl start dahdi)
I heard that it happens on some hardware with Digium cards, I'll try
tomorrow to change PCI slot to avoid sharing one IRQ with USB
devices, maybe disable USB at all. If it doesn't help, I'll try a new
server with different HW.
Now it seems a root cause of the most of problems with communication
between BSC and BTS

Thank you
Babanov Ivan

??, 10 ???. 2020 ?. ? 18:50, Harald Welte <laforge at gnumonks.org>:

> The pcap file shows that OsmoBSC is sending SABME requests but that the BTS
> never responds to any of them.  I would assume that somehow the timeslot
> configuration on BTS and BSC side don't agree, i.e. you're sending the
> SABME
> on a timeslot that the BTS doesn't expect it on.
>
> I remember that the E1 related configuration on the Noika BTS (at least
> the InSite)
> is relatively complex.  Might be best to check all related settings.
>
> --
> - Harald Welte <laforge at gnumonks.org>
> http://laforge.gnumonks.org/
>
> ============================================================================
> "Privacy in residential applications is a desirable marketing option."
>                                                   (ETSI EN 300 175-7 Ch.
> A6)
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20201012/bf346101/attachment.htm>

From laforge at gnumonks.org  Mon Oct 12 09:17:36 2020
From: laforge at gnumonks.org (Harald Welte)
Date: Mon, 12 Oct 2020 11:17:36 +0200
Subject: E1 line debug L1/L2
In-Reply-To: <CACWjWCgWNCwi6L7tDq8TywkuoZ=b412L5=xmNme8jAmUUz8sfQ@mail.gmail.com>
References: <CACWjWChT4q-bDB+SuR6CiWe8A1Hg+TQWMSpdBbN5y9HUg67Tcw@mail.gmail.com>
 <20201008172934.GA3994@nataraja>
 <CACWjWCgafiGjrQOMVRdLB9sbSHEy+0BDKYtYGqv22y-Usja_MA@mail.gmail.com>
 <20201010154826.GI843576@nataraja>
 <CACWjWCgWNCwi6L7tDq8TywkuoZ=b412L5=xmNme8jAmUUz8sfQ@mail.gmail.com>
Message-ID: <20201012091736.GE947663@nataraja>

Dear Ivan,

On Mon, Oct 12, 2020 at 12:26:22AM +0300, Ivan Babanov wrote:
> I heard that it happens on some hardware with Digium cards, I'll try
> tomorrow to change PCI slot to avoid sharing one IRQ with USB
> devices, maybe disable USB at all. If it doesn't help, I'll try a new
> server with different HW.

I'm sorry but I think you are looking at the wrong level.  I doubt that
the hardware is the problem.

If you are worried about the hardware/OS/drivers, just use a loopback E1
cable between two ports and run e1-prbs-test (from osmo-e1d/contrib) on
both sides to see if you can communicate between two ports.  If that
works, you can exclude any problems related to hardware or drivers.

If you have connceted span 1 + 2 via loopback, start

in one shell:
	e1-prbs-test /dev/dahdi/chan/001

in another shell:
	e1-prbs-test /dev/dahdi/chan/002

and check the stdout to see if they find sync in both direction.

This program sends pseudo-random bit sequences over every timeslot and
checks that the correct PRBS sequence arrives on the other side,
bidirectionally.

Regards,
	Harald
-- 
- Harald Welte <laforge at gnumonks.org>           http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
                                                  (ETSI EN 300 175-7 Ch. A6)


From ivan.babanov at gmail.com  Tue Oct 13 16:07:12 2020
From: ivan.babanov at gmail.com (Ivan Babanov)
Date: Tue, 13 Oct 2020 19:07:12 +0300
Subject: E1 line debug L1/L2
In-Reply-To: <20201012091736.GE947663@nataraja>
References: <CACWjWChT4q-bDB+SuR6CiWe8A1Hg+TQWMSpdBbN5y9HUg67Tcw@mail.gmail.com>
 <20201008172934.GA3994@nataraja>
 <CACWjWCgafiGjrQOMVRdLB9sbSHEy+0BDKYtYGqv22y-Usja_MA@mail.gmail.com>
 <20201010154826.GI843576@nataraja>
 <CACWjWCgWNCwi6L7tDq8TywkuoZ=b412L5=xmNme8jAmUUz8sfQ@mail.gmail.com>
 <20201012091736.GE947663@nataraja>
Message-ID: <CACWjWCjsGD+Zv1D9gFTBswM8RcSKdYNVt7Rteces43+XGthA4w@mail.gmail.com>

Hello Harald!

Today I was able to get hardware working. At least L2 link established and
I see OML/NM messages.
Files are attached.

Briefly the problem was with ports connections. I did not expected that
quad-port card requires all ports to be connected. Everything started to
work after I placed dummy loopback connectors to unused ports 3 and 4.
After it I was able to check physical link with e1-prbs-test and was able
to communicate with BTS.

Thank you
Babanov Ivan



??, 12 ???. 2020 ?. ? 12:20, Harald Welte <laforge at gnumonks.org>:

> Dear Ivan,
>
> On Mon, Oct 12, 2020 at 12:26:22AM +0300, Ivan Babanov wrote:
> > I heard that it happens on some hardware with Digium cards, I'll try
> > tomorrow to change PCI slot to avoid sharing one IRQ with USB
> > devices, maybe disable USB at all. If it doesn't help, I'll try a new
> > server with different HW.
>
> I'm sorry but I think you are looking at the wrong level.  I doubt that
> the hardware is the problem.
>
> If you are worried about the hardware/OS/drivers, just use a loopback E1
> cable between two ports and run e1-prbs-test (from osmo-e1d/contrib) on
> both sides to see if you can communicate between two ports.  If that
> works, you can exclude any problems related to hardware or drivers.
>
> If you have connceted span 1 + 2 via loopback, start
>
> in one shell:
>         e1-prbs-test /dev/dahdi/chan/001
>
> in another shell:
>         e1-prbs-test /dev/dahdi/chan/002
>
> and check the stdout to see if they find sync in both direction.
>
> This program sends pseudo-random bit sequences over every timeslot and
> checks that the correct PRBS sequence arrives on the other side,
> bidirectionally.
>
> Regards,
>         Harald
> --
> - Harald Welte <laforge at gnumonks.org>
> http://laforge.gnumonks.org/
>
> ============================================================================
> "Privacy in residential applications is a desirable marketing option."
>                                                   (ETSI EN 300 175-7 Ch.
> A6)
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20201013/0ba242d8/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OML.log
Type: application/octet-stream
Size: 1320 bytes
Desc: not available
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20201013/0ba242d8/attachment.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 2020005-insite.pcap
Type: application/octet-stream
Size: 35382 bytes
Desc: not available
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20201013/0ba242d8/attachment-0001.obj>

From laforge at gnumonks.org  Tue Oct 13 19:11:37 2020
From: laforge at gnumonks.org (Harald Welte)
Date: Tue, 13 Oct 2020 21:11:37 +0200
Subject: E1 line debug L1/L2
In-Reply-To: <CACWjWCjsGD+Zv1D9gFTBswM8RcSKdYNVt7Rteces43+XGthA4w@mail.gmail.com>
References: <CACWjWChT4q-bDB+SuR6CiWe8A1Hg+TQWMSpdBbN5y9HUg67Tcw@mail.gmail.com>
 <20201008172934.GA3994@nataraja>
 <CACWjWCgafiGjrQOMVRdLB9sbSHEy+0BDKYtYGqv22y-Usja_MA@mail.gmail.com>
 <20201010154826.GI843576@nataraja>
 <CACWjWCgWNCwi6L7tDq8TywkuoZ=b412L5=xmNme8jAmUUz8sfQ@mail.gmail.com>
 <20201012091736.GE947663@nataraja>
 <CACWjWCjsGD+Zv1D9gFTBswM8RcSKdYNVt7Rteces43+XGthA4w@mail.gmail.com>
Message-ID: <20201013191137.GH947663@nataraja>

Hi Ivan,

On Tue, Oct 13, 2020 at 07:07:12PM +0300, Ivan Babanov wrote:

> Today I was able to get hardware working. At least L2 link established and
> I see OML/NM messages.

congratulations!  Now the fun part starts.

> Briefly the problem was with ports connections. I did not expected that
> quad-port card requires all ports to be connected. Everything started to
> work after I placed dummy loopback connectors to unused ports 3 and 4.

This definitely does not reflect my experience with any of the DAHDI quad-port
cards I have used so far.

> After it I was able to check physical link with e1-prbs-test and was able
> to communicate with BTS.

Strange.  Maybe some bug or problem with the specific model you use, or
related to the suspected IRQ trouble, or it is a question of clocking?  Maybe
the clock reference was configured to (only) use a port that had no signal applied?

-- 
- Harald Welte <laforge at gnumonks.org>           http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
                                                  (ETSI EN 300 175-7 Ch. A6)


From ludovic.rousseau at free.fr  Wed Oct 14 17:01:52 2020
From: ludovic.rousseau at free.fr (Ludovic Rousseau)
Date: Wed, 14 Oct 2020 19:01:52 +0200
Subject: libosmocore: macOS support?
Message-ID: <629ac60b-4a2f-efc2-1a1d-573dc1d6d884@free.fr>

Hello,

I try to build utils/osmo-sim-test.c on macOS.
For that I need to build the complete libosmocore project.

I already patched/hacked some source code file to make them compile on macOS but now the compiler fails on src/vty/cpu_sched_vty.c because cpu_set_t is Linux-specific.
The problem is that src/vty/cpu_sched_vty.c contains *a lot* of use of cpu_set_t usage.

I am pretty sure utils/osmo-sim-test.c will not need the functions defined in cpu_sched_vty.c.

Is it possible to build utils/osmo-sim-test.c without building the complete libosmocore project?
Any interest in macOS support (even partial & unofficial support)?


Yes, the easiest option is to use Linux. But my main computer uses macOS. And I like challenges :-)

Regards,

-- 
Dr. Ludovic Rousseau


From laforge at osmocom.org  Wed Oct 14 18:13:29 2020
From: laforge at osmocom.org (Harald Welte)
Date: Wed, 14 Oct 2020 20:13:29 +0200
Subject: libosmocore: macOS support?
In-Reply-To: <629ac60b-4a2f-efc2-1a1d-573dc1d6d884@free.fr>
References: <629ac60b-4a2f-efc2-1a1d-573dc1d6d884@free.fr>
Message-ID: <20201014181329.GG947663@nataraja>

Hi Ludovic,

On Wed, Oct 14, 2020 at 07:01:52PM +0200, Ludovic Rousseau wrote:
> I try to build utils/osmo-sim-test.c on macOS.
> For that I need to build the complete libosmocore project.
>
> Any interest in macOS support (even partial & unofficial support)?

in general we are happy to merge patches for support of any OS, as long as there is
somebody willing to create, contribute and maintain them.  We used to e.g. have
FreeBSD support, but in absence of anyone interested in it, we removed them, as it
created too much extra work for the developers/maintainers at the time.

> I already patched/hacked some source code file to make them compile on macOS but now the compiler fails on src/vty/cpu_sched_vty.c because cpu_set_t is Linux-specific.
> The problem is that src/vty/cpu_sched_vty.c contains *a lot* of use of cpu_set_t usage.

I think the best approach would be to simply detect the support for cpuset_t during configure,
and then conditionally compile the entire file only if configure detected support for it.

This way, the related symbols provided by cpu_sched_vty.c are not available on some platforms
like macOS, but as long as the given application doesn't use them, it will work.

> I am pretty sure utils/osmo-sim-test.c will not need the functions defined in cpu_sched_vty.c.

that is correct.  This feature is only used by the 'large' osmocom
programs like osmo-bts, osmo-trx, ... in order to configure the most
optimal CPU scheduling.

> Is it possible to build utils/osmo-sim-test.c without building the complete libosmocore project?

Not today.

If you'd like, go ahead and work on patches to enable/disable cpuset_t
related support at 'configure' time, and submit them via gerrit, see
https://osmocom.org/projects/cellular-infrastructure/wiki/Gerrit

Thanks,
	Harald
-- 
- Harald Welte <laforge at osmocom.org>            http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
                                                  (ETSI EN 300 175-7 Ch. A6)


From jeremy.006 at gmail.com  Sun Oct 25 10:56:04 2020
From: jeremy.006 at gmail.com (Jeremy Herbert)
Date: Sun, 25 Oct 2020 20:56:04 +1000
Subject: [PATCH 0/1] pysim: make random seed function python3 compatible
Message-ID: <20201025105605.5692-1-jeremy.006@gmail.com>

Currently the random seed function _digits is not python3 compatible as it passes a unicode string to the sha1 function. It generates the following exception:


Using PC/SC reader interface

Card programming failed with an execption:
---------------------8<---------------------
Traceback (most recent call last):
  File "./pySim-prog.py", line 718, in <module>
    rc = process_card(opts, first, card_handler)
  File "./pySim-prog.py", line 643, in process_card
    cp = gen_parameters(opts)
  File "./pySim-prog.py", line 342, in gen_parameters
    iccid += _digits(opts.secret, 'ccid', ml, opts.num)
  File "./pySim-prog.py", line 228, in _digits
    s = hashlib.sha1(secret + usage + '%d' % num)
TypeError: Unicode-objects must be encoded before hashing
---------------------8<---------------------


This patch fixes this problem.


Jeremy Herbert (1):
  make random seed function python3 compatible

 pySim-prog.py | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

-- 
2.25.1



From jeremy.006 at gmail.com  Sun Oct 25 10:56:05 2020
From: jeremy.006 at gmail.com (Jeremy Herbert)
Date: Sun, 25 Oct 2020 20:56:05 +1000
Subject: [PATCH 1/1] make random seed function python3 compatible
In-Reply-To: <20201025105605.5692-1-jeremy.006@gmail.com>
References: <20201025105605.5692-1-jeremy.006@gmail.com>
Message-ID: <20201025105605.5692-2-jeremy.006@gmail.com>

---
 pySim-prog.py | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/pySim-prog.py b/pySim-prog.py
index 942cfb0..e172d80 100755
--- a/pySim-prog.py
+++ b/pySim-prog.py
@@ -225,8 +225,9 @@ def parse_options():
 
 
 def _digits(secret, usage, len, num):
-	s = hashlib.sha1(secret + usage + '%d' % num)
-	d = ''.join(['%02d'%ord(x) for x in s.digest()])
+	seed = secret + usage + '%d' % num
+	s = hashlib.sha1(seed.encode())
+	d = ''.join(['%02d' % x for x in s.digest()])
 	return d[0:len]
 
 def _mcc_mnc_digits(mcc, mnc):
-- 
2.25.1



From dchardware at gmail.com  Mon Oct 26 14:16:21 2020
From: dchardware at gmail.com (Sipos Csaba)
Date: Mon, 26 Oct 2020 15:16:21 +0100
Subject: Fwd: NMT-450 - partial success
In-Reply-To: <CALQr=E_dV=E2cGo2C5tL+TrumjYzPDCeTf=-n8VR204d+4STnQ@mail.gmail.com>
References: <CALQr=E_dV=E2cGo2C5tL+TrumjYzPDCeTf=-n8VR204d+4STnQ@mail.gmail.com>
Message-ID: <CALQr=E_Y0LWtzv-vRfS-Qof7+OKK15MPnqL=+vSZ1+tbDu=UWQ@mail.gmail.com>

Hi,

I know it is a bit off topic, but as osmocom-analog has no dedicated mail
list and my every attempt to contact Andreas lead to silence, I thought
this is the closest one to discuss it.

I try to create an NMT-450 network with Motorola MCR4800XL phones, and a
LimeSDR-mini. As the phones are locked to "Hungary" using a specific raster
and a large gap in the middle, first I needed to dig out the details, find
out the country code and create a patch so at least the phone is willing to
lock onto the DS signal. I managed to do all that, so now the phone is
actually able to decode the network and lock onto the signal.

My issue is with the uplink: when the phone tries Traffic Area update (the
phone's uplink transmission burts is clearly seen with a spectrum
analyzer), the network side is not able to detect the uplink burst at all.
Not even as bad, or incorrectly formatted frame. Andreas has a site which
describes how to set up the uplink side and do some tests:

http://osmocom-analog.eversberg.eu/docs/sdr.html

I followed that guide and when the uplink burst from the phone arrives, the
RX IQ constellation monitor indicates a correct burst with proper power
(the burst is nicely round and in the green area). If I try to set up a
call to the phone using the correct country code and phone number, the
phone clearly responds to the paging request, as the 3 paging attempt
generates 3 uplink bursts. Again, with no reception/decoding on the network
side. Tried with two phones of the same type, the effect is the same.

I have two questions:

1. Where to send patches for the osmocom-analog project?
2. Does anyone have an idea what can be wrong with my setup?

One more thing I noticed: compared to the channel frequency used to set the
NMT network up, the uplink is a couple kHz shifted:

http://www.imagebam.com/image/d17e881357285965

As it can be seen, the uplink burst appears 3-4kHz left relative to the
downlink signal.

The network is started with the following command:
nmt -k 239 -k 235 -Y HU,1 --limesdr-mini --sdr-rx-gain 20

Any and all help is appreciated.

Regards,
Csaba
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20201026/f0a83f66/attachment.htm>

From ralph at schmid.xxx  Mon Oct 26 14:33:54 2020
From: ralph at schmid.xxx (Ralph A. Schmid, dk5ras)
Date: Mon, 26 Oct 2020 15:33:54 +0100
Subject: NMT-450 - partial success
In-Reply-To: <CALQr=E_Y0LWtzv-vRfS-Qof7+OKK15MPnqL=+vSZ1+tbDu=UWQ@mail.gmail.com>
References: <CALQr=E_dV=E2cGo2C5tL+TrumjYzPDCeTf=-n8VR204d+4STnQ@mail.gmail.com>
 <CALQr=E_Y0LWtzv-vRfS-Qof7+OKK15MPnqL=+vSZ1+tbDu=UWQ@mail.gmail.com>
Message-ID: <03d701d6aba5$07ebb650$17c322f0$@schmid.xxx>

One thing, maybe your MCR has drifted, due to ageing?! 

 

From: OpenBSC [mailto:openbsc-bounces at lists.osmocom.org] On Behalf Of Sipos Csaba
Sent: Monday, October 26, 2020 3:16 PM
To: openbsc-request at lists.osmocom.org <openbsc at lists.osmocom.org>
Subject: Fwd: NMT-450 - partial success

 

Hi,

 

I know it is a bit off topic, but as osmocom-analog has no dedicated mail list and my every attempt to contact Andreas lead to silence, I thought this is the closest one to discuss it.

 

I try to create an NMT-450 network with Motorola MCR4800XL phones, and a LimeSDR-mini. As the phones are locked to "Hungary" using a specific raster and a large gap in the middle, first I needed to dig out the details, find out the country code and create a patch so at least the phone is willing to lock onto the DS signal. I managed to do all that, so now the phone is actually able to decode the network and lock onto the signal.

 

My issue is with the uplink: when the phone tries Traffic Area update (the phone's uplink transmission burts is clearly seen with a spectrum analyzer), the network side is not able to detect the uplink burst at all. Not even as bad, or incorrectly formatted frame. Andreas has a site which describes how to set up the uplink side and do some tests: 

 

http://osmocom-analog.eversberg.eu/docs/sdr.html

 

I followed that guide and when the uplink burst from the phone arrives, the RX IQ constellation monitor indicates a correct burst with proper power (the burst is nicely round and in the green area). If I try to set up a call to the phone using the correct country code and phone number, the phone clearly responds to the paging request, as the 3 paging attempt generates 3 uplink bursts. Again, with no reception/decoding on the network side. Tried with two phones of the same type, the effect is the same.

 

I have two questions:

 

1. Where to send patches for the osmocom-analog project?

2. Does anyone have an idea what can be wrong with my setup?

 

One more thing I noticed: compared to the channel frequency used to set the NMT network up, the uplink is a couple kHz shifted:

 

http://www.imagebam.com/image/d17e881357285965

 

As it can be seen, the uplink burst appears 3-4kHz left relative to the downlink signal. 

 

The network is started with the following command:

nmt -k 239 -k 235 -Y HU,1 --limesdr-mini --sdr-rx-gain 20

 

Any and all help is appreciated.

 

Regards,

Csaba

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20201026/d0c72728/attachment.htm>

From ralph at schmid.xxx  Mon Oct 26 14:32:58 2020
From: ralph at schmid.xxx (Ralph A. Schmid, dk5ras)
Date: Mon, 26 Oct 2020 15:32:58 +0100
Subject: NMT-450 - partial success
In-Reply-To: <CALQr=E_Y0LWtzv-vRfS-Qof7+OKK15MPnqL=+vSZ1+tbDu=UWQ@mail.gmail.com>
References: <CALQr=E_dV=E2cGo2C5tL+TrumjYzPDCeTf=-n8VR204d+4STnQ@mail.gmail.com>
 <CALQr=E_Y0LWtzv-vRfS-Qof7+OKK15MPnqL=+vSZ1+tbDu=UWQ@mail.gmail.com>
Message-ID: <03ca01d6aba4$e6787ad0$b3697070$@schmid.xxx>

Hi Chaba,

 

I have a Nokia handheld phone from Hungary, I can try with your settings and let you know.

 

Andreas seems to be difficult to reach these days, I found the same :/


With best regards


Ralph. 

 

 

 

From: OpenBSC [mailto:openbsc-bounces at lists.osmocom.org] On Behalf Of Sipos Csaba
Sent: Monday, October 26, 2020 3:16 PM
To: openbsc-request at lists.osmocom.org <openbsc at lists.osmocom.org>
Subject: Fwd: NMT-450 - partial success

 

Hi,

 

I know it is a bit off topic, but as osmocom-analog has no dedicated mail list and my every attempt to contact Andreas lead to silence, I thought this is the closest one to discuss it.

 

I try to create an NMT-450 network with Motorola MCR4800XL phones, and a LimeSDR-mini. As the phones are locked to "Hungary" using a specific raster and a large gap in the middle, first I needed to dig out the details, find out the country code and create a patch so at least the phone is willing to lock onto the DS signal. I managed to do all that, so now the phone is actually able to decode the network and lock onto the signal.

 

My issue is with the uplink: when the phone tries Traffic Area update (the phone's uplink transmission burts is clearly seen with a spectrum analyzer), the network side is not able to detect the uplink burst at all. Not even as bad, or incorrectly formatted frame. Andreas has a site which describes how to set up the uplink side and do some tests: 

 

http://osmocom-analog.eversberg.eu/docs/sdr.html

 

I followed that guide and when the uplink burst from the phone arrives, the RX IQ constellation monitor indicates a correct burst with proper power (the burst is nicely round and in the green area). If I try to set up a call to the phone using the correct country code and phone number, the phone clearly responds to the paging request, as the 3 paging attempt generates 3 uplink bursts. Again, with no reception/decoding on the network side. Tried with two phones of the same type, the effect is the same.

 

I have two questions:

 

1. Where to send patches for the osmocom-analog project?

2. Does anyone have an idea what can be wrong with my setup?

 

One more thing I noticed: compared to the channel frequency used to set the NMT network up, the uplink is a couple kHz shifted:

 

http://www.imagebam.com/image/d17e881357285965

 

As it can be seen, the uplink burst appears 3-4kHz left relative to the downlink signal. 

 

The network is started with the following command:

nmt -k 239 -k 235 -Y HU,1 --limesdr-mini --sdr-rx-gain 20

 

Any and all help is appreciated.

 

Regards,

Csaba

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20201026/dfff97fa/attachment.htm>

From dchardware at gmail.com  Mon Oct 26 15:08:01 2020
From: dchardware at gmail.com (Sipos Csaba)
Date: Mon, 26 Oct 2020 16:08:01 +0100
Subject: NMT-450 - partial success
In-Reply-To: <03ca01d6aba4$e6787ad0$b3697070$@schmid.xxx>
References: <CALQr=E_dV=E2cGo2C5tL+TrumjYzPDCeTf=-n8VR204d+4STnQ@mail.gmail.com>
 <CALQr=E_Y0LWtzv-vRfS-Qof7+OKK15MPnqL=+vSZ1+tbDu=UWQ@mail.gmail.com>
 <03ca01d6aba4$e6787ad0$b3697070$@schmid.xxx>
Message-ID: <CALQr=E-8mhBXWVYjYSrg_vV6USnzDW4opAMsCk1iRR1Oibt6LA@mail.gmail.com>

Hi Ralph,

I attached the patch for the country specific settings for Hungary, you can
apply it against "master" . TAs are not yet verified, but the phone goes
"green" with all TAs from 1 to 15. The RF part and country code are
verified.

> One thing, maybe your MCR has drifted, due to ageing?!

Well, that was my first impression too, as if you look at my picture (
http://www.imagebam.com/image/d17e881357285965 ) you will see that the
center of the downlink and uplink transmissions are not exactly 10MHz
apart, they have a couple kHz drift. On the picture the two markers are
indicating the nominal frequency of the channel. As you can see the uplink
burst is actually closer to the nominal frequency, compared to the
downlink. It is not in the standard (or I was not able to find it, in
general the RF spec is not very detailed...), so I am not sure if the SDRs
downlink signal is off, and the phone is correct or the other way around.
Although it sure looks like a low layer fault, as the NMT network is not
even detecting is as bad or incorrect frames.

I did a loopback test with a jumper between the TX and RX of the SDR and
that seemed to work (frame level and frame quality were 90+%). On the other
hand if the local oscillator would be off, the phone would not be able to
lock on the DL signal as well. I have no high precision counter at home,
but with a relatively primitive multimeter I was able to measure 12.7999MHz
on the 12.8MHz local oscillator. And both identical phones behave the same.

The question is if I can somehow offset the uplink frequency on the SDR
side or via config/source modification to remove this couple kHz drift?

If someone has seen a lot of these signals and can take a look at the image
above, would be lovely to hear if any of the signals are off.

I will also get another more "modern" phone hopefully soon, so I can try
with that.

Regards,
Csaba

Ralph A. Schmid, dk5ras <ralph at schmid.xxx> ezt ?rta (id?pont: 2020. okt.
26., H, 15:33):

> Hi Chaba,
>
>
>
> I have a Nokia handheld phone from Hungary, I can try with your settings
> and let you know.
>
>
>
> Andreas seems to be difficult to reach these days, I found the same :/
>
>
> With best regards
>
>
> Ralph.
>
>
>
>
>
>
>
> *From:* OpenBSC [mailto:openbsc-bounces at lists.osmocom.org] *On Behalf Of *Sipos
> Csaba
> *Sent:* Monday, October 26, 2020 3:16 PM
> *To:* openbsc-request at lists.osmocom.org <openbsc at lists.osmocom.org>
> *Subject:* Fwd: NMT-450 - partial success
>
>
>
> Hi,
>
>
>
> I know it is a bit off topic, but as osmocom-analog has no dedicated mail
> list and my every attempt to contact Andreas lead to silence, I thought
> this is the closest one to discuss it.
>
>
>
> I try to create an NMT-450 network with Motorola MCR4800XL phones, and a
> LimeSDR-mini. As the phones are locked to "Hungary" using a specific raster
> and a large gap in the middle, first I needed to dig out the details, find
> out the country code and create a patch so at least the phone is willing to
> lock onto the DS signal. I managed to do all that, so now the phone is
> actually able to decode the network and lock onto the signal.
>
>
>
> My issue is with the uplink: when the phone tries Traffic Area update (the
> phone's uplink transmission burts is clearly seen with a spectrum
> analyzer), the network side is not able to detect the uplink burst at all.
> Not even as bad, or incorrectly formatted frame. Andreas has a site which
> describes how to set up the uplink side and do some tests:
>
>
>
> http://osmocom-analog.eversberg.eu/docs/sdr.html
>
>
>
> I followed that guide and when the uplink burst from the phone arrives,
> the RX IQ constellation monitor indicates a correct burst with proper power
> (the burst is nicely round and in the green area). If I try to set up a
> call to the phone using the correct country code and phone number, the
> phone clearly responds to the paging request, as the 3 paging attempt
> generates 3 uplink bursts. Again, with no reception/decoding on the network
> side. Tried with two phones of the same type, the effect is the same.
>
>
>
> I have two questions:
>
>
>
> 1. Where to send patches for the osmocom-analog project?
>
> 2. Does anyone have an idea what can be wrong with my setup?
>
>
>
> One more thing I noticed: compared to the channel frequency used to set
> the NMT network up, the uplink is a couple kHz shifted:
>
>
>
> http://www.imagebam.com/image/d17e881357285965
>
>
>
> As it can be seen, the uplink burst appears 3-4kHz left relative to the
> downlink signal.
>
>
>
> The network is started with the following command:
>
> nmt -k 239 -k 235 -Y HU,1 --limesdr-mini --sdr-rx-gain 20
>
>
>
> Any and all help is appreciated.
>
>
>
> Regards,
>
> Csaba
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20201026/401af0d5/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-Add-country-specific-settings-for-Hungary.patch
Type: application/octet-stream
Size: 1829 bytes
Desc: not available
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20201026/401af0d5/attachment.obj>

From laforge at osmocom.org  Mon Oct 26 17:56:10 2020
From: laforge at osmocom.org (Harald Welte)
Date: Mon, 26 Oct 2020 18:56:10 +0100
Subject: [PATCH 0/1] pysim: make random seed function python3 compatible
In-Reply-To: <20201025105605.5692-1-jeremy.006@gmail.com>
References: <20201025105605.5692-1-jeremy.006@gmail.com>
Message-ID: <20201026175610.GA32319@nataraja>

Hi Jeremy,

On Sun, Oct 25, 2020 at 08:56:04PM +1000, Jeremy Herbert wrote:
> Currently the random seed function _digits is not python3 compatible as it passes a unicode string to the sha1 function. It generates the following exception:

thanks for your patch.  I've pushed it into our gerrit, see
 https://gerrit.osmocom.org/c/pysim/+/20922

Regards,
	Harald
-- 
- Harald Welte <laforge at osmocom.org>            http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
                                                  (ETSI EN 300 175-7 Ch. A6)


From domi at tomcsanyi.net  Mon Oct 26 18:54:04 2020
From: domi at tomcsanyi.net (Tomcsanyi, Domonkos)
Date: Mon, 26 Oct 2020 19:54:04 +0100
Subject: NMT-450 - partial success
In-Reply-To: <CALQr=E-8mhBXWVYjYSrg_vV6USnzDW4opAMsCk1iRR1Oibt6LA@mail.gmail.com>
References: <CALQr=E-8mhBXWVYjYSrg_vV6USnzDW4opAMsCk1iRR1Oibt6LA@mail.gmail.com>
Message-ID: <5D6A00A6-0654-4FDA-B690-909C388C8EDB@tomcsanyi.net>

Hello Csaba,

I am not sure if you know this, wanted to mention it: you could easily measure your SDR?s oscillator accuracy using the kalibrate tool. It uses nearby GSM BTSs if I am correct to give you a good estimation about how much off your oscillator is.
I used to use it with rtl-sdr a lot, because those USB dongles are crazy off in terms off accuracy.
Once you have an offset figured out for the current temperature I guess you could try to offset the frequency set by osmocom by that amount. Maybe even try to expose it as a variable if needed.
Other solution would be using some kind of a GPSDO or similar 10 MHz input if the LineSDR supports it.

Sorry again if this is known info, but wanted to chime in with some hopefully helpful bits.

Cheers,
Domi


> 2020. okt. 26. d?tummal, 16:08 id?pontban Sipos Csaba <dchardware at gmail.com> ?rta:
> 
> ?
> Hi Ralph,
> 
> I attached the patch for the country specific settings for Hungary, you can apply it against "master" . TAs are not yet verified, but the phone goes "green" with all TAs from 1 to 15. The RF part and country code are verified.
> 
> > One thing, maybe your MCR has drifted, due to ageing?! 
> 
> Well, that was my first impression too, as if you look at my picture ( http://www.imagebam.com/image/d17e881357285965 ) you will see that the center of the downlink and uplink transmissions are not exactly 10MHz apart, they have a couple kHz drift. On the picture the two markers are indicating the nominal frequency of the channel. As you can see the uplink burst is actually closer to the nominal frequency, compared to the downlink. It is not in the standard (or I was not able to find it, in general the RF spec is not very detailed...), so I am not sure if the SDRs downlink signal is off, and the phone is correct or the other way around. Although it sure looks like a low layer fault, as the NMT network is not even detecting is as bad or incorrect frames.
> 
> I did a loopback test with a jumper between the TX and RX of the SDR and that seemed to work (frame level and frame quality were 90+%). On the other hand if the local oscillator would be off, the phone would not be able to lock on the DL signal as well. I have no high precision counter at home, but with a relatively primitive multimeter I was able to measure 12.7999MHz on the 12.8MHz local oscillator. And both identical phones behave the same.
> 
> The question is if I can somehow offset the uplink frequency on the SDR side or via config/source modification to remove this couple kHz drift?
> 
> If someone has seen a lot of these signals and can take a look at the image above, would be lovely to hear if any of the signals are off.
> 
> I will also get another more "modern" phone hopefully soon, so I can try with that.
> 
> Regards,
> Csaba
> 
> Ralph A. Schmid, dk5ras <ralph at schmid.xxx> ezt ?rta (id?pont: 2020. okt. 26., H, 15:33):
>> Hi Chaba,
>> 
>>  
>> 
>> I have a Nokia handheld phone from Hungary, I can try with your settings and let you know.
>> 
>>  
>> 
>> Andreas seems to be difficult to reach these days, I found the same :/
>> 
>> 
>> With best regards
>> 
>> 
>> Ralph.
>> 
>>  
>> 
>>  
>> 
>>  
>> 
>> From: OpenBSC [mailto:openbsc-bounces at lists.osmocom.org] On Behalf Of Sipos Csaba
>> Sent: Monday, October 26, 2020 3:16 PM
>> To: openbsc-request at lists.osmocom.org <openbsc at lists.osmocom.org>
>> Subject: Fwd: NMT-450 - partial success
>> 
>>  
>> 
>> Hi,
>> 
>>  
>> 
>> I know it is a bit off topic, but as osmocom-analog has no dedicated mail list and my every attempt to contact Andreas lead to silence, I thought this is the closest one to discuss it.
>> 
>>  
>> 
>> I try to create an NMT-450 network with Motorola MCR4800XL phones, and a LimeSDR-mini. As the phones are locked to "Hungary" using a specific raster and a large gap in the middle, first I needed to dig out the details, find out the country code and create a patch so at least the phone is willing to lock onto the DS signal. I managed to do all that, so now the phone is actually able to decode the network and lock onto the signal.
>> 
>>  
>> 
>> My issue is with the uplink: when the phone tries Traffic Area update (the phone's uplink transmission burts is clearly seen with a spectrum analyzer), the network side is not able to detect the uplink burst at all. Not even as bad, or incorrectly formatted frame. Andreas has a site which describes how to set up the uplink side and do some tests:
>> 
>>  
>> 
>> http://osmocom-analog.eversberg.eu/docs/sdr.html
>> 
>>  
>> 
>> I followed that guide and when the uplink burst from the phone arrives, the RX IQ constellation monitor indicates a correct burst with proper power (the burst is nicely round and in the green area). If I try to set up a call to the phone using the correct country code and phone number, the phone clearly responds to the paging request, as the 3 paging attempt generates 3 uplink bursts. Again, with no reception/decoding on the network side. Tried with two phones of the same type, the effect is the same.
>> 
>>  
>> 
>> I have two questions:
>> 
>>  
>> 
>> 1. Where to send patches for the osmocom-analog project?
>> 
>> 2. Does anyone have an idea what can be wrong with my setup?
>> 
>>  
>> 
>> One more thing I noticed: compared to the channel frequency used to set the NMT network up, the uplink is a couple kHz shifted:
>> 
>>  
>> 
>> http://www.imagebam.com/image/d17e881357285965
>> 
>>  
>> 
>> As it can be seen, the uplink burst appears 3-4kHz left relative to the downlink signal.
>> 
>>  
>> 
>> The network is started with the following command:
>> 
>> nmt -k 239 -k 235 -Y HU,1 --limesdr-mini --sdr-rx-gain 20
>> 
>>  
>> 
>> Any and all help is appreciated.
>> 
>>  
>> 
>> Regards,
>> 
>> Csaba
>> 
> 
> <0001-Add-country-specific-settings-for-Hungary.patch>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20201026/e8285f46/attachment.htm>

From jeremy.006 at gmail.com  Mon Oct 26 22:41:34 2020
From: jeremy.006 at gmail.com (Jeremy Herbert)
Date: Tue, 27 Oct 2020 08:41:34 +1000
Subject: [PATCH 0/1] pysim: make random seed function python3 compatible
In-Reply-To: <20201026175610.GA32319@nataraja>
References: <20201025105605.5692-1-jeremy.006@gmail.com>
 <20201026175610.GA32319@nataraja>
Message-ID: <CAHYNNe0JFOoaFc-J_1R4MBuafcyKRk1+MZ9pSbEQy3ecfoiZrw@mail.gmail.com>

Hi Harald,

Thank you. Sorry, I looked but I must have missed the gerrit for this
project.

Thanks,
Jeremy

On Tue, 27 Oct 2020 at 04:00, Harald Welte <laforge at osmocom.org> wrote:

> Hi Jeremy,
>
> On Sun, Oct 25, 2020 at 08:56:04PM +1000, Jeremy Herbert wrote:
> > Currently the random seed function _digits is not python3 compatible as
> it passes a unicode string to the sha1 function. It generates the following
> exception:
>
> thanks for your patch.  I've pushed it into our gerrit, see
>  https://gerrit.osmocom.org/c/pysim/+/20922
>
> Regards,
>         Harald
> --
> - Harald Welte <laforge at osmocom.org>
> http://laforge.gnumonks.org/
>
> ============================================================================
> "Privacy in residential applications is a desirable marketing option."
>                                                   (ETSI EN 300 175-7 Ch.
> A6)
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20201027/bf868f84/attachment.htm>

From dchardware at gmail.com  Tue Oct 27 00:28:18 2020
From: dchardware at gmail.com (Sipos Csaba)
Date: Tue, 27 Oct 2020 01:28:18 +0100
Subject: NMT-450 - partial success
In-Reply-To: <5D6A00A6-0654-4FDA-B690-909C388C8EDB@tomcsanyi.net>
References: <CALQr=E-8mhBXWVYjYSrg_vV6USnzDW4opAMsCk1iRR1Oibt6LA@mail.gmail.com>
 <5D6A00A6-0654-4FDA-B690-909C388C8EDB@tomcsanyi.net>
Message-ID: <CALQr=E-Gy3pUuOK+RUR=GAgobs2gJMMdAhs4AAUs0uEKtT2CQQ@mail.gmail.com>

It works!

Long story short: the LimeSDR-Mini was off by 3.5kHz, and not the phone.
Even after 30 years, the phone is only off by 14Hz, what a performance.
Made in West Germany :-))

After the recalibration of the LimeSDR Mini, the phone successfully updated
the TA and went to normal idle state. Calls are also possible, SMS will be
tested when a capable phone arrives. All  TA combinations were tested
(1-15).

Will create an updated patch for the country specific settings, now that it
is tested.

The lesson is: trust but verify :-) Especially with cheap hardware.

Regards,
Csaba

Tomcsanyi, Domonkos <domi at tomcsanyi.net> ezt ?rta (id?pont: 2020. okt. 26.,
H, 19:54):

> Hello Csaba,
>
> I am not sure if you know this, wanted to mention it: you could easily
> measure your SDR?s oscillator accuracy using the kalibrate tool. It uses
> nearby GSM BTSs if I am correct to give you a good estimation about how
> much off your oscillator is.
> I used to use it with rtl-sdr a lot, because those USB dongles are crazy
> off in terms off accuracy.
> Once you have an offset figured out for the current temperature I guess
> you could try to offset the frequency set by osmocom by that amount. Maybe
> even try to expose it as a variable if needed.
> Other solution would be using some kind of a GPSDO or similar 10 MHz input
> if the LineSDR supports it.
>
> Sorry again if this is known info, but wanted to chime in with some
> hopefully helpful bits.
>
> Cheers,
> Domi
>
>
> 2020. okt. 26. d?tummal, 16:08 id?pontban Sipos Csaba <
> dchardware at gmail.com> ?rta:
>
> ?
> Hi Ralph,
>
> I attached the patch for the country specific settings for Hungary, you
> can apply it against "master" . TAs are not yet verified, but the phone
> goes "green" with all TAs from 1 to 15. The RF part and country code are
> verified.
>
> > One thing, maybe your MCR has drifted, due to ageing?!
>
> Well, that was my first impression too, as if you look at my picture (
> http://www.imagebam.com/image/d17e881357285965 ) you will see that the
> center of the downlink and uplink transmissions are not exactly 10MHz
> apart, they have a couple kHz drift. On the picture the two markers are
> indicating the nominal frequency of the channel. As you can see the uplink
> burst is actually closer to the nominal frequency, compared to the
> downlink. It is not in the standard (or I was not able to find it, in
> general the RF spec is not very detailed...), so I am not sure if the SDRs
> downlink signal is off, and the phone is correct or the other way around.
> Although it sure looks like a low layer fault, as the NMT network is not
> even detecting is as bad or incorrect frames.
>
> I did a loopback test with a jumper between the TX and RX of the SDR and
> that seemed to work (frame level and frame quality were 90+%). On the other
> hand if the local oscillator would be off, the phone would not be able to
> lock on the DL signal as well. I have no high precision counter at home,
> but with a relatively primitive multimeter I was able to measure 12.7999MHz
> on the 12.8MHz local oscillator. And both identical phones behave the same.
>
> The question is if I can somehow offset the uplink frequency on the SDR
> side or via config/source modification to remove this couple kHz drift?
>
> If someone has seen a lot of these signals and can take a look at the
> image above, would be lovely to hear if any of the signals are off.
>
> I will also get another more "modern" phone hopefully soon, so I can try
> with that.
>
> Regards,
> Csaba
>
> Ralph A. Schmid, dk5ras <ralph at schmid.xxx> ezt ?rta (id?pont: 2020. okt.
> 26., H, 15:33):
>
>> Hi Chaba,
>>
>>
>>
>> I have a Nokia handheld phone from Hungary, I can try with your settings
>> and let you know.
>>
>>
>>
>> Andreas seems to be difficult to reach these days, I found the same :/
>>
>>
>> With best regards
>>
>>
>> Ralph.
>>
>>
>>
>>
>>
>>
>>
>> *From:* OpenBSC [mailto:openbsc-bounces at lists.osmocom.org] *On Behalf Of
>> *Sipos Csaba
>> *Sent:* Monday, October 26, 2020 3:16 PM
>> *To:* openbsc-request at lists.osmocom.org <openbsc at lists.osmocom.org>
>> *Subject:* Fwd: NMT-450 - partial success
>>
>>
>>
>> Hi,
>>
>>
>>
>> I know it is a bit off topic, but as osmocom-analog has no dedicated mail
>> list and my every attempt to contact Andreas lead to silence, I thought
>> this is the closest one to discuss it.
>>
>>
>>
>> I try to create an NMT-450 network with Motorola MCR4800XL phones, and a
>> LimeSDR-mini. As the phones are locked to "Hungary" using a specific raster
>> and a large gap in the middle, first I needed to dig out the details, find
>> out the country code and create a patch so at least the phone is willing to
>> lock onto the DS signal. I managed to do all that, so now the phone is
>> actually able to decode the network and lock onto the signal.
>>
>>
>>
>> My issue is with the uplink: when the phone tries Traffic Area update
>> (the phone's uplink transmission burts is clearly seen with a spectrum
>> analyzer), the network side is not able to detect the uplink burst at all.
>> Not even as bad, or incorrectly formatted frame. Andreas has a site which
>> describes how to set up the uplink side and do some tests:
>>
>>
>>
>> http://osmocom-analog.eversberg.eu/docs/sdr.html
>>
>>
>>
>> I followed that guide and when the uplink burst from the phone arrives,
>> the RX IQ constellation monitor indicates a correct burst with proper power
>> (the burst is nicely round and in the green area). If I try to set up a
>> call to the phone using the correct country code and phone number, the
>> phone clearly responds to the paging request, as the 3 paging attempt
>> generates 3 uplink bursts. Again, with no reception/decoding on the network
>> side. Tried with two phones of the same type, the effect is the same.
>>
>>
>>
>> I have two questions:
>>
>>
>>
>> 1. Where to send patches for the osmocom-analog project?
>>
>> 2. Does anyone have an idea what can be wrong with my setup?
>>
>>
>>
>> One more thing I noticed: compared to the channel frequency used to set
>> the NMT network up, the uplink is a couple kHz shifted:
>>
>>
>>
>> http://www.imagebam.com/image/d17e881357285965
>>
>>
>>
>> As it can be seen, the uplink burst appears 3-4kHz left relative to the
>> downlink signal.
>>
>>
>>
>> The network is started with the following command:
>>
>> nmt -k 239 -k 235 -Y HU,1 --limesdr-mini --sdr-rx-gain 20
>>
>>
>>
>> Any and all help is appreciated.
>>
>>
>>
>> Regards,
>>
>> Csaba
>>
> <0001-Add-country-specific-settings-for-Hungary.patch>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20201027/82afc0ad/attachment.htm>

From laforge at osmocom.org  Tue Oct 27 08:39:04 2020
From: laforge at osmocom.org (Harald Welte)
Date: Tue, 27 Oct 2020 09:39:04 +0100
Subject: [PATCH 0/1] pysim: make random seed function python3 compatible
In-Reply-To: <CAHYNNe0JFOoaFc-J_1R4MBuafcyKRk1+MZ9pSbEQy3ecfoiZrw@mail.gmail.com>
References: <20201025105605.5692-1-jeremy.006@gmail.com>
 <20201026175610.GA32319@nataraja>
 <CAHYNNe0JFOoaFc-J_1R4MBuafcyKRk1+MZ9pSbEQy3ecfoiZrw@mail.gmail.com>
Message-ID: <20201027083904.GF32319@nataraja>

On Tue, Oct 27, 2020 at 08:41:34AM +1000, Jeremy Herbert wrote:
> Thank you. Sorry, I looked but I must have missed the gerrit for this
> project.

no worries.  I don't mind pushing some patches from e-mail to gerrit.

Using gerrit is mostly important if you want to contribute more regularly
(which you and anyone else is obviously very much invited to!)

Regards,
	Harald
-- 
- Harald Welte <laforge at osmocom.org>            http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
                                                  (ETSI EN 300 175-7 Ch. A6)


From domi at tomcsanyi.net  Tue Oct 27 09:17:31 2020
From: domi at tomcsanyi.net (Tomcsanyi, Domonkos)
Date: Tue, 27 Oct 2020 10:17:31 +0100
Subject: NMT-450 - partial success
In-Reply-To: <CALQr=E-Gy3pUuOK+RUR=GAgobs2gJMMdAhs4AAUs0uEKtT2CQQ@mail.gmail.com>
References: <CALQr=E-Gy3pUuOK+RUR=GAgobs2gJMMdAhs4AAUs0uEKtT2CQQ@mail.gmail.com>
Message-ID: <F553AED7-8FBE-4ED0-B32E-B75437D2334A@tomcsanyi.net>

Brilliant! \o/

Cheers,
Domi


> 2020. okt. 27. d?tummal, 1:28 id?pontban Sipos Csaba <dchardware at gmail.com> ?rta:
> 
> ?
> It works!
> 
> Long story short: the LimeSDR-Mini was off by 3.5kHz, and not the phone. Even after 30 years, the phone is only off by 14Hz, what a performance. Made in West Germany :-))
> 
> After the recalibration of the LimeSDR Mini, the phone successfully updated the TA and went to normal idle state. Calls are also possible, SMS will be tested when a capable phone arrives. All  TA combinations were tested (1-15).
> 
> Will create an updated patch for the country specific settings, now that it is tested.
> 
> The lesson is: trust but verify :-) Especially with cheap hardware.
> 
> Regards,
> Csaba
> 
> Tomcsanyi, Domonkos <domi at tomcsanyi.net> ezt ?rta (id?pont: 2020. okt. 26., H, 19:54):
>> Hello Csaba,
>> 
>> I am not sure if you know this, wanted to mention it: you could easily measure your SDR?s oscillator accuracy using the kalibrate tool. It uses nearby GSM BTSs if I am correct to give you a good estimation about how much off your oscillator is.
>> I used to use it with rtl-sdr a lot, because those USB dongles are crazy off in terms off accuracy.
>> Once you have an offset figured out for the current temperature I guess you could try to offset the frequency set by osmocom by that amount. Maybe even try to expose it as a variable if needed.
>> Other solution would be using some kind of a GPSDO or similar 10 MHz input if the LineSDR supports it.
>> 
>> Sorry again if this is known info, but wanted to chime in with some hopefully helpful bits.
>> 
>> Cheers,
>> Domi
>> 
>> 
>>> 2020. okt. 26. d?tummal, 16:08 id?pontban Sipos Csaba <dchardware at gmail.com> ?rta:
>>> 
>>> ?
>>> Hi Ralph,
>>> 
>>> I attached the patch for the country specific settings for Hungary, you can apply it against "master" . TAs are not yet verified, but the phone goes "green" with all TAs from 1 to 15. The RF part and country code are verified.
>>> 
>>> > One thing, maybe your MCR has drifted, due to ageing?! 
>>> 
>>> Well, that was my first impression too, as if you look at my picture ( http://www.imagebam.com/image/d17e881357285965 ) you will see that the center of the downlink and uplink transmissions are not exactly 10MHz apart, they have a couple kHz drift. On the picture the two markers are indicating the nominal frequency of the channel. As you can see the uplink burst is actually closer to the nominal frequency, compared to the downlink. It is not in the standard (or I was not able to find it, in general the RF spec is not very detailed...), so I am not sure if the SDRs downlink signal is off, and the phone is correct or the other way around. Although it sure looks like a low layer fault, as the NMT network is not even detecting is as bad or incorrect frames.
>>> 
>>> I did a loopback test with a jumper between the TX and RX of the SDR and that seemed to work (frame level and frame quality were 90+%). On the other hand if the local oscillator would be off, the phone would not be able to lock on the DL signal as well. I have no high precision counter at home, but with a relatively primitive multimeter I was able to measure 12.7999MHz on the 12.8MHz local oscillator. And both identical phones behave the same.
>>> 
>>> The question is if I can somehow offset the uplink frequency on the SDR side or via config/source modification to remove this couple kHz drift?
>>> 
>>> If someone has seen a lot of these signals and can take a look at the image above, would be lovely to hear if any of the signals are off.
>>> 
>>> I will also get another more "modern" phone hopefully soon, so I can try with that.
>>> 
>>> Regards,
>>> Csaba
>>> 
>>> Ralph A. Schmid, dk5ras <ralph at schmid.xxx> ezt ?rta (id?pont: 2020. okt. 26., H, 15:33):
>>>> Hi Chaba,
>>>> 
>>>>  
>>>> 
>>>> I have a Nokia handheld phone from Hungary, I can try with your settings and let you know.
>>>> 
>>>>  
>>>> 
>>>> Andreas seems to be difficult to reach these days, I found the same :/
>>>> 
>>>> 
>>>> With best regards
>>>> 
>>>> 
>>>> Ralph.
>>>> 
>>>>  
>>>> 
>>>>  
>>>> 
>>>>  
>>>> 
>>>> From: OpenBSC [mailto:openbsc-bounces at lists.osmocom.org] On Behalf Of Sipos Csaba
>>>> Sent: Monday, October 26, 2020 3:16 PM
>>>> To: openbsc-request at lists.osmocom.org <openbsc at lists.osmocom.org>
>>>> Subject: Fwd: NMT-450 - partial success
>>>> 
>>>>  
>>>> 
>>>> Hi,
>>>> 
>>>>  
>>>> 
>>>> I know it is a bit off topic, but as osmocom-analog has no dedicated mail list and my every attempt to contact Andreas lead to silence, I thought this is the closest one to discuss it.
>>>> 
>>>>  
>>>> 
>>>> I try to create an NMT-450 network with Motorola MCR4800XL phones, and a LimeSDR-mini. As the phones are locked to "Hungary" using a specific raster and a large gap in the middle, first I needed to dig out the details, find out the country code and create a patch so at least the phone is willing to lock onto the DS signal. I managed to do all that, so now the phone is actually able to decode the network and lock onto the signal.
>>>> 
>>>>  
>>>> 
>>>> My issue is with the uplink: when the phone tries Traffic Area update (the phone's uplink transmission burts is clearly seen with a spectrum analyzer), the network side is not able to detect the uplink burst at all. Not even as bad, or incorrectly formatted frame. Andreas has a site which describes how to set up the uplink side and do some tests:
>>>> 
>>>>  
>>>> 
>>>> http://osmocom-analog.eversberg.eu/docs/sdr.html
>>>> 
>>>>  
>>>> 
>>>> I followed that guide and when the uplink burst from the phone arrives, the RX IQ constellation monitor indicates a correct burst with proper power (the burst is nicely round and in the green area). If I try to set up a call to the phone using the correct country code and phone number, the phone clearly responds to the paging request, as the 3 paging attempt generates 3 uplink bursts. Again, with no reception/decoding on the network side. Tried with two phones of the same type, the effect is the same.
>>>> 
>>>>  
>>>> 
>>>> I have two questions:
>>>> 
>>>>  
>>>> 
>>>> 1. Where to send patches for the osmocom-analog project?
>>>> 
>>>> 2. Does anyone have an idea what can be wrong with my setup?
>>>> 
>>>>  
>>>> 
>>>> One more thing I noticed: compared to the channel frequency used to set the NMT network up, the uplink is a couple kHz shifted:
>>>> 
>>>>  
>>>> 
>>>> http://www.imagebam.com/image/d17e881357285965
>>>> 
>>>>  
>>>> 
>>>> As it can be seen, the uplink burst appears 3-4kHz left relative to the downlink signal.
>>>> 
>>>>  
>>>> 
>>>> The network is started with the following command:
>>>> 
>>>> nmt -k 239 -k 235 -Y HU,1 --limesdr-mini --sdr-rx-gain 20
>>>> 
>>>>  
>>>> 
>>>> Any and all help is appreciated.
>>>> 
>>>>  
>>>> 
>>>> Regards,
>>>> 
>>>> Csaba
>>>> 
>>> 
>>> <0001-Add-country-specific-settings-for-Hungary.patch>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20201027/bba2d9e1/attachment.htm>

From dchardware at gmail.com  Tue Oct 27 18:08:46 2020
From: dchardware at gmail.com (Sipos Csaba)
Date: Tue, 27 Oct 2020 19:08:46 +0100
Subject: [PATCH] Adds country specific settings for Hungary.
Message-ID: <CALQr=E9WMDr_-KBwWdQAH=UgB88nd=ph2p1G2dOSG8F_CtY_Jg@mail.gmail.com>

This is the final patch for Hungary specific settings for the
osmocom-analog project.

Tested against a locked Motorola MCR4800XL, it works on all channels and
TAs.

Please let me know if any more work needs to be done.

Regards,
Csaba
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20201027/44cb5fae/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-Adds-country-specific-settings-for-Hungary.patch
Type: application/octet-stream
Size: 1853 bytes
Desc: not available
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20201027/44cb5fae/attachment.obj>

From andreas at eversberg.eu  Tue Oct 27 20:06:25 2020
From: andreas at eversberg.eu (Andreas Eversberg)
Date: Tue, 27 Oct 2020 21:06:25 +0100
Subject: [PATCH] Adds country specific settings for Hungary.
In-Reply-To: <CALQr=E9WMDr_-KBwWdQAH=UgB88nd=ph2p1G2dOSG8F_CtY_Jg@mail.gmail.com>
References: <CALQr=E9WMDr_-KBwWdQAH=UgB88nd=ph2p1G2dOSG8F_CtY_Jg@mail.gmail.com>
Message-ID: <8060d204-0135-bfa2-e1c6-dd88f8c49c50@eversberg.eu>

Sipos Csaba wrote:
> This is the final patch for Hungary specific settings for the 
> osmocom-analog project.
>
> Tested against a locked Motorola MCR4800XL, it works on all channels 
> and TAs.
>
> Please let me know if any more work needs to be done.
>
> Regards,
> Csaba
Hi Csaba,

thank your for your patch! Can you review it for a moment?

You stated that "All  TA combinations were tested (1-15)." in your 
previous messages. Your patch only includes the range 1-9:

+ { 450, 1, 6, 1,9, "HU", "Hungary", "WESTEL 0660", frq_450_hu },

Also the channel 132 appears twice:

+ { 132,239, 467.370, -0.020, 0.8, 10.0, 0 },
+ { 1, 132, 469.990, -0.020, 0.8, 10.0, 0 },


For the first line it is 467.370 MHz
For the second line I calculated 467.370 MHz too.
Both channels have the same frequency. Why not combine them as "{ 1, 
239, 469.990, -0.020, 0.8, 10.0, 0 },". Is there some gap? Do I miss 
something?

Best regards,

Andreas



From a.valizadeh at sinacomsys.com  Wed Oct 28 10:55:46 2020
From: a.valizadeh at sinacomsys.com (a.valizadeh at sinacomsys.com)
Date: Wed, 28 Oct 2020 14:25:46 +0330
Subject: GSUP <> MAP Conversion
Message-ID: <11059cdcf89d6cca225b28a1b1f47059@sinacomsys.com>

Hi!

i'm very interested about GSUP <-> GSM MAP protocol conversion to 
perform HLR interrogation. Do you suggest a suitable solution for this 
problem? is there some related activity at OSMOCOM project?


From dchardware at gmail.com  Wed Oct 28 15:15:10 2020
From: dchardware at gmail.com (Sipos Csaba)
Date: Wed, 28 Oct 2020 16:15:10 +0100
Subject: OpenBSC Digest, Vol 72, Issue 18
In-Reply-To: <mailman.29.1603886400.24623.openbsc@lists.osmocom.org>
References: <mailman.29.1603886400.24623.openbsc@lists.osmocom.org>
Message-ID: <CALQr=E857M5-2DT0Wif=9Uyw94qDrPfgzL6j_M4SjngTeptLQA@mail.gmail.com>

Hi Andreas,

Fixed the patch. Yes there is a gap in the middle, that is why it is split
to two: 1..72 and 132..239 is the correct one and it uses a reverse
numbering like the Slovak or Czech networks. This is the reason the NMT
phones in Hungary was not compatible with any other country, and the phones
country settings were locked to Hungary only. For example in my MCR4800XL
the country cannot be set, yet if you read out the EPROM, it contains the
country settings for all country, but it is locked down to Hungary only.

Regards,
Csaba

<openbsc-request at lists.osmocom.org> ezt ?rta (id?pont: 2020. okt. 28., Sze,
13:00):

> Send OpenBSC mailing list submissions to
>         openbsc at lists.osmocom.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
>         https://lists.osmocom.org/mailman/listinfo/openbsc
> or, via email, send a message with subject or body 'help' to
>         openbsc-request at lists.osmocom.org
>
> You can reach the person managing the list at
>         openbsc-owner at 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. [PATCH] Adds country specific settings for Hungary. (Sipos Csaba)
>    2. Re: [PATCH] Adds country specific settings for Hungary.
>       (Andreas Eversberg)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Tue, 27 Oct 2020 19:08:46 +0100
> From: Sipos Csaba <dchardware at gmail.com>
> To: "openbsc-request at lists.osmocom.org" <openbsc at lists.osmocom.org>
> Subject: [PATCH] Adds country specific settings for Hungary.
> Message-ID:
>         <CALQr=E9WMDr_-KBwWdQAH=UgB88nd=
> ph2p1G2dOSG8F_CtY_Jg at mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> This is the final patch for Hungary specific settings for the
> osmocom-analog project.
>
> Tested against a locked Motorola MCR4800XL, it works on all channels and
> TAs.
>
> Please let me know if any more work needs to be done.
>
> Regards,
> Csaba
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> http://lists.osmocom.org/pipermail/openbsc/attachments/20201027/44cb5fae/attachment-0001.htm
> >
> -------------- next part --------------
> A non-text attachment was scrubbed...
> Name: 0001-Adds-country-specific-settings-for-Hungary.patch
> Type: application/octet-stream
> Size: 1853 bytes
> Desc: not available
> URL: <
> http://lists.osmocom.org/pipermail/openbsc/attachments/20201027/44cb5fae/attachment-0001.obj
> >
>
> ------------------------------
>
> Message: 2
> Date: Tue, 27 Oct 2020 21:06:25 +0100
> From: Andreas Eversberg <andreas at eversberg.eu>
> To: Sipos Csaba <dchardware at gmail.com>,
>         "openbsc-request at lists.osmocom.org" <openbsc at lists.osmocom.org>
> Subject: Re: [PATCH] Adds country specific settings for Hungary.
> Message-ID: <8060d204-0135-bfa2-e1c6-dd88f8c49c50 at eversberg.eu>
> Content-Type: text/plain; charset=UTF-8; format=flowed
>
> Sipos Csaba wrote:
> > This is the final patch for Hungary specific settings for the
> > osmocom-analog project.
> >
> > Tested against a locked Motorola MCR4800XL, it works on all channels
> > and TAs.
> >
> > Please let me know if any more work needs to be done.
> >
> > Regards,
> > Csaba
> Hi Csaba,
>
> thank your for your patch! Can you review it for a moment?
>
> You stated that "All  TA combinations were tested (1-15)." in your
> previous messages. Your patch only includes the range 1-9:
>
> + { 450, 1, 6, 1,9, "HU", "Hungary", "WESTEL 0660", frq_450_hu },
>
> Also the channel 132 appears twice:
>
> + { 132,239, 467.370, -0.020, 0.8, 10.0, 0 },
> + { 1, 132, 469.990, -0.020, 0.8, 10.0, 0 },
>
>
> For the first line it is 467.370 MHz
> For the second line I calculated 467.370 MHz too.
> Both channels have the same frequency. Why not combine them as "{ 1,
> 239, 469.990, -0.020, 0.8, 10.0, 0 },". Is there some gap? Do I miss
> something?
>
> Best regards,
>
> Andreas
>
>
>
> ------------------------------
>
> Subject: Digest Footer
>
> _______________________________________________
> OpenBSC mailing list
> OpenBSC at lists.osmocom.org
> https://lists.osmocom.org/mailman/listinfo/openbsc
>
>
> ------------------------------
>
> End of OpenBSC Digest, Vol 72, Issue 18
> ***************************************
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20201028/3ae4e416/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-Adds-country-specific-settings-for-Hungary.patch
Type: application/octet-stream
Size: 1854 bytes
Desc: not available
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20201028/3ae4e416/attachment.obj>

From andreas at eversberg.eu  Thu Oct 29 06:22:02 2020
From: andreas at eversberg.eu (Andreas Eversberg)
Date: Thu, 29 Oct 2020 07:22:02 +0100
Subject: OpenBSC Digest, Vol 72, Issue 18
In-Reply-To: <CALQr=E857M5-2DT0Wif=9Uyw94qDrPfgzL6j_M4SjngTeptLQA@mail.gmail.com>
References: <mailman.29.1603886400.24623.openbsc@lists.osmocom.org>
 <CALQr=E857M5-2DT0Wif=9Uyw94qDrPfgzL6j_M4SjngTeptLQA@mail.gmail.com>
Message-ID: <97957395-4c0b-f73e-f8f8-5ed3e0a38d9f@eversberg.eu>

Sipos Csaba wrote:
> Fixed the patch
Hi Csaba,

it is committed, thanx allot!

Andreas



From laforge at osmocom.org  Thu Oct 29 14:17:28 2020
From: laforge at osmocom.org (Harald Welte)
Date: Thu, 29 Oct 2020 15:17:28 +0100
Subject: GSUP <> MAP Conversion
In-Reply-To: <11059cdcf89d6cca225b28a1b1f47059@sinacomsys.com>
References: <11059cdcf89d6cca225b28a1b1f47059@sinacomsys.com>
Message-ID: <20201029141728.GI32319@nataraja>

Dear A. Valizadeh,

On Wed, Oct 28, 2020 at 02:25:46PM +0330, a.valizadeh at sinacomsys.com wrote:
> i'm very interested about GSUP <-> GSM MAP protocol conversion to perform
> HLR interrogation. Do you suggest a suitable solution for this problem? is
> there some related activity at OSMOCOM project?

We have all been very interested in this topic for many years, but like any
FOSS project, Osmocom only implements what people contribute, either in form
of code or in terms of funding so some of the existing developers can add that
support.

There has never been sufficient contributions in either developer resouces/code
or funding to complete e.g. the signerl TCAP/MAP implementation and to subsequently
translate GSUP to MAP.

There is a very minimalistic DIAMETeR to GSUP translator which was used to 
run an open5gs based EPC (together with Osmocom 2G/3G) against the OsmoHLR,
see https://git.osmocom.org/erlang/osmo_dia2gsup/

Regards,
	Harald
-- 
- Harald Welte <laforge at osmocom.org>            http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
                                                  (ETSI EN 300 175-7 Ch. A6)