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.
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 <laforge(a)gnumonks.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
(BTW, for GPRS we use osmocom-net-gprs(a)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
