Hi!
Collin Mulliner, Tobias Engel and myself have been meeting yesterday to
discuss a generic application interface for OpenBSC.
They are both doing security analysis and want to achieve a clean way
how an external application can get access to a more or less transparent
communication channel to the phone.
The purpose of this is to be able to send intentionally malformed
packets to the mobile phone GSM stack at various different levels within
the stack.
As of now, they have both hacked some custom code into openbsc that gets
them half way where they want to be - but not quite all the way.
The requirements can be summarized as follows:
1) Ability to establish a SDCCH or TCH channel by paging the phone
As of now, the 'silent call' feature from the VTY already does this.
2) Ability to send arbitrary layer3 protocol messages to the phone
Adding this is relatively easy (use rsl_sendmsg on the lchan from the
silent call)
3) Ability to receive responses from the phone, as well as error
conditions such as 'readio link failure'. We don't have a solution
for this yet, and we also have no clean way to identify what might
be a response from the phone to the external app, and what might
be a message from the phone to the normal network code in OpenBSC
4) Ability to selectively disable partial protocol handling in
OpenBSC. Let's say you want to play with the mobile phone call
control implementation. In this case, you want to make sure all CC
related messages go from/to the external program and not from the
regular OpenBSC network code.
So what I've been thinking of as a solution to the problem:
* store a bypass_flags bitmask related to the subscriber structure,
where we indicate values such as BYPASS_RR, BYPASS_MM, BYPASS_CC,
BYPASS_SAPI3.
* if we process an incoming message from the MS in gsm0408_rcvmsg(),
we check if a bypass flag matching the message is found. If yes,
forward the message to the external program
* if we want to send a message from our own protocol stack to the MS,
we check if a bypass flag matching the message is found. If yes,
we drop the message that we were about to send.
* any messages received from the application will be forwarded to the MS
The application interface protocol will likely have a close resemblance
to RSL RLL. We need to exchange the following primitives with the
application, like:
* ESTABLISH REQUEST -- app requests a channel be established to MS (by IMSI)
* ESTABLISH CONFIRM -- network confirms a channel has been established
* ESTABLISH INDICATION -- network tells app connection was made by MS
* [UNIT] DATA REQUEST -- app requests data to be sent to MS
* [UNIT] DATA INDICATION -- network indicates data was received from MS
* ERROR INDICATION -- network tells app something went wrong
* RELEASE REQUEST -- app asks network to release channel
* RELEASE CONFIRM -- net tells app that channel was released (as rqd)
* RELEASE INDICATION -- net tells app that channel was released (by MS)
The channel_number of RSL (indicating on-air timeslot) doesn't make much
sense in this context, of course.
The link_identifier on the other hand is great as it allows the app to
indicate SDCCH/FACCH or SACCH as well as the SAPI.
The actual RSL-like protocol would be encapsulated by UDP and available
on a socket of the MSC.
What do you think?
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)
Hi all!
This subject came to my attention again recently: Why not relicense
OpenBSC under AGPLv3?
Right now we are licensing under GPLv2+ (v2 or any later version). However,
if an operator was to make lots of private modifications and then operate
it on his own network, there would be no distribution and thus no need
for him to release his modified versions of the source code.
This may sound a bit strange to those who have been with the project
since its early days. But we are reaching production quality now, and
we already have the first number of production deployments of the software.
Companies like Netzing and On-waves have been FOSS-friendly and funding
parts of our development effort. They have no issues with the result being
Free Software again. However, there are definitely other companies out
there who are less fond of sharing...
So thus my idea is to put OpenBSC under AGPLv3. This way whoever uses
OpenBSC _in modified form_ to operate a communications network will
have to provide the source code to that modified form on a network
server at no charge.
The only controversial question to me is "your modified version must
prominently offer all users interacting with it remotely through a computer
network (if your version supports such interaction) an opportunity to receive
the Corresponding Source".
1) does a gsm network count as computer network? i'd say yes.
2) is using a gsm network 'interacting with it remotely'? I'd also say yes
3) what does 'prominently offer' mean in the context of GSM? We don't want
the operator to spam their users with advertisement SMS just to know
that they can get the soruce code, after all.
Notwithstanding those open questions, such a network operator would always
have the option of simply sending back his changes for integration in the
official project - and thus he would no longer use a modified version which
then means there is no need for the prominent notice / download at all.
We can make this very clear in the project documentation, putting further
encouragement
The actual relicensing should be less problematic than I thought, since AGPLv3
is compatible with GPLv3.
So I could re-license all parts that I own copyright on (which should be
the majority of the code base anyway) under AGPLv3, while the former GPLv2+
components (like VTY code from zebra, or contributions by other people)
then become GPLv3-or-later.
Of course I would want to encourage all developers/contributors to also
follow the re-licensing. Particularly Holger Freyther, Dieter Spaar, Andreas
Eversberg, Jan Luebbe, Sylvain Munaut, Daniel Willmann, Stefan Schmidt.
So let's start with a poll:
a) Do you think re-licensing to AGPLv3 is a good idea?
b) If you have contributed, would you re-license your code under AGPLv3?
If we have some kind of concesus in the community, I would approach
On-waves whether they would want to do the same for their share of the
copyright. As their "modifications" are all part of OpenBSC git repository,
they would not be subject to any different conditions than before.
Thanks in advance for your feedback,
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,
second try to add support to bs11_config for bport0/1 configuration. This
time with enum abis_bs11_line_cfg.
It seems sometimes creating bport1 fails, even LMT shows create obj
greyed out. Don't know why yet.
Regards,
Daniel Willmann
Daniel Willmann (1):
Add {create,delete}-bport1 and bport0-{star,multidrop} to bs11-config
openbsc/include/openbsc/abis_nm.h | 10 +++++++++-
openbsc/src/abis_nm.c | 31 +++++++++++++++++++++++++++++--
openbsc/src/bs11_config.c | 26 ++++++++++++++++++++++++++
3 files changed, 64 insertions(+), 3 deletions(-)
hello
my name is thomas and i study communication engineering at tfh berlin. i
write my bachelor this semester. the task is to program a handover
funktion between 2 bs11, openbsc runs on a pc with e1 interface. but
there are major problems. i can't login with my 2 handys that i use for
that. nokia 3310c and 6650. the network is found, but the login fails,
with both handys. it worked only one time, with the 6650. i backuped the
hlr-file. i assume it's this file that makes problems. when i delete the
hlr, it is new created, and none of my handys can login. when i restore
this special hlr, the 6650 connect without problems, but only this one.
is there a tool to edit hlr.sqlite3, windows-based if possible?
where are the protocoll files stored, for error search, or must i make a
screenshot ?
thanx
thomas
p.s.: answers in german prefered :-)
--
Wer Rechtschreibfehler findet, darf sie behalten
> This sounds wrong. What does 'which pkg-config' return?
> Did you really set PKG_CONFIG, and is the pkg-config binary not in
your
> PATH?
root@fuckup ~ # which pkg-config
/usr/bin/pkg-config
i think i had set PKG_CONFIG_PATH, since i have no pkg-config under
/usr/local/bin/.
>Yes, you have said that in the previous mail. I wonder _why_ you need
to
>set it and if our documentation is not accurate. Have you really set
>PKG_CONFIG? Does it mean that you do not have pkg-config available in
>your PATH?
my pkg-config is under /usr/lib/pkgconfig (gentoo). but libosmocore and
others are installed under /usr/local/lib/pkgconfig.
hi holger,
it works now. i set PKG_CONFIG and everything compiles. also the linux-call-router now compiles with opensbsc, after fixing some api issues.
regards,
andreas
-----Ursprüngliche Nachricht-----
Von: openbsc-bounces(a)lists.gnumonks.org [mailto:openbsc-bounces@lists.gnumonks.org] Im Auftrag von Holger Freyther
Gesendet: Montag, 31. Mai 2010 05:25
An: openbsc(a)lists.gnumonks.org
Betreff: Re: linking problems
On 05/28/2010 07:40 PM, Andreas.Eversberg wrote:
> with setting PKG_CONFIG it works. it was a layer-8 problem. still i don't understand why the linker finds symbols in "lib.so" but not in "lib.a"
Hi Andreas,
I looked into our build howto and I try to understand how it failed for
you. Have you passed a --prefix to the build of libosmocore?
regards
holger
with setting PKG_CONFIG it works. it was a layer-8 problem. still i don't understand why the linker finds symbols in "lib.so" but not in "lib.a".
-----Ursprüngliche Nachricht-----
Von: openbsc-bounces(a)lists.gnumonks.org [mailto:openbsc-bounces@lists.gnumonks.org] Im Auftrag von Holger Hans Peter Freyther
Gesendet: Freitag, 28. Mai 2010 10:45
An: openbsc(a)lists.gnumonks.org
Betreff: Re: linking problems
On 05/28/2010 04:02 PM, Andreas.Eversberg wrote:
> hi again,
>
> libosmocore.a has a reference to 'log_init', but the linker will not
> find it somehow. any idea?
Yes, you attempt static linking... which appears to not work. Build the
libosmocore as DSO and try linking again.
Hello,
OnWaves would like to get/set the status from OpenBSC via SNMP. I would
like to kick off the discussion about how we can best achieve that
while keeping everyone happy. :-)
There are two possibilities that have been discussed so far:
* Implement a subagent in OpenBSC. With this method OpenBSC would
directly connect to snmpd through the agentx protocol.
* Write a proxy that relays the snmp requests to OpenBSC. The proxy
would have to implement the snmp interface and talk to OpenBSC through
some protocol.
There are upsides and downsides with both approaches. One arguably
doesn't want to have the net-snmp library linked to OpenBSC (though I'm
not sure what the exact reasons are, I just heard it from different
people). On the other hand designing a new protocol to speak between
proxy and OpenBSC poses problems of its own. Furthermore, if you write
the proxy in C you'll be using net-snmp anyway.
You could use python to implement the proxy, but my local python expert
tells me that the python snmp library is far from nice to use.
Please share your thoughts, ideas, etc.
Regards,
Daniel Willmann
Hi,
I have two BS-11 here, which both show the same strange problem:
PHASE: 2 Load MBCCU MBCCU0: No Load MBCCU1: No Load Abis-link: Down
PHASE: 2 Load MBCCU MBCCU0: Load BTSCAC MBCCU1: No Load Abis-link: Down
PHASE: 2 Load MBCCU MBCCU0: Load BTSCAC MBCCU1: Load BTSCAC Abis-link: Down
PHASE: 2 Load MBCCU MBCCU0: No Load MBCCU1: Load BTSCAC Abis-link: Down
PHASE: 2 Load MBCCU MBCCU0: No Load MBCCU1: Load BTSCAC Abis-link: Down
PHASE: 2 Load MBCCU MBCCU0: No Load MBCCU1: Load BTSDRX Abis-link: Down
PHASE: 2 Load MBCCU MBCCU0: No Load MBCCU1: Load BTSBBX Abis-link: Down
PHASE: 2 Load MBCCU MBCCU0: No Load MBCCU1: Load BTSARC Abis-link: Down
PHASE: 2 Load MBCCU MBCCU0: No Load MBCCU1: Load Abis-link: Down
I.e. MBCCU0 aborts the software load process during BTSCAC phase, while MBCCU1
continues like usual.
Has anybody else seen this yet? I've already re-installed the firmware without
any success. If they are really broken, has anyone yet tried to switch some of the internal components? A BTS that only has TRX0 is still useful.. but
one without TRX0 but TRX1 is pretty useless :/
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)
hi holger,
it worked. thanx for your help. but now i got stuck here:
./configure in openbsc:
checking for LIBOSMOCORE... configure: error: Package requirements (libosmocore >= 0.1.6) were not met:
No package 'libosmocore' found
Consider adjusting the PKG_CONFIG_PATH environment variable if you
installed software in a non-standard prefix.
Alternatively, you may set the environment variables LIBOSMOCORE_CFLAGS
and LIBOSMOCORE_LIBS to avoid the need to call pkg-config.
See the pkg-config man page for more details.
"pkg-config --list-all" does not show libosmocore. my directory: "dir /usr/local/lib/pkgconfig/" shows libosmocore.pc and spandsp.pc, nothing else. it seems that my version of pkg-config stores it somewhere else. my version is 0.23.
with that it works, but it should be easier, i think:
LIBOSMOCORE_LIBS=/usr/local/lib/ LIBOSMOCORE_CFLAGS=-I../libosmocore/include/ LIBOSMOVTY_LIBS=/usr/local/lib/ LIBOSMOVTY_CFLAGS=-I../libosmocore/include/ ./configure
now i get these errors when compiling openbsc:
gsm_04_11.c:343:16: error: invalid suffix "b111" on integer constant
...
the source sais "switch (fi & 0b111) {". i never saw binary values in C. (gcc version 4.1.2)
andreas
-----Ursprüngliche Nachricht-----
Von: openbsc-bounces(a)lists.gnumonks.org [mailto:openbsc-bounces@lists.gnumonks.org] Im Auftrag von Holger Hans Peter Freyther
Gesendet: Dienstag, 25. Mai 2010 16:06
An: openbsc(a)lists.gnumonks.org
Betreff: Re: AW: (problems compiling openbsc)
On 05/25/2010 09:49 PM, Andreas.Eversberg wrote:
> rm libtool
> autoreconf -f
--install
?
hi again,
here is the current compiler output. compile works, but linking fails:
gcc -Wall -I../../libosmocore/include/ -I../../libosmocore/include/ -g
-O2 ../../libosmocore/src/.libs/libosmocore.a -o bsc_hack bsc_hack.o
bsc_init.o
bsc_vty.o vty_interface_layer3.o libmsc.a libbsc.a libvty.a libmsc.a
-ldl -ldbi ../../libosmocore/src/vty/.libs/libosmovty.a -lcrypt
bsc_hack.o: In function `main':
/files/projects/isdn/openbsc/openbsc/src/bsc_hack.c:215: undefined
reference to `log_init'
/files/projects/isdn/openbsc/openbsc/src/bsc_hack.c:216: undefined
reference to `talloc_named_const'
/files/projects/isdn/openbsc/openbsc/src/bsc_hack.c:221: undefined
reference to `log_target_create_stderr'
/files/projects/isdn/openbsc/openbsc/src/bsc_hack.c:222: undefined
reference to `log_add_target'
/files/projects/isdn/openbsc/openbsc/src/bsc_hack.c:229: undefined
reference to `log_set_all_filter'
...
libosmocore.a has a reference to 'log_init', but the linker will not
find it somehow. any idea?
andreas
>> hi,
>>
>> while trying to bring latest api of openbsc and linux-call-router
>> together, i experienced the following problem:
>
>make a clean rebuild... your libtool seems hosed.
this does not work:
rm libtool
autoreconf -f
make
and i have the non-working libtool again.
hi,
while trying to bring latest api of openbsc and linux-call-router
together, i experienced the following problem:
make[2]: Entering directory
`/files/projects/isdn/openbsc/libosmocore/src'
/bin/sh ../libtool --tag=CC --mode=compile gcc -DHAVE_CONFIG_H -I.
-I.. -I../include -fPIC -Wall -g -O2 -MT timer.lo -MD -MP -MF
.deps/timer.Tpo -c -o timer.lo timer.c
../libtool: line 775: X--tag=CC: command not found
../libtool: line 808: libtool: ignoring unknown tag : command not found
../libtool: line 775: X--mode=compile: command not found
../libtool: line 925: *** Warning: inferring the mode of operation is
deprecated.: command not found
../libtool: line 926: *** Future versions of Libtool will require
--mode=MODE be specified.: command not found
../libtool: line 1069: Xgcc: command not found
../libtool: line 1069: X-DHAVE_CONFIG_H: command not found
../libtool: line 1069: X-I.: command not found
../libtool: line 1069: X-I..: command not found
../libtool: line 1069: X-I../include: No such file or directory
../libtool: line 1069: X-fPIC: command not found
../libtool: line 1069: X-Wall: command not found
../libtool: line 1069: X-g: command not found
../libtool: line 1069: X-O2: command not found
../libtool: line 1069: X-MT: command not found
../libtool: line 1069: Xtimer.lo: command not found
../libtool: line 1069: X-MD: command not found
../libtool: line 1069: X-MP: command not found
../libtool: line 1069: X-MF: command not found
../libtool: line 1069: X.deps/timer.Tpo: No such file or directory
../libtool: line 1069: X-c: command not found
../libtool: line 1120: Xtimer.lo: command not found
../libtool: line 1125: libtool: compile: cannot determine name of
library object from `': command not found
make[2]: *** [timer.lo] Error 1
make[2]: Leaving directory
`/files/projects/isdn/openbsc/libosmocore/src'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/files/projects/isdn/openbsc/libosmocore'
make: *** [all] Error 2
andreas
Hi!
This is just a notification that I've now created a mailing list related to
OpenGGSN development. As the entire OpenGGSN project is running on sf.net, the
mailinglist is also running there:
https://lists.sourceforge.net/lists/listinfo/ggsn-devel
So if you're interested in following what's happening in OpenGGSN, I suggest
you subscribe there, too. I understand it would probably make more sense
to simply move the entire project to osmocom.org and use this very openbsc
list (it is low-traffic, after all) - but we never know if the original
author wants to come back, and I'd be able to keep that door open for him
and thus the project separate and on sf.net.
I've also made a openggsn-0.90 release including various bugfixes that
were contributed trough the last 5 years, as well as one criticial security
fix. You can obtain it from:
http://sourceforge.net/projects/ggsn/
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)
Hi,
I have git clone the openbsc program and encountered problem running
osmo_sgsn,
got the following error messages:
"
There is no such command.
Error occurred during reading below line:
nsip local port 23000
Failed to parse the config file: 'osmo-sgsn.cfg'
<0014> sgsn_main.c : 170 Cannot parse config file.
"
Appreciate help on this.
Thanks
Ken
Hi all,
as you can see from the attachment, the OpenGGSN takeover request at
soruceforge has been resolved earlier than expected, since the original
project creator/administrator was not reachable for sf.net.
I'll keep you posetd about the further progress.
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 Harald,
On Wed, 19 May 2010 21:28:10 +0200, "Harald Welte" <laforge(a)gnumonks.org> wrote:
>
> So let's start with a poll:
>
> a) Do you think re-licensing to AGPLv3 is a good idea?
I don't have much experience in this area (different GPL versions), but
for me it sounds OK.
> b) If you have contributed, would you re-license your code under AGPLv3?
There is probably not that much from me, but feel free to put the affected
parts under AGPLv3.
Best regards,
Dieter
--
Dieter Spaar, Germany spaar(a)mirider.augusta.de
Hi all!
I think it's about time that we seriously think about how to handle naming
of the individual programs as well as the project itself.
OpenBSC was always a mis-nomer since what we started with is much more
than a BSC: It's an entire GSM network (excluding BTS) in one process.
This was mostly due to the fact that OpenGSM was way too generic and I
wasn't able to come up with a good name.
Meanwhile, we've started project Osmocom (Open Soruce mobile Communications),
where work is being done on the MS (phone) side of GSM. The idea was to have
a name generic enough for sub-projects. There are currently two such projects:
* OsmocomBB - the BaseBand firmware
* libosmocore - the shared library with utilities that are used accross programs
In OpenBSC, we currently have the following executables:
* bsc_hack - the gsm network-in-a-box
* bsc_msc_ip - the actual BSC-only version talking to a real MSC
* bsc_nat - the A interface NAT
* bsc_mgcp - the media control gateway
* osmo-gbproxy - the Gb interface proxy
* osmo-sgsn - the soon-to-be-working SGSN
as well as a number of utilities like bs11-config, ipaccess-find,
ipaccess-config, etc.
What Zecke and me have decided some time ago is to move everything under the
umbrella of the Osmocom project name. This menans that the homepage and git
repositories will move to openbsc.osmocom.org/bsc.osmocom.org and git.osmocom.org
(while keeping aliases/redirects in place).
What worries me most is the naming of bsc_hack and bsc_msc_ip.
I think bsc_msc_ip should be called osmo-bsc, as it is a true BSC
implementation.
For bsc_hack it's much harder. A logical name would be osmo-gnib (gsm network
in a box), but as I've already received tons of complaints about osmocom, I'm
not going to come up with even stranger acronyms. However, I want to rename
it. It should be prefixed with "osmo-" and the name should not erroneously
indicate that we're talking abuot something thats _only_ a BSC.
Does anyone on this list have an idea for a good name?
For all the other programs, I'd also advocate prefixing them with "osmo-",
but that's less of a pressing concern right now.
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)
Hi all!
Thanks to the support from On-waves, I've been able to focus on my GPRS
work during recent weeks.
Today, I have managed to actually perform successful PDP context activation /
deactivation using a nanoBTS, OpenBSC, OsmoSGSN and OpenGGSN.
This is a big step forward, as it means that the GTP interface between
our SGSN and OpenGGSN is up and running. The IP addresses allocated
are from a pool defined on the GGSN side, and OpenGGSN opens a tun-device
for it.
Also, the GGSN implementation is much less proof-of-concept now, as it actually
maintains propper MM context, PDP context and other state information.
However, for reasons that I couldn't figure out (despite many hours of
debugging): There are no user/data plane packets anymore. This was already
working before I began the GTP / OpenGGSN intergration work 1-2 weeks ago.
The PDP context is established successfully on the LLC-GMM SAPI, the phone
shows that GPRS is up, but then it doesn't actually even send a single
packet (SNDCP, XID exchange, ...) over any of the user data SAPIs. The
SAPI and NSAPI have been assigned properly, and I could not find any differece
looking at packet traces for both the cases.
If you look at the NS-IP / Gb interface of the nanoBTS, not a single gprs
protocol message arrives after the PDP context is activated.
After a minute or two, the phone then simply disconnects with "Regular
Disconnect" cause, as if nothing had happened. Putting the phone in front of
an audio amplifier also doesn't reveal any noticable bursts being generated
by the phone.
For now I'm feeling a bit lost and will work on some other stuff before
returning with renewed energy to the SGSN at some later point.
In case you want to try it, the following steps are needed:
1) check out OpenGGSN from git://openbsc.gnumonks.org/openggsn.git (master
branch), run the usual autoreconf -1 && ./configure && make install
2) check out current OpenBSC master branch and build it. Only if libgtp
(installed by OpenGGSN) is found, it will build src/gprs/osmo-sgsn
3) the IP address where
4) Run OpenBSC like usual, however make sure that the followign settings
are configured in the openbsc.cfg config file:
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 123.192.152.236
Where the last ip address is the address of the machine where you will
run OsmoSGSN.
5) Configure /etc/ggsn.cfg of your GGSN machine. Check /etc/ggsn.conf
(example attached) Run
$ sudo ./ggsn -l 192.168.100.239 -d
where that address is the local _listening_ address of the GGSN
6) Then simply fire up osmo-sgsn. The only relevant config
setting in osmo_sgsn.cfg is:
sgsn
nsip local port 23000
7) start your favorite mobile phone and register it to your network
You can telnet to osmo-sgsn on port 4245, and type the followign commands
for some interesting information:
logging enable
logging filter all 1
logging level ns info
logging level bssgp debug
logging level llc debug
logging level gprs debug
logging level mm debug
show ns
show bssgp
show llc
show mm-context all
show pdp-context all
Oh, and last, but not least: Wireshark can debug the Gb interface packets
between BTS and SGSN, you simply have to select 'Decode as .... NSIP' on port
23000 packets. It also decodes the GTP between SGSN and GGSN without any extra
setting.
Have fun!
--
- 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,
Can anyone give me information about how i can connect and use telnet
interface. I tried by typing " telnet IP 4242" on command line of a PC
which was running bsc-hack program but i couldn't succeed. I want to send
SMS and use silent call property by using telnet. Please help me.
Ahmet.
Hi all,
once I ran the command ./gssm_usrp.py, I got following error:
zero@zero-laptop:~/airprobe/gssm/src/python$ ./gssm_usrp.py
Traceback (most recent call last):
File "./gssm_usrp.py", line 5, in <module>
from gnuradio import gr, usrp, db_dbs_rx, blks2
ImportError: cannot import name db_dbs_rx
I searched over internet and found somewhere that Josh and Eric has
mentioned that this version of gssm will not work with gnuradio 3.2, it will
work with 3.1, is there any other way to run this program on gnuradio-3.2.2.
kindly reply me please
my configuration:
I am using karmic, gnuradio3.2 with modified external 52MHz clock, please
help me to get out from this problem
On Thu, May 13, 2010 at 3:30 PM, <openbsc-request(a)lists.gnumonks.org> wrote:
> Send OpenBSC mailing list submissions to
> openbsc(a)lists.gnumonks.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://lists.gnumonks.org/mailman/listinfo/openbsc
> or, via email, send a message with subject or body 'help' to
> openbsc-request(a)lists.gnumonks.org
>
> You can reach the person managing the list at
> openbsc-owner(a)lists.gnumonks.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of OpenBSC digest..."
>
>
> Today's Topics:
>
> 1. Re: User location openbsc (Harald Welte)
> 2. ipaccess-config changes in master (Holger Freyther)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Wed, 12 May 2010 12:52:59 +0200
> From: Harald Welte <laforge(a)gnumonks.org>
> Subject: Re: User location openbsc
> To: Fabrice Ismael Poundeu Tchouatieu
> <fabrice.poundeu(a)smail.inf.fh-bonn-rhein-sieg.de>
> Cc: openbsc(a)lists.gnumonks.org
> Message-ID: <20100512105259.GP10052(a)prithivi.gnumonks.org>
> Content-Type: text/plain; charset=us-ascii
>
> On Wed, May 12, 2010 at 11:14:27AM +0200, Fabrice Ismael Poundeu Tchouatieu
> wrote:
> > Hello Harald,
> > can you please explain me how the subscriber location actually work
> > in openbsc. i have seen that you also have a VLR implemented. How
> > does this work? I actually just test the registration and calls in
> > roaming mode. To which part of the Openbsc implementation
> > (program-code) should i refer to for this (subscriber location
> > implementation)?
>
> We don't really have/use any VLR. All we have is a subscriber table,
> and each subscriber can have a completely different MCC/MNC as part of
> his IMSI - we simply don't care. There is no distinction between
> roaming and home network subscribers at all.
>
> All we care about is if the subscriber.authorized field is 0 or 1 in
> the sql database.
>
> Regarding 'subscriber location' between multiple BTS: We simply store
> the LAC of where the subscriber was last seen.
>
> --
> - 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)
>
>
>
> ------------------------------
>
> Message: 2
> Date: Thu, 13 May 2010 01:00:21 +0800
> From: Holger Freyther <zecke(a)selfish.org>
> Subject: ipaccess-config changes in master
> To: openbsc(a)lists.gnumonks.org
> Message-ID: <4BEADEA5.6050307(a)selfish.org>
> Content-Type: text/plain; charset=ISO-8859-1
>
> Hi all,
>
> I have done various changes to the ipaccess-config application to work
> with a multi-trx setup. I think I have tested everything on both
> single-trx and multi-trx setup. If something with ipaccess-config does
> not work anymore please shout and I will have a look.
>
> z.
>
>
>
>
> ------------------------------
>
> _______________________________________________
> OpenBSC mailing list
> OpenBSC(a)lists.gnumonks.org
> https://lists.gnumonks.org/mailman/listinfo/openbsc
>
>
> End of OpenBSC Digest, Vol 17, Issue 7
> **************************************
>
--
Thanks.....
Hi all,
I have done various changes to the ipaccess-config application to work
with a multi-trx setup. I think I have tested everything on both
single-trx and multi-trx setup. If something with ipaccess-config does
not work anymore please shout and I will have a look.
z.
Hi!
I've created a git repository for OpenGGSN, and imported the apparently
abandoned openggsn code using git cvsimport.
You can clone the repo via "git clone git://openbsc.gnumonks.org/openggsn.git
Please note: This is not meant as an attempt to fork or openggsn.
I just wanted to add all the fixed that had been contributed to the sourceforge
bug tracker to the latest released openggsn code (including a DoS fix from 6
years ago)... so I might as well make this available to others.
I'm still hoping to get in touch with the original author and see what we
can do to bring those fixes back into mainline and help openggsn's future.
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)
Hi all!
Since the SGSN was now built as a separate program, the modifications to
OpenBSC specific files are none, and the modifications to some shared files
were minimal (e.g. adding a new debug category).
Thus, I have decided it is no longer useful to keep the gprs-sgsn branch
as a separate branch. The GPRS code can now be found in the master branch.
Also, all gprs related code is moved to src/gprs to make the distinction
more clear. I don't expect any of my upcomign work on the GPRS side
to touch the regular BSC codebase in src/
The ipaccess-* executables are now also built in src/ipaccess and I think we
should gradually give the code more structure. Too many source file in one
directory make things complicated and make it too easy to have strange
dependencies.
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)
Hi!
The gprs-sgsn branch has seen quite a number of changes during the last
week, most of them are related to the gb-proxy that I'm currently implementing.
The Gb-proxy can multiplex several Gb connections (each to one BTS) and present
them as one NS-VC with many BSSGP-VC (one for each BTS) to the SGSN. The
proxy is not needed for most users OpenBSC operation.
However, I have now also adapted the SGSN support inside OpenBSC to the
modified NS and BSSGP code for the proxy. Furthermore, I've fixed many
of its limitations and it should now be fairly generic, working with
multiple BTSs, etc. Also, the SGSN is now a standalone program called
osmo_sgsn. A lot of the legacy cruft has been eliminated, i.e. the
SGSN code does no longer need the gsm_network/bts/trx/... data structures
that are not applicable to the GPRS network model anyway.
As a result, GPRS ATTACH and RA UPDATE are working again, like they did
months ago.
I'm now still stuck somewhere in PDP context activation, and am confident
that this will be solved tomorrow. After that point, the actual data plane
can be worked on, i.e. flow control and fragmentation, as well as somehow
actually routing IP packets into the LLC connection.
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)
