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 all,
Patch-file is attached - addresses a FIXME in abis_nm.c, parsing the
parameters passed by a Software Activate request. I've tested this on
three different IpAccess BTSs (including one which didn't work with the
original code), would be good if someone could check it on a BS11.
Best regards, Mike H.
Hey guys,
back in January I added ref-counting to the lchan and it has worked to some
degree, and we have seen ref-leaks as well (fixed thanks to Andreas). Currently
I'm working on integrating OpenBSC into a real MSC at on-waves.com and this
has made me read the GSM08.08 specification a bit more.
I would like to implement the following.
- Remove the refcount from lchan
- Replace it with the "transaction" concept. On certain 04.08 messgaes
(e.g. paging response, various MM messages) open a transaction
from BSC to MSC code. The channel is bound to the transaction.
The lchan is getting released when the transaction is finished, in
case of the "RSL chan" is going away too early there will be a
"clear" signal/method called from the BSC and the MSC side is asked
to let it go.
The benefit of this:
- BSC and MSC are better separated
- My MSC code could wrap the transaction into a SCCP connection
- Channel leak == transaction_free not getting called.
regards
holger
Hi Zecke,
I've been reviewing some of your patches:
> commit 45f9b3d3fc47074652be951eb74df2b0be2a230f
> Author: Holger Hans Peter Freyther <zecke(a)selfish.org>
> Date: Fri Aug 21 05:30:19 2009 +0200
>
> [paging] Use one of the two reserved LAC to page every BTS
>
> For the on-waves.com MSC case we want to page every BTS reached
> of the network. Our gsm_subscriber entry does not have a LAC
> entry set and defaults to zero. Use the reserved 0x0000 to
> indicate that we want to use every bts in the network.
>
> This will influence the paging code to start and stop paging.
The problem is that in the current code, we use LAC == 0 to indicate that the
subscriber has sent an IMSI DETACH message, i.e. switched his phone off.
You are now redefiniing the LAC 0 to something like the opposite case, which
I don't particularly like. Is there some alternative solution?
Regards,
--
- 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,
This week end I started coding a channel driver to integrate OpenBSC
and Asterisk directly.
You can find the code here http://github.com/smunaut/ast_chan_openbsc
The current public version is what I coded this Saturday, it doesn't
do much, only registers itself as a channel driver and runs the
openBSC core within asterisk. It will work only for the ip.access at
first (at least) because I'm directly bridging the RTP audio from the
nanoBTS to the RTP subsystem of Asterisk.
I spent a good part of today hacking together enough code to make a
call and it worked, I got bidirectional audio.
This latest code is not public yet because it's just a big mess and
only take care of setup and not cleanup (so you can do 1 call and then
restart :) With this hack, I just wanted to confirm that it could work
without too much problem. I will try to clean it up ASAP and publish
it so that there is a minimal functionality testable :)
OTOH, my time is limited and I split it between OpenBSC, OpenBTS and
airprobe so some weeks may be slow.
Sylvain
Hi everyone,
This evening I spent a few hours hacking a small test to activate
ciphering and I tought people might be interested with tinkering with
it. If you want to try for yourself, start off from the encryption
branch of Harald, then apply the 4 patches I just posted to this list
then apply the quick hack attached to this message.
This patch is not for merge since it's a gross hack just 'to see if it
works', and it does ! ( See the log in attachment )
What this patch does is pretty simple:
- When there is a location update, it does a AUTHENTICATION REQUEST
with a static RAND.
- When the AUTHENTICATION RESPONSE is received, it compares the
result with the 'known expected' results (see the wiki for AT commands
to get SRES and Kc for a given RAND)
- When sending a SMS to the MS, it activates the ciphering after
receiving the paging response with the 'known precomputed' Kc. If
everything goes well, the ME sends back a CIPHER MODE COMPLETE and the
rest of the talk is ciphered.
The included patch uses A5/2 but can be trivially modified for A5/1. I
just wanted to see if the iPhone would accept A5/2 and it doesn't
(works with A5/1 tough) ! My old Ericsson T610 takes A5/2 and A5/1.
Of course, this is no where near a good implementation but at least it
provides proof that the lower level functions works. I'm not sure
what's the best solution to get SRES and Kc. Most of the time getting
the Ki is not an option, so either we have a fixed RAND, or a bunch
RAND and corresponding SRES and Kc ... Or a side channel to run the
algo on the phone itself ...
Sylvain
commit 90e04861aa587d192025dd42aff5501e3742672a
Author: Sylvain Munaut <tnt(a)246tNt.com>
Date: Thu Sep 24 01:32:41 2009 +0200
[gsm_04_11] Free transaction on RX_RP_ACK for SMS
When only one SMS is sent, the freeing of the lchan will
automatically free all transactions on the lchan.
However, if there are several SMS sent at once, the call
to gsm411_send_sms_lchan will create a new transaction
with the same caracteristics as the previous one. If
the old one is not free'd, the next call to trans_find_by_id
(triggered by the next incoming RP-ACK) will not return the good
transaction and things go haywire.
Signed-off-by: Sylvain Munaut <tnt(a)246tNt.com>
openbsc/src/gsm_04_11.c | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
Hi,
has anyone tried running OpenBSC with the junghanns.net singleE1 MiniPCI card?
It has got the CologneChip HFC-E1 controller and seems to be supported by
mISDN. Target system would be an alix3d3.
cu,
Clemens
Hi,
I've noticed a problem when delivering several SMS to a mobile back-to-back.
The first one is ok, the second one is received by the MS but OpenBSC fails
with "RX RP-ACK but no sms in transaction?!?" when receiving the "RX SMS
RP-ACK (MO)"
(full log below)
From the symptoms and looking at the code, I would say that the transaction
of the first SMS delivery was not freed, therefore, when we receive the
RP-ACK of the second SMS, we do a trans_find_by_id in gsm0411_rcv_sms, and
we actually find the transaction of the _first_ deliver (which has its .sms
field cleared since it was released already).
I think you wouldn't notice if you waited between SMS because SMC Timer
TC1* would expire, calling trans_free().
The problem is that I don't really know _where_ trans_free should be
called. There are commented out call to it at several places ...
I would think the RP-ACK(MO) reception looks like a good place. But OTOH,
this whole process can queue data, giving away a reference to lchan
(without get) and trans_free does a put on lchan (so I guess that could
invalidate the lchan ref that was queued ? didn't check that in details)
Sylvain
--- SNIP ---
<0100> gsm_04_11.c:920 send_sms_lchan()
<0002> transaction.c:69 subscr=0x1fe52d0, subscr->net=0x1f8fc30
<0002> gsm_subscriber_base.c:131 subscr 46332 usage increases usage to: 4
<0002> gsm_04_11.c:937 lchan (bts=0,trx=0,ts=0,ch=0) increases usage to: 1
<0100> gsm_04_11.c:972 TX: SMS DELIVER
<0100> gsm_04_11.c:188 TX: CP-DATA trans=4
<0100> gsm_04_11.c:149 GSM4.11 TX 49 01 1e 01 2a 07 91 44 77 58 10 06 50 00
12 00 05 b9 72 65 f7 00 00 90 80 72 12 03 41 00 02 44 3a
<0001> abis_rsl.c:1215 channel=(bts=0,trx=0,ts=0) chan_nr=0x20 sapi=3 DATA
INDICATION
<0100> gsm_04_11.c:817 trans_id=c RX SMS CP-ACK
<0001> abis_rsl.c:1215 channel=(bts=0,trx=0,ts=0) chan_nr=0x20 sapi=3 DATA
INDICATION
<0100> gsm_04_11.c:817 trans_id=c RX SMS CP-DATA
<0100> gsm_04_11.c:191 TX: CP-ACK trans=4
<0100> gsm_04_11.c:149 GSM4.11 TX 49 04
<0100> gsm_04_11.c:750 RX SMS RP-ACK (MO)
<0002> gsm_subscriber_base.c:139 subscr 27567 usage decreased usage to: 0
<0002> gsm_subscriber_base.c:139 subscr 46332 usage decreased usage to: 3
DB: Found Subscriber: ID 2, IMSI 206205003327508, NAME '', TMSI 1666608304,
EXTEN '27567', LAC 1, AUTH 1
DBI: -7: The requested variable type does not match what libdbi thinks it
should be
<0002> gsm_subscriber_base.c:131 subscr 46332 usage increases usage to: 4
<0100> gsm_04_11.c:920 send_sms_lchan()
<0002> transaction.c:69 subscr=0x1fe52d0, subscr->net=0x1f8fc30
<0002> gsm_subscriber_base.c:131 subscr 46332 usage increases usage to: 5
<0002> gsm_04_11.c:937 lchan (bts=0,trx=0,ts=0,ch=0) increases usage to: 2
<0100> gsm_04_11.c:972 TX: SMS DELIVER
<0100> gsm_04_11.c:188 TX: CP-DATA trans=4
<0100> gsm_04_11.c:149 GSM4.11 TX 49 01 1f 01 2a 07 91 44 77 58 10 06 50 00
13 00 05 b9 72 65 f7 00 00 90 80 72 12 03 41 00 03 47 39 19
<0001> abis_rsl.c:1215 channel=(bts=0,trx=0,ts=0) chan_nr=0x20 sapi=3 DATA
INDICATION
<0100> gsm_04_11.c:817 trans_id=c RX SMS CP-ACK
<0001> abis_rsl.c:1215 channel=(bts=0,trx=0,ts=0) chan_nr=0x20 sapi=3 DATA
INDICATION
<0100> gsm_04_11.c:817 trans_id=c RX SMS CP-DATA
<0100> gsm_04_11.c:191 TX: CP-ACK trans=4
<0100> gsm_04_11.c:149 GSM4.11 TX 49 04
<0100> gsm_04_11.c:750 RX SMS RP-ACK (MO)
<0100> gsm_04_11.c:640 RX RP-ACK but no sms in transaction?!?
<0100> gsm_04_11.c:561 TX: SMS RP ERROR, cause 111 (Protocol Error)
<0100> gsm_04_11.c:188 TX: CP-DATA trans=4
<0100> gsm_04_11.c:149 GSM4.11 TX 49 01 04 05 2a 01 6f
<0001> abis_rsl.c:1215 channel=(bts=0,trx=0,ts=0) chan_nr=0x20 sapi=3 DATA
INDICATION
<0100> gsm_04_11.c:817 trans_id=c RX SMS CP-ACK
<0100> gsm_04_11.c:159 SMC Timer TC1* is expired, calling trans_free()
<0002> transaction.c:101 lchan (bts=0,trx=0,ts=0,ch=0) decreases usage to: 1
<0002> gsm_subscriber_base.c:139 subscr 46332 usage decreased usage to: 4
--- /SNIP ---
Hello Sylvain,
On Thu, 24 Sep 2009 02:13:45 +0200, "Sylvain Munaut" <246tnt(a)gmail.com> wrote:
>
> This evening I spent a few hours hacking a small test to activate
> ciphering and I tought people might be interested with tinkering with
> it. If you want to try for yourself, start off from the encryption
> branch of Harald, then apply the 4 patches I just posted to this list
> then apply the quick hack attached to this message.
Great that you provide the patches, I did a proof a concept implementation a
while ago (http://lists.gnumonks.org/pipermail/openbsc/2009-July/000584.html).
However I never found the time to actually complete it, so now I don't have
to care any more :-)
Best regards,
Dieter
--
Dieter Spaar, Germany spaar(a)mirider.augusta.de
Hi!
I'm surprised that this list is so quiet... no mails for more than a week
already.
Is anybody still playing with, developing or using OpenBSC? I would really
appreciate more community participation, such as
* more documentation in the wiki
* talk about what you're doing with OpenBSC (esp. the universities!)
* discussion / sharing of your experience
* bug reports (should probably go in trac)
* patches!
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)
commit 7aa86ed1e8669bcd06970ba23a1ff5abd5da81e6
Author: Sylvain Munaut <tnt(a)246tNt.com>
Date: Thu Sep 24 01:44:24 2009 +0200
[gsm_04_08] Fix gsm48_send_rr_ciph_mode algorithm ID
The algorithm ID used in the GSM 04.08 RR message is
(x-1) for A5/x. In RSL it's (x+1) for A5/x so there is
a difference of 2.
Signed-off-by: Sylvain Munaut <tnt(a)246tNt.com>
openbsc/src/gsm_04_08.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
Hi all!
I have recently been informed there is a job opening related to OpenBSC
in Dresden / Germany. So if you're interested in working full time on
issues such as
* integrating OpenBSC into actual applications / products
* testing OpenBSC with various handsets in various scenarios
* sending bug reports and interacting with actual developers
The job is not really about development of the OpenBSC stack itself, but
related to system integration. So don't worry if you are neither a full-blown
programmer, nor know the GSM protocol specs up to the last bit ..
Please drop me a note, in case you're interested.
Regards,
--
- 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 joerg,
i am not into debian. can you explain:
- what files in your directory http://www.dorchain.net/~joerg/code/debian/
should be added to the git repository?
- where should they be located? (inside lcr directory)
- what files of original lcr or mISDN git are changed?
thanx in advance,
andreas
Hello all,
Just thought I would give everyone an update on my progress with the
Ericsson RBS. I got a T1 card, a Digium TE122P
(http://www.digium.com/en/products/digital/te122.php). This card support
E1/T1/J1. The 2401 I have only supports T1, otherwise I would have gotten a
HFC based chipset that OpenBSC supports.
The TE122P uses the DAHDI drivers, which used to be Zaptel. In reading
through the list archives, I found a couple tidbits about Zaptel.
The first was back in February from Harald:
http://lists.gnumonks.org/pipermail/openbsc/2009-February/000023.html. I
didn't see any updates after that. Were there updates made to make the
integration with other drivers easier?
The next I found was in March from Klaus-Peter Junghann:
http://lists.gnumonks.org/pipermail/openbsc/2009-March/000064.html. It looks
like he actually got the Zaptel driver to work. I'm not sure how much of
Zaptel has changed when the driver set was renamed to DAHDI. I did not see a
post from Mr. Junghann with the zaptel input module he spoke of.
I'm not sure what the interest level is with getting OpenBSC to integrate
with Ericsson RBS's? Like I previously mentioned, I am not much of a coder,
so I can't help much in that department. That being said, I am willing to
provide remote access to all the resources I have here (Debian Linux 5.0
Server, RBS 2401, Windows LMT). I can also provide access to a spec an
(which would be accessed via software on the Windows LMT) if needed down the
road. I am going to look into a STA to test on a couple ARFCN's in the
GSM1900 band, and I am more than willing to help with handset debugging at
that stage. I have quite a few different handsets lying around!
Thanks much,
Caleb
Hello,
While experimenting with a Motorola V3 GSM branded for AT&T, I enabled the
Engineering Menu with a SEEM edit. Not a terribly hard procedure once you
know where to look. After performing this hack, I looked in the Engineering
Menu, and there is an option to force the ARFCN the phone camps on. I think
this would be a useful tool if you want to force a handset to camp on your
Base Station. I'm not if it will help with the clock issues, but it might
alleviate some frustration. The Original V3's (no 3G) can be found on ebay
for a decent price. I'm not sure if any other phones include this
functionality (I haven't come across any), so I thought I would share it
with you all. If you need help performing the SEEM edit, let me know.
Caleb
hi harald,
>Of course this will mean that we need to develop the RTP-to-MNCC
integration, since nanoBTS voice channels arrive on RTP. I am willing
to look into this, but I presume you also have a big interest in that
(and maybe more time?).
i am interested having RTP audio available to MNCC interface as well.
the audio stream (frames) should be equal for BS11 and nanoBTS, so both
streams work for MNCC interface without different handling on the
application side. for this i would like to cross-convert the frame
coding of BS11 to the actual gsm format inside OpenBSC instead of just
forwarding the TRAU frame format. if the TRAU frame is converted inside
OpenBSC, calls from BS11 to nanoBTS would also be possible.
>Since I now own more nanoBTS, I could send you one for 1-2 months of
development of that code. Are you interested in this?
yes, i am. this way it is easier to run some tests.
regards,
andreas
Hello All,
While testing DTMF facilities of OpenBSС I've discovered a couple of
bugs.
The first bug is generic to GSM TS 04.08, minor and is connected with
gsm0408_cc_msg_names variable
(gsm_04_08_utils.c). I've found that message names order is wrong: in
original source it is enumerated as
...
"unknown 0x3b",
"STATUS",
"unknown 0x3c"
"NOTIFY"
...
while it should be
...
"unknown 0x3b"
"unknown 0x3c"
"STATUS"
"NOTIFY"
...
thus faling to identify GSM 04.08 STATUS messages.
The second problem is connected with DTMF message sequence. According
to the GSM TS 04.08, DTMF
message flow is the following:
MS -----> START_DTMF
MNCC_START_DTMF_IND ----> MNCC
MNCC_START_DTMF_RSP <---- MNCC
MS <---- START_DTMF_ACK
MS ----> STOP_DTMF
MNCC_STOP_DTMF_IND ----> MNCC
MNCC_STOP_DTMF_RSP <---- MNCC
MS <---- STOP_DTMF_ACK
This is correct, but some mobile equipment (for example, my iPhone and
Nokia 6150) do not reply with
STOP_DTMF message; instead of this, they reply with STATUS message
(type 0x3D). This type of messages is
not processed within OpenBSC. Message is left unhandled in this state
and further DTMF transactions
become impossible because MNCC does not receive DTMF_STOP.
GSM standard says that STATUS message reports about some errors
occurred during transaction, but I
did not explore the message still, though, I can do that if it is
interesting for developers. I have no ideas why
some of my mobile phones behave wrong, while others work correctly.
I still don't know how to deal with STATUS messages properly, so I've
simply added processing entry to the
datastatelist[] variable in gsm_04_08.c which describes a call to
gsm48_cc_rx_stop_dtmf when received a
STATUS message.
It is incorrect, I know, but, however, temporary helps to process DTMF
messages with MS equipment which
have wrong DTMF sequence flow. Now it looks like this:
MS -----> START_DTMF
MNCC_START_DTMF_IND ----> MNCC
MNCC_START_DTMF_RSP <---- MNCC
MS <---- START_DTMF_ACK
MS ----> STATUS
MNCC_STOP_DTMF_IND ----> MNCC
MNCC_STOP_DTMF_RSP <---- MNCC
MS <---- STOP_DTMF_ACK
Sergey.
hi,
i just uploaded a new version of linux-call-router at
www.linux-call-router.de. this version is equal to the current git.
it has fixes, one is about conference creation and release. calls can
now be forwarded by joining conference during ringing state: "*3#" and
you may hang up, the party on hold will get transfered to the ringing
phone.
the major reason for a release is that OpenBSC main branch can be
compiled with LCR, without any patch.
hope you enjoy,
andreas
hi,
to connect multiple BS11 to one single E1 interface via cascade, a
special patch was required. now it is part of the mISDN GIT. (socket
branch)
use these module options:
modprobe hfcmulti dmask=0x00000042 bmask=0x0000003c,0x00000780
debug=0x40000
the dmask will give a dchannel mask for the first E1 interface. multiple
masks can be given for multiple E1 interfaces.
the dmask will have bit set for each dchanne. in the example we have two
bits set: slot 1 and slot 6.
the bmask will give a bchannel mask for each given dchannel bit:
for dchannel on slot 1 we use slot 2,3,4,5 for bchannel
for dchannel on slot 6 we use slot 7,8,9,10 for bchannel
the debug option displays initialization of E1 card on dmesg.
misdn_info:
Port 1 'hfc-e1.2-1': TE/NT-mode PRI E1 (for phone lines & E1
devices)
4 B-channels: 2-5
--------
Port 2 'hfc-e1.2-2': TE/NT-mode PRI E1 (for phone lines & E1
devices)
4 B-channels: 7-10
regards,
andreas