GPRS and PDP Context

[John Otten]

Good Day,

I have been working with OpenBSC for the past few weeks and I am able to
make voice calls and send SMS messages within the private network without
issues.

I am now attempting to add GPRS to the mix, and have been having less
success. I have been able to make it to the internet from my phones
occasionally, but in general, there appears to be an issue between
osmo-sgsn and OpenGSN. My hope is that it is a simple configuration
issue. However, I suspect it may be due to an issue in the code, or
perhaps something mentioned last May (I have been scouring the mail
archive) regarding foreign vs local TLLIs.

My current setup is:
One Linux workstation which runs all three pertinent executables:
osmo-nitb, osmo-sgsn and ggsn.
A nanoBTS 165BU (PCS1900)
Two Nokia 6013b phones
I am working in an RF chamber. I have some T-Mobile SIMs so, I have the
network set to T-Mobile rather than the test network.

I had previously been able to connect to the internet perhaps 1 in 10
times, presumably because the PDP contexts were not being created (the ggsn
output would not state that it was creating a context when I tried to
connect from the phone). I modified gprs_llc.c to handle the issue that
Frank Maas mentioned in May, regarding llme_alloc not localizing the TLLI.
Now, I can usually connect with a phone more consistently (but not always)
on a fresh restart of the three executables.

However, after connecting to the internet via the phone, if I cycle the
power on the phone, I am usually not able to connect to the internet again.
Sometimes the ggsn states that it "Received create PDP context request,"
and sometimes it doesn't state it when the sgsn (apparently) makes a
request. At times, the ggsn reports "Received packet with no
destination!!!" During these times, when I check the PDP contexts in
osmo-sgsn, I get:

OsmoSGSN> show pdp-context all
PDP Context IMSI: 310260XXXXXXXXX, SAPI: 3, NSAPI: 5
APN: epc.tmobile.com
PDP Address: IPv4 192.168.100.3
SGSN PDP Context Statistics:
User Data Messages ( In): 0 (0/s 0/m 0/h 0/d)
User Data Messages (Out): 0 (0/s 0/m 0/h 0/d)
User Data Bytes ( In): 0 (0/s 0/m 0/h 0/d)
User Data Bytes (Out): 0 (0/s 0/m 0/h 0/d)

The times when the ggsn does not state that it received a create PDP
context request, the "show pdp-context all" command shows nothing.

My newbie guess is that osmo-sgsn is saving the state of the phone's
connection (based on the IMSI?), and is not releasing or clearing it when
the phone is powered off. When the phone is powered back on, it will have
different connection parameters, but it will use the original parameters
after retrieving them based on the IMSI. I have started to look through
the code in the src/gprs directory to see if this is the case.

I am wondering if anyone might have some insight into why the connection is
not fully restored. Or perhaps they can offer guidance where I might begin
to look in the code. I can send logs and pcap files of a typical session if
anyone is interested.

Thanks!
John
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20120918/020e4211/attachment.html>

[☎]

Hello.

I have similar setup although in my case it doesn't work at all.

Could you share your configs so I can check that I hadn't missed something obvious.
Here are mine. Note that I run everything on a single machine 192.168.10.53
nanoBTS is configured and successfully connected to openbsc (green light on bts).

/etc/ggsn.conf:

listen 127.0.0.1
dynip 10.0.0.0/24
pcodns1 8.8.8.8
pcodns2 208.67.220.220

/etc/osmo_sgsn.cfg:
!
line vty

no login

!

sgsn

gtp local-ip 192.168.10.53
ggsn 0 remote-ip 127.0.0.1
ggsn 0 gtp-version 1

!

ns

timer tns-block 3
timer tns-block-retries 3
timer tns-reset 3
timer tns-reset-retries 3
timer tns-test 30
timer tns-alive 3
timer tns-alive-retries 10
encapsulation udp local-ip 192.168.10.53
encapsulation udp local-port 23000
encapsulation framerelay-gre enabled 0
!

bssgp
!

/etc/openbsc.cfg:
! !

password foo

!

line vty

no login
!

e1_input

e1_line 0 driver ipa
network

