From firatssonmez at gmail.com  Thu Feb  1 07:00:26 2018
From: firatssonmez at gmail.com (=?UTF-8?B?ZsSxcmF0IHPDtm5tZXo=?=)
Date: Thu, 1 Feb 2018 10:00:26 +0300
Subject: icmp encapsulation
Message-ID: <CAA5f=Pif=9hrG=FtWXim-sTDkynHrOGd32nLT0ujzivRgFX=Jw@mail.gmail.com>

Hi,

I would like to ask&know how the GGSN holds and finds pdp contexts for icmp
packets that have same source and destination address on the downlink?

For example, if there are two hosts having same IP address behind two
different network pinging same destination address and they are
encapsulated at SGSN and then one GGSN receives both and saves the packet,
decapsulates and sends to the destination. On the downlink destination
responds to the two ping packets (they are different because they have
different identifier in icmp packet), but then how does GGSN finds the pdp
contexts again to encapsulate these packets and send back to the two SGSNs?
The pdp context doesnt include thse icmp identifiers. There is no sockets
either since icmp doesnt have sockets. On the downlink, when there are two
icmp packets recieved by GGSN, there is only icmp identfier that
distinguish each other, but this identifier is not in the pdp context.

Would someone help me figure out this?
Thank you all
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/osmocom-net-gprs/attachments/20180201/f60208af/attachment.htm>

From pespin at sysmocom.de  Thu Feb  1 10:46:22 2018
From: pespin at sysmocom.de (Pau Espin Pedrol)
Date: Thu, 1 Feb 2018 11:46:22 +0100
Subject: icmp encapsulation
In-Reply-To: <CAA5f=Pif=9hrG=FtWXim-sTDkynHrOGd32nLT0ujzivRgFX=Jw@mail.gmail.com>
References: <CAA5f=Pif=9hrG=FtWXim-sTDkynHrOGd32nLT0ujzivRgFX=Jw@mail.gmail.com>
Message-ID: <8b38b755-96ef-0689-9f4e-d08e1cda7063@sysmocom.de>

Hi firat,

I didn't understand fully the configuration you are describing. 
Something like this?

Host1 --SGSN1--\GGSN--Server
Host2 --SGSN2--/

Where Host1 has been assigned IP1 and Host2 has been assigned IP2, both 
assigned by GGSN where IP1 != IP2. Let's assume the server IP is IPs and 
the GGSN public uplink (non-GTP) IP is IPg.

As far as I understand, it works as follow:

- Case without NAT between GGSN and Server:
Host1 sends ICMP packet with saddr=IP1 daddr=IPs, which gets 
encapsulated through GTP and GGSN decapsulates it. Same for Host2 but in 
this case the packet will have saddr=IP2. As there's no NAT (eg. host 
clients are assigned a public IP), the server receives 2 ICMP packets 
with different saddr, and when answering back using the original saddr 
now as daddr. As GGSN keeps track of the saddr assigned to each pdp 
context, when it receives a packet from the uplink (non-GTP side), it 
matches the daddr of the packet against the saddr of the active pdp ctx 
to find to which pdp ctx should forward the packet.

- Case with NAT between GGSN and Server:
Almost the same but with extra steps done by the NAT. When the GGSN 
sends the packet saddr=IP1 daddr=IPs to the server, the NAT changes 
saddr=IP1->IPg. It does the same for saddr=IP2, but the NAT keeps track 
of the binding. When the response is received from the server, the NAT 
converts back IPg->IP1 and GGSN can again track the pdp ctx as described 
in the previous case.

-- 
- 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 firatssonmez at gmail.com  Thu Feb  1 13:33:10 2018
From: firatssonmez at gmail.com (=?UTF-8?B?ZsSxcmF0IHPDtm5tZXo=?=)
Date: Thu, 1 Feb 2018 16:33:10 +0300
Subject: Fwd: icmp encapsulation
In-Reply-To: <CAA5f=PhhQbTAj3d03Xhbwb3c+rEEN_u+kqgqGe+kyrDmubLpMw@mail.gmail.com>
References: <CAA5f=Pif=9hrG=FtWXim-sTDkynHrOGd32nLT0ujzivRgFX=Jw@mail.gmail.com>
 <8b38b755-96ef-0689-9f4e-d08e1cda7063@sysmocom.de>
 <CAA5f=PhhQbTAj3d03Xhbwb3c+rEEN_u+kqgqGe+kyrDmubLpMw@mail.gmail.com>
