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)
Hi!
I'm getting to a point where we need to associate more and more state
and/or references with every individual msgb.
In the circuit switched BSC case, every message (msgb) is associated with
a logical channel (lchan) through which it is sent.
However, in the packet switched case, this is not the case. Rather, a msgb
is received on a particular NS-VC, inside a particular BSSGP-VC, inside a LLC
session, etc.
When we pass a msgb through the protocol layers and back, we somehow need
to identify where to send the response to. Once we actually reach the
04.08/04.11 layer, things become a bit less difficult. In the end, all
messages are at least somehow associated with a 'subscriber'.
If a message passes from the UDP socket into the NS protocol and into BSSGP, we
need to know the BSVCI and NSVCI if we want to send a response back. One
option would be to pass those values as explicit function call arguments,
which is partially what my current code is doing. But the more layers we traverse, the longer the function arguments get.
Furthermore, there are parts of our protocol (04.08 and 04.11 particularly)
that can either be transported on top of 08.58 (RSL) or LLC/BSSGP/NS. Those
upper layers shouldn't really care what the underlying transport looks like.
One possible option is to somehow identify the NS-VC and BSSGP-VC by putting
an identifier or pointer into a 'struct msgb' member. This would require
libosmocore changes every time we add some bits here or there.
Another option is to introduce something similar to the skb->cb in the
linux kernel: A 'control buffer' area of unspecified content provide by the
core networking code as part of every sk_buff, which gets type-casted
to the IPCB or TCB-CB when the msgb enters the respective protocol layer.
The advantage is that we could have one msgb structure definition with the
typecasting functions/macros being part of the application (e.g. openbsc)
The problem with this is: Its scope is limited to whatever is the current layer
of the protocol stack. The IPCB is overwritten with the TCBCB once the
message enters TCP.
In our case, we would actually want to have the associated data to persist
even while the msgb passes from one layer into another. This would mean
that there is a more-or-less static structure containing all the various
identifiers, which is then typecasted to the control buffer.
While this might not be ideal, it definitely keeps the details hidden
away from libosmocore, which is good.
Any comments are welcome,
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)
>> output of "misdn_info"
>Found 2 ports
> Port 0 'mISDN_l1loop.1': TE/NT-mode PRI E1 (for phone lines & E1
devices)
> 30 B-channels: 1-15 17-31
> B-protocols: RAW HDLC X75slp
> --------
> Port 1 'mISDN_l1loop.2': TE/NT-mode PRI E1 (for phone lines & E1
devices)
> 30 B-channels: 1-15 17-31
> B-protocols: RAW HDLC X75slp
hi fabrice,
the mISDN_l1loop interfaces are used to bring audio channels from the
BTS into the kernel (mISDN driver). there they can be connected to other
ISDN ports or used by chan_lcr (asterisk channel driver). both
interfaces are used by the [GSM] interface. (see gsm.conf) there are two
interfaces: one is for the BTS side and the other for the chan_lcr
(asterisk) side.
since you have no physical interface, i assume that you want to use
asterisk in combination with chan_lcr. but you also have [Int] and [Ext]
interfaces defined. you may only use them if you actually have physical
interfaces. what happens here: the given port numbers 0 and 1 match you
virtual l1loop interfaces, which are already in use for [GSM] interface.
unless you don't have physical cards, remove them. (interface.conf)
now you may route all call from the GSM interface (or any interface to
the chan_lcr:
see routing.conf
[main]
: remote application=asterisk
and from asterisk to lcr:
Dial(LCR/GSM/<extension from hlr>[/<options>])
try a test first:
[main]
: test prefix=5
and you should hear music...
regards,
andreas
p.s. i think we may require a howto. also i think i must put some
'working' packages together at one point to download. sometimes api
changes a bit, so always latest packets may not work together.
Hi all,
this is just a small head ups on the current differences between the
on-waves/bsc-master branch and HEAD.
New apps:
1.) bsc_msc_ip is the OpenBSC BSC that is speaking the A interface
2.) bsc_nat is a NAT/Multiplexer for BSCs and MGCP. One reason for it is
easy nat penetration.
I will look into git filter branch to merge the NAT into master as there
is nothing that is preventing it, for the bsc_msc_ip I need to continue
some merging.
Changes:
*) RF Failure handling. When a RF Channel fails, I switch it over to a
failure state, then ignore all SAPIs releases... and then set it back to
operational state.
*) RF bring down in SAPI order. So at first I will bring down SAPI=3,
then send SACH deactivate, then SAPI=0, then send the RF Channel
release. This is done as the nanoBTS likes to send a SAPI release
indication after the RF Channel Release ACK.
*) channel release reason, when closing a lchan one can set the release
reason. This is used on early assignment when closing down the old
signalling channel.
*) and of course the much talked about removal of ref counts from the lchan.
Hello Holger,
On Mon, 19 Apr 2010 12:37:12 +0800, "Holger Freyther" <zecke(a)selfish.org> wrote:
>
> The other problem is with the 20 paging requests every two seconds I'm
> creating a RACH DoS for my BTS to a point that I think (didn't bother to
> do the easy math, and I don't have the spec here right now) we have two
> MS picking the same random number. At least the symptom is that even if
> we assign a channel, it gets closed down with a RF Failure.
I wonder how frequently it happens with 20 MS that a RACH is sent on the
same frame and with the same random number. There are at least 16 possible
random numbers for the "Answere to Paging" Channel Request and there are
27 frames in the MF to chooses from (in the "Combined Configuration").
Do you use the same phones for testing and does the RF Failure happen
frequently (this probably would mean a bad random number generator in
this phone firmware) ? Also I would expect that two RACH burst will
disturb each other, at least in a testing environment where all the
MS have the same distance to the BTS and send with the same power.
Best regards,
Dieter
--
Dieter Spaar, Germany spaar(a)mirider.augusta.de