network country code 1
mobile network code 1
short name OpenBSC

long name OpenBSC

auth policy accept-all

location updating reject cause 13
encryption a5 0
neci 1
rrlp mode none

mm info 1
handover 0
handover window rxlev averaging 10
handover window rxqual averaging 1
handover window rxlev neighbor averaging 10
handover power budget interval 6
handover power budget hysteresis 3
handover maximum distance 9999
timer t3101 10
timer t3103 0
timer t3105 0
timer t3107 0
timer t3109 0
timer t3111 0
timer t3113 60
timer t3115 0
timer t3117 0
timer t3119 0
timer t3141 0
bts 0
type nanobts
band DCS1800
cell_identity 0
location_area_code 1
training_sequence_code 7
base_station_id_code 63
ms max power 15
cell reselection hysteresis 4
rxlev access min 0
channel allocator ascending
rach tx integer 9
rach max transmission 7
ip.access unit_id 1801 0
oml ip.access stream_id 255 line 0
gprs mode gprs
gprs routing area 0
gprs cell bvci 2
gprs nsei 101
gprs nsvc 0 nsvci 101
gprs nsvc 0 local udp port 23000
gprs nsvc 0 remote udp port 23000
gprs nsvc 0 remote ip 192.168.10.53
trx 0
rf_locked 0
arfcn 514
nominal power 23
max_power_red 20
rsl e1 tei 0
timeslot 0
phys_chan_config CCCH+SDCCH4
timeslot 1
phys_chan_config SDCCH8
timeslot 2
phys_chan_config TCH/F
timeslot 3
phys_chan_config TCH/F
timeslot 4
phys_chan_config TCH/F
timeslot 5
phys_chan_config PDCH
timeslot 6
phys_chan_config PDCH
timeslot 7
phys_chan_config TCH/F

[John Otten]

Hi Max,

I am reluctant to post my actual config files. However, your config files
seem nearly identical to mine. Below, I will describe the differences:

In your ggsn.conf file, your listen parameter is set to 127.0.0.1. What I
did was make an alias, eth0:1, to a different IP address (192.168.10.60)
and used it for this parameter. (Actually, my main IP address used for
OpenBSC is also an alias since I was trying to match the subnet that the
BTS came from which is different from the machine I am using. We didn't
want to reconfigure the BTS from its settings just so I could play with it.
So, I made an alias, eth0:0, which on your machine would be treated as eth0
- 192.168.10.53. In your case, you would probably not need to make the
eth0:0 alias, but if your BTS is configured to a different subnet from
192.168.10.X, then you might have to.) Anyway, you might want to make an
alias to 192,168.10.60 (or whatever address is available on your network)
and use that address for your listen parameter.

Also, in ggsn.conf, I used the IP address of my DNS server for both of the
pcodns parameters. Also, I set the apn parameter to epc.tmobile.com which
is the access point for T-Mobile (which is the kind of SIMs I am using). I
don't know if there is an apn that could be used for the 001 01 test
network. Perhaps that has been discussed on the list previously. In any
event, the apn parameter is experimental, so you may have different results.

Finally in ggsn.conf, I set the net and dynip parameters to 192.168.100.0/24,
and then made a tunnel to it after starting the ggsn executable (but before
starting osmo-sgsn) with the following command:
sudo route add -net 192.168.100.0 netmask 255.255.255.0 gw 192.168.100.1
How did we come up with 192.168.100.1 for the gateway address? Well, after
starting ggsn, the ifconfig command will show the IP address of the tunnel
endpoint (tun0) that is created by the ggsn. In our case (and probably all
cases), this was 192.168.100.1.

Make sure you have followed the instructions on the OpenBSC_GPRS page about
setting the iptables

In the osmo_sgsn.cfg, I set the gtp local-ip to the eth0:0 alias or
192.168.10.53 (which you probably have correct in your file - assuming your
BTS is configured for the same subnet of your machine), and the ggsn 0
remote-ip parameter to the eth0:1 alias (192.168.10.60).

In the openbsc.cfg file, the only difference I see is the NCC and MNC
(because I am using T-Mobile SIMs) and I made timeslot 7 a PDCH channel
instead of a TCH/F.