Message-ID: <CAA5f=PiiVRoxz24db3xPzBqoQPtbjyjoNH0yV-zZ7TGV86yCYA@mail.gmail.com>

---------- Forwarded message ----------
From: f?rat s?nmez <firatssonmez at gmail.com>
Date: 2018-02-01 15:51 GMT+03:00
Subject: Re: icmp encapsulation
To: Pau Espin Pedrol <pespin at sysmocom.de>


Hi Pau,

Thank you for your response.

You are right, I should have told the configuration in more detail.
However, you came to the point already. I am talking about the second case
where there is NAT. There is a slight difference though.

After the NAT two IP (IP1 and IP2) will be IPnat, but the NAT maps the IP1
and IP2 to the port range. Since, there is no port in ICMP, both IP1 and
IP2 will be go to uplink as IPg and but on the return there must be problem
for NAT machine to traverse the two different paths from IPnat to IP1 and
IPnat to IP2. I looked into the ICMP header and observed the packets have
different identifiers. So, NAT machine must be using the identifies to
reverse the packets.

Anyways, in my case the *IP1=IP2* (In my experimental architecture, the
GGSN will not be assigning distinct IP for each host. Instead, GGSN will
assign 1 IP address for 32 hosts (seems like NAT). My configuration is
probably out of standard architectures, but I need to understand how would
gtp handle matching these two pdp contexts. I have tried this
configuration, pinging from two different host with same IP and it was
successful!

Two packets coming from the server to the GGSN will be *[src:IPs | dst:IP1]*
and *[src:IPs | dst:IP2]*   IP1=IP2, but two packets have different icmp
identifier. And pdp contexts are still resolved successfully. so a big HOW
in my mind?

F?rat


2018-02-01 13:46 GMT+03:00 Pau Espin Pedrol <pespin at sysmocom.de>:

> Hi firat,
>
> I didn't understand fully the configuration you are describing. Something
> like this?
>
> Host1 --SGSN1--\GGSN--Server
> Host2 --SGSN2--/
>
> Where Host1 has been assigned IP1 and Host2 has been assigned IP2, both
> assigned by GGSN where IP1 != IP2. Let's assume the server IP is IPs and
> the GGSN public uplink (non-GTP) IP is IPg.
>
> As far as I understand, it works as follow:
>
> - Case without NAT between GGSN and Server:
> Host1 sends ICMP packet with saddr=IP1 daddr=IPs, which gets encapsulated
> through GTP and GGSN decapsulates it. Same for Host2 but in this case the
> packet will have saddr=IP2. As there's no NAT (eg. host clients are
> assigned a public IP), the server receives 2 ICMP packets with different
> saddr, and when answering back using the original saddr now as daddr. As
> GGSN keeps track of the saddr assigned to each pdp context, when it
> receives a packet from the uplink (non-GTP side), it matches the daddr of
> the packet against the saddr of the active pdp ctx to find to which pdp ctx
> should forward the packet.
>
> - Case with NAT between GGSN and Server:
> Almost the same but with extra steps done by the NAT. When the GGSN sends
> the packet saddr=IP1 daddr=IPs to the server, the NAT changes
> saddr=IP1->IPg. It does the same for saddr=IP2, but the NAT keeps track of
> the binding. When the response is received from the server, the NAT
> converts back IPg->IP1 and GGSN can again track the pdp ctx as described in
> the previous case.
>
> --
> - 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/osmocom-net-gprs/attachments/20180201/6b566a2a/attachment.htm>

