From nhofmeyr at sysmocom.de Fri Nov 3 17:59:00 2017 From: nhofmeyr at sysmocom.de (Neels Hofmeyr) Date: Fri, 3 Nov 2017 18:59:00 +0100 Subject: GPRS EXperiments In-Reply-To: <2d735e03-3bd5-afb1-b7ba-31f794987492@rhizomatica.org> References: <2d735e03-3bd5-afb1-b7ba-31f794987492@rhizomatica.org> Message-ID: <20171103175900.a6nerjpxnk6hoclc@my.box> (BTW, for GPRS we use osmocom-net-gprs at lists.osmocom.org but admittedly, almost all osmocom communication is taking place on openbsc@) On Mon, Oct 30, 2017 at 12:12:03PM -0600, Keith wrote: > I've installed up to date versions of osmo-bts and osmo-pcu > on sysmobts 2050 hardware and it's working great! > Dynamic channels are really nice, with half rate TCH and AMR > working perfectly. Thanks for all that work! Good to hear that! > I configured pcodns1 in the ggsn to point to this DNS > server, AND I setup a port 53 redirect to catch quite a lot > of traffic from android that likes to just talk directly to > 8.8.8.8 anyway. Interesting, this sounds like it would make for a good wiki page on osmocom.org. > games. Such is the sad state of affairs on today's internet. > Fortunately, we have iptables and ip sets and we have AS > blocks assigned to certain bandwidth hungry corporations :-) So instead of compromising net neutrality by giving the rich more bandwidth, you do it by cutting the big ones out instead ;) > I have observed that if I initiate any data transfer from > the network side then the uplink is established. By the same > token, If I transfer a file from the network (http download > or some such), the same applies. The link stays active and > the IM chat session is very responsive alongside the file > transfer. Shortly after the file transfer completes, the > uplink is quiet again and the latency in the IM session > becomes a problem. It might be related to a basic problem we still have with data services: we don't cache anything. If a PDP context is still being established, we drop data transfers to the floor, instead of storing them and sending them through when the context is established. I'm personally not familiar with the details there, but that's my current understanding. So a first ping would get lost, a second one within a timeframe that still has the PDP context open will go through. I think the idea there is that generally, higher level data communication should attempt to resend, but in practice that often doesn't seem to work that well. Not sure how to configure the PDP context timeout, or whether we even can. Theoretically, if you had on your phone a regular ping running in the background ... it's ugly, but yea. Caching those first packets is quite complex, especially for SGSNs sitting on a small device like a sysmoBTS with limited memory. I guess something could be tried there, by limiting resources used for caching in intelligent ways... Someone would need to fund that, or go ahead and try. ~N -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From laforge at gnumonks.org Sun Nov 12 14:17:35 2017 From: laforge at gnumonks.org (Harald Welte) Date: Sun, 12 Nov 2017 23:17:35 +0900 Subject: libgtpnl migrated to gerrit Message-ID: <20171112141735.osys7pwk2oxd4qdf@nataraja> Hi all, FYI: I migrated libgtpnl (the kernel-GTP netlink interface helper library used by OpenGGSN and OsmoGGSN) to gerrit earlier today. This means direct pushes to git.osmocom.org no longer work and you will have to submit modifications via gerrit, as we do for all our other major repositories. I've also set up a gerrit build verification job via jenkins-job-builder and added a corresponding contrib/jenkins.sh script to it. The buildhosts now need libmnl-dev as build dependency installed. I added this to our current debian8 + debian9 build slaves and the wiki documentation about them. In other news: libgtpnl is already part of the network:osmocom:nightly and network:osmocom:latest feeds for some weeks. I intend to test kernel GTP support in osmo-ggsn soon and then change the package builds to include kernel-gtp support via libgtpnl by default. Regards, Harald -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From congnt at viosoft.com Thu Nov 23 11:02:13 2017 From: congnt at viosoft.com (congnt) Date: Thu, 23 Nov 2017 18:02:13 +0700 Subject: Packets are not arrived at tunnel setup by libgtpnl Message-ID: <3d8f7c06-1d30-467d-f8bc-5983a68c4452@viosoft.com> Hi guys, I'm using libgtpnl tools (gtp-link, gtp-tunnel) to setup a tunnel in my local machines. I was able to setup gtp link to 2152 port as well as gtp tunnel. I have pre-recorded GTP packets with correct teid and IP address as well as chksum and port to send to 2152. However I can not see any packets in gtp link device when using tcpdump. By add some messages in gtp module, I notice that the function gtp1u_udp_encap_recv in gtp.c kernel file was never been called if I send packet with GTP headers. However, that function is called if I send normal UDP packet without GTP header. Note that I'm using Ubuntu 14.04 with kernel 4.8.0 lowlatency, the tunnel is on a VM created by Virtualbox using virtio network driver. Any suggestions on how to debug/solve this problem? Many thanks in advances. Best regards Cong. From laforge at gnumonks.org Thu Nov 23 13:30:44 2017 From: laforge at gnumonks.org (Harald Welte) Date: Thu, 23 Nov 2017 14:30:44 +0100 Subject: Packets are not arrived at tunnel setup by libgtpnl In-Reply-To: <3d8f7c06-1d30-467d-f8bc-5983a68c4452@viosoft.com> References: <3d8f7c06-1d30-467d-f8bc-5983a68c4452@viosoft.com> Message-ID: <20171123133044.itvqftame2hg3j6l@nataraja> hi Cong, it would be very useful if you could give a description of what exactly your are trying to achieve, using which particular versions of which software. The kernel GTP module is known-working and has been verified with both OpenGGSN and OsmoSGSN. There are also other users such as OpenAirInterface as well as (as far as I know) ergw. It might be easiest to simply use one of those programs to understnd how the kernel GTP-U driver is used. Also, if you want us to be able to help you, please always include the detailed copy+paste output of the related commands and tools, e.g. the exact gtp-link and gtp-tunnel commands you have been using. -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From congnt at viosoft.com Fri Nov 24 04:52:21 2017 From: congnt at viosoft.com (congnt) Date: Fri, 24 Nov 2017 11:52:21 +0700 Subject: Packets are not arrived at tunnel setup by libgtpnl In-Reply-To: <20171123133044.itvqftame2hg3j6l@nataraja> References: <3d8f7c06-1d30-467d-f8bc-5983a68c4452@viosoft.com> <20171123133044.itvqftame2hg3j6l@nataraja> Message-ID: <9eaff981-3850-8347-c43a-09bf078966ab@viosoft.com> Hi Harald and Firat, Thank you very much for your reply. Sorry for not provide detail information when asking question. Lucky me, I am able to solve my problem now. It's because of wrong MAC address in packets that cause gtp device unable to receive. Stupid mistake. Still, I post it here just in case it can help other newbies like me. Thanks and best regards Cong On 11/23/2017 08:30 PM, Harald Welte wrote: > hi Cong, > > it would be very useful if you could give a description of what exactly > your are trying to achieve, using which particular versions of which software. > > The kernel GTP module is known-working and has been verified with both > OpenGGSN and OsmoSGSN. There are also other users such as OpenAirInterface > as well as (as far as I know) ergw. It might be easiest to simply use > one of those programs to understnd how the kernel GTP-U driver is used. > > Also, if you want us to be able to help you, please always include the detailed > copy+paste output of the related commands and tools, e.g. the exact gtp-link > and gtp-tunnel commands you have been using. >