As requested are here the simple and most obvious changes from
the larger GTP changeset. I'll break down the rest and send them
out separately.
The module alias addition and the rcu_lock removal are just small
convenience changes.
The other changes are needed to correctly implement one of the
3GPP GW functions, userspace needs to see invalid T-PDU's in
order to generate the proper error messages, GTP fragmentation
rules need the cleared DF bit.
Andreas
--
Andreas Schultz (5):
gtp: add genl family modules alias
gtp: clear DF bit on GTP packet tx
gtp: fix cross netns recv on gtp socket
gtp: remove unnecessary rcu_read_lock
gtp: let userspace handle packets for invalid tunnels
drivers/net/gtp.c | 33 ++++++++-------------------------
1 file changed, 8 insertions(+), 25 deletions(-)
--
2.10.2
The current linking of GTP network devices and GTP enabled sockets means that
we can not have multiple VRF's per GTP socket. This series seperates the
sockets from network device, makes sockets attached to GTP network device
optional and adds a API function to enable GTP encapsulation on socket
without having to create a new GTP device.
It is still possible to use the old API. The network device attached socket is
then used when no socket is specified on PDP context creation.
During that work some smaller problems where found and fixes for them are
included.
v2 changes:
* the socket that is hold by the pdp context has to be release in a rcu
callback. Otherwise a stray GTP rx could end uo with an invalid socket.
* accessing the skb->sk field in gtp_rx is invalid, that field has no
been populated at that point
* add dst_cache to speed up the routing
Regards
Andreas
--
Andreas Schultz (18):
gtp: add genl family modules alias
gtp: clear DF bit on GTP packet tx
gtp: make GTP sockets in gtp_newlink optional
gtp: return error ptr in find pdp helpers
gtp: unify genl_find_pdp and prepare for per socket lookup
gtp: fix cross netns recv on gtp socket
gtp: remove unnecessary rcu_read_lock
gtp: consolidate pdp context destruction into helper
gtp: use addr_hash when traversing pdp contexts
gtp: add socket to pdp context
gtp: consolidate gtp socket rx path
gtp: let userspace handle packets for invalid tunnels
gtp: replace netdev_dbg and KERN_DEBUG printk with pr_debug
gtp: move TEID hash to per socket structure
gtp: rename gtp hashtable helpers
gtp: add genl cmd to enable GTP encapsulation on UDP socket
gtp: add support to select a GTP socket during PDP context creation
gtp: add dst_cache support
drivers/net/gtp.c | 714 +++++++++++++++++++++++++++--------------------
include/uapi/linux/gtp.h | 4 +
2 files changed, 422 insertions(+), 296 deletions(-)
--
2.10.2
The current linking of GTP network devices and GTP enabled sockets means that
we can not have multiple VRF's per GTP socket. This series seperates the
sockets from network device, makes sockets attached to GTP network device
optional and adds a API function to enable GTP encapsulation on socket
without having to create a new GTP device.
It is still possible to use the old API. The network device attached socket is
then used when no socket is specified on PDP context creation.
During that work some smaller problems where found and fixes for them are
included.
Regards
Andreas
--
Andreas Schultz (17):
gtp: add genl family modules alias
gtp: clear DF bit on GTP packet tx
gtp: make GTP sockets in gtp_newlink optional
gtp: return error ptr in find pdp helpers
gtp: unify genl_find_pdp and prepare for per socket lookup
gtp: fix cross netns recv on gtp socket
gtp: remove unnecessary rcu_read_lock
gtp: consolidate pdp context destruction into helper
gtp: use addr_hash when traversing pdp contexts
gtp: add socket to pdp context
gtp: consolidate gtp socket rx path
gtp: let userspace handle packets for invalid tunnels
gtp: replace netdev_dbg and KERN_DEBUG printk with pr_debug
gtp: move TEID hash to per socket structure
gtp: rename gtp hashtable helpers
gtp: add genl cmd to enable GTP encapsulation on UDP socket
gtp: add support to select a GTP socket during PDP context creation
drivers/net/gtp.c | 681 +++++++++++++++++++++++++++--------------------
include/uapi/linux/gtp.h | 4 +
2 files changed, 392 insertions(+), 293 deletions(-)
--
2.10.2
Problem is usrp x310 doesnot support the gsmband, it works above 1.2GHz. Also if I still change the MCC and MNC I am not not able to find the network on the phone, and any clue on this error "check_rx_md_err: An internal receive buffer has filled", it comes in osmo-trx.
________________________________
From: Dhananjay kumar <dhananjay.cse(a)gmail.com>
Sent: Monday, January 23, 2017 11:37:38 AM
To: Snehasish Kar
Cc: nhofmeyr(a)sysmocom.de
Subject: Re: Omsobts -osmotrx communication problem
hi,
network country code 404
mobile network code 31
Change it to
network country code 001
mobile network code 01
short name TESTPLMN
long name TESTPLMN
Try it in Band 850 .
900 and 1800 and widely used in India by commercial operates.
Remove all neighbor cell list.
You are using 404 31 , it might match some real network, and you will not able to see your test network.
BR
Dhananjay
On Mon, Jan 23, 2017 at 11:20 AM, Snehasish Kar <snehasish.cse(a)live.com<mailto:snehasish.cse@live.com>> wrote:
Hi I have attached my config as requested, also in osmo-trx I am getting the following error "check_rx_md_err: An internal receive buffer has filled" and I am not able to view the network in my phone. I am using usrp x310 and os UBUNTU.
BR
Snehasish
________________________________
From: Neels Hofmeyr <nhofmeyr(a)sysmocom.de<mailto:nhofmeyr@sysmocom.de>>
Sent: Saturday, January 21, 2017 4:35:06 AM
To: Snehasish Kar
Cc: openbsc(a)lists.osmocom.org<mailto:openbsc@lists.osmocom.org>
Subject: Re: Omsobts -osmotrx communication problem
On Fri, Jan 20, 2017 at 11:58:53AM +0000, Snehasish Kar wrote:
> Hi
>
> I have installed osmobts and osmotrx with openbsc, to enable openbsc with usrp. But whenever I tried running the three applications, I gave the following error in osmobts. Please help me with it.
>
>
> <000b> trx_if.c:490 Tx burst length 0 invalid
> > <000b> trx_if.c:490 Tx burst length 0 invalid
> > <000b> trx_if.c:490 Tx burst length 0 invalid
> > <000b> trx_if.c:490 Tx burst length 0 invalid
> > <000b> trx_if.c:490 Tx burst length 0 invalid
> > <000b> trx_if.c:490 Tx burst length 0 invalid
> > <000b> trx_if.c:490 Tx burst length 0 invalid
> > <000b> trx_if.c:490 Tx burst length 0 invalid
> > <000b> trx_if.c:490 Tx burst length 0 invalid
> > <000b> trx_if.c:490 Tx burst length 0 invalid
> > <000b> trx_if.c:490 Tx burst length 0 invalid
> > <000b> trx_if.c:490 Tx burst length 0 invalid
> > <000b> trx_if.c:490 Tx burst length 0 invalid
> > <000b> trx_if.c:490 Tx burst length 0 invalid
> > <000b> trx_if.c:490 Tx burst length 0 invalid
> > <000b> trx_if.c:490 Tx burst length 0 invalid
> > <000b> trx_if.c:490 Tx burst length 0 invalid
If I remember correctly, osmo-bts-trx will at startup show a bunch of these and
then continue normally.
To clarify, you need to run 'osmo-trx', 'osmo-bts-trx' and 'osmo-nitb'.
We can't help further with this little information on your config.
~N
--
- Neels Hofmeyr <nhofmeyr(a)sysmocom.de<mailto:nhofmeyr@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
--
Thanks & Regards
Dhananjay
9686184214
Luck is what happens when preparation meets opportunity.
Hi.
I've hit strange issue with redmine:
https://osmocom.org/issues/1836 gives 403 error
but
https://osmocom.org/issues/71 works for example.
Is this intended due to some access control restrictions or it's a
glitch in our setup?
--
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
HI.
A little heads up: uhd version in jenkins building osmo-trx should be
updated to 3.9.0 - this would allow gerrit #1117 to be properly verified
by jenkins.
--
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
Hi all,
( so.. by way of finding out what is the best way to do this kind of
thing, I went ahead and submitted my patch to gerrit. )
I've added a command to the vty to set the expire_lu value for the
subscriber to now.
My personal use case for this is that I wanted a way to set lac =
GSM_LAC_RESERVED_DETACHED when I know that the MS is not there, (because
I know it has gone to another nitb with a different lac) and therefore I
no longer want to page it and I also don't want it showing up as
connected when I poll the hlr for lac>0 via sqlite3. So if I set the
expire_lu to now, openbsc will very shortly afterwards, issue
<0002> gsm_subscriber.c:366 Expiring inactive subscriber......
I'm not sure if this would be considered something anybody else might
want, or confusing for users, and I haven't fully tested (yet) what
might happen if the mobile has not in fact done an IMSI attach to
another lac yet I expire it.
Also, my C programming history is nill. I have no idea if setting a
time_t to time(0) is cool, or will result in sky falling down.
I'm not quite sure if it's necessary to call subscr_put()
I also realise I left a pointless rc declaration in there. oh well..
guess I learn about submitting patch set 2..
So the unwritten question is, with ideas like this, should I first ask
here on the list for opinion on the theoretical merits or not of such an
idea, or should I just submit to gerrit and should the discussion, if
any, happen there?
Many Thanks!
k/
Hey,
osmo_sock_init is nice but I have hit a missing feature. I want to
be able to make an outgoing connection but need to specify the src
ip (and maybe src port too).
a.) I could extend osmo_sock_init to have a src_ip and src_port in
the parameter and issue a bind between the socket(2) and connect(2).
b.) I could add a cb function that is passing the fd to the cb and
do the bind (or others do setsockopt).
Any other ideas? Preferences? Comments?
holger