A critical issue is setting up the tunnel between osmo_sgsn and ggsn,
before starting osmo_sgsn. I also start the osmo-nitb executable last,
after the other two executables are up and running.

Finally, at the suggestion of one of the list members, I tried a different
phone that doesn't use the original Nokia baseband. I tried a Nokia Lumia
phone (which uses the Microsoft Mobile OS) and it works *much* better.

I hope that this information helps. Good Luck!
John

Post by ☎
Hello.
I have similar setup although in my case it doesn't work at all.
Could you share your configs so I can check that I hadn't missed something obvious.
Here are mine. Note that I run everything on a single machine 192.168.10.53
nanoBTS is configured and successfully connected to openbsc (green light on bts).
listen 127.0.0.1
dynip 10.0.0.0/24
pcodns1 8.8.8.8
pcodns2 208.67.220.220
!
line vty
no login
!
sgsn
gtp local-ip 192.168.10.53
ggsn 0 remote-ip 127.0.0.1
ggsn 0 gtp-version 1
!
ns
timer tns-block 3
timer tns-block-retries 3
timer tns-reset 3
timer tns-reset-retries 3
timer tns-test 30
timer tns-alive 3
timer tns-alive-retries 10
encapsulation udp local-ip 192.168.10.53
encapsulation udp local-port 23000
encapsulation framerelay-gre enabled 0
!
bssgp
!
! !
password foo
!
line vty
no login
!
e1_input
e1_line 0 driver ipa
network
network country code 1
mobile network code 1
short name OpenBSC
long name OpenBSC
auth policy accept-all
location updating reject cause 13
encryption a5 0
neci 1
rrlp mode none
mm info 1
handover 0
handover window rxlev averaging 10
handover window rxqual averaging 1
handover window rxlev neighbor averaging 10
handover power budget interval 6
handover power budget hysteresis 3
handover maximum distance 9999
timer t3101 10
timer t3103 0
timer t3105 0
timer t3107 0
timer t3109 0
timer t3111 0
timer t3113 60
timer t3115 0
timer t3117 0
timer t3119 0
timer t3141 0
bts 0
type nanobts
band DCS1800
cell_identity 0
location_area_code 1
training_sequence_code 7
base_station_id_code 63
ms max power 15
cell reselection hysteresis 4
rxlev access min 0
channel allocator ascending
rach tx integer 9
rach max transmission 7
ip.access unit_id 1801 0
oml ip.access stream_id 255 line 0
gprs mode gprs
gprs routing area 0
gprs cell bvci 2
gprs nsei 101
gprs nsvc 0 nsvci 101
gprs nsvc 0 local udp port 23000
gprs nsvc 0 remote udp port 23000
gprs nsvc 0 remote ip 192.168.10.53
trx 0
rf_locked 0
arfcn 514
nominal power 23
max_power_red 20
rsl e1 tei 0
timeslot 0
phys_chan_config CCCH+SDCCH4
timeslot 1
phys_chan_config SDCCH8
timeslot 2
phys_chan_config TCH/F
timeslot 3
phys_chan_config TCH/F
timeslot 4
phys_chan_config TCH/F
timeslot 5
phys_chan_config PDCH
timeslot 6
phys_chan_config PDCH
timeslot 7
phys_chan_config TCH/F
--
best regards,
Max, http://fairwaves.ru

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20120919/7e1e735e/attachment.html>

[Peter Stuge]

Post by ☎
I have similar setup although in my case it doesn't work at all.

..
..

Post by ☎
ns

..

Post by ☎
encapsulation udp local-ip 192.168.10.53
encapsulation udp local-port 23000

..

Post by ☎
bts 0

..

Post by ☎
gprs nsvc 0 local udp port 23000
gprs nsvc 0 remote udp port 23000
gprs nsvc 0 remote ip 192.168.10.53

I don't think both processes can use the same port; move one of them
and configure the other accordingly.


//Peter

[☎]

Post by Peter Stuge

Post by ☎
I have similar setup although in my case it doesn't work at all.

..
..

Post by ☎
ns

..

