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(-)
Hi Holger!
I'm currently reviewing changeset 2d501ea26a219176b1c556449e45ebd90d4accfb
and just noticed that you introduce a new 'int rf_locked' member to struct
gsm_bts_trx, which I believe is not needed.
We are already tracking the administrative state of all objects in the BTS
and mirror their state.
The specific state you are looking for should be in
gsm_bts_trx.nm_state.administrative
I would appreciate if you could fix this.
--
- 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!
While enroute to FOSS.in in Bangalore, I took the time to test and debug
the various issues I could find with the code in the system_information branch.
At least in all of my tests, the system information messages, including rest
octets and neighbor cell lists are looking perfectly fine. Especially now
that with my latest patch, wireshark is able to dissect the SI messages properly,
it is much easier to debug :)
If you want to give it a try, I recommend using something like git revision
63b152ebb74355acfde76e9ce1113f2d823c0804 of that branch.
Please note: We currently only support the relative bitmask format for the
neighbor cell lists. That means, you cannot have neighbors with ARFCN's
spanning a range of more than 111, i.e. your lowest and highest ARFCN have
to be within a distance of 111 ARFCN's.
Unless there are major objections, I intend to merge this branch ASAP (or
rather do a 'git diff master..system_information' and apply the resulting diff
as one commit to master)
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)
Dear openBSC users,
This project sounds interesting and promising.
I would like to collect MSISDN (mobile numbers) for people attending a fundraising gallery. Then I send them SMS (using the MSISDN list I made) with 5 bucks donation link.
Of course I can run with a pen and paper and do that, but instead I would like to use technology to help me.
Is this possible to do with openBSC? Or even other GNURadio modules?
I am not interested in:
using openBSC to make/receive phone calls nor IMSI and TMSI.
Bands of interest are:
900/1800 GSM
2100 UMTS
In case this is not possible using GNU Radio modules. Is there commercial solutions to do that?
Peace,
Mohammad Halawah
Project Engineer
JETZT REGISTRIEREN: Vierteljährlicher Newsletter über die Welt der mobilen Lösungen! http://www.smartmachine.net/newsletter.html <http://www.smartmachine.net/newsletter.html>
REGISTER NOW: Quarterly newsletter about the world of mobile solutions! http://www.smartmachine.net/en/newsletter.html <http://www.smartmachine.net/en/newsletter.html>
smartmachine Forschung & Entwicklung GmbH
Sterneckstraße 33
5020 Salzburg
Austria
O: + 43 662 880440-52
F: + 43 662 880440-99
M: + 43 664 1101 206
E: mohammad.halawah(a)smartmachine.net <mailto:martin.leitner@smartmachine.net>
Hi!
Today I spent some time investigating the cheap 16-in-1 SIM cards on which
we can set our own Ki. This means that those cards can be used for
cryptographic authentication with OpenBSC. Finally, we will have not only
IMSI-based identification, but actual authentication!
I've created a page in the Wiki about those cards:
http://openbsc.gnumonks.org/trac/wiki/MagicSIM
Using this information, I could send the RUN GSM ALGORITHM APDU to the card and
retreive SRES + Kc. The result matched what I can also obtain using the
COMP128v1 code from http://www.scard.org/gsm/a3a8.txt
I will add Comp128v1 support to OpenBSC as soon as I have tested acutal
authentication using this 16-in-1 SIM card.
By the way: It would really be great if somebody could hack up a small command
line program that can be used to program the Operator Name, Ki, ICCID, IMSI and
preferred PLMN into the 16-in-1 SIM.
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!
As Dieter has noticed, GSM traces from gammu / nokia DCT3 phones show the
complete SYS INFO decode inside wireshark. However, the RSL messages BCCH
INFORMATION do not decode it.
I've revolved this problem and submitted a patch to the wireshark team,
you can get it from https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=4268
Please note: This patch does not yet address the problem for the SI5/SI6 in
SACCH FILLING. The solution is not as easy, since in this case a generic
L3 IE is handed of to the GSM_A_DTAP rather than GSM_A_CCCH dissector.
If anyone wants to help out with fixing this for the SACCH, I'm sure many
OpenBSC users and wireshark guys will be happy to receive a patch/fix.
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!
While looking at a wireshark trace (with the newly discovered wireshark system
information dissector, for which I'll submit a patch to wireshark later
tonight), I just realized that in SI1 we still shend a Cell Allocation of a
hardcoded ARFCN 123.
So unless you run in GSM900 and you use ARFCN 123, the SI1 content will
disagree with the actual radio carrier.
This is likely to cause confusion with at least some phones.
We already have code to generate the channel lists inside SI messages, but this
code is so far not used in the master branch.
So this is just a reminder "There is a known Issue". If you want to experiment
with a supposed fix for it, try using the system_information branch.
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)
Sorry for this posting, but due a timewaster from berlin the last nanoBTS type 139 is for sale again.
It is a siemens branded (MOGIS) nanoBTS type 139, pictures you can see on http://umts.zerber.us
It is my last one, there is no PoE included, so the special price is 1900 euro plus shipping.
I am currently not in switzerland, I try to get some TETRA equipment,
so the shipment will be in the second week of december.
Payment to my bank account or PayPal.
I sold already a lot of this nanoBTS to members from the openBSC-Group for a good price,
thank you to all of you.
Thank you, Rohit for the link.
N.
On Mon, 2009-11-23 at 09:04 +0530, Rohit Joshi wrote:
> It suggest patch found conflict in code. Read this to get started on
> handling patch rejects http://elinux.org/Handling_Patch_Rejects
>
>
> 2009/11/23 ನಾಗೇಶ್ <openbscuser(a)gmail.com>:
> > Hi,
> > When applying patch (as described in Debian_Getting_Started page), I get
> > messages as shown in screenshot. What do these mean ?
> >
> > N.
> >
>
>
>
Hey Guys,
this is just a small head about the current work and how it relates to the
OpenBSC project. So far I had developed in a branch and used rebase on it but
I'm going to do regular releases so I have to stop modifying the history.
Now I have the following branches:
on-waves/mgcp:
- This includes the MGCP media gateway implementation. The MSC in use
has a mapping from the Circuit Identity Code (Multiplex + Timeslot)
to an MGCP Endpoint. To ease development I have one bsc process
and one mgcp one. To properly "connect" audio bsc and mgcp share
a secret which is the RTP port to be used... E.g. I can bind all
RTP ports ahead of time (also nice for tunneling data).
There is some overlap with the current rtp proxy code but I'm not
yet sure how these two fit together... So the future might be I
include the MGCP code in the BSC and use the existing proxy code..
but I really don't know right now.
on-waves/sccp:
- This includes the SCCP implementation. It has a test case and is working
quite reliable. Addressing (SSN) is achieved with something like a
sockaddr and it is mostly following the socket semantic. Instead of
accept and select I do have callbacks... this might change in the
future.
- There is no MTP* implementation in the code base...
- The one "problem" with it is the memcpy... and "queuing" inside the
code but both will be addressed over time.
on-waves/gsm0808:
- This is the current BSC app and GSM080 (BSSMAP/DTAP) code..
- This branch will rename the bssap.c to gsm_08_08.c and remove
all traces of SCCP from it, some code will move from bsc_msc_ip.c
to the bssap.
- an API will be created that can be used by the bsc_msc_ip.c and
the bsc_hack.c/gsm_04_08.c code.
- In terms of OpenBSC I want this to be done after the congress to not
create a mess right now.
on-waves/bsc-master:
- This will be my release branch. I will pull from the three branches, update
version, put in hacks, or short term things that are necessary.
- Think of it as a incubator for "master"
as there is little danger of breaking things I have merged the MGCP and SCCP
branches into master as well. I hope there is agreement (otherwise there is
always git revert)
z.