OpenBSC Digest, Vol 28, Issue 5

This is merely a historical archive of years 2008-2021, before the migration to mailman3.

A maintained and still updated list archive can be found at https://lists.osmocom.org/hyperkitty/list/OpenBSC@lists.osmocom.org/.

Rajitha peiris raji.oshin at hotmail.com
Thu Feb 9 03:30:11 UTC 2017


Hello all

can anyone  send me a openbsc.cfg file for nanobts 1900pcs....? because still i am struck with my nanobts pcs1900.....i can send sms but no voice calls.....do i need to install mISDN and LCR for single bts ? ....


thanks

regards

Rajitha Peiris

Sri lanka

________________________________
From: OpenBSC <openbsc-bounces at lists.osmocom.org> on behalf of openbsc-request at lists.osmocom.org <openbsc-request at lists.osmocom.org>
Sent: Wednesday, February 8, 2017 8:56:30 PM
To: openbsc at lists.osmocom.org
Subject: OpenBSC Digest, Vol 28, Issue 5

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. Re: MS cannot connect; Location Update Request not received
      by BTS (Hossein Amini)
   2. Re: [PATCH net-next v2 2/6] gtp: merge gtp_get_net and
      gtp_genl_find_dev (Harald Welte)
   3. Re: [PATCH net-next v2 1/6] gtp: make GTP sockets in
      gtp_newlink optional (Harald Welte)
   4. Re: [PATCH net-next v2 4/6] gtp: consolidate pdp context
      destruction into helper (Harald Welte)
   5. Re: [PATCH net-next v2 5/6] gtp: add socket to pdp context
      (Harald Welte)
   6. Re: [PATCH net-next v2 3/6] gtp: unify genl_find_pdp and
      prepare for per socket lookup (Harald Welte)
   7. Re: [PATCH net-next v2 0/6] gtp: misc improvements (Harald Welte)
   8. Re: weekly test report (w5 2017) (Neels Hofmeyr)


----------------------------------------------------------------------

Message: 1
Date: Mon, 6 Feb 2017 16:45:40 +0330
From: Hossein Amini <hosseinamini2578 at gmail.com>
To: openbsc at lists.osmocom.org
Subject: Re: MS cannot connect; Location Update Request not received
        by BTS
Message-ID:
        <CAF81cShkO+JiamxQJXhqfpbOWxi9_8aEWsd5wTDhmZ0Vd912Xw at mail.gmail.com>
Content-Type: text/plain; charset="utf-8"

I installed master branch now(4/feb/2017 at 18:30) and retry, but I can not
release channel and receive error in nitb.
I do not access to a external timing source like octoClock, do you use
external timing source? do you have a easy solution to check that?
My NITB log is like your log by 20170203014240662 and repeat. I retried
connecting about 10 min but nothing happened.

NITB log that repeat is:

20170204071216381 DRLL <0000> chan_alloc.c:352
(bts=0,trx=0,ts=0,pchan=CCCH+SDCCH4)
Allocating lchan=0 as SDCCH
20170204071216381 DRSL <0004> abis_rsl.c:1819 (bts=0,trx=0,ts=0,ss=0)
Activating ARFCN(0) SS(0) lctype SDCCH r=LOCATION_UPDATE ra=0x06 ta=0
20170204071216381 DRSL <0004> abis_rsl.c:580
(bts=0,trx=0,ts=0,pchan=CCCH+SDCCH4)
Tx RSL Channel Activate with act_type=INITIAL
20170204071216381 DRSL <0004> abis_rsl.c:1189 (bts=0,trx=0,ts=0,ss=0) state
NONE -> ACTIVATION REQUESTED
20170204071216381 DRSL <0004> abis_rsl.c:1546 (bts=0,trx=0,ts=0,ss=0)
CHANNEL ACTIVATE ACK
20170204071216381 DRSL <0004> abis_rsl.c:1189 (bts=0,trx=0,ts=0,ss=0) state
ACTIVATION REQUESTED -> ACTIVE
20170204071226381 DRSL <0004> abis_rsl.c:852 (bts=0,trx=0,ts=0,ss=0) RF
Channel Release due to error: 1
20170204071226381 DRSL <0004> abis_rsl.c:762 (bts=0,trx=0,ts=0,ss=0)
DEACTivate SACCH CMD
20170204071226381 DRSL <0004> abis_rsl.c:1189 (bts=0,trx=0,ts=0,ss=0) state
ACTIVE -> RELEASE DUE ERROR
20170204071226382 DRSL <0004> abis_rsl.c:925 (bts=0,trx=0,ts=0,ss=0) RF
CHANNEL RELEASE ACK
20170204071228382 DRSL <0004> abis_rsl.c:811 (bts=0,trx=0,ts=0,ss=0) is
back in operation.
20170204071228382 DRSL <0004> abis_rsl.c:1189 (bts=0,trx=0,ts=0,ss=0) state
RELEASE DUE ERROR -> NONE