From pespin at sysmocom.de  Thu Feb  1 13:46:33 2018
From: pespin at sysmocom.de (Pau Espin Pedrol)
Date: Thu, 1 Feb 2018 14:46:33 +0100
Subject: Fwd: icmp encapsulation
In-Reply-To: <CAA5f=PiiVRoxz24db3xPzBqoQPtbjyjoNH0yV-zZ7TGV86yCYA@mail.gmail.com>
References: <CAA5f=Pif=9hrG=FtWXim-sTDkynHrOGd32nLT0ujzivRgFX=Jw@mail.gmail.com>
 <8b38b755-96ef-0689-9f4e-d08e1cda7063@sysmocom.de>
 <CAA5f=PhhQbTAj3d03Xhbwb3c+rEEN_u+kqgqGe+kyrDmubLpMw@mail.gmail.com>
 <CAA5f=PiiVRoxz24db3xPzBqoQPtbjyjoNH0yV-zZ7TGV86yCYA@mail.gmail.com>
Message-ID: <9f6842be-245a-4d02-a14d-37d6d3784207@sysmocom.de>


> After the NAT two IP (IP1 and IP2) will be IPnat, but the NAT maps the 
> IP1 and IP2 to the port range. Since, there is no port in ICMP, both IP1 
> and IP2 will be go to uplink as IPg and but on the return there must be 
> problem for NAT machine to traverse the two different paths from IPnat 
> to IP1 and IPnat to IP2. I looked into the ICMP header and observed the 
> packets have different identifiers. So, NAT machine must be using the 
> identifies to reverse the packets.

That's indeed more like a generic ICMP NAT question than a GTP related 
one. I guess the NAT is going to be using the identifier and changing it 
to make sure they are unique on the outside world so it can match them 
when they come back. You can have a look at netfilter stack in the 
kernel to see what's it doing when NATing ICMP packets.