Post by ☎
encapsulation udp local-ip 192.168.10.53
encapsulation udp local-port 23000

..

Post by ☎
bts 0

..

Post by ☎
gprs nsvc 0 local udp port 23000
gprs nsvc 0 remote udp port 23000
gprs nsvc 0 remote ip 192.168.10.53

I don't think both processes can use the same port; move one of them
and configure the other accordingly.

Thanks for suggestion.

Now it looks like this:

/etc/osmo_sgsn.cfg:
...
encapsulation udp local-ip 192.168.10.53
encapsulation udp local-port 23333
...

/etc/openbsc.cfg:
...
gprs nsvc 0 local udp port 23000
gprs nsvc 0 remote udp port 23333
gprs nsvc 0 remote ip 192.168.10.53
...

Still no luck :(

How to obtain as much debug information as possible?

ggsn -d
osmo-sgsn -d GPRS (this causes core-dump unless executed in gdb :)
osmo-nitb -a -d GPRS

The only output I got in this configuration is:

Starting program: /usr/bin/osmo-sgsn
<0011> gprs_ns.c:171 NSVCI=65534 Creating NS-VC
<0011> gprs_ns.c:171 NSVCI=65535 Creating NS-VC
<0011> gprs_ns.c:806 Creating NS-VC for BSS at 192.168.10.55:23000
<0011> gprs_ns.c:679 NSEI=65535 Rx NS RESET (NSVCI=0, cause=O&M intervention)
<0011> gprs_ns.c:538 NSEI=101 Tx NS RESET ACK (NSVCI=101)
<0011> gprs_ns.c:865 NSEI=101 Rx NS UNBLOCK
<0012> gprs_bssgp.c:249 BSSGP BVCI=0 Rx RESET cause=Transmission capacity modified
<0012> gprs_bssgp.c:344 BSSGP BVCI=2 Rx BVC-UNBLOCK
<0012> gprs_bssgp_util.c:103 BSSGP BVCI=2 Tx STATUS, cause=Unknown BVCI
<0012> gprs_bssgp.c:249 BSSGP BVCI=2 Rx RESET cause=O&M intervention
<0012> gprs_bssgp.c:272 Cell 1-1-1-0 CI 0 on BVCI 2
<0012> gprs_bssgp.c:344 BSSGP BVCI=2 Rx BVC-UNBLOCK
<0012> gprs_bssgp.c:747 BSSGP BVCI=2 Rx Flow Control BVC

I don't even understand if phone requested ip address?
Was ip address assigned?
Is ggsn-sgsn-nitb connectivity ok?

It's good that howto briefly describes setup, but what do to when it's not working
out of the box?

Any troubleshooting tips?
Anyone with working gprs setup willing to share configuration files as a point of
reference?

[David Perez]

Hi,

In order to get more information, you may telnet into osmo-sgsn on port
4245 (telnet localhost 4245), and type:
---
logging enable
logging filter all 1
logging level mm debug
---

HTH.

----
David Perez
Founder & Senior Security Analyst
Taddong
david at taddong.com | [phone] | www.taddong.com
----
20sep12 1808

Post by ☎

Post by Peter Stuge

Post by ☎
I have similar setup although in my case it doesn't work at all.

..
..

Post by ☎
ns

..

Post by ☎
encapsulation udp local-ip 192.168.10.53
encapsulation udp local-port 23000

..

Post by ☎
bts 0

..

Post by ☎
gprs nsvc 0 local udp port 23000
gprs nsvc 0 remote udp port 23000
gprs nsvc 0 remote ip 192.168.10.53

I don't think both processes can use the same port; move one of them
and configure the other accordingly.

Thanks for suggestion.
...
encapsulation udp local-ip 192.168.10.53
encapsulation udp local-port 23333
...
...
gprs nsvc 0 local udp port 23000
gprs nsvc 0 remote udp port 23333
gprs nsvc 0 remote ip 192.168.10.53
...
Still no luck :(
How to obtain as much debug information as possible?
ggsn -d
osmo-sgsn -d GPRS (this causes core-dump unless executed in gdb :)
osmo-nitb -a -d GPRS
Starting program: /usr/bin/osmo-sgsn
<0011> gprs_ns.c:171 NSVCI=65534 Creating NS-VC
<0011> gprs_ns.c:171 NSVCI=65535 Creating NS-VC
<0011> gprs_ns.c:806 Creating NS-VC for BSS at 192.168.10.55:23000
<0011> gprs_ns.c:679 NSEI=65535 Rx NS RESET (NSVCI=0, cause=O&M intervention)
<0011> gprs_ns.c:538 NSEI=101 Tx NS RESET ACK (NSVCI=101)
<0011> gprs_ns.c:865 NSEI=101 Rx NS UNBLOCK
<0012> gprs_bssgp.c:249 BSSGP BVCI=0 Rx RESET cause=Transmission capacity modified
<0012> gprs_bssgp.c:344 BSSGP BVCI=2 Rx BVC-UNBLOCK
<0012> gprs_bssgp_util.c:103 BSSGP BVCI=2 Tx STATUS, cause=Unknown BVCI
<0012> gprs_bssgp.c:249 BSSGP BVCI=2 Rx RESET cause=O&M intervention
<0012> gprs_bssgp.c:272 Cell 1-1-1-0 CI 0 on BVCI 2
<0012> gprs_bssgp.c:344 BSSGP BVCI=2 Rx BVC-UNBLOCK
<0012> gprs_bssgp.c:747 BSSGP BVCI=2 Rx Flow Control BVC
I don't even understand if phone requested ip address?
Was ip address assigned?
Is ggsn-sgsn-nitb connectivity ok?
It's good that howto briefly describes setup, but what do to when it's not working
out of the box?
Any troubleshooting tips?
Anyone with working gprs setup willing to share configuration files as a point of
reference?

[☎]

Post by David Perez
Hi,
In order to get more information, you may telnet into osmo-sgsn on port
---
logging enable
logging filter all 1
logging level mm debug
---

Thanks for the hint. Sadly it has no visible effect so it looks like problem is
someplace else.

[Harald Welte]

Hi Max,

Post by ☎
How to obtain as much debug information as possible?

I suggest you study the logging subsystem of libosmocore, which is used
in all of osmo-nitb/osmo-sgsn/osmo-bsc/etc.

Post by ☎
ggsn -d
osmo-sgsn -d GPRS (this causes core-dump unless executed in gdb :)

It should be -d DGPRS, but I suggest you rather configure logging for
stdout or for your given telnet session via VTY.

I suggest to enable debug for NS, BSSGP, LLC, (G)MM

Post by ☎
The only output I got in this configuration is: [...]

This means that the SGSN and the BTS have connected successfully over
Gb/IP.

Post by ☎
I don't even understand if phone requested ip address?

Obtaining an IP address is the _last_ activity, after many other things.
NS/BSSGP is up. Next you should see some GPRS ATTACH / GPRS ROUTING
AREA UPDATE. Only after that, you can get to PDP CONTEXT ACTIVATE and
finally IP traffic.

Post by ☎
Is ggsn-sgsn-nitb connectivity ok?

At the point you're looking at, the GGSN is never used. It is only
involved in PDP context establishment and transport of IP packets.

Post by ☎
It's good that howto briefly describes setup, but what do to when it's
not working out of the box?

enable debugging for the respective protocol levels in osmo-sgsn using
VTY, and look at the Gb and GTP communication between the processes in
wireshark. All protocol layers of both Gb and GTP protocol stacking are
fully supported in mainline wireshark, so all information you can
possibly want is visualized.

Regards,
Harald

[☎]

Post by Harald Welte
It should be -d DGPRS, but I suggest you rather configure logging for
stdout or for your given telnet session via VTY.
I suggest to enable debug for NS, BSSGP, LLC, (G)MM

Sadly with latest libosmocore from git I got segfault in log_parse_category_mask()
with osmo-sgsn --debug=DNS:DGPRS:DNS:DBSSGP:DLLC:DMM:DGMM

Is it a known bug?

Post by Harald Welte

Post by ☎
The only output I got in this configuration is: [...]

This means that the SGSN and the BTS have connected successfully over
Gb/IP.

Post by ☎
I don't even understand if phone requested ip address?

Obtaining an IP address is the _last_ activity, after many other things.
NS/BSSGP is up. Next you should see some GPRS ATTACH / GPRS ROUTING
AREA UPDATE. Only after that, you can get to PDP CONTEXT ACTIVATE and
finally IP traffic.

Post by ☎
Is ggsn-sgsn-nitb connectivity ok?

At the point you're looking at, the GGSN is never used. It is only
involved in PDP context establishment and transport of IP packets.

Post by ☎
It's good that howto briefly describes setup, but what do to when it's
not working out of the box?

enable debugging for the respective protocol levels in osmo-sgsn using
VTY, and look at the Gb and GTP communication between the processes in
wireshark. All protocol layers of both Gb and GTP protocol stacking are
fully supported in mainline wireshark, so all information you can
possibly want is visualized.

Thank you for great hints.
Is it possible to add debug/troubleshooting section to
http://openbsc.osmocom.org/trac/wiki/OpenBSC_GPRS ?
I'm pretty sure I'm not the only one who'd find it useful.

[Peter Stuge]

Post by ☎

Post by Harald Welte
It should be -d DGPRS, but I suggest you rather configure logging for
stdout or for your given telnet session via VTY.
I suggest to enable debug for NS, BSSGP, LLC, (G)MM

Sadly with latest libosmocore from git I got segfault in log_parse_category_mask()
with osmo-sgsn --debug=DNS:DGPRS:DNS:DBSSGP:DLLC:DMM:DGMM

Please provide a backtrace.

Post by ☎

Post by Harald Welte
All protocol layers of both Gb and GTP protocol stacking are
fully supported in mainline wireshark, so all information you can
possibly want is visualized.

Thank you for great hints.
Is it possible to add debug/troubleshooting section to
http://openbsc.osmocom.org/trac/wiki/OpenBSC_GPRS ?
I'm pretty sure I'm not the only one who'd find it useful.

You mean like so:

How to troubleshoot ethernet- and IP-based GSM network components
Use a packet sniffer such as wireshark.

Seriously?


//Peter

[Nico Golde]

Hi,

Post by ☎

Post by Harald Welte
It should be -d DGPRS, but I suggest you rather configure logging for
stdout or for your given telnet session via VTY.
I suggest to enable debug for NS, BSSGP, LLC, (G)MM

Sadly with latest libosmocore from git I got segfault in log_parse_category_mask()
with osmo-sgsn --debug=DNS:DGPRS:DNS:DBSSGP:DLLC:DMM:DGMM

This seems to be caused by a bug in libosmocore. I'm
actually surprised that nobody encountered this crash
before. The reason is that log_parse_category_mask() checks
for osmo_log_info->cat[i].name being NULL after passing the
pointer to strlen.

Attached is a patch to fix this.

Cheers
Nico
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-logging.c-log_parse_category_mask-skip-log-category-.patch
Type: text/x-diff
Size: 1479 bytes
Desc: not available
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20120921/d5e1e26d/attachment.patch>

[☎]

And this one fix another segfault uncovered by previous patch :)
Seriously, what's the magic command-line option which enables logging without causing
segfaults?
--
best regards,
Max, http://fairwaves.ru
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-fix-segfault-during-show-running-config.patch
Type: text/x-patch
Size: 909 bytes
Desc: not available
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20120921/63cec98f/attachment.bin>

[Holger Hans Peter Freyther]

Post by Nico Golde
Attached is a patch to fix this.

thanks! I have applied it and moved the size_t into the scope
where the variable is used. I have moved the logging test from
the OpenBSC repository to libosmocore and modified the testcase
to cover this crash.

cheers
holger

[Harald Welte]

Hi Max,

Post by ☎

Post by Harald Welte
I suggest to enable debug for NS, BSSGP, LLC, (G)MM

Sadly with latest libosmocore from git I got segfault in log_parse_category_mask()
with osmo-sgsn --debug=DNS:DGPRS:DNS:DBSSGP:DLLC:DMM:DGMM
Is it a known bug?

not that I'm aware of, sorry. Any patches/fixes are appreciated. I
guess the command-line baesed logging specification was useful early on,
when there were 3 or for subsystems. Today it is nothing but an old
relict, and most people probably use the more comfortable VTY based
configuration.

Post by ☎
Is it possible to add debug/troubleshooting section to
http://openbsc.osmocom.org/trac/wiki/OpenBSC_GPRS ?
I'm pretty sure I'm not the only one who'd find it useful.

Sure it is possible and appreciated!

If you don't have a wiki account, please simply ask for one and you can
happily add all the information that you are missing.

[☎]

Post by John Otten
Hi Max,

Post by ☎
How to obtain as much debug information as possible?

I suggest you study the logging subsystem of libosmocore, which is used
in all of osmo-nitb/osmo-sgsn/osmo-bsc/etc.

Is there more comprehensive documentation for osmo-sgsn than
http://openbsc.osmocom.org/trac/wiki/osmo-sgsn_VTY ?
Something similar to
http://openbsc.osmocom.org/trac/wiki/osmo-nitb_VTY would be very helpful.

[Nico Golde]

Hi,

Post by ☎

Post by Harald Welte

Post by ☎
How to obtain as much debug information as possible?

I suggest you study the logging subsystem of libosmocore, which is used
in all of osmo-nitb/osmo-sgsn/osmo-bsc/etc.

Is there more comprehensive documentation for osmo-sgsn than
http://openbsc.osmocom.org/trac/wiki/osmo-sgsn_VTY ?
Something similar to
http://openbsc.osmocom.org/trac/wiki/osmo-nitb_VTY would be very helpful.

Unfortunately not. The best hint I can give at this point is
a grep on sgsn_vty.c ;)
DEFUN(cfg_sgsn, cfg_sgsn_cmd,
"sgsn",
SGSN_STR)
--
DEFUN(cfg_sgsn_bind_addr, cfg_sgsn_bind_addr_cmd,
"gtp local-ip A.B.C.D",
"GTP Parameters\n"
"Set the IP address for the local GTP bind\n"
"IPv4 Address\n")
--
DEFUN(cfg_ggsn_remote_ip, cfg_ggsn_remote_ip_cmd,
"ggsn <0-255> remote-ip A.B.C.D",
GGSN_STR "GGSN Number\n" IP_STR "IPv4 Address\n")
--
DEFUN(cfg_ggsn_remote_port, cfg_ggsn_remote_port_cmd,
"ggsn <0-255> remote-port <0-65535>",
"")
--
DEFUN(cfg_ggsn_gtp_version, cfg_ggsn_gtp_version_cmd,
"ggsn <0-255> gtp-version (0|1)",
GGSN_STR "GGSN Number\n" "GTP Version\n"
"Version 0\n" "Version 1\n")
--
DEFUN(cfg_apn_ggsn, cfg_apn_ggsn_cmd,
"apn APNAME ggsn <0-255>",
"")
--
DEFUN(show_sgsn, show_sgsn_cmd, "show sgsn",
SHOW_STR "Display information about the SGSN")
--
DEFUN(show_mmctx_tlli, show_mmctx_tlli_cmd,
"show mm-context tlli HEX [pdp]",
SHOW_STR MMCTX_STR "Identify by TLLI\n" "TLLI\n" INCLUDE_PDP_STR)
--
DEFUN(swow_mmctx_imsi, show_mmctx_imsi_cmd,
"show mm-context imsi IMSI [pdp]",
SHOW_STR MMCTX_STR "Identify by IMSI\n" "IMSI of the MM Context\n"
INCLUDE_PDP_STR)
--
DEFUN(swow_mmctx_all, show_mmctx_all_cmd,
"show mm-context all [pdp]",
SHOW_STR MMCTX_STR "All MM Contexts\n" INCLUDE_PDP_STR)
--
DEFUN(show_ggsn, show_ggsn_cmd,
"show ggsn",
"")
--
DEFUN(show_pdpctx_all, show_pdpctx_all_cmd,
"show pdp-context all",
SHOW_STR "Display information on PDP Context\n" "Show everything\n")

