gtphub on master

This is merely a historical archive of years 2008-2021, before the migration to mailman3.

A maintained and still updated list archive can be found at https://lists.osmocom.org/hyperkitty/list/OpenBSC@lists.osmocom.org/.

Neels Hofmeyr nhofmeyr at sysmocom.de
Mon Nov 16 14:54:04 UTC 2015


Hi OpenBSC,

I have just merged the gtphub branch to master. The request to do that has
been standing for a while, to let Jenkins run the tests etc., but there
were still quite volatile parts of the code until now.

The last few days, I have successfully tested gtphub in a mock network,
using a web capable phone, a sysmoBTS running an SGSN on-board, and a
gtphub and OpenGGSN on my laptop. It works: I can browse the net!

@Andreas: since our last discussion, I have incorporated all of your
comments. It *does* make sense after all. A peer may request gtphub from
any port, and by sequence number tracking, the response will go back to
that port and IP. Requests with unknown sequence number will be routed
according to the header's TEI, which means that gtphub will send Requests
always to the default port (a proxy with a specific port may be
configured, though). Another thanks for your input!

GGSN resolution by DNS (GRX C ares) is taking a shortcut: hoping that the
peer will try again, after a DNS request has first been fired, gtphub will
simply not respond. Once a GGSN has been resolved and sits in the cache,
Requests are served immediately. In this way, I avoided a mechanism to
queue incoming Requests (until DNS is done, so that other messages are not
blocked in the meantime), which would have been the proper way to do this,
but would add quite a bit of complexity that is really only needed for the
very first resolution of a given GGSN... According to spec, an SGSN will
resend Requests a number of times, so this should actually be sufficient,
I guess.

Some small bits are still outright missing, as you may notice from the
various TODO comments. But all the main parts are implemented and tested.
Probably a number of bugs still need to be found.

Some infrastructural things are also missing. Coming up is the debian
build, and soon to follow: rate control.

Thanks for any reviews!
(I intend to employ proper peer review for gtphub from this point on...)

~Neels

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20151116/526bdc72/attachment.bin>


More information about the OpenBSC mailing list