> Anyways, in my case the *IP1=IP2*?(In my experimental architecture, the 
> GGSN will not be assigning distinct IP for each host. Instead, GGSN will 
> assign 1 IP address for 32 hosts (seems like NAT). My configuration is 
> probably out of standard architectures, but I need to understand how 
> would gtp handle matching these two pdp contexts. I have tried this 
> configuration, pinging from two different host with same IP and it was 
> successful!

Which GGSN implementation are you using? osmo-ggsn should not allow you 
to do that afaict. Why are you assigning the same IP to different hosts 
/ pdp ctx ? I'm not sure because I don't know GTP in detail, but from my 
current knowledge I'd say that this is not a correct setup.

If you plan to have several computers under a given pdp ctx, then use a 
NAT before sending them to the SGSN, this way the NAT will take care of 
maintaining correct fields for each ICMP packet coming from different hosts.


-- 
- 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 osmocom at lains.me  Mon Feb  5 22:12:00 2018
From: osmocom at lains.me (Osmocom Mailing List)
Date: Mon, 05 Feb 2018 22:12:00 +0000
Subject: GPRS trafic in PCU - type BVC-UNBLOCK unknown // Protocol error -
 unspecified
Message-ID: <1517868720.1707.0@smtp.migadu.com>

Hi,

I'm trying to run GPRS in my network. So far I get flooded with the 
bellow trafic in the PCU and the GGNS doesn't appear to receive any 
traffic.

<000c> gprs_bssgp_bss.c:294 BSSGP (BVCI=2) Tx BVC-RESET CAUSE=O&M 
intervention
<000c> gprs_bssgp.c:551 BSSGP BVCI=0 Rx BVC STATUS, cause=Protocol 
error - unspecified
<000c> gprs_bssgp_pcu.cpp:348 Rx BSSGP BVCI=0 (SIGN) PDU type 
BVC-UNBLOCK unknown
<000c> gprs_bssgp_util.c:238 BSSGP BVCI=0 Tx STATUS, cause=Protocol 
error - unspecified
<000c> gprs_bssgp_pcu.cpp:298 Rx BSSGP BVCI=0 (SIGN) BVC_RESET_ACK
<000c> gprs_bssgp_pcu.cpp:835 Sending unblock on BVCI 2
<000c> gprs_bssgp_bss.c:274 BSSGP (BVCI=2) Tx BVC-BLOCK
<000c> gprs_bssgp.c:289 Cell 1-1-1-0 CI 0 on BVCI 2

Thanks,
Filipe La?ns <https://github.com/FFY00>


Sent via Migadu.com, world's easiest email hosting
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/osmocom-net-gprs/attachments/20180205/c2447e7b/attachment.htm>

From xinke.zhang at hotmail.com  Mon Feb  5 14:00:21 2018
From: xinke.zhang at hotmail.com (XINKE ZHANG)
Date: Mon, 5 Feb 2018 14:00:21 +0000
Subject: =?gb2312?B?tPC4tDogUHJvYmxlbSB3aGVuIGJ1aWxkaW5nIE9zbW9TR1NO?=
In-Reply-To: <0c698df4-1056-3475-467b-59d18d4dd9a5@sysmocom.de>
References: <HK2PR02MB1585863A007BF138992D1A21EAE60@HK2PR02MB1585.apcprd02.prod.outlook.com>
 <HK2PR02MB1585BABD01E2F13B42F2A8F4EAE50@HK2PR02MB1585.apcprd02.prod.outlook.com>
 <1e4be474-5c2d-100f-ab6d-75babbf316da@sysmocom.de>
 <HK2PR02MB158595AD319DB3E352727580EAE50@HK2PR02MB1585.apcprd02.prod.outlook.com>
 <20180130145931.35de57a6@lazus.yip>
 <HK2PR02MB1585642F0E9DD794B370E44FEAFB0@HK2PR02MB1585.apcprd02.prod.outlook.com>,
 <0c698df4-1056-3475-467b-59d18d4dd9a5@sysmocom.de>
Message-ID: <HK2PR02MB1585F64714C0BCED229C8978EAFA0@HK2PR02MB1585.apcprd02.prod.outlook.com>

Hi,

Problem has been solved. Thanks.

Best Regards,
Xinke Zhang

???: Pau Espin Pedrol<mailto:pespin at sysmocom.de>
????: 2018?1?31? 18:14
???: XINKE ZHANG<mailto:xinke.zhang at hotmail.com>; Alexander Couzens<mailto:lynxis at fe80.eu>
??: osmocom-net-gprs at lists.osmocom.org<mailto:osmocom-net-gprs at lists.osmocom.org>
??: Re: Problem when building OsmoSGSN



On 31/01/18 01:57, XINKE ZHANG wrote:
> Hi,
>
>
> I didn't find the *libgtp* project int the url of
> "https://projects.osmocom.org/". Pls show me how to fetch the *libgtp*
> codes. Thank you.

As I said in my previous message, libgtp can be found, built and
installed from osmo-ggsn.git.
https://git.osmocom.org/osmo-ggsn/

--
- 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/osmocom-net-gprs/attachments/20180205/7ef17f3b/attachment.htm>

From laforge at gnumonks.org  Mon Feb  5 23:44:10 2018
From: laforge at gnumonks.org (Harald Welte)
Date: Tue, 6 Feb 2018 00:44:10 +0100
Subject: GPRS trafic in PCU - type BVC-UNBLOCK unknown // Protocol error
 - unspecified
In-Reply-To: <1517868720.1707.0@smtp.migadu.com>
References: <1517868720.1707.0@smtp.migadu.com>
Message-ID: <20180205234410.GQ10874@nataraja>

Hi Filipe,

On Mon, Feb 05, 2018 at 10:12:00PM +0000, Filipe Lains wrote:
> I'm trying to run GPRS in my network. So far I get flooded with the bellow
> trafic in the PCU and the GGNS doesn't appear to receive any traffic.

Can you please explain your setup in more detail?  What is "your network?"
Which parts of it are Osmocom?  Only the OsmoPCU side, or also OsmoSGSN? Also
the GGSN side?  If not, which implementations are used?

A pcap format protocol trace of the related messages are helpful, as are
the relevant config files.

Regards,
	Harald

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


From viktor.tsymbalyuk at gmail.com  Wed Feb  7 15:00:16 2018
From: viktor.tsymbalyuk at gmail.com (Viktor Tsymbalyuk)
Date: Wed, 7 Feb 2018 17:00:16 +0200
Subject: sgsnemu: no outgoing GTP-U in "createif" mode
Message-ID: <a2473310-f331-c5e5-0bb9-1d42bb5427ed@gmail.com>

Hello,

I tried to run sgsnemu in "createif" mode - transfer traffic via tun 
interface.
tun interface created and routing too. But there are no outgoing GTP-U 
from test machine. (in my scenario sgsnemu on separated server).
 From gdb it looks, that in cb_tun_ind function ipm->pdp is 0x0, as result
gtp_data_req(gsn, ipm->pdp, pack, len);
not running.
After changes like below, it's start working. Does I correctly 
understood internal logic?


diff --git a/sgsnemu/sgsnemu.c b/sgsnemu/sgsnemu.c
index 630733b..cf4aa44 100644
--- a/sgsnemu/sgsnemu.c
+++ b/sgsnemu/sgsnemu.c
@@ -1462,7 +1462,7 @@ static int create_pdp_conf(struct pdp_t *pdp, void 
*cbp, int cause)
free(forwarding);
}

