From laforge at osmocom.org  Tue Feb  2 11:01:32 2021
From: laforge at osmocom.org (Harald Welte)
Date: Tue, 2 Feb 2021 12:01:32 +0100
Subject: Question about libgtpnl
In-Reply-To: <CANPQb9B3OOMb2MbSg84OZN1aQoC420DzjL_aezpqnR2+=WAo2Q@mail.gmail.com>
References: <CANPQb9B3OOMb2MbSg84OZN1aQoC420DzjL_aezpqnR2+=WAo2Q@mail.gmail.com>
Message-ID: <YBkxDJmBrUa6L3b2@nataraja>

On Sun, Jan 31, 2021 at 11:25:25PM +0330, morteza ali Ahmadi wrote:
> Hi Osmocom team
> We have a basic question about libgtpnl (Linux Kernel GTP-U).

I would suggest that you start with setting this up using OsmoGGSN.

It has built-in support for kernel GTP (via libgtpnl), see the related user manual.

Once that works, you have a "known working" setup and you can start comparing
the differences between how OsmoGGSN uses libgtpnl and how you are using it manually.

I have to admit that I never considered using the manual gtp-link/gtp-tunnel commands
in a "real" network.  Those were only ever used in artificial functional testing.

Regards,
	Harald
-- 
- Harald Welte <laforge at osmocom.org>            http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
                                                  (ETSI EN 300 175-7 Ch. A6)


From morteza.ali.ahmadi at gmail.com  Wed Feb  3 14:22:19 2021
From: morteza.ali.ahmadi at gmail.com (morteza ali Ahmadi)
Date: Wed, 3 Feb 2021 17:52:19 +0330
Subject: Question about libgtpnl
In-Reply-To: <YBkxDJmBrUa6L3b2@nataraja>
References: <CANPQb9B3OOMb2MbSg84OZN1aQoC420DzjL_aezpqnR2+=WAo2Q@mail.gmail.com>
 <YBkxDJmBrUa6L3b2@nataraja>
Message-ID: <CANPQb9AiGsbWBGg77esg8QXkmc9AJKXBjCoVDDfKK8dLHXnMyA@mail.gmail.com>

Hi Harald
Thanks for your advice. So, first, We will try to use OsmoGGSN.

Best regards
Morteza Ali Ahmadi


On Tue, Feb 2, 2021 at 2:32 PM Harald Welte <laforge at osmocom.org> wrote:

> On Sun, Jan 31, 2021 at 11:25:25PM +0330, morteza ali Ahmadi wrote:
> > Hi Osmocom team
> > We have a basic question about libgtpnl (Linux Kernel GTP-U).
>
> I would suggest that you start with setting this up using OsmoGGSN.
>
> It has built-in support for kernel GTP (via libgtpnl), see the related
> user manual.
>
> Once that works, you have a "known working" setup and you can start
> comparing
> the differences between how OsmoGGSN uses libgtpnl and how you are using
> it manually.
>
> I have to admit that I never considered using the manual
> gtp-link/gtp-tunnel commands
> in a "real" network.  Those were only ever used in artificial functional
> testing.
>
> Regards,
>         Harald
> --
> - Harald Welte <laforge at osmocom.org>
> http://laforge.gnumonks.org/
>
> ============================================================================
> "Privacy in residential applications is a desirable marketing option."
>                                                   (ETSI EN 300 175-7 Ch.
> A6)
>


-- 
*When there is much light, The shadow is deep...*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/osmocom-net-gprs/attachments/20210203/4b73b8b1/attachment.htm>

From morteza.ali.ahmadi at gmail.com  Sun Feb  7 18:44:59 2021
From: morteza.ali.ahmadi at gmail.com (morteza ali Ahmadi)
Date: Sun, 7 Feb 2021 22:14:59 +0330
Subject: Question about OsmoGGSN project
Message-ID: <CANPQb9D9Vt7BJjyuJ8ZPoVJQbQmZm+Vr+cpxE6sfrpcRhbJZ1w@mail.gmail.com>

Hi, osmocom team members

