Hi All,
Finally I got the setup up and running using Openggsn 0.84, seems like there is a bug in version 0.91 which was causing the earlier reported issue.
I've sgsnemu sending packets to Cisco 7200 gprs code emulated on dynmips now which inturn is configured to authenticate via FreeRadius. Everything works now, i'm able to get sgnsemu send packets with username password for the apn to get it authenticated via AAA.
My next challenge are:
1. To get sgsnemu read configuration file. Can anyone help me with a sample to do this, would like to see a configuration file where i can have multiple packets with different apn, qos ,imsi being sent out with having to manually type via cli. At this point , i see that there is a limitation of binding only one sgsnemu instance to local interface, is there a way to have multiple instances running?
2. Also would want to setup charging gateway if possible, i couldnt find a live download link to open charging gateway .
Would greatly appreciate any inputs on the same.
Thank you,
Anish
________________________________
From: anish achenkunju <anish_achenkunju(a)yahoo.com>
To: "openbsc(a)lists.osmocom.org" <openbsc(a)lists.osmocom.org>
Sent: Wednesday, September 21, 2011 4:57 PM
Subject: Fw: Mandatory info element invalid
Dear All,
I'm using sgsnemu of openggsn 0.91 to send traffic to Cisco 7200 GGSN code running on dynamips.
[root@localhost ~]# sgsnemu -l 3.3.3.3 -r 3.3.3.1
Using default DNS server
Local IP address is: 3.3.3.3 (3.3.3.3)
Remote IP address is: 3.3.3.1 (3.3.3.1)
IMSI is: 240010123456789 (0xf987654321010042)
Using NSAPI: 0
Using GTP version: 1
Using APN: internet
Using selection mode: 1
Using MSISDN: 46702123456
Initialising GTP library
openggsn[24632]: GTP: gtp_newgsn() started
Done initialising GTP library
Sending off echo request
Setting up PDP context #0
Waiting for response from ggsn........
I'm getting the following error on GGSN:
*Sep 19 20:45:35.487: %GTP-2-PDPACTIVATIONFAIL: GTP PDP activation/update failed, GSN: 0.0.0.0, TID: 00, Reason: Mandatory info element invalid
*Sep 19 20:45:35.491: %GTP-0-GTPv1PACKETPARSINGERROR: GSN: 3.3.3.1, TEID: 1, APN: NULL, Reason: Mandatory ie incorrect Mandatory info element invalid
And the following cause value on sgsnemu:
Received echo response
Received create PDP context response. Cause value: 201
Seems like the GSN adddr 0.0.0.0 ,TID: 00 generated by sgsnemu are invalid. Looking forward for a workaround fix to help me move forward, any help is greatly appreciated.
Thank you in advance,
Anish
Hi all,
Does anyone know how should we fill PDCH when no downlink transmission
is present? I can't find any mention about this in the standard. If
someone have traces from existing networks, I would very much
appreciate this.
Some background - we've recently started working on GPRS
implementation for OpenBTS, and we're stuck at the very beginning -
mobile sends RACH, but doesn't respond to our Packet Channel Immediate
Assignment. After spending quite some time tweaking Immediate
Assignment message, our conclusion is that mobile may want to see some
"filler" date at the idle PDCH and we don't do this yet.
I know that OpenBSC has GPRS working, so I hope someone here may help us.
--
Regards,
Alexander Chemeris.
Hi!
I've finally taken some time to re-write the gen_ladder tool in order to
avoid the stupid 'bent arrow' problem that was caused by using 'dot'.
I'm now drawing bitmap images directly from Perl using 'GD', rendering
PNG images. Support for printing a title and automati scaling of the
font size has been added.
However, this new version doesn't yet support the bi-directional arrows
and dashed lines. Patches are welcome ;)
I tried to use GD::SVG at some earlier version, and it seemed to work
too, i.e. we will have an easy path to still generate vector graphics,
if required.
There are also way more *.lad files in the repository now for various
protocol transaction, including supplementary services, roaming calls,
etc.
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)
Hello list,
I would like to be able to send a TRAP over the control interface
for certain signals. For this it would be nice if the signals have a
text representation of their name as is the case with the (rate)
counters.
I want to propose a different API where you register the signals (and
maybe even the subsystems) and provide a name for them.
The function register_signal would then return the numeric
representation of the signal. The performance hit would only be during
registering, not during dispatch.
The callback function would still be called with the numeric
representation in order to avoid resolving the name to the number every
time.
Inside the callback you would have to resolve the name of the signal to
the actual number, but using static variables you'll only have to do it
the first time:
void signal_cb(unsigned int subsysnum, unsigned int signalnum,
void *signal_data, void *handler_data)
{
static unsigned int foosig, barsig;
if (foosig == 0) {
foosig = osmo_signal_get_by_name("foo");
}
if (barsig == 0) {
barsig = osmo_signal_get_by_name("bar");
}
switch (signalnum) {
case foosig:
do_stuff;
break;
case barsig:
do_other_stuff;
break;
}
}
The functions that dispatch the signals would have to do something
similar.
Ideas? Is this too complex?
Do we gain enough from registering signals at runtime or should we
rather keep the enums and add a value_string for the name/description?
Regards,
Daniel Willmann
Hi,
I am looking for some help debugging a nanoBTS setup with OpenBSC/SGSN/GGSN as I am struggling getting GPRS to work.
I am seeing the following error in the SGSN output:
debian4:/opt/openbsc/openbsc/src/gprs# ./osmo-sgsn -c osmo_sgsn.cfg
<0011> gprs_ns.c:151 NSVCI=65534 Creating NS-VC
<0011> gprs_ns.c:151 NSVCI=65535 Creating NS-VC
<0011> gprs_ns.c:738 Creating NS-VC for BSS at 192.168.60.200:23000
<0011> gprs_ns.c:620 NSEI=65535 Rx NS RESET (NSVCI=0, cause=O&M intervention)
<0011> gprs_ns.c:488 NSEI=101 Tx NS RESET ACK (NSVCI=101)
<0011> gprs_ns.c:797 NSEI=101 Rx NS UNBLOCK
<0012> gprs_bssgp.c:246 BSSGP BVCI=0 Rx RESET cause=Transmission capacity modified
<0012> gprs_bssgp.c:246 BSSGP BVCI=2 Rx RESET cause=Transmission capacity modified
<0012> gprs_bssgp.c:269 Cell 1-1-1-0 CI 0 on BVCI 2
<0012> gprs_bssgp.c:322 BSSGP BVCI=2 Rx BVC-UNBLOCK
<0012> gprs_bssgp.c:322 BSSGP BVCI=2 Rx BVC-UNBLOCK
<0012> gprs_bssgp.c:462 BSSGP BVCI=2 Rx Flow Control BVC
<0012> gprs_bssgp.c:346 BSSGP TLLI=0x7f60277f Rx UPLINK-UNITDATA
<0013> gprs_llc.c:428 LLC SAPI=1 C FCS=0x447ea5CMD=UI DATA
<0013> gprs_llc.c:700 LLC RX: unknown TLLI 0x7f60277f, creating LLME on the fly
I came across this thread http://comments.gmane.org/gmane.comp.mobile.openbsc.general/687 which talks about a similar error but hasn't helped resolve the problem.
I have a second hand nanoBTS unit, are there any configuration settings I need to change on the unit itself to make it work with the example configs from OpenBSC?
Any help/advice much appreciated
Thanks
Jon
_______________________
Jon Southall
Technical Operations Manager
E: jon.southall(a)boku.com<mailto:jon.southall@boku.com>
M: +14153427958
[cid:image001.png@01CC82AD.3D217E20]
_______________________
Hi,
my goal is to generate our wiki pages (or docbook, or...) for the config
formats from the VTY commands directly. We might also want/need to add
additional docs inside the command.
My current hack is this:
diff --git a/src/vty/command.c b/src/vty/command.c
index ab1eaca..bcf72d0 100644
--- a/src/vty/command.c
+++ b/src/vty/command.c
@@ -426,6 +426,20 @@ void install_element(enum node_type ntype, struct
cmd_element *cmd)
cmd->strvec = cmd_make_descvec(cmd->string, cmd->doc);
cmd->cmdsize = cmd_cmdsize(cmd->strvec);
+
+ printf("NODE: %d\n", ntype);
+
+ int j;
+ for (j = 0; j < vector_count(cmd->strvec); ++j) {
+ vector descvec = vector_slot(cmd->strvec, j);
+ int i;
+ for (i = 0; i < vector_active(descvec); i++) {
+ struct desc *desc = vector_slot(descvec, i);
+ if (desc == NULL)
+ continue;
+ printf(" %s %s\n", desc->cmd, desc->str);
+ }
+ }
Output:
NODE: 1
show Show running system information
version Displays program version
NODE: 1
list Print command list
NODE: 1
exit Exit current mode and down to previous mode
NODE: 1
help Description of the interactive help system
NODE: 1
enable Turn on privileged mode command
NODE: 1
terminal Set terminal line parameters
length Set number of lines on a screen
<0-512> Number of lines on screen (0 for no pausing)
NODE: 1
Problems:
The goal would to have a VTY command to introspect all vty commands, one of
the problems is to do it recursively. E.g. we have commands that move to
another node but this is via code and can not be seen from the outside. The
other problem is we can not get the name from the node number...
PS: Can we move VTY to AGPL code, bit by bit? Remove one public function and
reimplement to make OpenBSC work again? E.g. the vector in vectors is a bit
crazy...
