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,
I'm currently implementing Early Assignment in the On Waves branch and as part
of this I will have to take care of RSL channel releases as well.
Someone else was pointing this out as well but I could not find the email. Our
channel release is a bit sloppy and I will fix it and start using T3111 and
T3109 in the rsl code for doing so.
In the "normal" case (bsc on the left, bts on the right):
RSL Channel Release -->
<- RSL Channel Release Ack
<- Release Indication SAPI=0
RSL Channel Release ->
<- RSL Channel Release Ack
In the "abnormal" case:
<- Error Indication
RSL Channel Release ->
<- RSL Channel Release Ack
<- Release Indication SAPI=0
RSL Channel Release ->
<- RSL Channel Release Ack
I'm going to change that into the following way.
"normal" case:
1.) Release the established SAPIs
2.) After their ACKs release the Channel
Have all this guarded by T3109 (or whatever is more appropriate)
"abnormal" case:
1.) Start T3109
2.) Then do the normal case.
During the shutdown sequence I need to make sure that we are not allocating
the channel again. I'm thinking of either using the chan mode Harald was
introducing while doing the hand over work, or just a "locked" flag to not
assign the channel.
I hope to be done with this by tomorrow or the day after, anyone has comments
or ideas on how to approach this?
z.
Hi all,
I'm cross-posting this to both OpenBTS and OpenBSC mailing lists
in a hope to get wider audience. Sorry if you get this message twice.
Ivan and I are working on USSD support for OpenBTS now. We've got
all our test phones working except old Siemens A52 (newer A65 is ok).
When we request more information from the phone in order to create
menu-like experience, this phone deny processing any further USSD
with "NOT EXECUTED" error, while still keeping L3 channel open.
This looks quite much like a bug in the phone, but also seems we have
a problem in our code too - I tested it with my working SIM card and
my normal operator USSD menu and it works.
So I kindly ask everyone who have Nokia 3310 with MBUS cable or
any other GSM sniffer and have access to live network with working
USSD to help us with gathering some real-network data. Please:
1) Call some simple USSD request, which just return a single piece
of data. Like "Show my balance"
2) Call some menu-like USSD request and go through several levels
of it. On our network we have a kind of "Self-care service" through
USSD which works that way.
3) If you know how to summon network-originated USSD request or
notification - we will appreciate if you include this too. I have never
seen this on my home network, though.
4) Send me your trace.
Thanks!
--
Regards,
Alexander Chemeris.
Hi there,
Has anyone been working on using OpenBSC with a Sangoma E1 card connected to
the BTS ? I guess they would be some patches to add to the generic driver to
have it fully working and recognized within the OpenBSC framework ?
The last thread I saw related to Sangoma was from Oystein :
http://lists.gnumonks.org/pipermail/openbsc/2009-August/000821.html
Cheers,
Xavier.
Hi
What needs to be changed in openbsc in order to add a new input ?
I'm currently developing a GAN protocol stack, and would like to add it to
openbsc so it could deal with the DTAP msg coming from GAN
regards,
--
k2
hi,
while porting the select.c to LCR, i found the problem:
the unix select function returns a set of file descriptors to be
handled. the result-loop (the loop after the select()) is called again,
if more than one descriptor is removed by the callback funtion. this may
lead to a another call to the callback function, because the bits of the
FD_SETs do not change and still set.
i think we must clear these bits, if they are handled, so the handler
will not be called twice in case of a "restart" of that loop.
regards,
andreas
Hello Andreas,
On Wed, 20 Jan 2010 09:30:17 +0100, "Andreas.Eversberg" <Andreas.Eversberg(a)versatel.de> wrote:
>
> some stupid question: if a phone does not support any encryption, is it
> possible to use it on an official GSM network? (authentication works, of
> course) if so, what phone might it be?
I did a quick check, at least Vodafone and T-Mobile here in Germany
reject the Location Update Request with "Network Failure" (0x11) if
they get a classmark without any encryption available. The registration
works with the same phone if the classmark indicates that encryption
support is available. The test was done with a phone where I can
modify the classmark data.
Best regards,
Dieter
--
Dieter Spaar, Germany spaar(a)mirider.augusta.de
hi,
some stupid question: if a phone does not support any encryption, is it possible to use it on an official GSM network? (authentication works, of course) if so, what phone might it be?
regards
andreas
Mit freundlichen Grüßen,
.-.
/'v'\
(/ \)
------------------------------------------------------------------"-"-
|_|
i.A. Andreas Eversberg
Network Operations / 2nd Level Data - KC Internet
Versatel Nord GmbH
Nordstr. 2
D-24937 Flensburg
Fon: +49-461-9099749 | Fax: +49-461-909960749
andreas.eversberg@versatel.de@versatel.de | www.versatel.de
Sitz der Gesellschaft: Flensburg, Registergericht: Flensburg, HRB 3395 FL
Geschäftsführer: Dr. Hai Cheng, Dr. Max Padberg, Joachim Bellinghoven
Hello list,
I have a nanobts1800 and installed openbsc on Debian yesterday (from git).
After building the project and configured the bts on the network, I executed
bsc_hack with -c openbsc.cfg.nanobts.
But it failed to execute with the following error:
<0005> bsc_init.c:860 Failed to parse the config file: 'openbsc.cfg.nanobts'
I haven't modified the config file, I haven't modified anything at all in
openbsc.
Any idea?
Thanks.
Hello,
the commit "[OML] parse attributes depending on BTS type" seems to break
bsc_hack completely since it's no longer possible to add a new BTS.
This happens because the VTY config sytem first tries to allocate a BTS
of type UNKNOWN and later changes that type when the type statement is
encountered. I have commited a patch in daniel/fixes that registers a
BTS of type unknown so the code should work as before (tested with a BS11).
Maybe it is smarter to change the way the gsm_bts_alloc function works
instead (so you don't need to provide a type there), I'm not sure about
that.
Regards,
Daniel Willmann
Hello,
I've noticed that recent versions of bs11_config don't show all the
infos they used to.
commit eb429b7b44f1c39548a1995cb93484b9cbe2996e
Author: Sylvain Munaut <tnt(a)246tNt.com>
Date: Mon Oct 26 20:19:59 2009 +0100
[TLV] Split the parser into 'parse loop' and 'parse single value'
seems to be the problem. If I revert it bs11_config query shows more
information again. I've looked at the patch, but so far couldn't find
out what it does differently. I'll keep looking, but maybe someone else
has an idea.
Regards,
Daniel Willmann
Hi,
I've just tested code I started at 26c3 but didn't get a chance to test and
I updated my various branches.
Here's a little status :
sylvain/rrlp : This contains only changes to rrlp-ephemeris. Mostly fixes
and more support to provide assistance data. Also asn1c patches to fix bugs
and a script for people to generate their own test data.ubx from their
receiver (to get up-to-date / local data).
sylvain/pending: Various things / fixes I made that I consider ready to be
reviewed / merged. I tested it all on both my nanoBTS 139.
sylvain/encryption: The current state of my encryption support work. I
rebased it and used the db structure you pushed for encryption. Everything
but the last 3 patches are pre-work / preparation / fixes and are imho OK.
The last 3 patches are the real implementation and I also think they're in
pretty good shape. Tested and working here :) Limitations includes : No Kc
re-use & No MT encryption yet.
sylvain/encryption_testing: More encryption work, based on
sylvain/encryption but not done/ready. Only pushed so that people can have a
peek ...
Cheers,
Sylvain
Hi Harald,
I have a stack corruption due the above method and here is my analysis of the
problem...
set_system_infos is having a u_int8_t array with 23 bytes on the stack and is
asking to generate system infos into this array...
Now what happens is:
1.) some system information types structs are already bigger
than the 23 bytes...
2.) this does not take the rest octets into account..
I would like to fix it like this:
1.) Turn bitvec_spare_padding to return void
2.) In the rest_octets_siX method return the bit_vec.data_len
3.) Change the generate_siX to return the sizeof the struct
+ return value of the rest_octets_siX instead of the fixed
MACBLOCK_LEN (23)
4.) always use this rc value instead of the size of the buffer...
(due to 1. of the above we set truncated values as well)
do you have a better idea? would you just increase the buffer size?
z.
Hello,
this list of patches includes support to change the PLL set and work
value with bs11_config.
Many thanks go to Dieter Spaar who figured out how to change the work
value.
Harald, if these patches are okay for you I'll go ahead and commit them.
Regards,
Daniel Willmann (5):
[abis_nm] Add generic abis_nm_bs11_logon function
[abis_nm] Add abis_nm_bs11_infield_logon to logon as user field
[abis_nm] Add abis_nm_bs11_set_pll function to change the set/work
value
[bs11_config] Whitespace changes so the help text looks nice
[bs11_config] Add pll-setvalue and pll-workvalue commands
openbsc/include/openbsc/abis_nm.h | 3 ++
openbsc/src/abis_nm.c | 39 +++++++++++++++++++++++++---
openbsc/src/bs11_config.c | 50 +++++++++++++++++++++++++-----------
3 files changed, 72 insertions(+), 20 deletions(-)
Hello,
I ‘ve tried to use the latest OpenBSC code with a nanoBTS at 850 MHz.
I have been able to compile the code in Debian Linux and run it
successfully. Mobiles were able to register successfully to the network. In
addition the IMSI and TMSI numbers were collected successfully. However, I
have encountered a few issues that are summarised below:
- Segmentation faults (software crashes) occur in situations where I try
to send an SMS message through the telnet interface or when I try to make a
phone call from one mobile to another
- When sending SMSs from one mobile to another, the SMS are collected
successfully to the database but are not sent to the other mobile. In the
telnet interface I use the command “SMS SEND PENDING” but nothing happens.
The SMSs are sent to the terminating mobile when either restarting the
OpenBSC software or when the terminating mobile re-registers to the OpenBSC
network
- IMEI numbers are sometimes not collected (especially on Nokia phones)
or the wrong IMEI number is displayed
Have anyone else noticed these issues?
I am trying to install a debugger to check why the segmentation faults
occurs. The only debugger that works is from Netbeans that uses the GDB
debugger. However the debugger hangs when trying to initialise the database
(it stucks in command dbi_initialize(NULL) on db.c file)
Can anyone help why the debugger hangs or recommend a debugger that will
work with this code?
Many thanks
Regards,
Dimitris
Hi,
I don't see how this commits helps ? The function code is exactly the same
in both files and the db.c dependency in vty_interface.c hasn't been
removed.
Am I missing something here ?
[ See commit 424c4f0e2927d5a7538b31c69113c6e4f861d2c9 on the git for context
]
Sylvain
On Fri, 01 Jan 2010 04:05:06 +0100, Miguel Elias <nobody_su(a)chaostreff.ch>
wrote:
> hi hi,
nicht witzig ich arbeite momentan dran :)
> 2m sind normalerweise für amateure verwendet, die bos sind normalerweise
> auf 4m, aber dass heist nicht das auch auf den kommerziellen frequenzen
> auch bos dienste möglich sind.
Stimmt schon nur sagt die PDV/DV 800 (hab sie momentan nicht hier, daher
kann ich nicht zitieren)
das der 2m W/U Funk auf den Betriebskanälen nur für Übungs und
einsatzzwecke zu verwenden ist.
> ich sehe das nicht so eng und ich denke auch die bnetza nicht, da ihr
> auf dem camp nicht den funkdienst mitsbraucht sondern auch da übungen
> für eure feuerwehrarbeit.
Die Interessiert das herzlich wenig, habe schon 4 auf 2m Relais gesehen um
der knappheit an 4m Handfunkgeräten zu entgehen. Rechtlich gesehen
absolutes no-go aber kratzt keinen.
> es wird wird wohl einfacher sein, mehr dieser 2m funkgeräte zubesorgen
> und zusätlich ein sog. relais zu besorgen, welches du dann an einem
> hohen standort installieren müsstes... damit würdest jenach gegenheiten
> bis zu 30km und mehr abdecken.
Da kommen wir schonwieder zu diversen Problemen, BOS 2m Geräte sind eher
unerschwinglich (minimum 300eu).
Akkus sind relativ teuer. Und sie werden meißtens (99%) dafür angeschafft
um auf Fahrzeugen verlastet zu sein. Um im Ernstfalle (Einsatzfall) halt
Griffbereit zu sein.
Das wir derzeit fürs Zeltlager diese Menge an 2m aus dem Tagesgeschäft
rausziehen ist vielen aktiven Kammeraden ein riesiges Dorn im Auge. Und
ehrlich gesagt will ich das auch nicht mehr, weil Funk nur dann
funktioniert wenn alle richtig Mitspielen. Darüberhinaus habe ich selbst
schon oft die erfahrung gemacht das man oft im Feld bei den Kids, es nicht
mitbekommt wenn man selber gerufen wird. Und was passiert? 30sek. später
klingelt das Handy.
30km hört sich zwar verdammt lecker an, ist aber nicht das was ich will.
Fläche von ca 90.000 qm = quadrat von 300m :) (im idealfall)
> eine BTS für ein soches netz aufzubauen ist zu einem gewissen grad ein
> overkill...
Finde ich nicht. Derzeit habe ich zwar noch nicht wirklich Informationen
darüber welches Einzugsgebiet ich mit ner nanoBTS abdecken kann, aber
wenns was werden sollte denke ich das wir minimum 2 eher 3 BTS'n aufbauen
werden.
Derzeit habe ich noch keine offiziellen Preise gefunden, aber bereits den
Hinweis bekommen das die Kisten für rund 2.5keu über den Ladentisch
gehen.
Endgeräte finden sich in den meißten Haushalten. Ob man jetzt beigeht und
sein primär Handy verwendet, oder das vor-24Monats Modell welches in der
Schublade oxidiert, ist jetzt erstmal egal. Aber defakto ist doch das
Endgeräte vorhanden sind.
Weiterhin ist für mich entscheidend das niemand von mir eine Einweisung in
ein Handy braucht. Im regelfall weiß jeder wie sein Handy funktioniert und
wenn nicht... ich hab 2000 potentielle 1-Level-Supporter rumlaufen :D
Letztlich denke ich das in vielen Köpfren vorhanden ist, das GSM bzw.
Mobile Kommunikation immer was mit teurer Technik verbunden ist. Was
defakto durch die Arbeit des openBTS Projekts einfach nicht mehr der fall
ist. (An dieser Stelle nochmal vielen Dank für die tolle Arbeit)
Ausserdem warum nicht?
Was spricht dagegen GSM zu verwenden (und Geld ist für mich kein Grund)?
Gruß Henrik
Hi first i wan't to intoduce myself, i m henrik and am from germany.
my english isn't good as is should be but i hope everyone can understand
me. :)
I'm searching for a Siemens BS-11 GSM1800.
Why?
Im the technical operator of the biggest summer-camp in lower saxony /
germany of youth-fire-fighters.
I know hard to understand. :D
My plan is it, to operate a GSM zell on our camp next year.
some background informations:
-2000 youth member at the camp-ground.
-up to 200 tecnical supporters.
-300 youth supporters.
more informations about the event 2009: http://www.zeltlager-2009.de/
The Mainorganisators of the camp know about this idea, and are willing to
get a short-time licence for the event. The first contact to the
"Bundesnetzagentur" is already done.
What can i give the openBSC community?
A place to test / benchmark OpenBSC.
Also i'm a c / php developer and maybe i can help develope some external
features for openBSC.
Greetings from cold old Germany
Henrik