-?????? ipset((struct iphash_t *)pdp->peer, &addr);
+?????? ipset(iph, &addr);

 ??????? state = 2;????????????? /* Connected */


If need more test details, please let me know.
-- 
Viktor


From pespin at sysmocom.de  Fri Feb  9 11:45:01 2018
From: pespin at sysmocom.de (Pau Espin Pedrol)
Date: Fri, 9 Feb 2018 12:45:01 +0100
Subject: sgsnemu: no outgoing GTP-U in "createif" mode
In-Reply-To: <a2473310-f331-c5e5-0bb9-1d42bb5427ed@gmail.com>
References: <a2473310-f331-c5e5-0bb9-1d42bb5427ed@gmail.com>
Message-ID: <955a371c-aedb-3465-ba96-6008601800e5@sysmocom.de>

Hi,

I did a quick look a few days ago but I couldn't find a direct answer to 
your provided change.

Can you please send a patch to gerrit so it doesn't get lost? You can 
add me as a reviewer, I'll have a deeper look when I have some time.

-- 
- 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 tomas.boros92 at gmail.com  Wed Feb 14 23:11:27 2018
From: tomas.boros92 at gmail.com (Thomas Boros)
Date: Thu, 15 Feb 2018 00:11:27 +0100
Subject: Interfering with the GTP-u Kernel module
Message-ID: <1F934BE9-5B85-467D-A69F-F77199E111C8@gmail.com>

Hello,

I would like to implement a command line tool, which will be able to open / close , read / write to gtp tunnels. I was able to install the libgtpnl library, but due to lack of documentation I have no idea where to start. 

Is there some sort of documentation available for this library? 

I need to be able to create and delete tunnels without the GTP-C communication, so just basic command line tool like create-gtp-tunnel + arguments like IPs, version and teid. The GTP-U tunnels must be kernel based. I have the latest kernel with the gtp kernel module loaded. 

Any help is appreciated. 
Thank you,
Tomas

From tomas.boros92 at gmail.com  Thu Feb 15 10:06:12 2018
From: tomas.boros92 at gmail.com (Thomas Boros)
Date: Thu, 15 Feb 2018 11:06:12 +0100
Subject: Interfering with the GTP-u Kernel module
In-Reply-To: <1F934BE9-5B85-467D-A69F-F77199E111C8@gmail.com>
References: <1F934BE9-5B85-467D-A69F-F77199E111C8@gmail.com>
Message-ID: <0A0C4CCA-E884-4A6C-A555-665BB237F4C7@gmail.com>

Hello,

I found, that there are tools available for this purpose, however they are not compiled on build. By adding the bin_PROGRAMS to the makefile the tools are built. I was too lazy to set up the whole gerrit thing, so I?m sending the patch.