On Fri, Feb 3, 2017 at 2:28 AM, Neels Hofmeyr <neels at hofmeyr.de> wrote:

> Dear Hossein,
>
> the mailing list is indeed the proper place to ask. If no-one replied to
> your
> question, it either means that no-one knows the answer, or that no-one has
> found the time to look into it. Don't be discouraged by that. Indeed I
> would
> prefer if you ask again on the mailing list instead of asking single mail
> addresses. I actually saw your mail on the list and did not know what to
> answer.
>
> If you ask your question on-list again (possibly once a week), it might be
> that
> someone will come up with either an answer or with more questions that may
> lead
> you to a solution...
>
> I sincerely hope that you will find a solution. It seems to me that it's
> merely
> a minor detail.
>
> ~N
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20170206/8ee7ceac/attachment-0001.html>

------------------------------

Message: 2
Date: Mon, 6 Feb 2017 14:55:12 +0100
From: Harald Welte <laforge at netfilter.org>
To: Andreas Schultz <aschultz at tpip.net>
Cc: Pablo Neira <pablo at netfilter.org>, netdev at vger.kernel.org, Lionel
        Gauthier <Lionel.Gauthier at eurecom.fr>, openbsc at lists.osmocom.org
Subject: Re: [PATCH net-next v2 2/6] gtp: merge gtp_get_net and
        gtp_genl_find_dev
Message-ID: <20170206135512.sbxvkbe3hzgnwwjt at nataraja>
Content-Type: text/plain; charset=us-ascii

Hi Andreas,

On Mon, Jan 30, 2017 at 05:37:09PM +0100, Andreas Schultz wrote:
> Both function are always used together with the final goal to
> get the gtp_dev. This simplifies the code by merging them together.

Ok, some code restructuring / unification, seems useful.

However:

> -                     netdev_dbg(dev, "GTPv0-U: update tunnel id = %llx (pdp %p)\n",
> -                                pctx->u.v0.tid, pctx);
> +                     pr_debug("GTPv0-U: update tunnel id = %llx (pdp %p)\n",
> +                              pctx->u.v0.tid, pctx);

(and other related changes) appear to be purely cosmetic and should thus
be unrelated to the function merging described in the change log
message.

--
- Harald Welte <laforge at netfilter.org>                 http://netfilter.org/
============================================================================
  "Fragmentation is like classful addressing -- an interesting early
   architectural error that shows how much experimentation was going
   on while IP was being designed."                    -- Paul Vixie


------------------------------

Message: 3
Date: Mon, 6 Feb 2017 14:51:09 +0100
From: Harald Welte <laforge at netfilter.org>
To: Andreas Schultz <aschultz at tpip.net>
Cc: Pablo Neira <pablo at netfilter.org>, netdev at vger.kernel.org, Lionel
        Gauthier <Lionel.Gauthier at eurecom.fr>, openbsc at lists.osmocom.org
Subject: Re: [PATCH net-next v2 1/6] gtp: make GTP sockets in
        gtp_newlink optional
Message-ID: <20170206135109.sw5p2yb7cbsa3g37 at nataraja>
Content-Type: text/plain; charset=us-ascii

Hi Andreas,

my kernel coding skills are getting a bit rusty (no pun intended), and
I'll think others on this list are more capable to do so.  But let me at
least provide feedback from the "3GPP / GTP side":

