I have some questions:
1) When I start bsc_hack bsc_init.c first establishes OML link and
initializes the bts then it establishes RSL link and bts starts
broadcasting. However, it takes so much time to start the bts. Instead of
this I want to do the following: it establishes OML link at the beginning
and only once, then when i want to start broadcasting it establishes just
the RSL link and bts will start faster since i don't have to wait for OML
link. What should be done for this?
2) If i send one or two word messages from telnet interface it is okay. But
if i send a longer message the phone could't receive the end of the message
correctly(last words may be incomplete). Did any one encounter with this
problem? What is wrong with me?
3) Could I send SMS in which extension of the sender is text not integer.
For example, i want to send an information SMS that this is a test network.
For this purpose i want to send an SMS from 'OpenBSC'. I set the extension
of the first subscriber in database as text and tried to send the SMS but
SMS wasn't delivered. What should i do?
4) Can i add SMS externally to SMS table of database?
Thanks.
Jason
Hi all,
Maybe I'm missing something, but I haven't found an easy way to
download pdf versions of all the 3gpp specs. Why would you want to do
that? Well, dealing with MS-Word format is a pain. And, there's no
online full-text search of all the specs.
So, I threw together a quick web scraper to pull down the latest
version of all the 3GPP specs from the ETSI web site in pdf format.
Thought it might be useful to others -
http://monkey.org/~joe/files/fetch_3gpp.py
Feel free to contact me if you have any trouble using it.
-Joe
Hello guys,
I haven't been busy with openbsc for a while, however, I was following
the mailing-list.
I have the following question, is timing advance also implemented for
the nanoBTS? Cause I don't really know where to look in the sources,
thank you.
Nothing required actually.
The firmware is preloaded.Just configure the Nanobts using the installation
CD given.
Some jar file is there for configuring part.
> https://lists.osmocom.org/mailman/listinfo/openbsc
> or, via email, send a message with subject or body 'help' to
> openbsc-request(a)lists.osmocom.org
>
> You can reach the person managing the list at
> openbsc-owner(a)lists.osmocom.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of OpenBSC digest..."
>
>
> Today's Topics:
>
> 1. Re: How to download firmware and configure NanoBTS the first
> time... (Harald Welte)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Wed, 16 Feb 2011 22:52:33 +0100
> From: Harald Welte <laforge(a)gnumonks.org>
> Subject: Re: How to download firmware and configure NanoBTS the first
> time...
> To: Omar Atia <omar.atia(a)its.ws>
> Cc: 'Peter Hasse' <peter.hasse(a)fokus.fraunhofer.de>,
> openbsc(a)lists.osmocom.org
> Message-ID: <20110216215233.GO25856(a)prithivi.gnumonks.org>
> Content-Type: text/plain; charset=us-ascii
>
> Omar,
>
> how should we know in what you get your particular nanoBTS units delivered?
>
> You have to talk to your supplier about that.
>
> For all I know, it is customary for the nanoBTS to ship with pre-installed
> firmware. Based on your support contract with ip.access you may receive
> firmware updates from time to time, which you can then apply either using
> tools from ip.access or using our ipaccess-config. Our tool is of course
> not officially recognized/authorized/recommended/endorsed for this purpose.
>
> 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)
>
>
>
> ------------------------------
>
> _______________________________________________
> OpenBSC mailing list
> OpenBSC(a)lists.osmocom.org
> https://lists.osmocom.org/mailman/listinfo/openbsc
>
>
> End of OpenBSC Digest, Vol 26, Issue 15
> ***************************************
>
hi harald,
i would also suggest to combine mncc.h of openbsc and osmocom-bb first, and move it to libosmocore. this way the LCR (or other mncc_socket client) does not depend on any files of openbsc and osmocom-bb, just on libosmocore.
because i like to use the same socket interface for osmocom-bb, i would suggest to to put mncc_sock.c into libosmocore too, so it must not be implemented twice.
then i would make lcr to be able to connect to both osmocom-bb and openbsc sockets. finally there is no more polling of file descriptor required at lcr.
if you agree, can you move the code to libosmocore? i will work on the socket configuration and see what i can do with the versioning.
andreas
-----Ursprüngliche Nachricht-----
Von: Harald Welte [mailto:laforge@gnumonks.org]
Gesendet: Dienstag, 22. Februar 2011 13:22
An: Andreas.Eversberg
Cc: openbsc(a)lists.gnumonks.org
Betreff: Re: fix of chan_lcr / new socket interface for openbsc
Andreas,
thanks for integrating the mncc socket patch into lcr.
I would personally like to see the following improvements:
* add some (preferrable automatically computed) version to the mncc,
to make sure you cannot run lcr + bsc_hack built from a different mncc.h
file. We could do something like a md5sum over the header at compilation
time, stored in both openbsc and lcr. Once they connect the mncc socket,
they request the remote side md5-value and compare it with the local-side
value. If they don't match, print an error message and exit the program.
* make the socket path configurable, which is required for running multiple
instances of openbsc+lcr on the same machine.
If you (or anyone else on this list) happens to have some time to work on
that, it would be greatly appreciated.
Regards,
Harald
hi,
the broken chan_lcr is now fixed in the "develop" branch of lcr git. i
have tested it with asterisk 1.8.1. the locking seems to be improved in
this asterisk version. i could not run it in a deadlock, as i could with
asterisk 1.6. i would suggest to try this out, but please keep your
current asterisk and lcr sources. if all works fine, i would like to
merge the "develop" branch into the "master" branch soon.
for the gsm users: the second change in the "develop" branch is the
socket interface between openbsc and lcr. thanks to harald welte for
providing this patch. instead of linking openbsc to lcr, openbsc runs
it's own process. (using bsc_hack as usual) lcr connects to a socket of
openbsc. with it, the gsm.conf became obsolte and has been removed from
lcr. in order to run lcr with openbsc ("master" branch of openbsc) :
bsc_hack -P -m -l <sqlite-database> -c <openbsc-config>
-P is required to enable rtp proxy for use with ipaccess bts.
-m is required to allow call control via socket interface
to get lcr from "develop" branch, do:
git-clone git://git.misdn.org/git/lcr.git/
cd lcr
sh checkout-branch.sh develop
regards,
andreas
Hi!
With the help of graphviz, I have written a small perl-based tool that
allows you to generate ladder diagrams. It can be found at
git://git.osmocom.org/gen_ladder.git
For your reference, I'm attaching a sample input and output file.
The bent/curved arrows are a result of graphviz trying to indicate
that the message is between e.g. MS and MSC and 'bypasses' BTS and BSC.
I'm still waiting for somebody with more graphviz skills to make this an
option.
Hope this is useful for some of you...
--
- 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,
I just stumbled over the following change in libosmocore
diff --git a/src/vty/Makefile.am b/src/vty/Makefile.am
index 7353ab8..8d730c3 100644
--- a/src/vty/Makefile.am
+++ b/src/vty/Makefile.am
@@ -10,5 +10,5 @@ lib_LTLIBRARIES = libosmovty.la
libosmovty_la_SOURCES = buffer.c command.c vty.c vector.c utils.c \
telnet_interface.c logging_vty.c
-libosmovty_la_LIBADD = $(top_builddir)/src/libosmocore.la
+libosmovty_la_LIBADD = -losmocore $(top_builddir)/src/libosmocore.la
endif
from commit 2822296d
The -losmocore seems wrong as it is the library we're building here and
it's not necessarily already installed.
If I remove that part libosmocore builds for me again.
Regards,
Daniel Willmann
Hi,
as probably for most of us an official (testing) licence is out of reach, is
there a "workaround" for this problem?
- Is there some part of the official gsm bands that overlaps with local ISM
or other not-so-tightly-regulated frequencies?
(i.e, GSM1900 seems to have a small part that's not used by DECT...)
- Are there any "standard" gsm handsets that could be modified (preferably
in software) to work at 2,4GHz?
- Is UMA/GAN (http://en.wikipedia.org/wiki/Generic_Access_Network) something
that could be used with OpenBSC? As far as i understand the specification,
UMA is GSM Layer 3 over an GPRS/IPSEC tunnel to the BSC, so all the
GSM-Goodies should be there.
I realize the first two options would not exactly make it legal, but i'd
prefer the wrath of my neighbors over the suicide-squad from a carrier or
regulatory agency ;).
Any comments?
Regards,
Jay
Dear sir
I am new to openbsc.I have two NanoBTS(165cu).I'm facing some difficulty
which I'm summarizing below
I'm using Ubuntu10.04
1) Can we proceed with one nanobts.?
2)I've configured bts ip,unit id, oml ip of one bts.But not able to get the
firmware.
How to get it and configure for NanoBTS??
3)how to run openbsc ??
Please suggest the procedure to run the openbsc.
Thanks
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)
For our ongoing experiment, we are hoping to tether some laptops onto the
EDGE connection, either through a USB style dongle or a USB cord into a
phone that allows it to be treated like a modem (And for some old school
phones, maybe even a Serial port connection). These situations require a
number to be dialed, what I believe is a USSD code, and sometimes a username
and password to be entered. I am not talking about newer smart phones where
the connection is sometimes shared using advanced drivers. Has anyone been
able to do this with OpenBSC?
Chris Rankine
Hi all,
Some people have been working together in order to finally start with
support of the Ericsson RBS2308 (and similar models) in OpenBSC.
The biggest issue so far is bringing up the actualy LAPD on the E1/T1 link.
It seems Ericsson is using some dynamic timeslot configuration between BSC
and BTS, so unlike e.g. Siemens, you cannot explicitly configure the OML E1
timeslot on the BTS using local configuration tools.
The current working assumption is: Somehow the BSC produces bit-patterns on the
E1 link and uses them to let the BTS know where to start LAPD for OML.
One contributor was friendly enough to do raw bit-traces of a Racal 6113
connected to the Ericsson RBS, and they look like this:
Racal to BTS
Initialization
openbsc:/etc/dahdi# cat /dev/dahdi/1 | hexdump
0000000 aaaa aaaa aaaa aaaa aaaa aaaa aaaa aaaa
*
00092e0 aaaa aaaa aaaa aaaa aaaa aaaa aaaa 55aa
00092f0 ffff ffff ffff ffff ffff ffff ffff ffff
*
0009600 ffff ffff ffff ffff ffff ffff ffff 7e7e
0009610 7e7e 7e7e 7e7e 7e7e 7e7e 7e7e 7e7e 7e7e
*
00096b0 7e7e 7e7e 7e7e 7e7e 7e7e 7e7e 7e7e 5f7e
00096c0 3e5f 49ce cfef cfcf cfcf cfcf cfcf cfcf
00096d0 cfcf cfcf cfcf cfcf cfcf cfcf cfcf cfcf
*
I've written a small C program to do soft-hdlc decode.
* a pattern of alternating bits (0xaa)
* a pattern of all-1 bits(0xff)
* a sequence of FLAG symbols (01111110)
* a HDLC message FA 7D 7F 4E F2, which is a TEI=62/SAPI=62 SABME
(SAPI 62 / TEI62 is configured for OML on the BTS)
The interesting part is:
1) this is a SABME from BSC to BTS, whereas GSM 08.56
specifically says the BTS is the TE and the BSC the NT
2) we have not seen any TEI manager related messages(L2ML)
Keep alives afterwards, about every 8 seconds
001d5e0 cfcf cfcf cfcf ebcb 04e4 a805 f323 f3f3
001d5f0 f3f3 f3f3 f3f3 f3f3 f3f3 f3f3 f3f3 f3f3
*
0031630 f3f3 f2f3 f9fa 0101 086a fcfc fcfc fcfc
0031640 fcfc fcfc fcfc fcfc fcfc fcfc fcfc fcfc
*
0045680 fcfc fcfc fcfc fcfc fcfc fcfc bebe 4040
0045690 825a 3f3f 3f3f 3f3f 3f3f 3f3f 3f3f 3f3f
00456a0 3f3f 3f3f 3f3f 3f3f 3f3f 3f3f 3f3f 3f3f
*
00596e0 3f3f 2f3f 90af 1610 8fa0 cfcf cfcf cfcf
00596f0 cfcf cfcf cfcf cfcf cfcf cfcf cfcf cfcf
*
006d730 cfcf cfcf cfcf cfcf cbcf e4eb 0504 23a8
006d740 f3f3 f3f3 f3f3 f3f3 f3f3 f3f3 f3f3 f3f3
*
0081790 faf2 01f9 6a01 fc08 fcfc fcfc fcfc fcfc
00817a0 fcfc fcfc fcfc fcfc fcfc fcfc fcfc fcfc
*
00957e0 fcfc fcfc fcfc befc 40be 5a40 3f82 3f3f
00957f0 3f3f 3f3f 3f3f 3f3f 3f3f 3f3f 3f3f 3f3f
If you decode this, you get
FA 7D 01 01 AD 20 (LAPD RR)
FA 7D 01 01 21 AC (LAPD RR)
FA 7D 01 01 AD 20 (LAPD RR)
FA 7D 01 01 AD 20 (LAPD RR)
FA 7D 01 01 AD 20 (LAPD RR)
FA 7D 01 01 AD 20 (LAPD RR)
FA 7D 01 01 AD 20 (LAPD RR)
If we look at the BTS to Racal 6113 side:
Initialization
openbsc:/etc/dahdi# cat /dev/dahdi/1 | hexdump
0000000 e7e7 e7e7 e7e7 e7e7 e7e7 e7e7 e7e7 e7e7
*
000fe00 e7e7 e7e7 e7e7 e7e7 e7e7 e7e7 e5e7 f3f5
000fe10 1039 f971 f9f9 f9f9 f9f9 f9f9 f9f9 f9f9
000fe20 f9f9 f9f9 f9f9 f9f9 f9f9 f9f9 f9f9 f9f9
*
Keep Alives, every 8 seconds
0023e40 f9f9 f9f9 f9f9 f9f9 f9f9 7c7d 8080 04b5
0023e50 7e7e 7e7e 7e7e 7e7e 7e7e 7e7e 7e7e 7e7e
*
0037ea0 5f5f 2020 412d 9f1f 9f9f 9f9f 9f9f 9f9f
0037eb0 9f9f 9f9f 9f9f 9f9f 9f9f 9f9f 9f9f 9f9f
*
004bef0 9f9f 9f9f 9f9f 9f9f 979f c8d7 0b08 4750
004bf00 e7e7 e7e7 e7e7 e7e7 e7e7 e7e7 e7e7 e7e7
*
005ff40 e7e7 e7e7 e7e7 e7e7 e7e7 e7e7 e7e7 f5e5
005ff50 02f2 d402 f911 f9f9 f9f9 f9f9 f9f9 f9f9
005ff60 f9f9 f9f9 f9f9 f9f9 f9f9 f9f9 f9f9 f9f9
*
0073fa0 f9f9 f9f9 f9f9 7c7d 8080 04b5 7e7e 7e7e
0073fb0 7e7e 7e7e 7e7e 7e7e 7e7e 7e7e 7e7e 7e7e
*
0087ff0 7e7e 7e7e 7e7e 7e7e 7e7e 7e7e 5f7e 205f
0088000 2d20 1f41 9f9f 9f9f 9f9f 9f9f 9f9f 9f9f
0088010 9f9f 9f9f 9f9f 9f9f 9f9f 9f9f 9f9f 9f9f
*
009c050 9f9f 9f9f 979f c8d7 0b08 4750 e7e7 e7e7
009c060 e7e7 e7e7 e7e7 e7e7 e7e7 e7e7 e7e7 e7e7
*
Decoded, we get:
FA 7D 73 60 3A (LAPD UA)
FA 7D 01 01 AD 20 (LAPD RR)
FA 7D 25 25 AD 20 (LAPD unknown??)
FA 7D 01 01 AD 20 (LAPD RR)
FA 7D 01 01 AD 20 (LAPD RR)
FA 7D 01 01 AD 20 (LAPD RR)
FA 7D 01 01 AD 20 (LAPD RR)
FA 7D 01 01 AD 20 (LAPD RR)
So as a summary, it seems that
1) the BSC applies some magic pattern (0xaa / 0xff)
2) the BSC establishes the LAPD session for OML TEI/SAPI
3) there is no L2ML, contrary to lots of Ericsson Abis documentation
that you can find online.
We'll continue our attempts and see if we can get the OML up...
--
- 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)
This is probably completely off-topic, but can thoses nano-bts also be
used for data, instead of voice?
I don't mean sms, but access to email and so-on.
It is not about performance, but being able to test gsm-dongles for
wireless internet. (not wifi)
Hans
hello
my 2nd bs-11(bts 1) has a defective trx0, so no c0 can be created. lets
have a look at gsm_bts_trx_alloc in gsm_data.c:
i changed
trx->bts = bts;
trx->nr = bts->num_trx++;
trx->nm_state.administrative = NM_STATE_UNLOCKED;
to
trx->bts = bts;
if(bts->nr == 1) {trx->nr = 1;}
else {trx->nr = bts->num_trx++;}
trx->nm_state.administrative = NM_STATE_UNLOCKED;
in gsm_bts_alloc, the primary trx should be created then, in the case of
bts 1 starting at trx1, since trx0 dont exist
unfortunately, i get a general protection fault :-(
hints very velcome!
T.
--
Wer Rechtschreibfehler findet, darf sie behalten!
hi list,
i came over line 523 in gsm_data.h:
/* CCCH is on C0 */
struct gsm_bts_trx *c0;
could this be the reason why a bs-11 without aktivated trx0 dont work /
isnt seen by handy?
T.
--
Wer Rechtschreibfehler findet, darf sie behalten!
Hi,
I've been playing with Dahdi and OpenBSC (I have an old T100P card) and
something I'm a little confused about is what is the proper configuration
for system.conf?
Does dahdi itself take care of the hdlc/lapd signalling (in which case I'd
expect the signalling channel to be set as dchan in
/etc/dahdi/system.conf) or is openbsc taking care of the hdlc/lapd
signalling (in which case I'd expect the signalling channel to be set as
clear)?
Thanks,
Gus Bourg
Hi!
Today I've been working on improving + cleaning up the DAHDI work that
had been done last year by Xavier Carcelle and Matthew Fredrickson, which in
turn uses some simplistic LAPD implementation by Oystein Homelien.
It now seems to be working fine, at least for my TE110P card and a BS-11
in 2-TRX configuration. Haven't tried multi-drop yet.
All you need to do is to
* make sure your dahdi/user.h is found in the include path
* build openbsc
* configure your /etc/dahdi/system.conf according to your T1/E1 physical
setup
* check that dahdi_tool shows no Alarms for the physical line
* use e.g. openbsc.cfg.1-1 as sample and change 'e1_line 0 driver misdn' to
'e1_line 0 driver dahdi'
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)
Notice to all OpenBSC users with mISDN / BS-11:
I've had to introduce some new config file statements in order for the
upcoming DAHDI support.
This means if you update beyond git revision
3016d9f299ea4cfc8961376d20862b9418cfb059, openbsc will not start with
an old 'openbsc.cfg' file.
You will have to add the following two lines to make it work again
(like shonw in the new openbsc.cfg.1-1):
==============
e1_input
e1_line 0 driver misdn
==============
Sorry for that inconvenience.
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 all,
I am trying to implement a bluetooth RSAP daemon for the iPhone platform.
I read your description on http://openbsc.osmocom.org/trac/wiki/A5_GSM_AT_tricks .
Unfortunately it does not seem to work on my phone.
It always returns error code 0x6E00 for class 0xA0 (GSM application) commands:
> AT+CSIM=14,"A0A40000023F00"
> +CSIM: 4,"6E00"
Which iPhone version and "baseband" firmware was used when doing these
experiments? Any further tips?
By the way, it is better to use one of the virtual serial lines,
e.g. /dev/dlci.spi-baseband.extra_13 to access the X-Gold 608 when doing normal
stuff rather than using the real UART interfaces (/dev/tty.debug etc.) because
one does not need to unload CommCenter to have a reliable connection.
--j
--
Jens David, DG1KJD
jens.david(a)jens-david-consulting.com
http://www.jens-david-consulting.com
Hello everybody,
after setting up a nanoBTS with OpenBSC/SGSN/GGSN,
I had some troubles trying to connect my smartphone
to the GPRS cell.
Investigating the BTS-to-SGSN traffic, I saw that the
frames sent by the SGSN were all marked with the same
N(U) value (at LLC layer), the value was 0.
With some debug, I found that the there was a mismatch
in the TLLI storage, used to keep the status of attached
terminals.
The mentioned code is contained in gprs_llc.c, involving
LL Entity functions and gprs_llc_tx_ui().
/* look-up or create the LL Entity for this (TLLI, SAPI) tuple
*/ lle = lle_by_tlli_sapi(msgb_tlli(msg), sapi);
if (!lle) {
struct gprs_llc_llme *llme;
LOGP(DLLC, LOGL_ERROR, "LLC TX: unknown TLLI 0x%08x, "
"creating LLME on the fly\n", msgb_tlli(msg));
llme = llme_alloc(msgb_tlli(msg));
lle = &llme->lle[sapi];
}
The TX function uses the previously received TLLI to
lookup for the LLE. The lle_by_tlli_sapi() performs the
search, but preliminary it applies a foreign2local TLLI
conversion to ensure to have a local one.
Since no valid entry for the searched TLLI is found,
a new one is created. And the problem is here.
The new entry has the foreign TLLI.
Next time the lookup fails again, and a new entry is created.
This way, the counter N(U) is always reset, and the
mobile do not recognize the message sequence and no attach
is possible.
My question is about foreign and local TLLIs.
I patched the lookup, avoiding the conversion, so that the
LLE is found and everything works fine... but...
What is the sense of the conversion?
Should the TLLI be always stored as a local one?
Can this problem be solved with another foreign2local
while allocating new entries?
Actually, my problem has been solved with that workaround.
But I'm curious to know what is the right way.
Hope somebody can answer :)
Thanks.
Cheers,
LM
Hello Holger,
On Wed, 02 Feb 2011 12:40:13 +0100, "Holger Hans Peter Freyther" <holger(a)freyther.de> wrote:
>
> OpenBSC does not support data calls. You could start implementing it though,
> we should have all the enum values and structs that you need to send the right
> messages to the MS.
You mean CSD ? Then its most certainly also necessary to implement RLP
(Radio Link Protocol) which is the protocol used for non-transparent
CSD. At least I did not manage yet to get a reliable CSD connection
between two phones by just connecting the data traffic between them
(I tried transparent and non-transparent modes).
Best regards,
Dieter
--
Dieter Spaar, Germany spaar(a)mirider.augusta.de
hi list,
have to sync one of my bs-11. got the hfc-s card and soldered the 2
wires.
is any driver needed for the hfc-s?
or is the clock always on c4io and f0io once the card is plugged in?
the hfcmulti driver loads the e1 card, i have a bmask and a dmask
parameter in modprobe.conf. should i remove them or just hang on the
"type=0x00800"?
i have only one try, so i want to clear all possible problems before
T.
--
Wer Rechtschreibfehler findet, darf sie behalten!
Hi,
Can You please help me how to setup a session - packet or CS call session and capture trace messages - protocol traces , Alarms, Performance Management Counters and CDR?
It will be very kind of you if you help me in this issue.
Regards,
Piyush
Please do not print this email unless it is absolutely necessary.
The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s) and may contain proprietary, confidential or privileged information. If you are not the intended recipient, you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately and destroy all copies of this message and any attachments.
WARNING: Computer viruses can be transmitted via email. The recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email.
www.wipro.com
This Femtocell looks both from a pricing point of view as from a hardware
point of view very interesting. Now that the integration in OpenBSC looks
very promising it would become a good alternative for the more expensive
ip.access picocells. It seems that these HSL femtocell can not be bought
without first investing in the developers pack from HSL which cost as much
as 7000$. Does anyone know how to obtain one of these cells for a
reasonable price? Are they already deployed by operators?
Looking at the internal hardware, it may even become a substitute for the
USRP's....