Hi!
I've updated the system_information branch. The purpose of this branch
is to move away from static u_int8_t arrays that are used as templates
for the SYSTEM INFORMATION messages. Thise arrays are reminiscent of the
old days of bs11_init, where everything had been done this way.
The current head of system_information is now managing to actually do that.
The full SI1-SI4 on the BCCH as well as the SI5/SI6 on the SACCH are now
created from scratch (see code in system_information.c)
The content of the SI is "phase 1" content, i.e. before rest octets were
introduced
I've also written some code to generate the rest octets, as well as a some
"rest octet encoding aware" bit vector routines that understand the meaning of
0/1/L/H.
However, those rest octet routines are not yet used. They need some careful
testing before use. Testing is actually quite hard, as not even wireshark
has dissector for the system information messages (anyone interested in
contributing on this? It's needed for airprobe, too)
One interesting bit that stalled development for quite some time: If you send
a SACCH FILLing with length > 18 bytes, then the nanoBTS will actually crash
somewhere in the layer 2, sending you long error strings with addresses
(stack?) as error reports before rebooting :)
Feel free to start testing the system_information branch if you're interested.
I'd be happy to hear any "master works for my phone, but system_information
branch confuses my phone" kind of reports.
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!
Holger has asked me to send an update on the status of the wireshark patches
that we have in git:
gsm_a_rr-rrlp.patch and abisip.patch are mainline wireshark, they can
be removed from our git tree.
abis_oml.patch:
* does not yet dissect all the different 12.21 IEs, especially not
all of the standard IEs
* does not yet differentiate between BTS types. We need a preference where
we can select the BTS model in order to really pars all the messages, plus
vendor dependent IE tables
* might possibly use non-standard C language syntax and thus not be portable
to micrsofot compilers on windows. not sure what the wireshark requirements
are in that regard
rsli-ipaccess.patch:
* does not support all of the ip.access RSL extensions yet
* no major reason why it should nt be merged to wireshark
* additional ip.access RSL extensions can be sent as incremental patches
lucent-hmb.patch
* this is just a minimal stub, should be completed more before
submitting anywhere
--
- Harald Welte <laforge(a)gpl-violations.org> http://gpl-violations.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
Hey,
the clang C frontend has found some issues in our OpenBSC code. I think we
will need to have a table for BS11 and one for ipaccess with the shared/speced
elements being in both tables.
Here is the list of things I can resolve myself right now:
[NM_ATT_IPACC_FREQ_CTRL] = { TLV_TYPE_FIXED, 2 }
[NM_ATT_IPACC_FREQ_CTRL] = { TLV_TYPE_TV, },
these vendor specific commands have the same value:
[NM_ATT_IPACC_NS_CFG] = { TLV_TYPE_TL16V },
[NM_ATT_BS11_BIT_ERR_THESH] = { TLV_TYPE_FIXED, 2 },
[NM_ATT_IPACC_BSSGP_CFG] = { TLV_TYPE_TL16V },
[NM_ATT_BS11_BOOT_SW_VERS] = { TLV_TYPE_TLV },
^~~~~~~~~~~~
[NM_ATT_IPACC_RLC_CFG] = { TLV_TYPE_TL16V },
[NM_ATT_BS11_CCLK_ACCURACY] = { TLV_TYPE_TV },
^~~~~~~~~~~
[NM_ATT_IPACC_ALM_THRESH_LIST]= { TLV_TYPE_TL16V },
[NM_ATT_BS11_CCLK_TYPE] = { TLV_TYPE_TV },
^~~~~~~~~~~
[NM_ATT_IPACC_CODING_SCHEMES] = { TLV_TYPE_TL16V },
[0xa8] = { TLV_TYPE_TLV },
[NM_ATT_IPACC_UPTIME] = { TLV_TYPE_TL16V },
[NM_ATT_BS11_L1_PROT_TYPE] = { TLV_TYPE_TV },
[NM_ATT_IPACC_RLC_CFG_3] = { TLV_TYPE_TL16V },
[NM_ATT_BS11_LINE_CFG] = { TLV_TYPE_TV },
[0x85] = { TLV_TYPE_TV },
[NM_ATT_IPACC_STREAM_ID] = { TLV_TYPE_TV, },
Hi,
IIRC Harald et all. were seeing GSM subscriber leakage at HAR2009 and we have
not yet explored the cause of this problem. I would like to have no subscriber
leaks for the congress and propose the following changes.
I have pushed the "holger/subscr-ref-handling" branch to our repository and
would be happy if people could give it a spin. My testing here is pretty
limited.
Currently I have two commits. The second is removing a leak in the vty console
for SMS sending and subscriber usage and the other patch is trying to stop
borrowing someone else's gsm_subscriber reference. More details below.
Currently we do lchan->subscr = new_subscr and then we have two flavors of
checking if the channel is already used. I have changed this to use a new
assignment function that will do the check consistently and updated call
sites.
I would establish the following guideline for gsm_subscriber handling:
In every method where subscr_get* is called the subscriber must be released at
the exit with subscr_put unless the referenced provider is assigned to a
struct that is created in the same method, then the subscriber must be
released next to the talloc_free.
More details:
- paging.c seems fine
- gsm_subscriber_chan seems fine
- gsm_04_08_utils.c seems fine
- gsm_04_08.c seems fine now as well. subscr_get/_put should be balanced
- gsm_04_11.c if we leak a subscriber we also leak a sms I have not
checked all SMS paths to be sure we don't leak there.
I would be very happy if people could test this.
z,
Hello Sylvain,
On Mon, 26 Oct 2009 10:19:55 +0100, "Sylvain Munaut" <246tnt(a)gmail.com> wrote:
>
> So a lot of phones seem to support this and with assistance data could
> maybe provide a location.
> Did you try to correlate IMEI manufacturer part with the messages ?
No, not yet.
> Do you have any log of a successful response ? Maybe I screw up the
> encoding of the position somehow.
Yes, here is an example. This is the response from the phone
42 11 00 00 6A 57 9F B6 41 29 B1 B0 10 8D 84 00 6C 9C 9C 01 B1 0C
This is decoded PDU (asn1c was used):
PDU ::= {
referenceNumber: 2
component: MsrPosition-Rsp ::= {
locationInfo: LocationInfo ::= {
refFrame: 0
gpsTOW: 6969247
fixType: 1
posEstimate: 90 4A 6C 6C 04 23 61 00 1B 27 27 00 6C 43
}
}
}
And those are the coordinates from "posEstimate" (I did not care about
the height):
52.329040 - 52 19'44" N
5.819342 - 5 49' 9" E
Best regards,
Dieter
--
Dieter Spaar, Germany spaar(a)mirider.augusta.de
Hello,
here is a summary of the RRLP requests from HAR2009. It is the summary
from a time periode of about 10 hours near the end of the event.
Total number of RRLP responses: 2179
"methodNotSupported" response: 122
"notEnoughSats" response: 667
"gpsAssDataMissing" response: 1368
Successful positions returned: 22
Number of different phones: 86
Phones which returned "methodNotSupported": 5
Phones which returned a position: 7
Requested assitance data for the "gpsAssDataMissing" response:
530 Navigation Model, Reference Location, Reference Time
468 Navigation Model, Reference Location
141 Navigation Model
123 Almanac, Navigation Model, Reference Location, Reference Time
58 Almanac, Navigation Model, Reference Location, Reference Time,
Real-Time Integrity
27 Almanac, Navigation Model, Reference Location
13 Almanac, UTC Model, Ionospheric Model, Navigation Model,
Reference Location, Reference Time, Real-Time Integrity
5 Reference Location
3 Navigation Model, Reference Time
And this was the request sent to the phones:
PDU: 40 01 78 A8
referenceNumber 2
msrPositionReq
methodType msBased
Accuracy 60
positionMethod gps
measureResponseTime 2
useMultipleSets oneSet
Best regards,
Dieter
--
Dieter Spaar, Germany spaar(a)mirider.augusta.de
Hello Sylvain,
On Sun, 25 Oct 2009 19:50:53 +0100, "Sylvain Munaut" <246tnt(a)gmail.com> wrote:
> Does anyone have a clue ?
You already had a look at TS 44.031 ? It describes the RRLP procedures
in detail. It also mentiones that the RRLP maximum PDU size is 242 bytes
and that you have to use RRLP pseudo-segmentation to deliver larger PDUs,
however it also mentiones that "legacy" MS and SMLC may exceed this PDU
size.
Best regards,
Dieter
--
Dieter Spaar, Germany spaar(a)mirider.augusta.de
Hi,
I've been working on improving RRLP support lately. Most precisely,
providing real assistance data sourced directly from a GPS receiver
attached to the control PC.
My problem right now is that the generated APDU is about 1500 bytes
and obviously there is no way that fits in a single L3 frame.
GSM 04.08 9.1.53 describes the format of the APDU and there is a 4
bits flag fields, which from what I understand occupies the 4 upper
fields of the first octet and that allows fragmentation. From reading
the IE description in 10.5.2.49 I should set :
0x10 for the first segment
0x30 for the intermediate segments
0x20 for the last segment
Which is what I tried, by modifying the gsm48_send_rr_app_info
function like this : http://yourpaste.net/3558/
Unfortunately, I couldn't make it work. When I set the segment size to
try and have L3 frame of 251 bytes, I get some RSL error back and when
I use a smaller size, the MS seems to interpret each segment
separately and not reconstituting them ...
Does anyone have a clue ?
Sylvain
Here's a log, where you see the MS answering independently to the 3
segments (with errors since you can't just decode partial data ...):
<0002> gsm_04_08.c:280 lchan (bts=0,trx=0,ts=0,ch=0) decreases usage to: 0
<0004> gsm_04_08.c:901 -> LOCATION UPDATE ACCEPT
<0002> gsm_04_08_utils.c:144 (bts 0 trx 0 ts 0 pd 05) Sending 0x02 to MS.
l3_len = 14
<0004> gsm_04_08.c:1222 -> MM INFO
<0002> gsm_04_08_utils.c:144 (bts 0 trx 0 ts 0 pd 05) Sending 0x32 to MS.
l3_len = 22
<0008> gsm_04_08.c:1651 TX APPLICATION INFO id=0x00, len=688
<0008> gsm_04_08.c:1669 TX APPLICATION INFO Segment ofs=0 len=230 id=10
<0002> gsm_04_08_utils.c:144 (bts 0 trx 0 ts 0 pd 06) Sending 0x38 to MS.
l3_len = 234
<0008> gsm_04_08.c:1669 TX APPLICATION INFO Segment ofs=230 len=230 id=30
<0002> gsm_04_08_utils.c:144 (bts 0 trx 0 ts 0 pd 06) Sending 0x38 to MS.
l3_len = 234
<0008> gsm_04_08.c:1669 TX APPLICATION INFO Segment ofs=460 len=228 id=20
<0002> gsm_04_08_utils.c:144 (bts 0 trx 0 ts 0 pd 06) Sending 0x38 to MS.
l3_len = 232
<0001> abis_rsl.c:1282 channel=(bts=0,trx=0,ts=0) chan_nr=0x20 sapi=0
DATA INDICATION
<0004> gsm_04_08.c:1438 TMSI Reallocation Completed. Subscriber: 206205003327508
<0001> abis_rsl.c:1282 channel=(bts=0,trx=0,ts=0) chan_nr=0x20 sapi=0
DATA INDICATION
<0020> gsm_04_08.c:1594 RX APPLICATION INFO id/flags=0x00 apdu_len=2 apdu=48 20
<0010> abis_rsl.c:997 channel=(bts=0,trx=0,ts=0) chan_nr=0x28
CONNECTION FAIL: CAUSE=0x01(Radio Link Failure) RELEASING.
<0010> abis_rsl.c:720 RF Channel Release CMD
channel=(bts=0,trx=0,ts=0) chan_nr=0x28
<0010> abis_rsl.c:997 channel=(bts=0,trx=0,ts=0) chan_nr=0x28 RF
CHANNEL RELEASE ACK
<0001> abis_rsl.c:1282 channel=(bts=0,trx=0,ts=0) chan_nr=0x20 sapi=0
DATA INDICATION
<0020> gsm_04_08.c:1594 RX APPLICATION INFO id/flags=0x00 apdu_len=2 apdu=88 10
<0010> abis_rsl.c:720 RF Channel Release CMD
channel=(bts=0,trx=0,ts=0) chan_nr=0x28
<0010> abis_rsl.c:997 channel=(bts=0,trx=0,ts=0) chan_nr=0x28 RF
CHANNEL RELEASE ACK
<0001> abis_rsl.c:1282 channel=(bts=0,trx=0,ts=0) chan_nr=0x20 sapi=0
DATA INDICATION
<0020> gsm_04_08.c:1594 RX APPLICATION INFO id/flags=0x00 apdu_len=2 apdu=c8 00
<0001> abis_rsl.c:1282 channel=(bts=0,trx=0,ts=0) chan_nr=0x20 sapi=0
RELEASE INDICATION
<0010> abis_rsl.c:720 RF Channel Release CMD
channel=(bts=0,trx=0,ts=0) chan_nr=0x20
<0010> abis_rsl.c:997 channel=(bts=0,trx=0,ts=0) chan_nr=0x20 RF
CHANNEL RELEASE ACK
<0002> gsm_subscriber_base.c:150 subscr 201 usage decreased usage to: 0
