Dear all,
so far libosmo-sccp had some code with a partial SCCP implementation
that date back to the earliest day of OsmoBSC in 2009, done by Holger.
It also contained a SUA implementation which (mostly) I did last year
in the wake of the Iuh and IuCS/IuPS support for the Osmocom 3G support.
The latter code is already more 'modern' and uses the osmocom primitives
(osmo_prim) between the SCCP User (the application) and the SCCP
Provider (the library). Those primitives are modelled after the related
specifications.
What I'm now wokring on is to get those last SUA related patches finally
merged in master, and to
* add missing ASPTM and ASPSM protocol code + osmo_fsm state machines in
a generic way that they can be shared by all SIGTRAN xUA variants
* add M3UA while sharing more code between SUA and M3UA
* introduce a MTP SAP based on osmo_prim that can be used on top of M3UA
* wrap the existing sccp.c code to use the MTP SAP on the lower end and
the SCCP User SAP on the upper edge
In the above implementations, I am aiming for implementing SGW, ASP and
IPSP roles. However, primary focus is on ASP.
In the end, we will be able to stack M3UA and SCCP code using
primitives, and interact with the SCCP using the exact same primitives
and API as we interact with SUA currently.
This will give us:
* true/real IuCS/IuPS suppotr (we currently do SUA, which is not as per
spec) in OsmoCSCN, OsmoSGSN and OsmoHNBGW without any real modificatin
of their code
* a way towards 3GPP compliant AoIP, by using the SCCP User SAP from
OsmoBSC. This means that we'll also have to add that SCCP User SAP to
the SCCPlite/IPA code that OsmoBSC is using for now.
While all of the above sounds great, it somehow hurts me that we have
already some (partial?) implementations of M3UA in cellmgr-ng
(particularly the osmo-stp application). It hurts me that I'm not able
to use the code that Holger wrote in recent years, but I still think
it's worth-while to do an implementation centered around osmo_prim for
layer-boundaries and osmo_fsm for state machines.
So my apologies to Holger on this. It's not "Not Invented Here"
syndrome, but I think there are reasons to take a different route than
the existing code. I'm of course also looking forward to hearing other
opinions on that.
[... and while I'm working on this, I also think about introducing some
generic inter-layer primitive logging code, so we can enable logging of
the primitives at a given SAP without the specific SAP implementation
having to implement anything, like we do in terms of osmo_fsm logging]
Regards,
Harald
--
- Harald Welte <laforge(a)gnumonks.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
Will there be a separate mailing list for the accelerate3g5 "winners"? Maybe we
could just make it a general osmocom-3G@ mailing list. Alternatively, we could
use this list for 3G as well. What's the plan?
~N
[cid:9b893015-fe6c-4d05-9933-7169f767fc97]
________________________________
From: OpenBSC <openbsc-bounces(a)lists.osmocom.org> on behalf of openbsc-request(a)lists.osmocom.org <openbsc-request(a)lists.osmocom.org>
Sent: Thursday, February 9, 2017 9:00:47 AM
To: openbsc(a)lists.osmocom.org
Subject: OpenBSC Digest, Vol 28, Issue 6
Send OpenBSC mailing list submissions to
openbsc(a)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(a)lists.osmocom.org
You can reach the person managing the list at
openbsc-owner(a)lists.osmocom.org
When replying, please edit your Subject line so it is more specific
than "Re: Contents of OpenBSC digest..."
Today's Topics:
1. Re: weekly test report (w5 2017) (Ivaylo Kostov)
2. Re: weekly test report (w5 2017) (Harald Welte)
3. Re: weekly test report (w5 2017) (Neels Hofmeyr)
4. Re: OpenBSC Digest, Vol 28, Issue 5 (Rajitha peiris)
----------------------------------------------------------------------
Message: 1
Date: Wed, 8 Feb 2017 16:33:26 +0100
From: Ivaylo Kostov <ikostov(a)sysmocom.de>
To: Neels Hofmeyr <nhofmeyr(a)sysmocom.de>
Cc: Harald Welte <laforge(a)gnumonks.org>, openbsc(a)lists.osmocom.org
Subject: Re: weekly test report (w5 2017)
Message-ID: <06726d26-d66f-d48d-cf9d-533178a13ada(a)sysmocom.de>
Content-Type: text/plain; charset=windows-1252; format=flowed
Hi Neels,
Yes. I do have TCH/F_PDCH dynamic timeslots in the test procedure.
regards,
Ivaylo
On 08.02.2017 16:26, Neels Hofmeyr wrote:
> (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
>
>--
------------------------------
- Ivaylo Kostov <ikostov(a)sysmocom.de> <mailto:ikostov@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
------------------------------
------------------------------
Message: 2
Date: Wed, 8 Feb 2017 16:45:57 +0100
From: Harald Welte <laforge(a)gnumonks.org>
To: Neels Hofmeyr <nhofmeyr(a)sysmocom.de>
Cc: Ivaylo Kostov <ikostov(a)sysmocom.de>, openbsc(a)lists.osmocom.org
Subject: Re: weekly test report (w5 2017)
Message-ID: <20170208154557.2rmslkrzuqlv7xc4@nataraja>
Content-Type: text/plain; charset=us-ascii
Hi all,
On Wed, Feb 08, 2017 at 04:26:11PM +0100, Neels Hofmeyr wrote:
> 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?
libbsc should be extended to handle those restrictions, i.e. reject a
configuration containing HR codec or a osmocom-style dynamic channel on
a bts model 'nanobts'.
Similarly, the BS11 should reject any codec except HRv1, FR and EFR
(i.e. no AMR).
In reality there are also older nanoBTSs that don't support AMR (as far
as I remember), but that shouldn't prevent us from having at least the
most basic checks in place.
For osmo-bts, we need a more sophisticated hand-shaking mechanism, as
there are many different hardware/PHYs (and associated versions)
supported by it. This is left for further study ;)
--
- Harald Welte <laforge(a)gnumonks.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
------------------------------
Message: 3
Date: Thu, 9 Feb 2017 00:43:35 +0100
From: Neels Hofmeyr <nhofmeyr(a)sysmocom.de>
To: Harald Welte <laforge(a)gnumonks.org>
Cc: Ivaylo Kostov <ikostov(a)sysmocom.de>, openbsc(a)lists.osmocom.org
Subject: Re: weekly test report (w5 2017)
Message-ID: <20170208234335.GB27422(a)my.box>
Content-Type: text/plain; charset="us-ascii"
On Wed, Feb 08, 2017 at 04:45:57PM +0100, Harald Welte wrote:
> libbsc should be extended to handle those restrictions, i.e. reject a
> configuration containing HR codec or a osmocom-style dynamic channel on
> a bts model 'nanobts'.
i.e. checks on the VTY level.
Seems like we want an issue for that: https://osmocom.org/issues/1946
~N
Hi.
There seems to be peculiar coding error with osmo-bts-trx and usrp b210:
...
<0006> gsm0503_coding.c:1850 tch_hr_decode(): error checking CRC8 for an
HR frame (211/211 bits) [0/0/0]
<0006> scheduler_trx.c:1279 Received bad TCH frame ending at fn=1550946
ts=7 for TCH/H(1)
<0006> gsm0503_coding.c:1850 tch_hr_decode(): error checking CRC8 for an
HR frame (211/211 bits) [1/0/0]
<0006> scheduler_trx.c:1279 Received bad TCH frame ending at fn=1550950
ts=7 for TCH/H(1)
<0006> gsm0503_coding.c:1850 tch_hr_decode(): error checking CRC8 for an
HR frame (211/211 bits) [0/0/0]
<0006> scheduler_trx.c:1279 Received bad TCH frame ending at fn=1550955
ts=7 for TCH/H(1)
<0006> gsm0503_coding.c:1850 tch_hr_decode(): error checking CRC8 for an
HR frame (211/211 bits) [1/0/0]
<0006> scheduler_trx.c:1279 Received bad TCH frame ending at fn=1550959
ts=7 for TCH/H(1)
<0006> gsm0503_coding.c:1850 tch_hr_decode(): error checking CRC8 for an
HR frame (211/211 bits) [0/0/0]
...
The error seems to:
- happen only on 2nd subslot of TCH/H
- does not prevent calls establishement
- let voice to go through
The visible effect though is extra delay for call establishment when BSC
allocates next available subslot - see
https://projects.osmocom.org/issues/1795 for details.
Have anyone else seen this?
It could be that tch_hr_decode() screw up bits somehow while trying to
decode stolen FACCH bits but the code seems rather arcane. For instance,
when calling unmap (it actually just attempts to get hu(B) and hl(B)
flags from 3GPP TS 45.003 §4.3.5 located in bits 58 and 57
correspondingly) potentially stolen bits in the beginning of function,
why bursts 0..3 are treated as even and 2..4 as odd?
--
Max Suraev <msuraev(a)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
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(a)lists.osmocom.org> on behalf of openbsc-request(a)lists.osmocom.org <openbsc-request(a)lists.osmocom.org>
Sent: Wednesday, February 8, 2017 8:56:30 PM
To: openbsc(a)lists.osmocom.org
Subject: OpenBSC Digest, Vol 28, Issue 5
Send OpenBSC mailing list submissions to
openbsc(a)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(a)lists.osmocom.org
You can reach the person managing the list at
openbsc-owner(a)lists.osmocom.org
When replying, please edit your Subject line so it is more specific
than "Re: Contents of OpenBSC digest..."
Today's Topics:
1. Re: 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(a)gmail.com>
To: openbsc(a)lists.osmocom.org
Subject: Re: MS cannot connect; Location Update Request not received
by BTS
Message-ID:
<CAF81cShkO+JiamxQJXhqfpbOWxi9_8aEWsd5wTDhmZ0Vd912Xw(a)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(a)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
>
>
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(a)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
>
>
Hi,
the machine hosting most of *.osmocom.org is running FreeBSD9.3 which
EOLed end of december and I would like to upgrade to FreeBSD10.3. I do
not expect many problems but I also don't want to interfere with other
peoples work.
Even if it is short notice, any objections for Saturday->Sunday night
of a European timezone? Otherwise I would pick next Friday->Saturday.
regards
holger
Hello all
I have installed openbsc with pcs1900 nano bts but I can't make voice calls only the messages.
It's telling network busy
Thanks
Regards
Rajitha
Sri Lanka
Sent from my iPhone
On Jan 27, 2017, at 3:11 PM, "openbsc-request(a)lists.osmocom.org<mailto:openbsc-request@lists.osmocom.org>" <openbsc-request(a)lists.osmocom.org<mailto:openbsc-request@lists.osmocom.org>> wrote:
Send OpenBSC mailing list submissions to
openbsc(a)lists.osmocom.org<mailto:openbsc@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(a)lists.osmocom.org<mailto:openbsc-request@lists.osmocom.org>
You can reach the person managing the list at
openbsc-owner(a)lists.osmocom.org<mailto:openbsc-owner@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: [MERGED] osmo-trx[master]: Do not embed sqlite3 when
building (Alexander Chemeris)
2. Re: [PATCH net v2 3/3] gtp: fix cross netns recv on gtp
socket (David Miller)
3. Re: [MERGED] osmo-trx[master]: Do not embed sqlite3 when
building (Neels Hofmeyr)
4. HEADS UP: jenkins DOWN (Neels Hofmeyr)
5. HEADS DOWN: jenkins UP (Neels Hofmeyr)
6. Re: HEADS DOWN: jenkins UP (Holger Freyther)
7. [PATCH net v3 0/3] various gtp fixes (Andreas Schultz)
8. [PATCH net v3 2/3] gtp: clear DF bit on GTP packet tx
(Andreas Schultz)
----------------------------------------------------------------------
Message: 1
Date: Thu, 26 Jan 2017 20:53:07 +0400
From: Alexander Chemeris <alexander.chemeris(a)gmail.com<mailto:alexander.chemeris@gmail.com>>
To: Max <msuraev(a)sysmocom.de<mailto:msuraev@sysmocom.de>>
Cc: OpenBSC Mailing List <openbsc(a)lists.osmocom.org<mailto:openbsc@lists.osmocom.org>>
Subject: Re: [MERGED] osmo-trx[master]: Do not embed sqlite3 when
building
Message-ID:
<CABmJbFUifn=3OdUWH=aH5Nij9xz4v7Z3HCm09SQEHOBkaEBtXA(a)mail.gmail.com<mailto:CABmJbFUifn=3OdUWH=aH5Nij9xz4v7Z3HCm09SQEHOBkaEBtXA@mail.gmail.com>>
Content-Type: text/plain; charset=UTF-8
Great. I was also going to ask about debian contrl files, etc. Glad
this is already fixed.
Is there a way to subscribe to gerrit patches for a particular project?
On Thu, Jan 26, 2017 at 8:10 PM, Max <msuraev(a)sysmocom.de<mailto:msuraev@sysmocom.de>> wrote:
It should have been removed with gerrit 1485
<https://gerrit.osmocom.org/1485>. See also gerrit 1691
<https://gerrit.osmocom.org/1691> for follow-up fixes.
On 26.01.2017 16:53, Alexander Chemeris wrote:
Hi Harald, Thomas,
I think it also makes sense to remove sqlite3 subdirectory, since it's no
longer used. Any reason it's kept in the repository?
--
Max Suraev <msuraev(a)sysmocom.de<mailto:msuraev@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
--
Regards,
Alexander Chemeris.
CEO, Fairwaves, Inc.
https://fairwaves.co
------------------------------
Message: 2
Date: Thu, 26 Jan 2017 14:22:47 -0500 (EST)
From: David Miller <davem(a)davemloft.net<mailto:davem@davemloft.net>>
To: aschultz(a)tpip.net<mailto:aschultz@tpip.net>
Cc: pablo(a)netfilter.org<mailto:pablo@netfilter.org>, netdev(a)vger.kernel.org<mailto:netdev@vger.kernel.org>,
Lionel.Gauthier(a)eurecom.fr<mailto:Lionel.Gauthier@eurecom.fr>, openbsc(a)lists.osmocom.org<mailto:openbsc@lists.osmocom.org>,
laforge(a)gnumonks.org<mailto:laforge@gnumonks.org>
Subject: Re: [PATCH net v2 3/3] gtp: fix cross netns recv on gtp
socket
Message-ID: <20170126.142247.527598780818100974.davem(a)davemloft.net<mailto:20170126.142247.527598780818100974.davem@davemloft.net>>
Content-Type: Text/Plain; charset=iso-8859-7
From: Andreas Schultz <aschultz(a)tpip.net<mailto:aschultz@tpip.net>>
Date: Thu, 26 Jan 2017 16:11:34 +0100
The use of the passed through netlink src_net to check for a
cross netns operation was wrong. Using the GTP socket and the
GTP netdevice is always correct (even if the netdev has been
moved to new netns after link creation).
Remove the now obsolete net field from gtp_dev.
Signed-off-by: Andreas Schultz <aschultz(a)tpip.net<mailto:aschultz@tpip.net>>
Please at least compile test your submissions:
drivers/net/gtp.c: In function ?gtp_newlink?:
drivers/net/gtp.c:677:8: error: too many arguments to function ?gtp_encap_enable?
err = gtp_encap_enable(dev, gtp, fd0, fd1, src_net);
^
drivers/net/gtp.c:659:12: note: declared here
static int gtp_encap_enable(struct net_device *dev, struct gtp_dev *gtp,
^
drivers/net/gtp.c: At top level:
drivers/net/gtp.c:822:12: error: conflicting types for ?gtp_encap_enable?
static int gtp_encap_enable(struct net_device *dev, struct gtp_dev *gtp,
^
drivers/net/gtp.c:659:12: note: previous declaration of ?gtp_encap_enable? was here
static int gtp_encap_enable(struct net_device *dev, struct gtp_dev *gtp,
^
drivers/net/gtp.c:659:12: warning: ?gtp_encap_enable? used but never defined
drivers/net/gtp.c:822:12: warning: ?gtp_encap_enable? defined but not used [-Wunused-function]
static int gtp_encap_enable(struct net_device *dev, struct gtp_dev *gtp,
^
scripts/Makefile.build:299: recipe for target 'drivers/net/gtp.o' failed
------------------------------
Message: 3
Date: Thu, 26 Jan 2017 21:40:27 +0100
From: Neels Hofmeyr <nhofmeyr(a)sysmocom.de<mailto:nhofmeyr@sysmocom.de>>
To: Alexander Chemeris <alexander.chemeris(a)gmail.com<mailto:alexander.chemeris@gmail.com>>
Cc: Max <msuraev(a)sysmocom.de<mailto:msuraev@sysmocom.de>>, OpenBSC Mailing List
<openbsc(a)lists.osmocom.org<mailto:openbsc@lists.osmocom.org>>
Subject: Re: [MERGED] osmo-trx[master]: Do not embed sqlite3 when
building
Message-ID: <20170126204027.GA7681(a)my.box<mailto:20170126204027.GA7681@my.box>>
Content-Type: text/plain; charset="us-ascii"
On Thu, Jan 26, 2017 at 08:53:07PM +0400, Alexander Chemeris wrote:
Great. I was also going to ask about debian contrl files, etc. Glad
this is already fixed.
Is there a way to subscribe to gerrit patches for a particular project?
I'm not sure, but I guess not. We have our gerrit-log mailing list that catches
all changes https://lists.osmocom.org/mailman/listinfo/gerrit-log -- otherwise
take a look at your user's settings, maybe there's such a feature hidden there?
~N