On Mon, Jan 30, 2017 at 05:37:08PM +0100, Andreas Schultz wrote:
> Having both GTPv0-U and GTPv1-U is not always desirable.
> Fallback from GTPv1-U to GTPv0-U was depreciated from 3GPP
> Rel-8 onwards. Post Rel-8 implementation are discuraged
> from listening on the v0 port (see 3GPP TS 29.281, Sect. 1).

I confirm this and I think the related change should be applied.

> A future change will completely decouple the sockets from the
> network device. Till then, at least one of the sockets needs to
> be specified (either v0 or v1), the other is optional.

Makes sense.

--
- Harald Welte <laforge at netfilter.org>                 http://netfilter.org/
============================================================================
  "Fragmentation is like classful addressing -- an interesting early
   architectural error that shows how much experimentation was going
   on while IP was being designed."                    -- Paul Vixie


------------------------------

Message: 4
Date: Mon, 6 Feb 2017 14:58:59 +0100
From: Harald Welte <laforge at gnumonks.org>
To: Andreas Schultz <aschultz at tpip.net>
Cc: Pablo Neira <pablo at netfilter.org>, netdev at vger.kernel.org, Lionel
        Gauthier <Lionel.Gauthier at eurecom.fr>, openbsc at lists.osmocom.org
Subject: Re: [PATCH net-next v2 4/6] gtp: consolidate pdp context
        destruction into helper
Message-ID: <20170206135859.mq6pidofidnps2q6 at nataraja>
Content-Type: text/plain; charset=us-ascii

Hi Andreas,

On Mon, Jan 30, 2017 at 05:37:11PM +0100, Andreas Schultz wrote:
> Consolidate duplicate code into helper.

Makes complete sense.

However:

> +static void pdp_context_delete(struct pdp_ctx *pctx);
> +

why introduce the forward-declaration and then define the function
further down in the file?  I think in general, it is preferred to put
helper functions on top, before their first use, so forward declarations
can be avoided?  Particularly if the helper function doesn't call any
other functions that are not yet declared at this point.

Please note the above might just be my personal taste, not sure if
that's a general habit in the kernel networking code these days.

So with or without the re-ordering:

Acked-by: Harald Welte <laforge at gnumonks.org>

--
- 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)


------------------------------

Message: 5
Date: Mon, 6 Feb 2017 15:04:18 +0100
From: Harald Welte <laforge at gnumonks.org>
To: Andreas Schultz <aschultz at tpip.net>
Cc: pablo <pablo at netfilter.org>, netdev <netdev at vger.kernel.org>,
        Lionel Gauthier <Lionel.Gauthier at eurecom.fr>, openbsc
        <openbsc at lists.osmocom.org>
Subject: Re: [PATCH net-next v2 5/6] gtp: add socket to pdp context
Message-ID: <20170206140418.dwiofucns5eolgel at nataraja>
Content-Type: text/plain; charset=us-ascii

Dear All,

On Thu, Feb 02, 2017 at 04:07:23PM +0100, Andreas Schultz wrote:
> ----- On Feb 2, 2017, at 3:46 PM, pablo pablo at netfilter.org wrote:
> > On Thu, Feb 02, 2017 at 03:38:07PM +0100, Andreas Schultz wrote:
> >> ----- On Feb 2, 2017, at 3:28 PM, pablo pablo at netfilter.org wrote:
> >> > I suggest you just call kfree_rcu() from 4/6.
> >> >
> >> > Regarding holding socket reference, see my comment for patch 1/6.
> >>
> >> This is going to be a problem at this stage of the changes.
> >>
> >> The final goal is to have a reference from the socket to the pdp context.
> >
> > Is this just a cleanup? Or you need this sk caching for some follow up
> > work?
>
> It's not caching, the plan is to completely remove the socket from the
> GTP netdevice (as far as that is possible without breaking the existing API).

I agree this is the way to go.  When I originally thought about the GTP
kernel tunneling module early on, I was not aware of the fact that
operators actually in practise run multiple "virtual GGSNs" on one IP
address/port.  From a pure technical point of view you would say "why
bother"?  They could just use separate IP addresses for each of them.
However, the reailty is that each new IP address that an operator uses
for a GGSN results in paper forms required to be exchanged between this
operator and all his roming partners, followed-up by manual
re-configuration of the policies on all of those roaming partners.  This
is time-consuming and error-prone, but hey, it's how the procedures
between GSMA members seem to work ;)