Cheers
Nico

[Holger Hans Peter Freyther]

Post by ☎
Is there more comprehensive documentation for osmo-sgsn than
http://openbsc.osmocom.org/trac/wiki/osmo-sgsn_VTY ?
Something similar to
http://openbsc.osmocom.org/trac/wiki/osmo-nitb_VTY would be very helpful.

Hi,

I have created libosmocore support to dump the VTY commands into a xml
file (and wrote a schema). It is up to users to pick that up and write
a manual. Using the "contrib/dump_all_docs.py" is the easiest way to
dump the VTY commands into an XML file.


holger

[☎]

Post by Harald Welte
Obtaining an IP address is the _last_ activity, after many other things.
NS/BSSGP is up. Next you should see some GPRS ATTACH / GPRS ROUTING
AREA UPDATE. Only after that, you can get to PDP CONTEXT ACTIVATE and
finally IP traffic.

Despite my efforts to make use of logging system I do not see anything like GPRS
ATTACH / GPRS ROUTING AREA UPDATE.

So either I'm not running enough logging or failure is lurking somewhere in previous
steps.
Hence the questions:

- who exactly will report "GPRS ATTACH / GPRS ROUTING AREA UPDATE" messages?
- how do I check that NS/BSSGP is up?

[Arturo Rivas]

