23 Jun
2009
23 Jun
'09
9:50 a.m.
Hello guys,
Has anybody registered a PDA phone of 2.5G/3G type to the BS11 bts
succesfully?
Cause I'm still struggling with it for my nanoBTS (1800 Mhz).
Thank you.
23 Jun
23 Jun
10:29 a.m.
New subject: OpenBSC with 2.5G or 3G mobile devices support? / Tested Phones
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi,
Nordin wrote:
Has anybody registered a PDA phone of 2.5G/3G type to
the BS11 bts
succesfully?
I've tested my BS11 with a certain number of phones. Most phones
work, but there are some picky ones:
Siemens S3com works
Siemens S10D works, sometime
Siemens C35 works
Siemens S35 works
Ericsson R290 works, picky about the SIM (problem has nothing
to do about the BS11)
SonyEricsson K600i* works, a little picky sometimes
SonyEricsson T610 almost never works, in fact it registered only
once (but worked then)
Nokia 6610i works
Nokia E90* works
Nokia 810 Carphone works
Motorola V3x* works mostly (sometimes the signal strength
changes regularly)
Phones marked with an * are 3G-capable.
All phones were tested using China Mobile M-Zone SIMs (460-02) and a
BS11 on channel 23, broadcasting network 460-02.
(these SIM are available from
http://www.dealextreme.com/details.dx/sku.16159 for $3.94 per 10pc,
including shipping, to reduce problems with SIM trying to register
with its home networks here)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
iJwEAQECAAYFAkpArpAACgkQAFwr480vHf0mjAQAhrxFafYOccl9KPHgMgBqMSxE
5IZ8ucxZPvR8luD6M9KfwidO+4oWZVAgyfDBYmPNaVF7fS8gbfx0ip5UoOFJQwaO
vD2AwHNB5io5EaoiVaAcYsJNo88SGtOYvkOhCw1cDn7B/IJqnwC0MK9KyVuMAWQb
GBpLlBKLXFJ54AqGE/Y=
=S700
-----END PGP SIGNATURE-----
9:06 p.m.
New subject: OpenBSC with 2.5G or 3G mobile devices support? / Tested Phones
Thanks Kai,
I even manually tried to register with my HTC Artemis to our nanoBTS using a
T-Mobile sim but it failed. I'll do some more tests and hopefully with more
results...
24 Jun
24 Jun
4:59 a.m.
New subject: OpenBSC with 2.5G or 3G mobile devices support? / Tested Phones
On Tue, Jun 23, 2009 at 11:06:30PM +0200, Nordin Bouchtaoui wrote:
Thanks Kai,
I even manually tried to register with my HTC Artemis to our nanoBTS using a
T-Mobile sim but it failed. I'll do some more tests and hopefully with more
results...
if you can provide us with the detailed log of OpenBSC while you attempt to do
that location update (and preferrably just this one, no other phones
simultaneously), it could enable us to help 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)
1:04 p.m.
New subject: OpenBSC with 2.5G or 3G mobile devices support? / Tested Phones
I did the following command:
./bsc_hack -t nanobts1800 -c 204 -n 16 -f 866 -L 11 -d -p dump1.pcap
But when I open this pcap file in Wireshark, I get the following message:
The capture file appears to be damaged or corrupt.
(libpcap: LAPD file has a 15-byte packet, too small to have even a LAPD
pseudo-header).
/This is in WinXP environment./
The filesize keeps at 4 kB and doesn't want to grow, does anyone
recognises this?
When I manually select our nanoBTS with my HTC pda-phone, it just can't
register and keeps unconnected to the GSM network, which also shows the
no-gsm-network symbol (a cross near the antenna symbol) on the display.
Sometimes it comes with a message "Can't register on the selected
network. Choose another network or disconnect the data connection and
try again." The latter part is interesting, what does it mean with
"disconnect the data connection"? I checked how to turn off GRPS, but up
to now, I don't know how to configure that. I tried everything.
The debug info of bsc_hack doesn't show any requests from my pda-phone,
so it doesn't attempt to do a request of whatever type. That's why I
think my pda-phone is somehow strugling with interpetting the BCCH
channel concerning the GPRS part. Or there must be another reason. I
took a gsm-trace from the web and modified SI 3 and SI 4 Rest Octets,
such that it mimics GPRS support. But the problem is, the pcap file the
bsc_hack produces, is damaged as I said before. Once again, the debug
shows nothing when trying to register to our nanoBTS manually.
By the way, I used a T-Mobile sim-card on my pda-phone. The same
sim-card in a Nokia 6310i registers fine on our nanoBTS.
If you need more information, just ask please. I'll do everything I can.
Thank you.
2:09 p.m.
New subject: OpenBSC with 2.5G or 3G mobile devices support? / Tested Phones
On Wednesday 24 June 2009 15:04:01 Nordin wrote:
I did the following command:
./bsc_hack -t nanobts1800 -c 204 -n 16 -f 866 -L 11 -d -p dump1.pcap
Yes... pcap for nanobts is broken in at least two ways... For one direction
of the package (from BTS to BSC) the input layer is not used and the message
is sent directly to the abis_rsl... For the other direction we are currently
not adding any mISDN header... Please see the "patch 28: wrieshark pcap
logging" thread for a hint what to do with the current pcap dumping code to
make it work for the nanobts as well...
z.
2:27 p.m.
New subject: OpenBSC with 2.5G or 3G mobile devices support? / Tested Phones
Ok thanks Holger,
It just takes much more time for me to realize that as a "beginner" in
GNU/Linux environment, but this is the best opportunity to become an
experienced Linux user :)
At the moment I'm trying to get traces with TShark.
But Holger, do you also have registering issues with pda-phones, like
the HTC or maybe even the iPhone?
Regards,
Nordin.
2:33 p.m.
New subject: OpenBSC with 2.5G or 3G mobile devices support? / Tested Phones
On Wednesday 24 June 2009 16:27:30 Nordin wrote:
Ok thanks Holger,
It just takes much more time for me to realize that as a "beginner" in
GNU/Linux environment, but this is the best opportunity to become an
experienced Linux user.
Yes, the code is not that difficult to understand. Mostly only two files and
three methods...and you could start with a gross hack and then clean it up?
But Holger, do you also have registering issues with
pda-phones, like
the HTC or maybe even the iPhone?
I remember we had some problems with the PDA phones at the 25C3, I currently
have no physical access to any BTS and can't do tests.
z.
3:25 p.m.
New subject: OpenBSC with 2.5G or 3G mobile devices support? / Tested Phones
Holger -
[OpenBTS - I'm cross posting this from OpenBSC.]
A problem we had with a lot of PDA phones in OpenBTS was that they
would attempt to register or access CM services by TMSI, even when
our system had a different MCC/MNC/LAC and even when we had not yet
assigned a TMSI. I first saw this with a Palm Treo 650 but have seen
it with other PDA phones since then. I suspect a lot of them are
using the same broken GSM chipset that does not follow the standard's
TMSI invalidation rules. I don't know what you do for TMSI
resolution in OpenBSC, but if you don't handle this case correctly
you will have problems with these handsets.
-- David
On Jun 24, 2009, at 7:33 AM, Holger Freyther wrote:
David A. Burgess
Kestrel Signal Processing, Inc.
But Holger, do you also have registering issues
with pda-phones, like
the HTC or maybe even the iPhone?
I remember we had some problems with the PDA phones at the 25C3, I
currently
have no physical access to any BTS and can't do tests.
z.
3:50 p.m.
New subject: OpenBSC with 2.5G or 3G mobile devices support? / Tested Phones
Thanks for your post David,
Well that sounds strange, this means that if I turn off my pda phone in
Holland and turn it on in France, my pda phone won't register because of
non-standard TMSI issue? I doubt about that.
The case is, I don't even see any transaction between OpenBSC and the
PDA phone from the debugging of bsc_hack. I have the feeling that the
PDA phone don't even do any request based on System Informations
provided by the BCCH of the bsc_hack.
As far as I know, we don't do TMSI resolution. We kind of like saying
"hey PDA, I don't want the TMSI, just give me your IMSI instead" and so
the PDA "should" drop the TMSI as it's TEMPRORAY MSI anyway. If that's
how it works.
c u later...
David A. Burgess schreef:
Holger -
[OpenBTS - I'm cross posting this from OpenBSC.]
A problem we had with a lot of PDA phones in OpenBTS was that they
would attempt to register or access CM services by TMSI, even when our
system had a different MCC/MNC/LAC and even when we had not yet
assigned a TMSI. I first saw this with a Palm Treo 650 but have seen
it with other PDA phones since then. I suspect a lot of them are
using the same broken GSM chipset that does not follow the standard's
TMSI invalidation rules. I don't know what you do for TMSI resolution
in OpenBSC, but if you don't handle this case correctly you will have
problems with these handsets.
-- David
On Jun 24, 2009, at 7:33 AM, Holger Freyther wrote:
David A. Burgess
Kestrel Signal Processing, Inc.
But Holger, do you also have registering issues
with pda-phones, like
the HTC or maybe even the iPhone?
I remember we had some problems with the PDA phones at the 25C3, I
currently
have no physical access to any BTS and can't do tests.
z.
4:18 p.m.
New subject: OpenBSC with 2.5G or 3G mobile devices support? / Tested Phones
On Jun 24, 2009, at 8:50 AM, Nordin wrote:
Thanks for your post David,
Well that sounds strange, this means that if I turn off my pda
phone in Holland and turn it on in France, my pda phone won't
register because of non-standard TMSI issue? I doubt about that.
No. It means the PDA might first try to register with that Dutch
TMSI and then the network will need to explicitly request the IMSI.
It's not supposed to use that Dutch TMSI in France, but it might try
if there's a bug in its GSM stack.
The case is, I don't even see any transaction
between OpenBSC and
the PDA phone from the debugging of bsc_hack. I have the feeling
that the PDA phone don't even do any request based on System
Informations provided by the BCCH of the bsc_hack.
Ah. Sorry. You are probably correct then. There's something about
the BCCH that the phone doesn't like.
As far as I know, we don't do TMSI resolution. We
kind of like
saying "hey PDA, I don't want the TMSI, just give me your IMSI
instead" and so the PDA "should" drop the TMSI as it's TEMPRORAY
MSI anyway. If that's how it works.
That's part of what I mean by TMSI resolution: if you can't recognize
or support the TMSI, turn around and request the IMSI. The problem,
sometimes, is that some phones don't drop the TMSI. They insist on
using it, even when it should have been invalidated. The only way we
could get the Treo 650 to stop sending us AT&T's old TMSI was to
assign it one of our own.
c u later...
Not if I c u first... ;-)
-- David
25 Jun
25 Jun
7:46 a.m.
New subject: OpenBSC with 2.5G or 3G mobile devices support? / Tested Phones
No. It means the PDA might first try to register with
that Dutch TMSI
and then the network will need to explicitly request the IMSI. It's
not supposed to use that Dutch TMSI in France, but it might try if
there's a bug in its GSM stack.
Well I'm sorry, but I'm still not convinced about that. Cause that would
be a major bug, which won't be accepted by the biggest user group for
PDA phones (like business men, or presidents like Obama).
Ah. Sorry. You are probably correct then.
There's something about
the BCCH that the phone doesn't like.
That's I think is most likely the case.
That's part of what I mean by TMSI resolution: if
you can't recognize
or support the TMSI, turn around and request the IMSI.
Yeah, that is what OpenBSC does, I think. But Harald, Holger, Dieter and
others know more about it.
The problem, sometimes, is that some phones
don't drop the TMSI.
They insist on using it, even when it should have been invalidated.
In that case, I would see some negotiations from the debug bsc_hack,
which there is not. So my assumption is still some missing information
in the BCCH channel. Cause once again, trying to register to my BTS
manually failed and I don't see any attempt to do just a simple Radio
Resource request. The latter one I can't confirm that for 100 %, because
it's possible the debug doesn't show all of that.
The only way we could get the Treo 650 to stop sending
us AT&T's old
TMSI was to assign it one of our own.
Well, at least the Treo talked to you.
c u later...
Not if I c u first... ;-) 
8:32 a.m.
New subject: OpenBSC with 2.5G or 3G mobile devices support? / Tested Phones
Did anyone try a Samsung mobile phone?
I tried 3 different kind of Samsung and none of them can attach to the
network (but they can see it with manual research).
Problems with :
Samsung U600
Samsung PlayerAddict I900
Samsung E840
Working fine with Nokia and Ericsson mobile phones
Eric Cathelinaud
2009/6/25 Nordin <bouchtaoui(a)gmail.com>
No. It means the PDA might first try to register with that Dutch TMSI and
uhhhh....c u soon? :)
then the network will need to explicitly request
the IMSI. It's not
supposed to use that Dutch TMSI in France, but it might try if there's a bug
in its GSM stack.
Well I'm sorry, but I'm still not convinced about that. Cause that would be
a major bug, which won't be accepted by the biggest user group for PDA
phones (like business men, or presidents like Obama).
Ah. Sorry. You are probably correct then. There's something about the
BCCH that the phone doesn't like.
That's I think is most likely the case.
That's part of what I mean by TMSI resolution: if you can't recognize or
support the TMSI, turn around and request the
IMSI.
Yeah, that is what OpenBSC does, I think. But Harald, Holger, Dieter and
others know more about it.
The problem, sometimes, is that some phones don't drop the TMSI. They
insist on using it, even when it should have been
invalidated.
In that case, I would see some negotiations from the debug bsc_hack, which
there is not. So my assumption is still some missing information in the BCCH
channel. Cause once again, trying to register to my BTS manually failed and
I don't see any attempt to do just a simple Radio Resource request. The
latter one I can't confirm that for 100 %, because it's possible the debug
doesn't show all of that.
The only way we could get the Treo 650 to stop sending us AT&T's old TMSI
was to assign it one of our own.
Well, at least the Treo talked to you.
c u
later...
Not if I c u first... ;-)
2:54 p.m.
New subject: OpenBSC with 2.5G or 3G mobile devices support? / Tested Phones
On Jun 25, 2009, at 12:46 AM, Nordin wrote:
I agree that it is a major bug and a security risk for high-profile
users, but it is real. The users might reject it if they knew, but
most have no way of knowing, unless, of course, someone publishes a
report on it and to my knowledge nobody has. (OK, except for Obama.
You can bet someone competent has done an analysis of his PDA.)
It would be great if someone with an OpenBTS system could turn on
debugging messages and capture the raw bits from our system
information messages 1-4 and send them to you for you to try in your
OpenBSC build. I'd do it myself but I am traveling a lot lately and
don't have the equipment with me.
I looked at the BCCH messages in OpenBSC yesterday, but could not
identify the problem. I don't know how OpenBSC handles the "rest
octets" at the ends of these messages, but it is important that these
be properly padded with the GSM filler pattern if you are not coding
anything there. This is especially important for high-feature phones
that might actually be looking for GPRS parameters. It is also
important to present the BCCH messages in the correct sequence and
with the timing given in GSM 05.02 6.3.1.3, but I suspect your BTS
takes care of that for you.
I agree with your analysis. If the handset actually sees the
network, then you do not have a frequency offset problem. Therefore,
if you do not see channel requests coming from the phone via the BTS
the most likely explanation is that the phone has found some
inconsistency in the BCCH.
uhhhh....c u soon? :)
Sorry. It's joking response: If I see you coming, I will hide. Just
a joke, though.
-- David
David A. Burgess
Kestrel Signal Processing, Inc.
No. It means the PDA might first try to register
with that Dutch
TMSI and then the network will need to explicitly request the
IMSI. It's not supposed to use that Dutch TMSI in France, but it
might try if there's a bug in its GSM stack.
Well I'm sorry, but I'm still not convinced about that. Cause that
would be a major bug, which won't be accepted by the biggest user
group for PDA phones (like business men, or presidents like Obama). Ah. Sorry. You are probably correct then.
There's something
about the BCCH that the phone doesn't like.
That's I think is most likely the case. That's part of what I mean by TMSI
resolution: if you can't
recognize or support the TMSI, turn around and request the IMSI.
Yeah, that is what OpenBSC does, I think. But Harald, Holger,
Dieter and others know more about it.
The problem, sometimes, is that some phones
don't drop the
TMSI. They insist on using it, even when it should have been
invalidated.
In that case, I would see some negotiations from the debug
bsc_hack, which there is not. So my assumption is still some
missing information in the BCCH channel. Cause once again, trying
to register to my BTS manually failed and I don't see any attempt
to do just a simple Radio Resource request. The latter one I can't
confirm that for 100 %, because it's possible the debug doesn't
show all of that. The only way we could get the Treo 650 to stop
sending us AT&T's
old TMSI was to assign it one of our own.
Well, at least the Treo talked to you.
c u later...
Not if I c u first... ;-)
26 Jun
26 Jun
9:15 a.m.
New subject: OpenBSC with 2.5G or 3G mobile devices support? / Tested Phones
It would be great if someone with an OpenBTS system
could turn on
debugging messages and capture the raw bits from our system
information messages 1-4 and send them to you for you to try in your
OpenBSC build.
Well, I already did that by using some traces I found in
http://wiki.thc.org/. There I copied some values for GPRS support and
changed that in OpenBSC source. Also added the missing SI 13 to the
source, which contains some more info about the GPRS, but without success.
I looked at the BCCH messages in OpenBSC yesterday,
but could not
identify the problem. I don't know how OpenBSC handles the "rest
octets" at the ends of these messages, but it is important that these
be properly padded with the GSM filler pattern if you are not coding
anything there. This is especially important for high-feature phones
that might actually be looking for GPRS parameters. It is also
important to present the BCCH messages in the correct sequence and
with the timing given in GSM 05.02 6.3.1.3, but I suspect your BTS
takes care of that for you.
In OpenBSC (I have older version, didn't do any updates yet) There are
SI 1 to 4 that are filled and the Rest Octets (in SI 3 and SI 4) are
filled with 0x2B, which the MS should ignore and thus it also indicates
no GPRS support.
I agree with your analysis. If the handset actually
sees the network,
then you do not have a frequency offset problem. Therefore, if you do
not see channel requests coming from the phone via the BTS the most
likely explanation is that the phone has found some inconsistency in
the BCCH.
Exactly, that's my assumption too. But as my collegue once said
"Assumption is the mother of all f@ck" from a movie scene of Steven
Seagal's film Under Siege 2. The fact is, it should/must work with BTSs
without GPRS, so I think some important basic information on the BCCH is
not complete and thus maybe corrupt in a certain way. Cause the same
problem also occurs with the BS11 BTS according to other guys in the
list. So I'll concentrate more on the BCCH and try to understand it
carefully.
Sorry. It's joking response: If I see you coming,
I will hide. Just
a joke, though.
No need for appolagize, I like jokes too :p It's funny we laugh about
jokes. Actually, we should always laugh and laugh harder when we hear a
joke. The world would be so beautiful than.
Greetings,
Laughing Nordin.
3 Jul
3 Jul
9:21 a.m.
New subject: OpenBSC with 2.5G or 3G mobile devices support? / Tested Phones
Hello guys,
As I am not an experienced GSM engineer I can't fully understand the GSM
specs.
But I found this in paragraph 4.1.1.2.1 of GSM 04.08:
"NOTE:
Whenever GMM performs a combined GMM procedure, a GPRS MS enters the MM
state
MM LOCATION UPDATING PENDING in order to prevent the MM to perform a
location update procedure."
Since we haven't done anything for GPRS support, this might be the
reason why a location update is not performed with bsc_hack.
Once again, I'm a beginner on this field and still need some more
readings and learning of GSM and OpenBSC sources.
But I hope I found the part that might lead you to solve the GPRS
supported mobiles registering issue.
P.S.: Is everybody on holiday...:)
4 Jul
4 Jul
9:22 a.m.
New subject: OpenBSC with 2.5G or 3G mobile devices support? / Tested Phones
On Fri, Jul 03, 2009 at 11:21:59AM +0200, Nordin wrote:
As I am not an experienced GSM engineer I can't
fully understand the GSM
specs.
But I found this in paragraph 4.1.1.2.1 of GSM 04.08:
"NOTE:
Whenever GMM performs a combined GMM procedure, a GPRS MS enters the MM
state
MM LOCATION UPDATING PENDING in order to prevent the MM to perform a
location update procedure."
I think the way OpenBSC is working (or at leats supposed to work), we don't
permit for any combined GMM procedures but rather tread GSM and GPRS entirely
separate. I don't remember the terminology, but there are three entirely
different methods on how MM and GMM interact. They probably reflect the
evolvement of GSM equipment. The simplest case to move forward for us is
to keep GSM and GPRS entirely separate, i.e. not risking any regressions
due to the inclusion of GPRS support (if at all, at some point).
I strongly believe the problem is related to our SYSTEM INFROMATION headers,
but I currently don't have the time to debug/verify the implementation that I
did for it in some git branch...
P.S.: Is everybody on holiday...:)
no, working full-time on GSM security right now.
--
- 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)
24 Jun
24 Jun
3:28 p.m.
New subject: OpenBSC with 2.5G or 3G mobile devices support? / Tested Phones
On Wed, Jun 24, 2009 at 03:04:01PM +0200, Nordin wrote:
I did the following command:
./bsc_hack -t nanobts1800 -c 204 -n 16 -f 866 -L 11 -d -p dump1.pcap
But when I open this pcap file in Wireshark, I get the following message:
you should not use PCAP mode with nanoBTS. in the case of nanoBTS, it is easy
to start tcpdump or wireshark to capture the IP traffic off the ethernet
interface.
pcap mode of OpenBSC is intended for BS-11 connected to traditional E1
lines.
--
- 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)
5481
days inactive
5482
days old
18 comments
7 participants
participants (7)
-
David A. Burgess -
Eric Cathelinaud -
Harald Welte -
Holger Freyther -
Kai Münz -
Nordin -
Nordin Bouchtaoui