26 Oct
2015
26 Oct
'15
5:14 p.m.
Hi,
Some time ago, Pablo Neira Ayuso wrote a GTP-U kernel module and OpenGGSN
support for it. The OpenGGSN side is easily available in the osmocom git [1].
The kernel part is somewhat harder to find, but it's at [2].
It seems that both sides are at 70% completion and only somewhat working.
I have played with the kernel module, changed a couple things and would
like to get some feedback on my changes.
It can be found at: https://github.com/RoadRunnr/osmo-ggsn
Things I've changed:
* requires kernel from net-next (or 4.3)
* convert to use the existing kernel iptunnel infrastructure
* fix GTP-u v1 TEI usage (we need one TEI for RX and another one
for TX)
* use UDP sockets passed from userland for sending (instead of
direct push to network interface)
* fix resource release on GTP-U socket shutdown
* release all resource on module removal
The module currently works with a proof-of-concept GGSN/PGW implemented
in Erlang (will post once the licensing is sorted). OpenGGSN will need
some small changes (will post soon).
Andreas
[1]: http://git.osmocom.org/openggsn/
[2]: http://git.sysmocom.de/osmo-ggsn
26 Oct
26 Oct
11:07 p.m.
On Mon, Oct 26, 2015 at 06:14:19PM +0100, Andreas Schultz wrote:
Hi,
Some time ago, Pablo Neira Ayuso wrote a GTP-U kernel module and OpenGGSN
support for it. The OpenGGSN side is easily available in the osmocom git [1].
The kernel part is somewhat harder to find, but it's at [2].
It seems that both sides are at 70% completion and only somewhat working.
I have played with the kernel module, changed a couple things and would
like to get some feedback on my changes.
It can be found at: https://github.com/RoadRunnr/osmo-ggsn
Things I've changed:
* requires kernel from net-next (or 4.3)
* convert to use the existing kernel iptunnel infrastructure
* fix GTP-u v1 TEI usage (we need one TEI for RX and another one
for TX)
* use UDP sockets passed from userland for sending (instead of
direct push to network interface)
* fix resource release on GTP-U socket shutdown
* release all resource on module removal
The module currently works with a proof-of-concept GGSN/PGW implemented
in Erlang (will post once the licensing is sorted). OpenGGSN will need
some small changes (will post soon).
Will looking into this, probably we can get this submitted mainstream soon.
Thanks for sharing incremental updates.
27 Oct
27 Oct
7:36 a.m.
Hi Andreas,
good to seee you on the mailing list, and thanks for sharing your work.
On Mon, Oct 26, 2015 at 06:14:19PM +0100, Andreas Schultz wrote:
Some time ago, Pablo Neira Ayuso wrote a GTP-U kernel
module and OpenGGSN
support for it. The OpenGGSN side is easily available in the osmocom git [1].
The kernel part is somewhat harder to find, but it's at [2].
This is for historical reasons... I've now moved the kernel part to
http://git.osmocom.org/osmo-gtp-kernel/
and the 'osmocom developers with commit access' can now push to it via
git://gitosis@git.osmocom.org:osmo-gtp-kernel.git
It seems that both sides are at 70% completion and
only somewhat working.
I would have expected a higher percentage, but then indeed it is true,
the project got halted / postponed at the time due to changing customer
requirements, as far as I remember
I have played with the kernel module, changed a couple
things and would
like to get some feedback on my changes.
It can be found at: https://github.com/RoadRunnr/osmo-ggsn
I think it would be best (and customary practise) to send your changes
to this list (using git format-patch / send-email) for review.
After a brief initial review it looks fine to me, but Pablo is clearly
the better judge of that.
One thing I seem to notice immediaately at a brief look is that it
appears often 8 spaces are used instead of tab for indentation. I know
it's picky, but that has to be adressed before any mainline merge
attempt :/
I think you mentioned last week that you still had some issues with
module unloading ? It would be good to share any remaining problems,
maybe somebody has some idea/input on what is causing the problem.
Please also feel free to add yourself to the list of Copyright holders
in the file headers, so we have proper documentation of that before
submission.
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)
9:13 a.m.
On 10/27/2015 08:36 AM, Harald Welte wrote:
The number was just a guestimate, but the existing code was definitely a
great starting point.
Will do, but I think I will have to rework the changesets a bit. There
are a few intermediate commits that can probably be squashed and others
that might have to be split.
Hi Andreas,
good to seee you on the mailing list, and thanks for sharing your work.
On Mon, Oct 26, 2015 at 06:14:19PM +0100, Andreas Schultz wrote:
Great, thanks.
Some time ago, Pablo Neira Ayuso wrote a GTP-U
kernel module and OpenGGSN
support for it. The OpenGGSN side is easily available in the osmocom git [1].
The kernel part is somewhat harder to find, but it's at [2].
This is for historical reasons... I've now moved the kernel part to
http://git.osmocom.org/osmo-gtp-kernel/
and the 'osmocom developers with commit access' can now push to it via
git://gitosis@git.osmocom.org:osmo-gtp-kernel.git It seems that
both sides are at 70% completion and only somewhat working.
I would have expected a higher percentage, but then indeed it is true,
the project got halted / postponed at the time due to changing customer
requirements, as far as I remember I have played
with the kernel module, changed a couple things and would
like to get some feedback on my changes.
It can be found at: https://github.com/RoadRunnr/osmo-ggsn
I think it would be best (and customary practise) to send your changes
to this list (using git format-patch / send-email) for review. After a brief initial review it looks fine to me, but
Pablo is clearly
the better judge of that.
One thing I seem to notice immediaately at a brief look is that it
appears often 8 spaces are used instead of tab for indentation. I know
it's picky, but that has to be adressed before any mainline merge
attempt :/
Oops, bad editor settings combined with cut&paste ;-)
I think you mentioned last week that you still had
some issues with
module unloading ? It would be good to share any remaining problems,
maybe somebody has some idea/input on what is causing the problem.
I've found that, it's fixed in the last commit. The problem was actually
the error handling when the creation of the gtp interface failed.
Please also feel free to add yourself to the list of
Copyright holders
in the file headers, so we have proper documentation of that before
submission.
Will do.
Andreas
Regards,
Harald
28 Oct
28 Oct
3:40 a.m.
On Tue, Oct 27, 2015 at 10:13:58AM +0100, Andreas Schultz wrote:
This is a fairly large changeset (20 patches), I'd suggest you start
with bugfixes in first place. The patches are lacking also
descriptions, they are important.
Try to send a small batch to start with, to avoid a small patchbomb
thing ;-)
The update to port this on top of iptunnel is fairly large, I would
expect that. I wonder if you can find a good way to split this in
logic changes to make the review easier.
Thanks.
On 10/27/2015 08:36 AM, Harald Welte wrote:
[...]
I think it
would be best (and customary practise) to send your changes
to this list (using git format-patch / send-email) for review.
Will do, but I think I will have to rework the changesets a bit. There
are a few intermediate commits that can probably be squashed and others
that might have to be split. 
1:59 p.m.
On Wed, Oct 28, 2015 at 04:40:48AM +0100, Pablo Neira Ayuso wrote:
Try to send a small batch to start with, to avoid a
small patchbomb
thing ;-)
*cough* like my patch bombs...
But, in fact, I would personally prefer to read a large number of small
neat patches than a small number of large convoluted patches.
So me, I'm basically all for patch bombs (presuming sufficiently detailed
commit log messages). They are rather easy to skip in the mail inbox and
allow for easier review.
It can pay off to invest "too much" time in restructuring/splitting
patches, allowing N people to save time reading them. My occasional tiny
cosmetic patches are split off for this reason alone.
I wonder if you can find a good way to split this in
logic changes to
make the review easier.
There, you said it ;)
But, please do let me know if I should refrain from sending patch bombs...
(My current work being sponsored does produce a lot of patches, and once
Holger is done reviewing the last one, there's a lot more to come.)
~Neels
3590
days inactive
3592
days old
5 comments
4 participants
participants (4)
-
Andreas Schultz -
Harald Welte -
Neels Hofmeyr -
Pablo Neira Ayuso