Hi list!

I have a doubts about configuration. First of all, the interface tun0. Have
they to be in the same net that mobile phones? I have configured dynip with
subnet 192.168.254.0/24 but tun0 is in subnet 192.168.0.1. In addiction
'ggsn' shows 'net: 192.168.0.0/24' in its log.

'osmo-nitb' log shows 'Failure Event Report Type=communication failure
Severity=critical failure Probable cause= 03 03 11 Additional Text=' but
voice configuration works well.

Thank you very much!

2012/9/25 ? <Max.Suraev at fairwaves.ru>

Post by ☎

Post by Harald Welte
Obtaining an IP address is the _last_ activity, after many other things.
NS/BSSGP is up. Next you should see some GPRS ATTACH / GPRS ROUTING
AREA UPDATE. Only after that, you can get to PDP CONTEXT ACTIVATE and
finally IP traffic.

Despite my efforts to make use of logging system I do not see anything like GPRS
ATTACH / GPRS ROUTING AREA UPDATE.
So either I'm not running enough logging or failure is lurking somewhere in previous
steps.
- who exactly will report "GPRS ATTACH / GPRS ROUTING AREA UPDATE" messages?
- how do I check that NS/BSSGP is up?
--
best regards,
Max, http://fairwaves.ru

[John Otten]

