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.comHello 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>