> A GGSN or PGW can serve multiple APN's on the same GTP-U socket. Those APN's
> can have overlapping IP address ranges. The only sensible way to handle
> this, is to have a netdevice per APN. This breaks the current 1:1 relation
> between sockets and netdevices.

Indeed.  So the question is how to do this best and how to keep
backwards compatibility of the netlink interface.  I don't claim to have
answers to that, sorry.

--
- 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)


------------------------------

Message: 6
Date: Mon, 6 Feb 2017 14:56:13 +0100
From: Harald Welte <laforge at gnumonks.org>
To: Andreas Schultz <aschultz at tpip.net>
Cc: Pablo Neira <pablo at netfilter.org>, netdev at vger.kernel.org, Lionel
        Gauthier <Lionel.Gauthier at eurecom.fr>, openbsc at lists.osmocom.org
Subject: Re: [PATCH net-next v2 3/6] gtp: unify genl_find_pdp and
        prepare for per socket lookup
Message-ID: <20170206135613.x6ryxtrzktqx65n2 at nataraja>
Content-Type: text/plain; charset=us-ascii

On Mon, Jan 30, 2017 at 05:37:10PM +0100, Andreas Schultz wrote:
> Signed-off-by: Andreas Schultz <aschultz at tpip.net>

Acked-by: Harald Welte <laforge at gnumonks.org>

--
- 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)


------------------------------

Message: 7
Date: Mon, 6 Feb 2017 14:46:37 +0100
From: Harald Welte <laforge at gnumonks.org>
To: David Miller <davem at davemloft.net>
Cc: aschultz at tpip.net, pablo at netfilter.org, netdev at vger.kernel.org,
        Lionel.Gauthier at eurecom.fr, openbsc at lists.osmocom.org
Subject: Re: [PATCH net-next v2 0/6] gtp: misc improvements
Message-ID: <20170206134637.bwiyfrtsmhycipxx at nataraja>
Content-Type: text/plain; charset=us-ascii

Hi Dave and List,

On Tue, Jan 31, 2017 at 01:05:43PM -0500, David Miller wrote:
> Please someone with GTP knowledge properly review this series.

I am happy to provide review, but I was travelling and my time to work
on things outside my dayjob is typically quite limited.  So I'd like to
ask for a bit more patience for patch review from me.  Thanks for your
understanding.

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)


------------------------------

Message: 8
Date: Wed, 8 Feb 2017 16:26:11 +0100
From: Neels Hofmeyr <nhofmeyr at sysmocom.de>
To: Ivaylo Kostov <ikostov at sysmocom.de>
Cc: Harald Welte <laforge at gnumonks.org>, openbsc at lists.osmocom.org
Subject: Re: weekly test report (w5 2017)
Message-ID: <20170208152611.GB1544 at my.box>
Content-Type: text/plain; charset="iso-8859-1"

(found this mail stuck in my outbox, sending late)

On Mon, Feb 06, 2017 at 10:09:23AM +0100, Ivaylo Kostov wrote:
> Hi Harald,
>
> I see. What was communicated to me was that NITB channel configuration
> TCH/F_TCH/H_PDCH is not supported with nanoBTS.
>
> I will have in mind that nanoBTS does not support HR (v1) codec.

Yes, we discussed TCH/F_TCH/H_PDCH for the nanoBTS. I remember to be surprised
because from some discussion it appeared that the nanoBTS supports HR, and I
was expecting TCH/F only.

While talking about codecs, the ip.access nanoBTS *should* in fact support the
TCH/F_PDCH dynamic timeslots. Ivaylo, could you check whether that is part of
your testing procedure and add it if not?

~N


--
- Neels Hofmeyr <nhofmeyr 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
* Gesch?ftsf?hrer / Managing Directors: Harald Welte
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20170208/5dfdfaff/attachment.bin>

------------------------------

Subject: Digest Footer

_______________________________________________
OpenBSC mailing list
OpenBSC at lists.osmocom.org
https://lists.osmocom.org/mailman/listinfo/openbsc


------------------------------

End of OpenBSC Digest, Vol 28, Issue 5
**************************************
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20170209/fa7bb625/attachment.htm>


More information about the OpenBSC mailing list