Post by Peter Stuge

Post by ☎
I have similar setup although in my case it doesn't work at all.

..
..

Post by ☎
ns

..

Post by ☎
encapsulation udp local-ip 192.168.10.53
encapsulation udp local-port 23000

..

Post by ☎
bts 0

..

Post by ☎
gprs nsvc 0 local udp port 23000
gprs nsvc 0 remote udp port 23000
gprs nsvc 0 remote ip 192.168.10.53

I don't think both processes can use the same port; move one of them
and configure the other accordingly.
//Peter

Hmm... They are both set to the same port in my openbsc.cfg (which appears
to be working). The main GPRS page (
http://openbsc.osmocom.org/trac/wiki/OpenBSC_GPRS) has them both the same
when discussing the OpenBSC configuration. Should they be different? Could
my version be working because I have aliased some IP addresses on my system?

I don't want to modify a working configuration to find out, but if making
them different is a good plan, I would want to explore that option.

Thanks,
John
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20120924/ec0f70ac/attachment.html>

[Peter Stuge]

Post by John Otten

Post by Peter Stuge

Post by ☎
encapsulation udp local-ip 192.168.10.53
encapsulation udp local-port 23000
gprs nsvc 0 local udp port 23000
gprs nsvc 0 remote udp port 23000
gprs nsvc 0 remote ip 192.168.10.53

I don't think both processes can use the same port; move one of them
and configure the other accordingly.

Hmm... They are both set to the same port in my openbsc.cfg

Connection tuples consist of IP address and port. I should perhaps
have written "the same IP and port" to be clear enough.


//Peter