We have run OsmoGGSN project using the attached config file in this email
and the following command:

osmo-ggsn

As you can see in the config file, we have set IP 127.0.0.2 for GGSN.
After executing the above command, a tunnel named tun4 is created.

To communicate with SGSN, we use the SGSN emulator in OsmoGGSN as follow:

sgsnemu -l 127.0.0.1 -r 127.0.0.2

After executing the above command, we see that 2 packets are sent from SGSN
to GGSN. These packets are "Echo request" and "Create PDP context request"
and GGSN responses to SGSN with the packets "Echo response" and "Create PDP
context response".

To test tun4, we send a GTP <DNS> packet containing an arbitrary query to
GGSN and we see that this GTP <DNS> packet is received in Loopback (lo)
interface and also, the DNS packet is received in tun4 interface. But there
is no DNS response to our query neither in tun4 interface nor lo interface.
A screenshot of the lo interface and tun4 interface in the wireshark is
attached in this email (right is lo and left is tun4).

How can we receive DNS responses to our DNS query? (Does tun4 require
routing or something else?)

-- 
*When there is much light, The shadow is deep...*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/osmocom-net-gprs/attachments/20210207/fec76fff/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: osmo-ggsn.cfg
Type: application/octet-stream
Size: 1075 bytes
Desc: not available
URL: <http://lists.osmocom.org/pipermail/osmocom-net-gprs/attachments/20210207/fec76fff/attachment.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: log.png
Type: image/png
Size: 207848 bytes
Desc: not available
URL: <http://lists.osmocom.org/pipermail/osmocom-net-gprs/attachments/20210207/fec76fff/attachment.png>

From pespin at sysmocom.de  Mon Feb  8 09:35:02 2021
From: pespin at sysmocom.de (Pau Espin Pedrol)
Date: Mon, 8 Feb 2021 10:35:02 +0100
Subject: Question about OsmoGGSN project
In-Reply-To: <CANPQb9D9Vt7BJjyuJ8ZPoVJQbQmZm+Vr+cpxE6sfrpcRhbJZ1w@mail.gmail.com>
References: <CANPQb9D9Vt7BJjyuJ8ZPoVJQbQmZm+Vr+cpxE6sfrpcRhbJZ1w@mail.gmail.com>
Message-ID: <ed20a5c3-57bf-0a6a-ca1d-f7279a933d8f@sysmocom.de>

Hi,

you are probably facing a routing issue, and you need to solve it by 
using different network namespaces (netns).
In your current setup, you probably have routing for those DNS packets 
to go through the sgsnemu iface, and once the ggsn puts them again in 
the network stack after going through GTP, the kernel probably ends up 
dropping the packet because it finds out some sort of loop.

In order to solve it, the easiest is to run sgsnemu under a different 
netns, and set default routing inside that netns to the tun iface 
created by sgsnemu. AFAIR, the netns can take care of creating the netns 
and configuring it for you, check it's man page ("--defaultroute", 
"--netns").

Hope this is useful to you,
Pau

-- 
- Pau Espin Pedrol <pespin at sysmocom.de>         http://www.sysmocom.de/
=======================================================================
* sysmocom - systems for mobile communications GmbH
* Alt-Moabit 93
* 10559 Berlin, Germany
* Sitz / Registered office: Berlin, HRB 134158 B
* Geschaeftsfuehrer / Managing Director: Harald Welte


From morteza.ali.ahmadi at gmail.com  Mon Feb  8 21:05:26 2021
From: morteza.ali.ahmadi at gmail.com (morteza ali Ahmadi)
Date: Tue, 9 Feb 2021 00:35:26 +0330
Subject: Question about OsmoGGSN project
In-Reply-To: <ed20a5c3-57bf-0a6a-ca1d-f7279a933d8f@sysmocom.de>
References: <CANPQb9D9Vt7BJjyuJ8ZPoVJQbQmZm+Vr+cpxE6sfrpcRhbJZ1w@mail.gmail.com>
 <ed20a5c3-57bf-0a6a-ca1d-f7279a933d8f@sysmocom.de>