diff --git a/tools/Makefile.am b/tools/Makefile.am
index 95aef86..3db095e 100644
--- a/tools/Makefile.am
+++ b/tools/Makefile.am
@@ -1,5 +1,8 @@
 include $(top_srcdir)/Make_global.am

+bin_PROGRAMS = gtp-link                        \
+               gtp-tunnel
+
 check_PROGRAMS = gtp-link              \
                 gtp-tunnel


Tomas

> On 15 Feb 2018, at 00:11, Thomas Boros <tomas.boros92 at gmail.com> wrote:
> 
> Hello,
> 
> I would like to implement a command line tool, which will be able to open / close , read / write to gtp tunnels. I was able to install the libgtpnl library, but due to lack of documentation I have no idea where to start. 
> 
> Is there some sort of documentation available for this library? 
> 
> I need to be able to create and delete tunnels without the GTP-C communication, so just basic command line tool like create-gtp-tunnel + arguments like IPs, version and teid. The GTP-U tunnels must be kernel based. I have the latest kernel with the gtp kernel module loaded. 
> 
> Any help is appreciated. 
> Thank you,
> Tomas



From laforge at gnumonks.org  Fri Feb 16 07:24:40 2018
From: laforge at gnumonks.org (Harald Welte)
Date: Fri, 16 Feb 2018 08:24:40 +0100
Subject: Interfering with the GTP-u Kernel module
In-Reply-To: <0A0C4CCA-E884-4A6C-A555-665BB237F4C7@gmail.com>
References: <1F934BE9-5B85-467D-A69F-F77199E111C8@gmail.com>
 <0A0C4CCA-E884-4A6C-A555-665BB237F4C7@gmail.com>
Message-ID: <20180216072440.GL13099@nataraja>

Hi Thomas,

On Thu, Feb 15, 2018 at 11:06:12AM +0100, Thomas Boros wrote:
> +bin_PROGRAMS = gtp-link                        \
> +               gtp-tunnel
> +
>  check_PROGRAMS = gtp-link              \
>                  gtp-tunnel

This would have them both in bin_PROGRAMS and in check_PROGRAMS, which is redundant.

In any case bin_PROGRAMS installs those tools, which are really only useful to developers
and not for the typical users.  I went for an alternative and included them in noinst_PROGRAMS,
i.e. they are always being built during 'make' not only 'make check', but they still aren't
installed during 'make install'.

See https://gerrit.osmocom.org/6517

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


From laforge at gnumonks.org  Fri Feb 16 07:19:43 2018
From: laforge at gnumonks.org (Harald Welte)
Date: Fri, 16 Feb 2018 08:19:43 +0100
Subject: Problem when building OsmoSGSN
In-Reply-To: <HK2PR02MB1585863A007BF138992D1A21EAE60@HK2PR02MB1585.apcprd02.prod.outlook.com>
References: <HK2PR02MB1585863A007BF138992D1A21EAE60@HK2PR02MB1585.apcprd02.prod.outlook.com>
Message-ID: <20180216071943.GK13099@nataraja>

Hi Xinke,

On Sun, Jan 28, 2018 at 03:22:47AM +0000, XINKE ZHANG wrote:
> I built OsmoSGSN with the these following instructions.

My first curious question is: Why are you building from source rather than using the
"latest" or "nightly" package feeds we are providing at osmocom.org?

> <build instructions>
> git clone git://git.osmocom.org/osmo-sgsn
> cd osmo-sgsn
> autoreconf -fi
> ./configure --enable-iu
> make -j5
> make check
> make install
> sudo ldconfig
> <build instructions>
> 
> And no error came out during building process, but no ?osmo-sgsn? executable was found. Pls help me. Thank you in advance.

Please provide the log output generated by the build process.  you can create this by
something like 

./configure --enable-iu 2>&1 | tee /tmp/configure.log
make -j5 2>&1 | tee /tmp/make.log

etc. which ensures that both stdout and stderr end up in the respective .log file.

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


