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
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.
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
On 10/27/2015 08:36 AM, Harald Welte wrote:
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
Great, thanks.
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
The number was just a guestimate, but the existing code was definitely a great starting point.
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.
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.
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
On Tue, Oct 27, 2015 at 10:13:58AM +0100, Andreas Schultz wrote:
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.
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 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