Hello Nordin,
On Fri, 03 Jul 2009 14:44:50 +0200, "Nordin" <bouchtaoui(a)gmail.com> wrote:
>
> I hope this will at least try to do a LOCATION UPDATE REQUEST.
> But it suprises me that older mobilephones don't care about SI 1 (and
> maybe more information on the BCCH) and just try to register whatever in
> the BCCH is.
I have further investigated the problem. Besides the fact that
the channel allocation in SYSTEM INFORMATION 1 is not correct
for GSM 1800, this is probably not the reason for the problem.
Most certainly its just one wrong bit, the GPRS indicator in
the SYSTEM INFORMATION 3 rest octets.
The current setting is
0x80, 0x00, 0x00, 0x2B
but it should be
0x80, 0x00, 0x08, 0x2B
What might lead to some confusion is the meaning of "L" and "H" in
the specification of CSN.1. For the rest octets the bit value is
determined by a comparsion (XOR) to the padding byte 0x2B. So the
value 0x08 above actually means "L" for the GPRS indicator, which
means "No GPRS".
Its seem that some phones are really sensible to this setting, some
other GPRS capable phones just don't care and register to the
network even if there is no GPRS.
Best regards,
Dieter
--
Dieter Spaar, Germany spaar(a)mirider.augusta.de
Hello Harald,
On Sun, 5 Jul 2009 04:42:20 +0200, "Harald Welte" <laforge(a)gnumonks.org> wrote:
>
> where did you find this XOR? I just searched through 04.07 and 04.08 and
> didn't find any indication thereof. Sure, the padding bit sequence ix 0x2b, so
> all spare bits have to be padded with that. But where did you get the XOR
> from?
I started to search deeper because I was a bit confused how the Message
Decoding Tool from Joachim Goeller interpreted the rest octets. I looked
at some phone firmware how they do it and found it there. Later I also
found a good explanation at http://csn1.info (they sell a tool which
can be used to generate message parsing source code for various
specifications).
> Also, this would mean that if we put explicitly 0x2b into the padding of
> our messages, then it would result in all-zero 0x00 on the air, since
>
> 0x2b xor 0x2b == 0x00
The XOR is actually only used for "L" and "H", basically it means that
if a bit at an "L"/"H" position is different from the padding sequence,
its an "H". At least this is how I understand it.
> I'm now looking at an actual abis trace from a production cell with GPRS
> enabled, and it has
>
> "0x80, 0x00, 0x80, 0x0b"
Here is how I would interpret it according to GSM 04.08, 10.5.2.34:
Selection Parameter:
byte 0: 0x80 ^ 0x2B = 0xAB, (bit 7) -> H (15 bits for parameter follow)
Power Offset:
byte 2: 0x80 ^ 0x2B = 0xAB, (bit 7) -> H ( 2 bits for parameter follow)
System Information 2ter Indicator:
byte 2: 0x80 ^ 0x2B = 0xAB, (bit 4) -> L (has no parameters)
Early Classmark Sending Control:
byte 2: 0x80 ^ 0x2B = 0xAB, (bit 3) -> H (has no parameters)
Scheduling if and where:
byte 2: 0x80 ^ 0x2B = 0xAB, (bit 2) -> L
GPRS Indicator:
byte 2: 0x80 ^ 0x2B = 0xAB, (bit 1) -> H ( 4 bits for parameter follow)
> During early start of the BTS, SI3 rest octets are set to
>
> "0x80, 0x00, 0x83, 0x2b"
The only difference is that at this stage GPRS is not yet set:
GPRS Indicator:
byte 2: 0x83 ^ 0x2B = 0xA8, (bit 1) -> L
Best regards,
Dieter
--
Dieter Spaar, Germany spaar(a)mirider.augusta.de
Hello Andreas,
On Mon, 29 Jun 2009 23:37:51 +0200, "Andreas.Eversberg" <Andreas.Eversberg(a)versatel.de> wrote:
>
> this was the problem. finally got the measurement reports (--debug
> ....:DMEAS). you just need to add to misdn.c:
>
> case DL_UNITDATA_IND:
>
> and everything is fine.
Great, so this is solved.
I noticed one minor problem, its the meaning of the MEAS-VALID
flag. The spec says that "0" means "valid" and "1" is "not valid".
So
if (!(meas_rep.flags & MEAS_REP_F_VALID))
should be changed or the parsing of the measurement result where this
flag is set.
Best regards,
Dieter
--
Dieter Spaar, Germany spaar(a)mirider.augusta.de
Hi!
I've just committed some recent improvements of the Abis dissection of
wireshark to git.
There's some initial work on a 12.21 OML decoder in
epan/dissectors/packet-abis_oml.c. It will happily decode the common FOM
header and tell you the name of the message as well as list all attributes
in it. It does not yet understand details on how to parse all the various
attributes. If anyone wants to make himself familiar with this part of
GSM, get a copy of 12.21, look at OpenBSC or protocol traces and add
more of that attribute parsing code!
The A-bis/IP dissector has only been improved slightly.
If you apply abisip.patch and abis_oml.patch to current wireshark svn,
you will be able to decode 94-99% of what you see in any capture between
OpenBSC and a nanoBTS.
I currently don't have access to a BS-11, so I cannot test the wireshark
code with it. In case somebody wants to send me some pcap files of BS-11
traces, either by using the openbsc pcap option or by tracing it through mISDN,
I'm more than happy to make sure that it works on thos traces, too.
Testing as well as contributed patches are also always welcome!
Thanks,
--
- 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)
On Sunday 28 June 2009 18:47:31 Andreas.Eversberg wrote:
> patch 39: the location update process did not work, if mobile station
> uses tmsi when comming from a different network. in this case the
> reject-timer must also be started, and we wait for imsi identity
> response. in case we can't find the subscriber or if we have an
> unimplemented location update, we release location update process and
> send a reject.
Sorry, to me it seems the patch is doing something else...
1.)
if (!subscr) {
DEBUGPC(DRR, "<- Can't find any subscriber for this ID\n");
/* FIXME: request id? close channel? */
+ release_loc_updating_req(lchan);
+ gsm0408_loc_upd_rej(lchan, reject_cause);
return -EINVAL;
}
I think we can just move the schedule_reject from two lines below the if to
the top. What do you think?
2.) The patch changes the policy from delayed reject (to not make the MS come
back immediately) to a direct one. What is the reasoning?
hi,
i did some heavy tests this weekend with many mobile stations at once.
with these patches all ressources (channels / subscribers) were released
cleanly. even when mobile stations request more than 4 channels at a
time (the current SDCCH4 is full), there is no ressource getting stuck
anymore.
patch 39: the location update process did not work, if mobile station
uses tmsi when comming from a different network. in this case the
reject-timer must also be started, and we wait for imsi identity
response. in case we can't find the subscriber or if we have an
unimplemented location update, we release location update process and
send a reject.
patch 40: in case of a channel breakdown, the signal handler for
releasing lchan is called. the wrong pointer was used as lchan. (see
last hunk) also we don't need to check use counter of lchan, if we
receive an "cause 22 error". the lchan gets released anyway, if use
counter becomes 0. (see first hunk). also i think we can force channel
release when we receive an error indication. this can easily be tested:
remove the battery during active call, then send a message to the mobile
station (hang up on the remote). the message cannot be delivered, so the
BTS send us an error indication, the channels and the call process gets
released.
patch 41: the pointer "tall_bsc_ctx" belongs to the gsm_data.c file, not
to include file.
patch 42: again my traffic channel patch. the mobile requests a channel.
in case of a location update, we deliver the requested channel type. if
we receive a channel request for other reasons, i force a TCH_F channel.
this is requied, because we cannot change (modify) the channel right
now. also i check if we have a TCH_F channel when we want to make a call
to the mobile. if so, the channel is used, if not, paging is stated as
if we would have no channel. so it is possible to call a mobile during
location update, when it holds not a TCH_F channel.
patch 43: this small fix will not check for given subscriber/imsi here.
this is already done in the next "if"-condition.
patch 38: still i use this little hacked install patch to install
library and include files, so other applications like LCR can use
openbsc without refering to the openbsc source directory. i use that
install-hook, because i don't know much about autoconf. maybe there is a
better way to do that.
anyway i don't get any measurement reports at all. i tried two BTS' and
used the firmware as described in the wiki.
regards,
andreas
> UI frames should be reported to userspace as DL_UNITDATA_IND rather
than DL_DATA_IND. openbsc/input/misdn.c currently doesn't support
DL_UNITDATA_IND in the switch statement of handle_ts1_read. That sounds
like the most likely cause.
hi harald,
this was the problem. finally got the measurement reports (--debug
....:DMEAS). you just need to add to misdn.c:
case DL_UNITDATA_IND:
and everything is fine.
regards,
andreas
Hi!
ipaccess-config can now set the nanoBTS NVRAM flags. It has the following
syntax:
ipaccess-config <IP-addr> -n flags/mask
so e.g.
> ipaccess-config 1.2.3.4 -n 0x400/0x400
will set bit number 10 in NVRAM, whereas
> ipaccess-config 1.2.3.4 -n 0x000/0x400
will clear that very bit.
A list of known bits that you can set:
0 Static Interface IP configuration
1 Static IP Gateway configuration
8 Secondary OML enable (incoming TCP port 3006)
10 CLI enable (command line interface on serial port)
11 HTTP enable (https server on TCP port 443)
13 SNMP enable
If somebody wants to add a '--help' message to ipaccess-config, patches
are always welcome.
Cheers,
--
- 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 all!
As some of you might have seen from the various git commit messages, I spent
quite a bit of time to implement a GSM 12.21 (A-bis OML) plugin for wireshark
from scratch. It's available in our git repository at /wireshark/abis_oml.patch
My main focus has been the parsing of the ip.access vendor-specific extensions
to 12.21, as that part is much harder than just implementing what's written
in TS 12.21 itself.
One of the things that it can now decode is decoding of the 'network listen'
functionality implemented as 12.21 'perform test'.
Using this, you can scan over all ARFCN and report the rx level (good for
determining an unused channel at your current location), or you can actually
decode the BCCH information of all cells in your vicinity.
This is just the wireshark plugin. I did not write any FOSS code for actually
starting those tests, you still need some non-free software for that. However,
looking at the pcap file I sent some time ago and at this wireshark plugin,
anyone interested should be able to implement this very quickly, maybe as an
addition to ipaccess-config.
Due to my current lack of access to BS-11 hardware, the plugin was not yet
tested against it. If anyone can do some testing in this regard, it would
be much appreciated. Alternatively, if somebody can send me some BS11 pcap
files (maybe just of OpenBSC starting up), I can make sure to fix it.
I'm planning to do some more work regarding cleanup and feature-completeness of
the plugin before submitting it mainline to wireshark.
However, the Abis-IP plugin should be quite complete and I'll plan to submit
it really soon now.
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)
> I think we can just move the schedule_reject from two lines below the
if to the top. What do you think?
> 2.) The patch changes the policy from delayed reject (to not make the
MS come
> back immediately) to a direct one. What is the reasoning?
hi holger,
1. just move it to the top.
2. you are right. only we need to restart the timer and exit, on
location update with TMSI. also i was concerned about loosing link to
mobile. in this case we get a timeout, so only the first 3 lines make
sense. anyway i will test it and see if i missed to explain an
importaint reason.
regards,
andreas