From tomas.boros92 at gmail.com  Fri Feb 16 08:00:22 2018
From: tomas.boros92 at gmail.com (Thomas Boros)
Date: Fri, 16 Feb 2018 09:00:22 +0100
Subject: Interfering with the GTP-u Kernel module
In-Reply-To: <20180216072440.GL13099@nataraja>
References: <1F934BE9-5B85-467D-A69F-F77199E111C8@gmail.com>
 <0A0C4CCA-E884-4A6C-A555-665BB237F4C7@gmail.com>
 <20180216072440.GL13099@nataraja>
Message-ID: <0D2F8179-7DAA-4FEB-A3DF-9FB0EFA2E4ED@gmail.com>

Hi Harald,

I?ve also noticed one unusual thing. I noticed, that the the gtp-link app must be running, so the socket remains open. If I kill the application and I have gtp-tunnels set up, the machine responds with and ICMP port unreachable message, but I suppose, this behaviour is ok. Another issue I?ve noticed, I?ve enabled module debugging and I can clearly see, if there is a GTP datagram arriving on the socket to a pdp context, which is not existing, the log says that the datagram is going to be handled in the userspace. However, even if the gtp-link tool is running, the datagrams are not passed to the userspace, they get buffered in the Recieve-Q (checked via netstat). On each packet this queue gets larger, what I assume is not the desired functionality. I guess there is something wrong with the gtp-link tool. Did you encounter such situation? I?m using the latest kernel 4.15.3 and the library is compiled from the osmocom repository.

root at gtpt:~# uname -ar
Linux gtpt 4.15.3-041503-generic #201802120730 SMP Mon Feb 12 07:31:14 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux

Tomas

> On 16 Feb 2018, at 08:24, Harald Welte <laforge at gnumonks.org> wrote:
> 
> Hi Thomas,
> 
> On Thu, Feb 15, 2018 at 11:06:12AM +0100, Thomas Boros wrote:
>> +bin_PROGRAMS = gtp-link                        \
>> +               gtp-tunnel
>> +
>> check_PROGRAMS = gtp-link              \
>>                 gtp-tunnel
> 
> This would have them both in bin_PROGRAMS and in check_PROGRAMS, which is redundant.
> 
> In any case bin_PROGRAMS installs those tools, which are really only useful to developers
> and not for the typical users.  I went for an alternative and included them in noinst_PROGRAMS,
> i.e. they are always being built during 'make' not only 'make check', but they still aren't
> installed during 'make install'.
> 
> See https://gerrit.osmocom.org/6517
> 
> -- 
> - Harald Welte <laforge at gnumonks.org>           http://laforge.gnumonks.org/
> ============================================================================
> "Privacy in residential applications is a desirable marketing option."
>                                                  (ETSI EN 300 175-7 Ch. A6)



From tomas.boros92 at gmail.com  Fri Feb 16 08:27:51 2018
From: tomas.boros92 at gmail.com (Thomas Boros)
Date: Fri, 16 Feb 2018 09:27:51 +0100
Subject: Interfering with the GTP-u Kernel module
In-Reply-To: <0D2F8179-7DAA-4FEB-A3DF-9FB0EFA2E4ED@gmail.com>
References: <1F934BE9-5B85-467D-A69F-F77199E111C8@gmail.com>
 <0A0C4CCA-E884-4A6C-A555-665BB237F4C7@gmail.com>
 <20180216072440.GL13099@nataraja>
 <0D2F8179-7DAA-4FEB-A3DF-9FB0EFA2E4ED@gmail.com>
Message-ID: <F67FC62D-FEFC-4ACF-81D5-BEA1D663C00D@gmail.com>

I?m attaching some logs to my previous mail:

Feb 16 09:26:01 gtpt kernel: [ 2044.151300] gtp0: encap_recv sk=000000005f3daa49
Feb 16 09:26:01 gtpt kernel: [ 2044.151302] gtp0: received GTP1U packet
Feb 16 09:26:01 gtpt kernel: [ 2044.151303] gtp0: No PDP ctx to decap skb=000000001be38557
Feb 16 09:26:01 gtpt kernel: [ 2044.151304] gtp0: pass up to the process


