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
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
---------- Forwarded message ----------
From: fırat sönmez <firatssonmez(a)gmail.com>
Date: 2018-02-01 15:51 GMT+03:00
Subject: Re: icmp encapsulation
To: Pau Espin Pedrol <pespin(a)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(a)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(a)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
>
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
Hello,
I continue to play with sgsnemu, and found that it stopped for some
reason after "Request accepted".
Does sgsnemu working?
At my mind problem inside `create_pdp_conf` function . After small
changes, I start to see icmp inside gtp tunnel in trace.
Please check attachments with console output, patch and pcap. May be I
has wrong understanding.
--
Viktor
Dear all,
I've written up a "short" review of what I perceive as the most important
events in the Osmocom Cellular Infrastructure projects in 2017.
See http://osmocom.org/news/84 for all details, or below for a raw copy+paste:
h1. Osmocom Review 2017
This is a review of the most significant changes and events in the Osmocom Cellular Infrastructure projects in 2017
h2. January 2017
* announce of first ever public [[OsmoCon:]] conference in April
* osmo-bts
** Add Abis OML failure event reporting
** fix memory leaks in osmo-bts-{sysmo,lc15} at every channel activation
* openbsc/osmo-bsc
** support multiple UARFCNs in SI2quater
* osmo-hlr
** add test suite for 2G and 3G authentication
** fix UMTS AKA re-sync
h2. February 2017
* weekly manual testing with related weekly test reports to mailing list
* "heads-up about the (lack of a )future of osmo-nitb":http://lists.osmocom.org/pipermail/openbsc/2017-February/010300.html
* "heads-up about libosmo-sccp SIGTRAN work":http://lists.osmocom.org/pipermail/openbsc/2017-February/010274.html
* "sysmo-usim-tool":http://lists.osmocom.org/pipermail/openbsc/2017-February/010317.html
* libosmo-abis
** unix domain socket support (for Ericsson L2TP)
* osmo-bts
** fix AMR HR DTX FSM logic
** fix SACCH sending fo system information with enum value > 7
** osmo-bts-trx: fix RXGAIN and POWER parameters on second TRX
** fix TCH/H interleaving table bit position
** sysmoBTS 1020/1100: slow power ramp-up on TRX enable
* osmo-sgsn
** fix PDP context activation memory allocation bug
** integrate support for UMTS AKA
* openggsn
** fix kernel-gtp tunnel creation/removal for GTPv1
** release 0.93
h3. March 2017
* "cgit improvements":http://lists.osmocom.org/pipermail/openbsc/2017-March/010448.html (about page, change-ID hyperlinks, issue hyperlinks)
* Add README.md files to all our repositories
* libosmocore
** migrate gsm 05.03 coding from OsmoBTS to libosmocore
** fix SQN / SEQ handling in UMTS AKA
** 3GPP AoIP message encoding/decoding
* libosmo-abis
** fix ever-increasing jitter buffer
* libosmo-netif
** handle SCTP in in stream server
** doxygen documentation on stream an datagram modules
* osmo-bts
** octphy: CBCH support
** include MS timing offset in RSL measurements
* osmo-sgsn
** handle IMSIs with leading zeroes
* osmo-bsc
** fix T3186 encoding in SI13
** Improved Ericsson OM2000/RBS2000 support
** new ctrl2soap proxy in python
* osmo-hlr
** add CTRL interface
** fix SQN/SEQ handling in UMTS AKA
h3. April 2017
* "update of coding style for longer line lengths":http://lists.osmocom.org/pipermail/openbsc/2017-April/010502.html
* [[osmo-dev-con:OsmoCon2017]] and [[osmo-dev-con:OsmoDevCon2017]]
* libosmocore
** "control interface for osmo_fsm":http://lists.osmocom.org/pipermail/openbsc/2017-April/010542.html
* libosmo-netif
** fix file descriptor leak in error paths
** work around linux kenrel SCTP bug with sender_dry_events
** RTP marker bit support
* libosmo-sccp
** Add new [[libosmo-sigtran:]] library with SS7 AS/ASP Link/Linkset handling, M3UA support, new FSM based SCCP implementation
** Add [[osmo-stp:]] program
* osmo-bts
** inform BSC of PCU disconnect
** fix measurement reporting period
** exclude idle channels from uplink measurement processing
** octphy: measurement reports
h3. May 2017
* libosmocore
** fix embedded builds
** import and generalise 'sercomm' from osmocom-bb into libosmocore
** SSE optimized convolutional coder
** fix wrong GSM FR codec SID frame generation
** doxygen docs for libosmocoding
* osmo-bsc
** TS 04.14 mobile station side loop control
* osmo-bts
** consistently check all RSL and OML TLVs for minimum length value
** fix bit-order in every HR codec parameter (spec compliance)
** OML get/set attribute handling
** SI2quater support
** bypass radio link timeout for lab testing
* osmo-bsc
** PCU socket support for BSC-colocated PCU for Ericsson RBS2000
** reelase 1.0.1
* "M3UA and SUA testing as part of jenkins":http://lists.osmocom.org/pipermail/openbsc/2017-May/010698.html
* "osmo-gsm-tester produces successful runs with NITB as well as new AoIP":http://lists.osmocom.org/pipermail/openbsc/2017-May/010760.html
h3. June 2017
* libosmocore
** doxygen autobrief
** doxygen documentation for libosmogb
* osmo-bts
** use CLOCK_MONOTONIC timer for GSM frame timer
** PDTCH loopback support
h3. July 2017
* "Plan for openbsc.git split and code review":http://lists.osmocom.org/pipermail/openbsc/2017-July/010914.html
* libosmocore
** PDP charging characteristics in GSUP
** PRBS sequence generators
** multicast IP related helper functions
** 'make release' target
* libosmo-sccp
** SCCP address book
* osmo-bts
** new virtual BTS @osmo-bts-virtual@ for testing without radio hardware
** don't send dummy UI frames on unused BCCH slots on TC=5
** GSMTAP: don't log/send fill frames consisting of only padding
* osmo-hlr
** change to default GSUP port 4222
h3. August 2017
* "Support for SMPP Delivery Receipt / GSM03.40 Status Report":http://lists.osmocom.org/pipermail/openbsc/2017-August/011023.html
* "Jenkins now executing M3UA, SUA and GGSN testsuite":http://lists.osmocom.org/pipermail/openbsc/2017-August/011043.html
* libosmocore
** fix crash in lapd_est_req()
* libosmo-abis
** release 0.4.0
* osmo-bts
** osmo-bts-trx: fix MS power control loop
** release 0.6.0
** support sending/removing SI13 to/from PCU
* osmo-bsc
** indicate R99+ MSC in SI3 to enable UMTS AKA over GERAN
* osmo-sgsn
** properly report GERAN/UTRAN mode in PDP CTX ACT REQ to GGSN
* osmo-msc
** implement IuCS support
** split openbsc.git into osmo-bsc.git, osmo-msc.git and osmo-sgsn.git
* openggsn
** Add IPv6 address pool and IPV6 user (inner) plane support
** release 0.94
h3. September 2017
* libosmocore.git
** "'show talloc-context' VTY introspection":http://lists.osmocom.org/pipermail/openbsc/2017-June/010771.html
** CTRL parsing unit tests
** unification of vty exit/end commands
* osmo-hlr
** CTRL interface tests
--
- 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)
Dear Osmocom Community,
[please respect the Reply-To and post all follow-up discussion to this
to openbsc(a)lists.osmocom.org, so we avoid having long threads
cross-posted to several mailing lists.]
Like every year in early December, it is time to discuss as schedule for
OsmoDevCon in the upcoming year.
Note: Ths is about OsmoDevCon, the more private meeting of developers,
*NOT* about OsmoCon, the public conference.
== When, Who, Where ==
I propose the following date for OsmoDevCon 2018:
April 20 - April 23rd, 2018
* Who: Active developers/contributors of Osmocom projects (as usual)
* Where: IN-Berlin, Berlin (as usual)
Please let me know ASAP if that proposed date works for everyone who'd
want to attend. We can still change it now, but I would want to nail
down the date pretty soon.
== Format ==
After the experiment of reducing from 4 to 3 days last year (due to
OsmoCon), we will again go for *four days* in 2018.
However, we should clearly divide the days in a way that e.g. "GSM/3G"
topics are on two days, while SDR+Other topics are on the other days, so
people not interested in some topics can skip one or two days, as
needed.
We could even divide it further like:
* 1 day 3GPP RAN (osmo-bts, osmo-bsc, osmo-pcu, virt_phy, fake_trx, ...)
* 1 day 3GPP CN (osmo-msc, osmo-hlr, osmo-sip-connector, nextepc, etc.)
* 2 days misc
Regards, and looking forward to meeting you [again] in 2018,
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)
Hi guys,
I'm using libgtpnl tools (gtp-link, gtp-tunnel) to setup a tunnel in my
local
machines. I was able to setup gtp link to 2152 port as well as gtp tunnel.
I have pre-recorded GTP packets with correct teid and IP address as well
as chksum and port to send to 2152. However I can not see any packets
in gtp link device when using tcpdump.
By add some messages in gtp module, I notice that the function
gtp1u_udp_encap_recv in gtp.c kernel file was never been called if I send
packet with GTP headers. However, that function is called if I send normal
UDP packet without GTP header.
Note that I'm using Ubuntu 14.04 with kernel 4.8.0 lowlatency, the tunnel
is on a VM created by Virtualbox using virtio network driver. Any
suggestions
on how to debug/solve this problem?
Many thanks in advances.
Best regards
Cong.
Hi all,
FYI: I migrated libgtpnl (the kernel-GTP netlink interface helper
library used by OpenGGSN and OsmoGGSN) to gerrit earlier today. This
means direct pushes to git.osmocom.org no longer work and you will have
to submit modifications via gerrit, as we do for all our other major
repositories.
I've also set up a gerrit build verification job via jenkins-job-builder
and added a corresponding contrib/jenkins.sh script to it.
The buildhosts now need libmnl-dev as build dependency installed. I
added this to our current debian8 + debian9 build slaves and the wiki
documentation about them.
In other news: libgtpnl is already part of the network:osmocom:nightly
and network:osmocom:latest feeds for some weeks. I intend to test
kernel GTP support in osmo-ggsn soon and then change the package builds
to include kernel-gtp support via libgtpnl by default.
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)