Message-ID: <CANPQb9DNMErt0+LC2xORH2sOhE98yAUGz1WBoYFzMsX6wGFu3g@mail.gmail.com>

Thanks Pau, I'll check it out and share my results with you.

On Mon, Feb 8, 2021 at 1:05 PM Pau Espin Pedrol <pespin at sysmocom.de> wrote:

> Hi,
>
> you are probably facing a routing issue, and you need to solve it by
> using different network namespaces (netns).
> In your current setup, you probably have routing for those DNS packets
> to go through the sgsnemu iface, and once the ggsn puts them again in
> the network stack after going through GTP, the kernel probably ends up
> dropping the packet because it finds out some sort of loop.
>
> In order to solve it, the easiest is to run sgsnemu under a different
> netns, and set default routing inside that netns to the tun iface
> created by sgsnemu. AFAIR, the netns can take care of creating the netns
> and configuring it for you, check it's man page ("--defaultroute",
> "--netns").
>
> Hope this is useful to you,
> Pau
>
> --
> - Pau Espin Pedrol <pespin at sysmocom.de>         http://www.sysmocom.de/
> =======================================================================
> * sysmocom - systems for mobile communications GmbH
> * Alt-Moabit 93
> * 10559 Berlin, Germany
> * Sitz / Registered office: Berlin, HRB 134158 B
> * Geschaeftsfuehrer / Managing Director: Harald Welte
>


-- 
*When there is much light, The shadow is deep...*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/osmocom-net-gprs/attachments/20210209/b388b7ba/attachment.htm>

From laforge at osmocom.org  Sat Feb 13 17:16:43 2021
From: laforge at osmocom.org (Harald Welte)
Date: Sat, 13 Feb 2021 18:16:43 +0100
Subject: Very useful wireshark fix for NS / BSSGP decoding
Message-ID: <YCgJexYGwGMwcsPu@nataraja>

In case anyone has been annoyed by this before:

wireshark so far always showed _only_ the BSSGP decode in the Information column
of a Gb interface pcap file, even if that BSSGP was contained in the "erroneous
message" IE of a NS-STATUS message.

This made it particularly difficult to spot NS-STATUS, and without custom
coloring rules or search filters, a protocol trace would just look fine - except
that in reality it isn't.

I've now found out what's the proper method to resolve this and submitted
a patch to wireshark, which was merged very quickly:
	https://gitlab.com/wireshark/wireshark/-/merge_requests/2081

After this change, the Information column in the packet list will show
NS-STATUS with the human-redaable cause value for the reject, rather than
displaying BSSGP as if nothing odd happened.

Regards,
	Harald

-- 
- Harald Welte <laforge at osmocom.org>            http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
                                                  (ETSI EN 300 175-7 Ch. A6)


From pespin at sysmocom.de  Fri Feb 26 16:33:47 2021
From: pespin at sysmocom.de (Pau Espin Pedrol)
Date: Fri, 26 Feb 2021 17:33:47 +0100
Subject: Osmocom CNI release 202102
Message-ID: <0c5afc56-951f-c8a5-39fe-5da1a5af46c8@sysmocom.de>

Dear all,

I am pleased to announce new tagged releases for Osmocom Cellular 
Network Infrastructure components.

Find more information about the release here [1].

Osmocom "Latest" repositories in OBS [2] should already contain packages 
for the new versions.

OpenEmbedded related meta-layers such as meta-telephony usual 
stable/testing branch "201705" [3] have also been updated to build 
recipes for new versions.

Regards,
Pau

[1] https://osmocom.org/news/132
[2] https://osmocom.org/projects/cellular-infrastructure/wiki/Latest_Builds
[3] https://git.osmocom.org/meta-telephony/log/?h=201705

-- 
- Pau Espin Pedrol <pespin at sysmocom.de>         http://www.sysmocom.de/
=======================================================================
* sysmocom - systems for mobile communications GmbH
* Alt-Moabit 93
* 10559 Berlin, Germany
* Sitz / Registered office: Berlin, HRB 134158 B
* Geschaeftsfuehrer / Managing Director: Harald Welte