root at gtpt:~# gtp-link add gtp0
WARNING: attaching dummy socket descriptors. Keep this process running for testing purposes.


Every 1.0s: netstat -aup                                                                                       Fri Feb 16 09:27:29 2018

Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address           Foreign Address         State       PID/Program name
udp        0      0 *:3386                  *:*                                 3338/gtp-link
udp        0      0 *:bootpc                *:*                                 741/dhclient
udp     6144      0 *:2152                  *:*                                 3338/gtp-link


Tomas


> On 16 Feb 2018, at 09:00, Thomas Boros <tomas.boros92 at gmail.com> wrote:
> 
> Hi Harald,
> 
> I?ve also noticed one unusual thing. I noticed, that the the gtp-link app must be running, so the socket remains open. If I kill the application and I have gtp-tunnels set up, the machine responds with and ICMP port unreachable message, but I suppose, this behaviour is ok. Another issue I?ve noticed, I?ve enabled module debugging and I can clearly see, if there is a GTP datagram arriving on the socket to a pdp context, which is not existing, the log says that the datagram is going to be handled in the userspace. However, even if the gtp-link tool is running, the datagrams are not passed to the userspace, they get buffered in the Recieve-Q (checked via netstat). On each packet this queue gets larger, what I assume is not the desired functionality. I guess there is something wrong with the gtp-link tool. Did you encounter such situation? I?m using the latest kernel 4.15.3 and the library is compiled from the osmocom repository.
> 
> root at gtpt:~# uname -ar
> Linux gtpt 4.15.3-041503-generic #201802120730 SMP Mon Feb 12 07:31:14 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux
> 
> Tomas
> 
>> On 16 Feb 2018, at 08:24, Harald Welte <laforge at gnumonks.org> wrote:
>> 
>> Hi Thomas,
>> 
>> On Thu, Feb 15, 2018 at 11:06:12AM +0100, Thomas Boros wrote:
>>> +bin_PROGRAMS = gtp-link                        \
>>> +               gtp-tunnel
>>> +
>>> check_PROGRAMS = gtp-link              \
>>>                gtp-tunnel
>> 
>> This would have them both in bin_PROGRAMS and in check_PROGRAMS, which is redundant.
>> 
>> In any case bin_PROGRAMS installs those tools, which are really only useful to developers
>> and not for the typical users.  I went for an alternative and included them in noinst_PROGRAMS,
>> i.e. they are always being built during 'make' not only 'make check', but they still aren't
>> installed during 'make install'.
>> 
>> See https://gerrit.osmocom.org/6517
>> 
>> -- 
>> - Harald Welte <laforge at gnumonks.org>           http://laforge.gnumonks.org/
>> ============================================================================
>> "Privacy in residential applications is a desirable marketing option."
>>                                                 (ETSI EN 300 175-7 Ch. A6)
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/osmocom-net-gprs/attachments/20180216/09ca568f/attachment.htm>

From xinke.zhang at hotmail.com  Wed Feb 28 00:53:21 2018
From: xinke.zhang at hotmail.com (XINKE ZHANG)
Date: Wed, 28 Feb 2018 00:53:21 +0000
Subject: Data Rate of EGPRS is Too Low
Message-ID: <HK2PR02MB1585032030330724B314BC4AEAC70@HK2PR02MB1585.apcprd02.prod.outlook.com>

Hi all,


I have set up the EGPRS network using software bundles (osmo-nitb + osmo-bts-trx + osmo-trx + osmo-pcu + osmo-sgsn + openggsn) based on the USRP B210 platform. Now the cell phone can connect to the EGPRS network, but the network is not stable and the data rate is too low (only about 8kbs).


Is this data rate correct? If not, could you pls send me some working config files? Thank you.


Best Regards,

Xinke
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/osmocom-net-gprs/attachments/20180228/d7bcb2c9/attachment.htm>