Hello guys,
Suppose I have 8 MS registered on my nanoBTS and the ninth wants also to
register. How can I tell the ninth MS "Sorry dude, there is no room for
you, try another ARFCN"? I've checked the REJECT causes in gsm 04.08,
but couldn't really find one which is informing the BTS is out of free
channels.
Now my mobile keeps trying to register to my nanoBTS, although I
rejected him with a standard cause.
Maybe someone can give me a hint where to look at?
Thanks.
hi,
here is the almost final patch for fragmenting HFC-E1 cards for multiple
BTS connecting to one card. if it is stable, i will submit it after some
tests.
load module with:
$ modprobe hfcmulti dmask=0x00000042 bmask=0x0000003c,0x00000780
debug=0x40000
the dmask must be given von all E1 cards that have to be fragmented. in
this case we only fragment the first card.
the bmask must be given for all fragments. because we have two bits set
(slot 1 and slot 6), we need two values.
each bmask value will define the the bchannels to use for the given
dchannel.
the card is fragmented from lower dchannel to higher dchannel given in
the mask. (slot 1 for first fragment, slot 2 for second fragment)
run misdn_info after loading to see the fragments.
happy testing,
andreas
hi,
i found some leaking on the subscriber ressource usage. this patch is
not final. maybe we find better solutions.
1. trans_alloc() may not allocate subscriber for transaction, because
may be already done before, so i removed subscr_get() from transaction.c
-> on outgoing calls we allocate subscriber ressource (by searching for
it) and use it for transaction.
-> in incomming calls we use the subscriber pointer from the lchan.
2. on an incomming call/sms, the lchan holds a subscriber ressource, so
i added subscr_get() after successfully calling trans_alloc()
3. when _send_sms_buffer() is called, we already hold a subscriber
ressource for the receiver, so the subsequently called function
sms_from_text() must not allocate the receiver again. if this function
fails, the allocated subcriber ressource must be released in
_send_sms_buffer().
4. on trans_free we don't need to remove pending paging processes,
because it is done when paging expires. anyway if we want to keep it in
trans_free(), we must remove paging_remove_request() from
paging_T3113_expired(), because it will then be done when transaction is
removed. also we need to add paging_remove_request() when sms is removed
due to paging expiery.
i also fixed linux call router for compiling with openbsc without any
patch at all. by linking the source directory to the lcr source
directory, the "configure" script automatically detects it and it will
compile. (latest git)
regards,
andreas
Hi!
I've alerady sent this to wireshark-dev, but maybe somebody on this list
can also help...
I'm right now working for a dissector for the 3GPP IuH (Home-NodeB) protocol.
However, I believe the pcap files that I currently have for the protocol are
actually invalid.
Is there anyone on this list who would be able to provide me with RUA and/or
HNBAP protocol traces (preferrably inside SCTP)?
Thanks a lot.
--
- 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,
When trying to run bsc_hack I get the following messages:
bootstrapping OML for BTS 0
<0020> abis_nm.c:1644 Set BTS Attr (bts=0)
<0020> abis_nm.c:1661 Set TRX Attr (bts=0,trx=0)
<0020> abis_nm.c:1754 Set Chan Attr (bts=0,trx=0,ts=0)
<0020> abis_nm.c:1754 Set Chan Attr (bts=0,trx=0,ts=1)
<0020> abis_nm.c:1624 CONNECT TERR TRAF Um=(bts=0,trx=0,ts=1) E1=(0,2,1)
<0020> abis_nm.c:1754 Set Chan Attr (bts=0,trx=0,ts=2)
<0020> abis_nm.c:1624 CONNECT TERR TRAF Um=(bts=0,trx=0,ts=2) E1=(0,2,2)
<0020> abis_nm.c:1754 Set Chan Attr (bts=0,trx=0,ts=3)
<0020> abis_nm.c:1624 CONNECT TERR TRAF Um=(bts=0,trx=0,ts=3) E1=(0,2,3)
<0020> abis_nm.c:1754 Set Chan Attr (bts=0,trx=0,ts=4)
<0020> abis_nm.c:1624 CONNECT TERR TRAF Um=(bts=0,trx=0,ts=4) E1=(0,3,0)
<0020> abis_nm.c:1754 Set Chan Attr (bts=0,trx=0,ts=5)
<0020> abis_nm.c:1624 CONNECT TERR TRAF Um=(bts=0,trx=0,ts=5) E1=(0,3,1)
<0020> abis_nm.c:1754 Set Chan Attr (bts=0,trx=0,ts=6)
<0020> abis_nm.c:1624 CONNECT TERR TRAF Um=(bts=0,trx=0,ts=6) E1=(0,3,2)
<0020> abis_nm.c:1754 Set Chan Attr (bts=0,trx=0,ts=7)
<0020> abis_nm.c:1624 CONNECT TERR TRAF Um=(bts=0,trx=0,ts=7) E1=(0,3,3)
bootstrapping RSL for BTS/TRX (0/0) using MCC=1 MNC=1 BSIC=1 TSC=7
<0020> abis_nm.c:805 OC=SIEMENSHW(a5) INST=(03,00,00) STATE CHG:
<0020> abis_nm.c:805 OC=SIEMENSHW(a5) INST=(03,00,00) Failure Event
Report Severity=indeterminate failure
<0020> abis_nm.c:805 OC=SIEMENSHW(a5) INST=(03,00,00) STATE CHG:
Debug with -dDMI:DRSL:DNM shows strange lines:
...
<1000> input/misdn.c:132 DL_INFORMATION_IND: use channel(0) sapi(63)
tei(127) for now
mISDN message for unknown sign_link
...
<1000> input/misdn.c:132 DL_INFORMATION_IND: use channel(2) sapi(62)
tei(1) for now
mISDN message for unknown sign_link
...
Why TEI=1 or TEI=127 while it should be 25?
Also, dmesg produces:
...
mISDN_send: error -12
...
I've reviewed mailing list for similiar problems description and found
that several people have already seen
these problems, but didn't find the solution.
I thought that these problems may be connected with internal BS11
oscillator calibration, so
I've performed calibration as described in wiki (though I used Nateks
SDH mux with Stratum oscillator
as E1 clock source instead of HFC-S ISDN card, which I don't have).
Calibration was successful, but
it didn't help. Here is query output while running bsc_hack:
...
LMT LOGON: ACK
PHASE: 3 Normal MBCCU0: Load MBCCU1: No Load
Abis-link: Up
BS11 ATTRIBUTES:
BS-11 ESN PCB Serial Number: 001132
BS-11 ESN Hardware Code Number: 135-2044/03.03
BS-11 ESN Firmware Code Number: 135-2044/03.03
E1 Channel: Port=255 Timeslot=161 Subslot=39
PLL Set Value=1024, Work Value=1023
SITE MANAGER ATTRIBUTES:
E1 Channel: Port=0 Timeslot=1 (Full Slot)
TEI: 25
BS11 Line Interface ATTRIBUTES:
PLL Mode: Standalone
BS11 CCLK ATTRIBUTES:
CCLK Accuracy: Medium (0)
BS11 Power Amplifier 0 ATTRIBUTES:
TRX Power: 30mW (GSM)
LMT LOGOFF: ACK
...
It seems that everything should be ok, but... there is no success.
Best regards,
Sergey.
Hey guys,
for some historic reason our tmsi is an character array but all places dealing
with it treat it as a 4 octet, and according to the spec it is a four octet. I
have changed the definition and the code using the tmsi. It can be found in my
onwaves.com branch.
Does it make sense to switch?
z.
both subdevices: b553 and b523 are already part of the driver.
{ PCI_VENDOR_ID_CCD, PCI_DEVICE_ID_CCD_HFCE1, PCI_VENDOR_ID_CCD,
PCI_SUBDEVICE_ID_CCD_IOB1E1, 0, 0, H(24)}, /* IOB1E1 */
{ PCI_VENDOR_ID_CCD, PCI_DEVICE_ID_CCD_HFCE1, PCI_VENDOR_ID_CCD,
PCI_SUBDEVICE_ID_CCD_JHSE1, 0, 0, H(25)}, /* Junghanns E1 */
please check definitions. PCI_SUBDEVICE_ID_CCD_IOB1E1 should be b523 and PCI_SUBDEVICE_ID_CCD_JHSE1 should be b553. (do a grep onto your repository (grep b523 <path>/* -r)
-----Ursprüngliche Nachricht-----
Von: openbsc-bounces(a)lists.gnumonks.org [mailto:openbsc-bounces@lists.gnumonks.org] Im Auftrag von Harald Welte
Gesendet: Mittwoch, 19. August 2009 18:08
An: dexter
Cc: openbsc(a)lists.gnumonks.org
Betreff: Re: Problems with HFC-E1 card (Unknown HFC multiport controller)
On Mon, Aug 17, 2009 at 08:24:50PM +0200, dexter wrote:
> Here is an output from a linux box that works with the other card:
> Unknown HFC multiport controller (vendor:1397 device:30b1
> subvendor:ffffffff subdevice:ffffffff) Please contact the driver
> maintainer for support.
Hi, I think you should report this to the misdn development list.
as a quick workaround, I suggesty you add the pci vendor / device ID to the hfcmulti.c driver (hfcmulti_probe() would be the case).
What particular HFC-E1 card is this?
At least according to my kernel,
PCI_VENDOR_ID_CCD is 0x1397
PCI_DEVICE_ID_CCD_HFCE1 is 0x30b1
so I don't know why you get that message...
--
- 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)
