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
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 -- best regards, Max, http://fairwaves.ru
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 On Wed, Sep 19, 2012 at 5:14 AM, ☎ <Max.Suraev@fairwaves.ru> wrote:
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
-- best regards, Max, http://fairwaves.ru
☎ wrote:
I have similar setup although in my case it doesn't work at all. .. /etc/osmo_sgsn.cfg: .. ns .. encapsulation udp local-ip 192.168.10.53 encapsulation udp local-port 23000
/etc/openbsc.cfg: .. bts 0 .. 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
19.09.2012 17:48, Peter Stuge пишет:
☎ wrote:
I have similar setup although in my case it doesn't work at all. .. /etc/osmo_sgsn.cfg: .. ns .. encapsulation udp local-ip 192.168.10.53 encapsulation udp local-port 23000
/etc/openbsc.cfg: .. bts 0 .. 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? -- best regards, Max, http://fairwaves.ru
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@taddong.com | +34-699982432 | www.taddong.com ---- 20sep12 1808 On 20-Sep-12 18:00, ☎ wrote:
19.09.2012 17:48, Peter Stuge пишет:
☎ wrote:
I have similar setup although in my case it doesn't work at all. .. /etc/osmo_sgsn.cfg: .. ns .. encapsulation udp local-ip 192.168.10.53 encapsulation udp local-port 23000
/etc/openbsc.cfg: .. bts 0 .. 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?
20.09.2012 18:09, 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 --- Thanks for the hint. Sadly it has no visible effect so it looks like problem is someplace else.
-- best regards, Max, http://fairwaves.ru
Hi Max, On Thu, Sep 20, 2012 at 06:00:01PM +0200, ☎ wrote:
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.
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
The only output I got in this configuration is: [...]
This means that the SGSN and the BTS have connected successfully over Gb/IP.
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.
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.
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 -- - Harald Welte <laforge@gnumonks.org> http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)
21.09.2012 09:24, 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?
The only output I got in this configuration is: [...] This means that the SGSN and the BTS have connected successfully over Gb/IP.
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.
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.
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. -- best regards, Max, http://fairwaves.ru
☎ wrote:
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.
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
Hi, * ☎ <Max.Suraev@fairwaves.ru> [2012-09-21 15:12]:
21.09.2012 09:24, 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
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
On Fri, Sep 21, 2012 at 05:56:07PM +0200, Nico Golde wrote:
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
Hi Max, On Fri, Sep 21, 2012 at 11:36:37AM +0200, ☎ wrote:
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.
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. -- - Harald Welte <laforge@gnumonks.org> http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)
21.09.2012 09:24, Harald Welte пишет:
Hi Max,
On Thu, Sep 20, 2012 at 06:00:01PM +0200, ☎ wrote:
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. -- best regards, Max, http://fairwaves.ru
Hi, * ☎ <Max.Suraev@fairwaves.ru> [2012-09-24 17:38]:
21.09.2012 09:24, Harald Welte пишет:
On Thu, Sep 20, 2012 at 06:00:01PM +0200, ☎ wrote:
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
On Mon, Sep 24, 2012 at 05:18:07PM +0200, ☎ wrote:
21.09.2012 09:24, Harald Welte пишет:
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
21.09.2012 09:24, 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? -- best regards, Max, http://fairwaves.ru
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@fairwaves.ru>
21.09.2012 09:24, 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?
-- best regards, Max, http://fairwaves.ru
-- Best regards, Arturo Rivas.
On Wed, Sep 19, 2012 at 11:48 AM, Peter Stuge <peter@stuge.se> wrote:
☎ wrote:
I have similar setup although in my case it doesn't work at all. .. /etc/osmo_sgsn.cfg: .. ns .. encapsulation udp local-ip 192.168.10.53 encapsulation udp local-port 23000
/etc/openbsc.cfg: .. bts 0 .. 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
John Otten wrote:
/etc/osmo_sgsn.cfg: encapsulation udp local-ip 192.168.10.53 encapsulation udp local-port 23000
/etc/openbsc.cfg: 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
participants (8)
-
Arturo Rivas -
David Perez -
Harald Welte -
Holger Hans Peter Freyther -
John Otten -
Nico Golde -
Peter Stuge -
☎