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.
-----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)
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...
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.
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.
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.
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.
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.
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:
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.
David A. Burgess Kestrel Signal Processing, Inc.
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:
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.
David A. Burgess Kestrel Signal Processing, Inc.
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
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... ;-)
uhhhh....c u soon? :)
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@gmail.com
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... ;-)
uhhhh....c u soon? :)
On Jun 25, 2009, at 12:46 AM, Nordin wrote:
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).
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.)
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.
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.
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.
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.
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... ;-)
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.
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.
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...:)
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.
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.
-
David A. Burgess -
Eric Cathelinaud -
Harald Welte -
Holger Freyther -
Kai Münz -
Nordin -
Nordin Bouchtaoui