<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">
<meta name="Generator" content="Microsoft Exchange Server">
<!-- converted from text --><style><!-- .EmailQuote { margin-left: 1pt; padding-left: 4pt; border-left: #800000 2px solid; } --></style>
</head>
<body>
<meta content="text/html; charset=UTF-8">
<style type="text/css" style="">
<!--
p
{margin-top:0;
margin-bottom:0}
-->
</style>
<div dir="ltr">
<div id="x_divtagdefaultwrapper" dir="ltr" style="font-size:12pt; color:#000000; font-family:Calibri,Arial,Helvetica,sans-serif">
<p><img size="135124" id="x_img298238" style="max-width:99.9%" src="cid:9b893015-fe6c-4d05-9933-7169f767fc97"><br>
</p>
</div>
<hr tabindex="-1" style="display:inline-block; width:98%">
<div id="x_divRplyFwdMsg" dir="ltr"><font face="Calibri, sans-serif" color="#000000" style="font-size:11pt"><b>From:</b> OpenBSC <openbsc-bounces@lists.osmocom.org> on behalf of openbsc-request@lists.osmocom.org <openbsc-request@lists.osmocom.org><br>
<b>Sent:</b> Thursday, February 9, 2017 9:00:47 AM<br>
<b>To:</b> openbsc@lists.osmocom.org<br>
<b>Subject:</b> OpenBSC Digest, Vol 28, Issue 6</font>
<div> </div>
</div>
</div>
<font size="2"><span style="font-size:10pt;">
<div class="PlainText">Send OpenBSC mailing list submissions to<br>
openbsc@lists.osmocom.org<br>
<br>
To subscribe or unsubscribe via the World Wide Web, visit<br>
<a href="https://lists.osmocom.org/mailman/listinfo/openbsc">https://lists.osmocom.org/mailman/listinfo/openbsc</a><br>
or, via email, send a message with subject or body 'help' to<br>
openbsc-request@lists.osmocom.org<br>
<br>
You can reach the person managing the list at<br>
openbsc-owner@lists.osmocom.org<br>
<br>
When replying, please edit your Subject line so it is more specific<br>
than "Re: Contents of OpenBSC digest..."<br>
<br>
<br>
Today's Topics:<br>
<br>
1. Re: weekly test report (w5 2017) (Ivaylo Kostov)<br>
2. Re: weekly test report (w5 2017) (Harald Welte)<br>
3. Re: weekly test report (w5 2017) (Neels Hofmeyr)<br>
4. Re: OpenBSC Digest, Vol 28, Issue 5 (Rajitha peiris)<br>
<br>
<br>
----------------------------------------------------------------------<br>
<br>
Message: 1<br>
Date: Wed, 8 Feb 2017 16:33:26 +0100<br>
From: Ivaylo Kostov <ikostov@sysmocom.de><br>
To: Neels Hofmeyr <nhofmeyr@sysmocom.de><br>
Cc: Harald Welte <laforge@gnumonks.org>, openbsc@lists.osmocom.org<br>
Subject: Re: weekly test report (w5 2017)<br>
Message-ID: <06726d26-d66f-d48d-cf9d-533178a13ada@sysmocom.de><br>
Content-Type: text/plain; charset=windows-1252; format=flowed<br>
<br>
Hi Neels,<br>
<br>
Yes. I do have TCH/F_PDCH dynamic timeslots in the test procedure.<br>
<br>
regards,<br>
Ivaylo<br>
<br>
On 08.02.2017 16:26, Neels Hofmeyr wrote:<br>
> (found this mail stuck in my outbox, sending late)<br>
><br>
> On Mon, Feb 06, 2017 at 10:09:23AM +0100, Ivaylo Kostov wrote:<br>
>> Hi Harald,<br>
>><br>
>> I see. What was communicated to me was that NITB channel configuration<br>
>> TCH/F_TCH/H_PDCH is not supported with nanoBTS.<br>
>><br>
>> I will have in mind that nanoBTS does not support HR (v1) codec.<br>
><br>
> Yes, we discussed TCH/F_TCH/H_PDCH for the nanoBTS. I remember to be surprised<br>
> because from some discussion it appeared that the nanoBTS supports HR, and I<br>
> was expecting TCH/F only.<br>
><br>
> While talking about codecs, the ip.access nanoBTS *should* in fact support the<br>
> TCH/F_PDCH dynamic timeslots. Ivaylo, could you check whether that is part of<br>
> your testing procedure and add it if not?<br>
><br>
> ~N<br>
><br>
>-- <br>
------------------------------<br>
- Ivaylo Kostov <ikostov@sysmocom.de> <<a href="mailto:ikostov@sysmocom.de">mailto:ikostov@sysmocom.de</a>>
<br>
<a href="http://www.sysmocom.de/">http://www.sysmocom.de/</a><br>
=======================================================================<br>
* sysmocom - systems for mobile communications GmbH<br>
* Alt-Moabit 93<br>
* 10559 Berlin, Germany<br>
* Sitz / Registered office: Berlin, HRB 134158 B<br>
* Geschaeftsfuehrer / Managing Director: Harald Welte<br>
------------------------------<br>
<br>
<br>
<br>
------------------------------<br>
<br>
Message: 2<br>
Date: Wed, 8 Feb 2017 16:45:57 +0100<br>
From: Harald Welte <laforge@gnumonks.org><br>
To: Neels Hofmeyr <nhofmeyr@sysmocom.de><br>
Cc: Ivaylo Kostov <ikostov@sysmocom.de>, openbsc@lists.osmocom.org<br>
Subject: Re: weekly test report (w5 2017)<br>
Message-ID: <20170208154557.2rmslkrzuqlv7xc4@nataraja><br>
Content-Type: text/plain; charset=us-ascii<br>
<br>
Hi all,<br>
<br>
On Wed, Feb 08, 2017 at 04:26:11PM +0100, Neels Hofmeyr wrote:<br>
<br>
> While talking about codecs, the ip.access nanoBTS *should* in fact support the<br>
> TCH/F_PDCH dynamic timeslots. Ivaylo, could you check whether that is part of<br>
> your testing procedure and add it if not?<br>
<br>
libbsc should be extended to handle those restrictions, i.e. reject a<br>
configuration containing HR codec or a osmocom-style dynamic channel on<br>
a bts model 'nanobts'.<br>
<br>
Similarly, the BS11 should reject any codec except HRv1, FR and EFR<br>
(i.e. no AMR).<br>
<br>
In reality there are also older nanoBTSs that don't support AMR (as far<br>
as I remember), but that shouldn't prevent us from having at least the<br>
most basic checks in place.<br>
<br>
For osmo-bts, we need a more sophisticated hand-shaking mechanism, as<br>
there are many different hardware/PHYs (and associated versions)<br>
supported by it. This is left for further study ;)<br>
<br>
-- <br>
- Harald Welte <laforge@gnumonks.org> <a href="http://laforge.gnumonks.org/">
http://laforge.gnumonks.org/</a><br>
============================================================================<br>
"Privacy in residential applications is a desirable marketing option."<br>
(ETSI EN 300 175-7 Ch. A6)<br>
<br>
<br>
------------------------------<br>
<br>
Message: 3<br>
Date: Thu, 9 Feb 2017 00:43:35 +0100<br>
From: Neels Hofmeyr <nhofmeyr@sysmocom.de><br>
To: Harald Welte <laforge@gnumonks.org><br>
Cc: Ivaylo Kostov <ikostov@sysmocom.de>, openbsc@lists.osmocom.org<br>
Subject: Re: weekly test report (w5 2017)<br>
Message-ID: <20170208234335.GB27422@my.box><br>
Content-Type: text/plain; charset="us-ascii"<br>
<br>
On Wed, Feb 08, 2017 at 04:45:57PM +0100, Harald Welte wrote:<br>
> libbsc should be extended to handle those restrictions, i.e. reject a<br>
> configuration containing HR codec or a osmocom-style dynamic channel on<br>
> a bts model 'nanobts'.<br>
<br>
i.e. checks on the VTY level.<br>
<br>
Seems like we want an issue for that: <a href="https://osmocom.org/issues/1946">https://osmocom.org/issues/1946</a><br>
<br>
~N<br>
-------------- next part --------------<br>
A non-text attachment was scrubbed...<br>
Name: signature.asc<br>
Type: application/pgp-signature<br>
Size: 819 bytes<br>
Desc: Digital signature<br>
URL: <<a href="http://lists.osmocom.org/pipermail/openbsc/attachments/20170209/14039e1e/attachment-0001.bin">http://lists.osmocom.org/pipermail/openbsc/attachments/20170209/14039e1e/attachment-0001.bin</a>><br>
<br>
------------------------------<br>
<br>
Message: 4<br>
Date: Thu, 9 Feb 2017 03:30:11 +0000<br>
From: Rajitha peiris <raji.oshin@hotmail.com><br>
To: "openbsc@lists.osmocom.org" <openbsc@lists.osmocom.org><br>
Subject: Re: OpenBSC Digest, Vol 28, Issue 5<br>
Message-ID:<br>
<HK2PR0301MB13146A64D0273A56FAB1142382450@HK2PR0301MB1314.apcprd03.prod.outlook.com><br>
<br>
Content-Type: text/plain; charset="us-ascii"<br>
<br>
Hello all<br>
<br>
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 ? ....<br>
<br>
<br>
thanks<br>
<br>
regards<br>
<br>
Rajitha Peiris<br>
<br>
Sri lanka<br>
<br>
________________________________<br>
From: OpenBSC <openbsc-bounces@lists.osmocom.org> on behalf of openbsc-request@lists.osmocom.org <openbsc-request@lists.osmocom.org><br>
Sent: Wednesday, February 8, 2017 8:56:30 PM<br>
To: openbsc@lists.osmocom.org<br>
Subject: OpenBSC Digest, Vol 28, Issue 5<br>
<br>
Send OpenBSC mailing list submissions to<br>
openbsc@lists.osmocom.org<br>
<br>
To subscribe or unsubscribe via the World Wide Web, visit<br>
<a href="https://lists.osmocom.org/mailman/listinfo/openbsc">https://lists.osmocom.org/mailman/listinfo/openbsc</a><br>
or, via email, send a message with subject or body 'help' to<br>
openbsc-request@lists.osmocom.org<br>
<br>
You can reach the person managing the list at<br>
openbsc-owner@lists.osmocom.org<br>
<br>
When replying, please edit your Subject line so it is more specific<br>
than "Re: Contents of OpenBSC digest..."<br>
<br>
<br>
Today's Topics:<br>
<br>
1. Re: MS cannot connect; Location Update Request not received<br>
by BTS (Hossein Amini)<br>
2. Re: [PATCH net-next v2 2/6] gtp: merge gtp_get_net and<br>
gtp_genl_find_dev (Harald Welte)<br>
3. Re: [PATCH net-next v2 1/6] gtp: make GTP sockets in<br>
gtp_newlink optional (Harald Welte)<br>
4. Re: [PATCH net-next v2 4/6] gtp: consolidate pdp context<br>
destruction into helper (Harald Welte)<br>
5. Re: [PATCH net-next v2 5/6] gtp: add socket to pdp context<br>
(Harald Welte)<br>
6. Re: [PATCH net-next v2 3/6] gtp: unify genl_find_pdp and<br>
prepare for per socket lookup (Harald Welte)<br>
7. Re: [PATCH net-next v2 0/6] gtp: misc improvements (Harald Welte)<br>
8. Re: weekly test report (w5 2017) (Neels Hofmeyr)<br>
<br>
<br>
----------------------------------------------------------------------<br>
<br>
Message: 1<br>
Date: Mon, 6 Feb 2017 16:45:40 +0330<br>
From: Hossein Amini <hosseinamini2578@gmail.com><br>
To: openbsc@lists.osmocom.org<br>
Subject: Re: MS cannot connect; Location Update Request not received<br>
by BTS<br>
Message-ID:<br>
<CAF81cShkO+JiamxQJXhqfpbOWxi9_8aEWsd5wTDhmZ0Vd912Xw@mail.gmail.com><br>
Content-Type: text/plain; charset="utf-8"<br>
<br>
I installed master branch now(4/feb/2017 at 18:30) and retry, but I can not<br>
release channel and receive error in nitb.<br>
I do not access to a external timing source like octoClock, do you use<br>
external timing source? do you have a easy solution to check that?<br>
My NITB log is like your log by 20170203014240662 and repeat. I retried<br>
connecting about 10 min but nothing happened.<br>
<br>
NITB log that repeat is:<br>
<br>
20170204071216381 DRLL <0000> chan_alloc.c:352<br>
(bts=0,trx=0,ts=0,pchan=CCCH+SDCCH4)<br>
Allocating lchan=0 as SDCCH<br>
20170204071216381 DRSL <0004> abis_rsl.c:1819 (bts=0,trx=0,ts=0,ss=0)<br>
Activating ARFCN(0) SS(0) lctype SDCCH r=LOCATION_UPDATE ra=0x06 ta=0<br>
20170204071216381 DRSL <0004> abis_rsl.c:580<br>
(bts=0,trx=0,ts=0,pchan=CCCH+SDCCH4)<br>
Tx RSL Channel Activate with act_type=INITIAL<br>
20170204071216381 DRSL <0004> abis_rsl.c:1189 (bts=0,trx=0,ts=0,ss=0) state<br>
NONE -> ACTIVATION REQUESTED<br>
20170204071216381 DRSL <0004> abis_rsl.c:1546 (bts=0,trx=0,ts=0,ss=0)<br>
CHANNEL ACTIVATE ACK<br>
20170204071216381 DRSL <0004> abis_rsl.c:1189 (bts=0,trx=0,ts=0,ss=0) state<br>
ACTIVATION REQUESTED -> ACTIVE<br>
20170204071226381 DRSL <0004> abis_rsl.c:852 (bts=0,trx=0,ts=0,ss=0) RF<br>
Channel Release due to error: 1<br>
20170204071226381 DRSL <0004> abis_rsl.c:762 (bts=0,trx=0,ts=0,ss=0)<br>
DEACTivate SACCH CMD<br>
20170204071226381 DRSL <0004> abis_rsl.c:1189 (bts=0,trx=0,ts=0,ss=0) state<br>
ACTIVE -> RELEASE DUE ERROR<br>
20170204071226382 DRSL <0004> abis_rsl.c:925 (bts=0,trx=0,ts=0,ss=0) RF<br>
CHANNEL RELEASE ACK<br>
20170204071228382 DRSL <0004> abis_rsl.c:811 (bts=0,trx=0,ts=0,ss=0) is<br>
back in operation.<br>
20170204071228382 DRSL <0004> abis_rsl.c:1189 (bts=0,trx=0,ts=0,ss=0) state<br>
RELEASE DUE ERROR -> NONE<br>
<br>
On Fri, Feb 3, 2017 at 2:28 AM, Neels Hofmeyr <neels@hofmeyr.de> wrote:<br>
<br>
> Dear Hossein,<br>
><br>
> the mailing list is indeed the proper place to ask. If no-one replied to<br>
> your<br>
> question, it either means that no-one knows the answer, or that no-one has<br>
> found the time to look into it. Don't be discouraged by that. Indeed I<br>
> would<br>
> prefer if you ask again on the mailing list instead of asking single mail<br>
> addresses. I actually saw your mail on the list and did not know what to<br>
> answer.<br>
><br>
> If you ask your question on-list again (possibly once a week), it might be<br>
> that<br>
> someone will come up with either an answer or with more questions that may<br>
> lead<br>
> you to a solution...<br>
><br>
> I sincerely hope that you will find a solution. It seems to me that it's<br>
> merely<br>
> a minor detail.<br>
><br>
> ~N<br>
><br>
><br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <<a href="http://lists.osmocom.org/pipermail/openbsc/attachments/20170206/8ee7ceac/attachment-0001.html">http://lists.osmocom.org/pipermail/openbsc/attachments/20170206/8ee7ceac/attachment-0001.html</a>><br>
<br>
------------------------------<br>
<br>
Message: 2<br>
Date: Mon, 6 Feb 2017 14:55:12 +0100<br>
From: Harald Welte <laforge@netfilter.org><br>
To: Andreas Schultz <aschultz@tpip.net><br>
Cc: Pablo Neira <pablo@netfilter.org>, netdev@vger.kernel.org, Lionel<br>
Gauthier <Lionel.Gauthier@eurecom.fr>, openbsc@lists.osmocom.org<br>
Subject: Re: [PATCH net-next v2 2/6] gtp: merge gtp_get_net and<br>
gtp_genl_find_dev<br>
Message-ID: <20170206135512.sbxvkbe3hzgnwwjt@nataraja><br>
Content-Type: text/plain; charset=us-ascii<br>
<br>
Hi Andreas,<br>
<br>
On Mon, Jan 30, 2017 at 05:37:09PM +0100, Andreas Schultz wrote:<br>
> Both function are always used together with the final goal to<br>
> get the gtp_dev. This simplifies the code by merging them together.<br>
<br>
Ok, some code restructuring / unification, seems useful.<br>
<br>
However:<br>
<br>
> - netdev_dbg(dev, "GTPv0-U: update tunnel id = %llx (pdp %p)\n",<br>
> - pctx->u.v0.tid, pctx);<br>
> + pr_debug("GTPv0-U: update tunnel id = %llx (pdp %p)\n",<br>
> + pctx->u.v0.tid, pctx);<br>
<br>
(and other related changes) appear to be purely cosmetic and should thus<br>
be unrelated to the function merging described in the change log<br>
message.<br>
<br>
--<br>
- Harald Welte <laforge@netfilter.org> <a href="http://netfilter.org/">
http://netfilter.org/</a><br>
============================================================================<br>
"Fragmentation is like classful addressing -- an interesting early<br>
architectural error that shows how much experimentation was going<br>
on while IP was being designed." -- Paul Vixie<br>
<br>
<br>
------------------------------<br>
<br>
Message: 3<br>
Date: Mon, 6 Feb 2017 14:51:09 +0100<br>
From: Harald Welte <laforge@netfilter.org><br>
To: Andreas Schultz <aschultz@tpip.net><br>
Cc: Pablo Neira <pablo@netfilter.org>, netdev@vger.kernel.org, Lionel<br>
Gauthier <Lionel.Gauthier@eurecom.fr>, openbsc@lists.osmocom.org<br>
Subject: Re: [PATCH net-next v2 1/6] gtp: make GTP sockets in<br>
gtp_newlink optional<br>
Message-ID: <20170206135109.sw5p2yb7cbsa3g37@nataraja><br>
Content-Type: text/plain; charset=us-ascii<br>
<br>
Hi Andreas,<br>
<br>
my kernel coding skills are getting a bit rusty (no pun intended), and<br>
I'll think others on this list are more capable to do so. But let me at<br>
least provide feedback from the "3GPP / GTP side":<br>
<br>
On Mon, Jan 30, 2017 at 05:37:08PM +0100, Andreas Schultz wrote:<br>
> Having both GTPv0-U and GTPv1-U is not always desirable.<br>
> Fallback from GTPv1-U to GTPv0-U was depreciated from 3GPP<br>
> Rel-8 onwards. Post Rel-8 implementation are discuraged<br>
> from listening on the v0 port (see 3GPP TS 29.281, Sect. 1).<br>
<br>
I confirm this and I think the related change should be applied.<br>
<br>
> A future change will completely decouple the sockets from the<br>
> network device. Till then, at least one of the sockets needs to<br>
> be specified (either v0 or v1), the other is optional.<br>
<br>
Makes sense.<br>
<br>
--<br>
- Harald Welte <laforge@netfilter.org> <a href="http://netfilter.org/">
http://netfilter.org/</a><br>
============================================================================<br>
"Fragmentation is like classful addressing -- an interesting early<br>
architectural error that shows how much experimentation was going<br>
on while IP was being designed." -- Paul Vixie<br>
<br>
<br>
------------------------------<br>
<br>
Message: 4<br>
Date: Mon, 6 Feb 2017 14:58:59 +0100<br>
From: Harald Welte <laforge@gnumonks.org><br>
To: Andreas Schultz <aschultz@tpip.net><br>
Cc: Pablo Neira <pablo@netfilter.org>, netdev@vger.kernel.org, Lionel<br>
Gauthier <Lionel.Gauthier@eurecom.fr>, openbsc@lists.osmocom.org<br>
Subject: Re: [PATCH net-next v2 4/6] gtp: consolidate pdp context<br>
destruction into helper<br>
Message-ID: <20170206135859.mq6pidofidnps2q6@nataraja><br>
Content-Type: text/plain; charset=us-ascii<br>
<br>
Hi Andreas,<br>
<br>
On Mon, Jan 30, 2017 at 05:37:11PM +0100, Andreas Schultz wrote:<br>
> Consolidate duplicate code into helper.<br>
<br>
Makes complete sense.<br>
<br>
However:<br>
<br>
> +static void pdp_context_delete(struct pdp_ctx *pctx);<br>
> +<br>
<br>
why introduce the forward-declaration and then define the function<br>
further down in the file? I think in general, it is preferred to put<br>
helper functions on top, before their first use, so forward declarations<br>
can be avoided? Particularly if the helper function doesn't call any<br>
other functions that are not yet declared at this point.<br>
<br>
Please note the above might just be my personal taste, not sure if<br>
that's a general habit in the kernel networking code these days.<br>
<br>
So with or without the re-ordering:<br>
<br>
Acked-by: Harald Welte <laforge@gnumonks.org><br>
<br>
--<br>
- Harald Welte <laforge@gnumonks.org> <a href="http://laforge.gnumonks.org/">
http://laforge.gnumonks.org/</a><br>
============================================================================<br>
"Privacy in residential applications is a desirable marketing option."<br>
(ETSI EN 300 175-7 Ch. A6)<br>
<br>
<br>
------------------------------<br>
<br>
Message: 5<br>
Date: Mon, 6 Feb 2017 15:04:18 +0100<br>
From: Harald Welte <laforge@gnumonks.org><br>
To: Andreas Schultz <aschultz@tpip.net><br>
Cc: pablo <pablo@netfilter.org>, netdev <netdev@vger.kernel.org>,<br>
Lionel Gauthier <Lionel.Gauthier@eurecom.fr>, openbsc<br>
<openbsc@lists.osmocom.org><br>
Subject: Re: [PATCH net-next v2 5/6] gtp: add socket to pdp context<br>
Message-ID: <20170206140418.dwiofucns5eolgel@nataraja><br>
Content-Type: text/plain; charset=us-ascii<br>
<br>
Dear All,<br>
<br>
On Thu, Feb 02, 2017 at 04:07:23PM +0100, Andreas Schultz wrote:<br>
> ----- On Feb 2, 2017, at 3:46 PM, pablo pablo@netfilter.org wrote:<br>
> > On Thu, Feb 02, 2017 at 03:38:07PM +0100, Andreas Schultz wrote:<br>
> >> ----- On Feb 2, 2017, at 3:28 PM, pablo pablo@netfilter.org wrote:<br>
> >> > I suggest you just call kfree_rcu() from 4/6.<br>
> >> ><br>
> >> > Regarding holding socket reference, see my comment for patch 1/6.<br>
> >><br>
> >> This is going to be a problem at this stage of the changes.<br>
> >><br>
> >> The final goal is to have a reference from the socket to the pdp context.<br>
> ><br>
> > Is this just a cleanup? Or you need this sk caching for some follow up<br>
> > work?<br>
><br>
> It's not caching, the plan is to completely remove the socket from the<br>
> GTP netdevice (as far as that is possible without breaking the existing API).<br>
<br>
I agree this is the way to go. When I originally thought about the GTP<br>
kernel tunneling module early on, I was not aware of the fact that<br>
operators actually in practise run multiple "virtual GGSNs" on one IP<br>
address/port. From a pure technical point of view you would say "why<br>
bother"? They could just use separate IP addresses for each of them.<br>
However, the reailty is that each new IP address that an operator uses<br>
for a GGSN results in paper forms required to be exchanged between this<br>
operator and all his roming partners, followed-up by manual<br>
re-configuration of the policies on all of those roaming partners. This<br>
is time-consuming and error-prone, but hey, it's how the procedures<br>
between GSMA members seem to work ;)<br>
<br>
> A GGSN or PGW can serve multiple APN's on the same GTP-U socket. Those APN's<br>
> can have overlapping IP address ranges. The only sensible way to handle<br>
> this, is to have a netdevice per APN. This breaks the current 1:1 relation<br>
> between sockets and netdevices.<br>
<br>
Indeed. So the question is how to do this best and how to keep<br>
backwards compatibility of the netlink interface. I don't claim to have<br>
answers to that, sorry.<br>
<br>
--<br>
- Harald Welte <laforge@gnumonks.org> <a href="http://laforge.gnumonks.org/">
http://laforge.gnumonks.org/</a><br>
============================================================================<br>
"Privacy in residential applications is a desirable marketing option."<br>
(ETSI EN 300 175-7 Ch. A6)<br>
<br>
<br>
------------------------------<br>
<br>
Message: 6<br>
Date: Mon, 6 Feb 2017 14:56:13 +0100<br>
From: Harald Welte <laforge@gnumonks.org><br>
To: Andreas Schultz <aschultz@tpip.net><br>
Cc: Pablo Neira <pablo@netfilter.org>, netdev@vger.kernel.org, Lionel<br>
Gauthier <Lionel.Gauthier@eurecom.fr>, openbsc@lists.osmocom.org<br>
Subject: Re: [PATCH net-next v2 3/6] gtp: unify genl_find_pdp and<br>
prepare for per socket lookup<br>
Message-ID: <20170206135613.x6ryxtrzktqx65n2@nataraja><br>
Content-Type: text/plain; charset=us-ascii<br>
<br>
On Mon, Jan 30, 2017 at 05:37:10PM +0100, Andreas Schultz wrote:<br>
> Signed-off-by: Andreas Schultz <aschultz@tpip.net><br>
<br>
Acked-by: Harald Welte <laforge@gnumonks.org><br>
<br>
--<br>
- Harald Welte <laforge@gnumonks.org> <a href="http://laforge.gnumonks.org/">
http://laforge.gnumonks.org/</a><br>
============================================================================<br>
"Privacy in residential applications is a desirable marketing option."<br>
(ETSI EN 300 175-7 Ch. A6)<br>
<br>
<br>
------------------------------<br>
<br>
Message: 7<br>
Date: Mon, 6 Feb 2017 14:46:37 +0100<br>
From: Harald Welte <laforge@gnumonks.org><br>
To: David Miller <davem@davemloft.net><br>
Cc: aschultz@tpip.net, pablo@netfilter.org, netdev@vger.kernel.org,<br>
Lionel.Gauthier@eurecom.fr, openbsc@lists.osmocom.org<br>
Subject: Re: [PATCH net-next v2 0/6] gtp: misc improvements<br>
Message-ID: <20170206134637.bwiyfrtsmhycipxx@nataraja><br>
Content-Type: text/plain; charset=us-ascii<br>
<br>
Hi Dave and List,<br>
<br>
On Tue, Jan 31, 2017 at 01:05:43PM -0500, David Miller wrote:<br>
> Please someone with GTP knowledge properly review this series.<br>
<br>
I am happy to provide review, but I was travelling and my time to work<br>
on things outside my dayjob is typically quite limited. So I'd like to<br>
ask for a bit more patience for patch review from me. Thanks for your<br>
understanding.<br>
<br>
Regards,<br>
Harald<br>
<br>
--<br>
- Harald Welte <laforge@gnumonks.org> <a href="http://laforge.gnumonks.org/">
http://laforge.gnumonks.org/</a><br>
============================================================================<br>
"Privacy in residential applications is a desirable marketing option."<br>
(ETSI EN 300 175-7 Ch. A6)<br>
<br>
<br>
------------------------------<br>
<br>
Message: 8<br>
Date: Wed, 8 Feb 2017 16:26:11 +0100<br>
From: Neels Hofmeyr <nhofmeyr@sysmocom.de><br>
To: Ivaylo Kostov <ikostov@sysmocom.de><br>
Cc: Harald Welte <laforge@gnumonks.org>, openbsc@lists.osmocom.org<br>
Subject: Re: weekly test report (w5 2017)<br>
Message-ID: <20170208152611.GB1544@my.box><br>
Content-Type: text/plain; charset="iso-8859-1"<br>
<br>
(found this mail stuck in my outbox, sending late)<br>
<br>
On Mon, Feb 06, 2017 at 10:09:23AM +0100, Ivaylo Kostov wrote:<br>
> Hi Harald,<br>
><br>
> I see. What was communicated to me was that NITB channel configuration<br>
> TCH/F_TCH/H_PDCH is not supported with nanoBTS.<br>
><br>
> I will have in mind that nanoBTS does not support HR (v1) codec.<br>
<br>
Yes, we discussed TCH/F_TCH/H_PDCH for the nanoBTS. I remember to be surprised<br>
because from some discussion it appeared that the nanoBTS supports HR, and I<br>
was expecting TCH/F only.<br>
<br>
While talking about codecs, the ip.access nanoBTS *should* in fact support the<br>
TCH/F_PDCH dynamic timeslots. Ivaylo, could you check whether that is part of<br>
your testing procedure and add it if not?<br>
<br>
~N<br>
<br>
<br>
--<br>
- Neels Hofmeyr <nhofmeyr@sysmocom.de> <a href="http://www.sysmocom.de/">
http://www.sysmocom.de/</a><br>
=======================================================================<br>
* sysmocom - systems for mobile communications GmbH<br>
* Alt-Moabit 93<br>
* 10559 Berlin, Germany<br>
* Sitz / Registered office: Berlin, HRB 134158 B<br>
* Gesch?ftsf?hrer / Managing Directors: Harald Welte<br>
-------------- next part --------------<br>
A non-text attachment was scrubbed...<br>
Name: signature.asc<br>
Type: application/pgp-signature<br>
Size: 819 bytes<br>
Desc: Digital signature<br>
URL: <<a href="http://lists.osmocom.org/pipermail/openbsc/attachments/20170208/5dfdfaff/attachment.bin">http://lists.osmocom.org/pipermail/openbsc/attachments/20170208/5dfdfaff/attachment.bin</a>><br>
<br>
------------------------------<br>
<br>
Subject: Digest Footer<br>
<br>
_______________________________________________<br>
OpenBSC mailing list<br>
OpenBSC@lists.osmocom.org<br>
<a href="https://lists.osmocom.org/mailman/listinfo/openbsc">https://lists.osmocom.org/mailman/listinfo/openbsc</a><br>
<br>
<br>
------------------------------<br>
<br>
End of OpenBSC Digest, Vol 28, Issue 5<br>
**************************************<br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <<a href="http://lists.osmocom.org/pipermail/openbsc/attachments/20170209/fa7bb625/attachment.html">http://lists.osmocom.org/pipermail/openbsc/attachments/20170209/fa7bb625/attachment.html</a>><br>
<br>
------------------------------<br>
<br>
Subject: Digest Footer<br>
<br>
_______________________________________________<br>
OpenBSC mailing list<br>
OpenBSC@lists.osmocom.org<br>
<a href="https://lists.osmocom.org/mailman/listinfo/openbsc">https://lists.osmocom.org/mailman/listinfo/openbsc</a><br>
<br>
<br>
------------------------------<br>
<br>
End of OpenBSC Digest, Vol 28, Issue 6<br>
**************************************<br>
</div>
</span></font>
</body>
</html>