Hello Harald,
Should the plugin you added for Wireshark decode almost all messages or not? Cause on the OML layer a lot of OML messages are not decoded, is this behaviour normal?
I now try to follow the communication flow, but can't seem to understand the multiple OML messages. It starts with 0x00, than a datalen and than protocol (0xFF) and than it starts with 0x80, 0x80,.... But I can't find 0x80 (messagetype) in OpenBSC source. I've checked ipaccess.h and ipaccess.c, but nothing...maybe I lokked at the wrong place.
On Wed, Jul 29, 2009 at 05:31:03PM +0200, Nordin wrote:
Hello Harald,
Should the plugin you added for Wireshark decode almost all messages or not? Cause on the OML layer a lot of OML messages are not decoded, is this behaviour normal?
there is a oml decoder plugin, I've posted it to this list, it is in our git tree and it is mentioned in the wiki, so it should be pretty easy to find.
I now try to follow the communication flow, but can't seem to understand the multiple OML messages. It starts with 0x00, than a datalen and than protocol (0xFF) and than it starts with 0x80, 0x80,.... But I can't find 0x80 (messagetype) in OpenBSC source. I've checked ipaccess.h and ipaccess.c, but nothing...maybe I lokked at the wrong place.
oml is implemented in abis_nm.c
Sorry Harald,
Should read the info on the wiki better. And also the debugging output reveals some info. Anyway thanks.
2009/7/29 Harald Welte laforge@gnumonks.org
On Wed, Jul 29, 2009 at 05:31:03PM +0200, Nordin wrote:
Hello Harald,
Should the plugin you added for Wireshark decode almost all messages or not? Cause on the OML layer a lot of OML messages are not decoded, is this behaviour normal?
there is a oml decoder plugin, I've posted it to this list, it is in our git tree and it is mentioned in the wiki, so it should be pretty easy to find.
I now try to follow the communication flow, but can't seem to understand the multiple OML messages. It starts with 0x00, than a datalen and than protocol (0xFF) and than it starts with 0x80, 0x80,.... But I can't find 0x80 (messagetype) in OpenBSC source. I've checked ipaccess.h and ipaccess.c, but nothing...maybe I lokked at the wrong place.
oml is implemented in abis_nm.c
--
- Harald Welte laforge@gnumonks.org
============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)
On Wednesday 29 July 2009 17:31:03 Nordin wrote:
Hello Harald,
Should the plugin you added for Wireshark decode almost all messages or not? Cause on the OML layer a lot of OML messages are not decoded, is this behaviour normal?
Feel free to upload your pcap file somewhere so we can take a look.
Hi Holger,
Thnx for your offer, there is nothing to look at it than just an initialization process on the OML layer. It decodes some OML messages but not all, the RSL messages are decoded well I think, can't completely confirm that.
For me it's important to follow the procedure of the nanobts up and running before handling RSL messages. Harald posted me some traces for scanning neighbouring cells, which I think is important to fill the BA List. But according to Harald these were ip.access specific messages, so how am I suppose to interpret that? I mean which bytes indicates a neighbouring cell, or how am I suppose to understand the meaning of certain bytes i.e. dBm level of a certain neigbouring cell and which ARFCN? It's like reading a piece of Frenche text without having a dictionarry (well, I understand a little bit french :-) ).
I don't know how you, Harald and others interpretted the messages during reverse-engineering. Cause I assume you don't have any technical documents about ip.access specific messages, except the GSM specs and some own experience?
Kind regards,
Nordin.
On Thu, Jul 30, 2009 at 10:55:49AM +0200, Nordin wrote:
Hi Holger,
Thnx for your offer, there is nothing to look at it than just an initialization process on the OML layer. It decodes some OML messages but not all,
Can you please indicate which OML messages (packet number in your pcap) are not decoded well? It looks quite fine for me here. Also, I think it should be pretty straight forward to look at the 12.21 spec and extend the packet-gsm_abis_oml.c code in wireshark. We need more people working on this than just me ;)
Harald posted me some traces for scanning neighbouring cells, which I think is important to fill the BA List.
Why would you need that? If you run your own network, then you know the neighbouring cells at the BSC and you can fill it from there.
If you want to operate a rouge BTS for security research or in imsi-catcher style applications, then you probably don't want to fill neighbor cell information in the syste info messages, since that would tell the phones how to easily get away from your rogue cell (which you typically don't want)
But according to Harald these were ip.access specific messages, so how am I suppose to interpret that? I mean which bytes indicates a neighbouring cell, or how am I suppose to understand the meaning of certain bytes i.e. dBm level of a certain neigbouring cell and which ARFCN? It's like reading a piece of Frenche text without having a dictionarry (well, I understand a little bit french :-) ).
Yes, that's exactly it. That's how the samba developers first implemented the SMB protocol of windows filesharing, and that's how we write OpenBSC and wireshark code for nanoBTS.
Also, the abis-oml.patch already includes support for parsing the test result messages of a nanoBTS. See dissect_ipacc_test_rep() as well as ipacc_tr_ie_chan_usage and ipacc_tr_ie_bcch() in the attached patch.
I don't know how you, Harald and others interpretted the messages during reverse-engineering. Cause I assume you don't have any technical documents about ip.access specific messages, except the GSM specs and some own experience?
No, we don't have other documentatio. Just our common sense :)
Can you please indicate which OML messages (packet number in your pcap) are not decoded well?
I think all OML messages. The ipaccess-specific and RSL are decoded well. But I run Wireshark under windows, so I guess it's not provided with your latest patches.
Also, I think it should be pretty straight forward to look at the 12.21 spec and extend the packet-gsm_abis_oml.c code in wireshark. We need more people working on this than just me ;)
Yes, it is straightforward. I really do my best to get some time free to extend the decodings for Wireshark and I really like to cooperate to help the project.
Why would you need that? If you run your own network, then you know the neighbouring cells at the BSC and you can fill it from there.
Well, if you reject a MS, it will be left with an empty BA list, so I guess it starts scanning all over again for a BTS to register. But if the MS has a BA list, it can, after it is rejected, reselect for antoher bts/arfcn. So in this way, I can accept my own MS and reject others, without disturbing the others. And I can play with my MS and see how our bsc behaves and, who knows, find a security leak?
If you want to operate a rouge BTS for security research or in imsi-catcher style applications, then you probably don't want to fill neighbor cell information in the syste info messages, since that would tell the phones how to easily get away from your rogue cell (which you typically don't want)
For me it's more important to learn understanding the GSM technique, how to read a documentation, how to program in Linux, how to develope with a community, how to use git, how to analyze data packets using Wireshark and tcpdump, how to create a project with Autotools, etc... :) I'm undergoing a transformation from Windows developer to Linux developer. I'm like Jetfire from Transformer II, leaving the Decepticons for becoming an Autobot :p
Yes, that's exactly it. That's how the samba developers first implemented the SMB protocol of windows filesharing, and that's how we write OpenBSC and wireshark code for nanoBTS.
So, you guys like challenges :)
Also, the abis-oml.patch already includes support for parsing the test result messages of a nanoBTS. See dissect_ipacc_test_rep() as well as ipacc_tr_ie_chan_usage and ipacc_tr_ie_bcch() in the attached patch.
My Linux is just command-line for now, so I run Wireshark GUI in windows.
No, we don't have other documentatio. Just our common sense :)
And a bit of sense of humor... :)
Hi guys,
In GSM 12.21 there is a mistype. In par. 8.8.1 State Changed Event Report, it says Length of Availability Status is >= 2, but actually it's
=4. Cause if you look at part. 9.4.7, you have 1 octet for Attr. Id.
(T), 2 octets of Length (L) and Avail. State (V), which could contain one or more octets.
I found this fault when I was analyzing pcap with Wireshark and gsm spec. 12.21.
Hi Nordin. On Fri, Jul 31, 2009 at 10:30:05AM +0200, Nordin wrote:
Can you please indicate which OML messages (packet number in your pcap) are not decoded well?
I think all OML messages. The ipaccess-specific and RSL are decoded well. But I run Wireshark under windows, so I guess it's not provided with your latest patches.
if you patched and compiled it yourself, then it is 'provided' with my patches. If you do something else, then please be very clear in your e-mails, as I really don't want to spend time trying to figure out what kind of problems there are with decoding your packets - when in fact there are none. There are more efficient ways how I can spend my time. No offence taken, but please keep this in mind for the future.
Yes, it is straightforward. I really do my best to get some time free to extend the decodings for Wireshark and I really like to cooperate to help the project.
Why would you need that? If you run your own network, then you know the neighbouring cells at the BSC and you can fill it from there.
Well, if you reject a MS, it will be left with an empty BA list, so I guess it starts scanning all over again for a BTS to register. But if the MS has a BA list, it can, after it is rejected, reselect for antoher bts/arfcn. So in this way, I can accept my own MS and reject others, without disturbing the others. And I can play with my MS and see how our bsc behaves and, who knows, find a security leak?
please note that this would mean that you yourself are using the same MCC/MNC of an existing commercial network. I can only state my utmost concern about this. Do not interfere with actual GSM networks without the permission/knowledge of that very operator! In most countries interference with public telecommunications services is quite significant offence.
If you want to operate a rouge BTS for security research or in imsi-catcher style applications, then you probably don't want to fill neighbor cell information in the syste info messages, since that would tell the phones how to easily get away from your rogue cell (which you typically don't want)
For me it's more important to learn understanding the GSM technique, how to read a documentation, how to program in Linux, how to develope with a community, how to use git, how to analyze data packets using Wireshark and tcpdump, how to create a project with Autotools, etc... :)
I'm undergoing a transformation from Windows developer to Linux developer. I'm like Jetfire from Transformer II, leaving the Decepticons for becoming an Autobot :p
you don't really need all of that, at least with the nanoBTS: Dieter is running OpenBSC happily on Windows. Still, the open source experience / learning curve remains - it's just no longer related to Linux itself.
Yes, that's exactly it. That's how the samba developers first implemented the SMB protocol of windows filesharing, and that's how we write OpenBSC and wireshark code for nanoBTS.
So, you guys like challenges :)
I would love to have documentation. But as we can see by those examples, it is not a strict requirements. By implementing it anyway, even without public documentation we basicall say: Your security by obscurity or "keep the competition away by obscurity" kind of model does not work. Next time you might disclose the documentation right from the beginning.
Also, the abis-oml.patch already includes support for parsing the test result messages of a nanoBTS. See dissect_ipacc_test_rep() as well as ipacc_tr_ie_chan_usage and ipacc_tr_ie_bcch() in the attached patch.
My Linux is just command-line for now, so I run Wireshark GUI in windows.
Even on Windows you can take wireshark sources, patch them and compile them!
if you patched and compiled it yourself, then it is 'provided' with my patches. If you do something else, then please be very clear in your e-mails, as I really don't want to spend time trying to figure out what kind of problems there are with decoding your packets - when in fact there are none. There are more efficient ways how I can spend my time. No offence taken, but please keep this in mind for the future.
No problem, now I'm sure it's because of missing patches.
please note that this would mean that you yourself are using the same MCC/MNC of an existing commercial network. I can only state my utmost concern about this. Do not interfere with actual GSM networks without the permission/knowledge of that very operator! In most countries interference with public telecommunications services is quite significant offence.
I'm aware of that. But still, it would be nice to have a BA list, it makes OpenBSC more complete.
For me it's more important to learn understanding the GSM technique, how to read a documentation, how to program in Linux, how to develope with a community, how to use git, how to analyze data packets using Wireshark and tcpdump, how to create a project with Autotools, etc... :)
I'm undergoing a transformation from Windows developer to Linux developer. I'm like Jetfire from Transformer II, leaving the Decepticons for becoming an Autobot :p
you don't really need all of that, at least with the nanoBTS: Dieter is running OpenBSC happily on Windows. Still, the open source experience / learning curve remains - it's just no longer related to Linux itself.
Shouldn't you be proud to have a new Linux member/user/developer :) If Dieter has a Windows variant of OpenBSC, it would be great. For me now, it's still much easier to debug in windows than in Linux, because I'm not yet comfortable with gdb in comman-line.
I would love to have documentation. But as we can see by those examples, it is not a strict requirements. By implementing it anyway, even without public documentation we basicall say: Your security by obscurity or "keep the competition away by obscurity" kind of model does not work. Next time you might disclose the documentation right from the beginning.
In a certain way I agree with you, but you can also see it this way: If a magician shows you how he did the trick, the trick won't be special anymore.
Even on Windows you can take wireshark sources, patch them and compile them!
I'll check that out.
Hi,
On Mon, Aug 03, 2009 at 09:50:18AM +0200, Nordin wrote:
I'm undergoing a transformation from Windows developer to Linux developer. I'm like Jetfire from Transformer II, leaving the Decepticons for becoming an Autobot :p
you don't really need all of that, at least with the nanoBTS: Dieter is running OpenBSC happily on Windows. Still, the open source experience / learning curve remains - it's just no longer related to Linux itself.
Shouldn't you be proud to have a new Linux member/user/developer :)
I'm not a missionary. Everyone uses what they think solves their problems best.
If Dieter has a Windows variant of OpenBSC, it would be great.
I've been asking Dieter all the time to send patches that we can integrate. However, nothing has been coming forward yet. Especially if we look at nanoBTS-only and ignore the HFC-E1/BS11 stuff, it should be pretty easy, most likely just some different header filee includes here and there.
I'm not a missionary. Everyone uses what they think solves their problems best.
I just meant it as a joke...
I've been asking Dieter all the time to send patches that we can integrate. However, nothing has been coming forward yet. Especially if we look at nanoBTS-only and ignore the HFC-E1/BS11 stuff, it should be pretty easy, most likely just some different header filee includes here and there.
According to him he uses Cygwin, so no windows based tools are used. In that case I rather use Linux straight than use some kind of emulator.
There are GUI frontends for gdb, including the old "ddd" as well as modern bloatware like eclipse ;)
I know, but I work remotely with putty.
Anyway thnx for the info...
Hi Harald,
You once posted a pcap of a "Network Listen" process of the ip.access nanoBTS, I think. If I anlyze the traffic, I can't find any messages leading to "Network Listen" activities. According to the nanobts product spec. "Network Listen" is an ip.access specific message, so when looking at 0xfe (ipaccess) I only see the Ping/Pong messages.
In GSM 12.21 I couldn't find something about scanning or listening for other ARFCNs. But it's possible I haven't read the spec well or didn't understand completely.
Any idea's?
On Fri, Jul 31, 2009 at 04:43:29PM +0200, Nordin wrote:
Hi Harald,
You once posted a pcap of a "Network Listen" process of the ip.access nanoBTS, I think. If I anlyze the traffic, I can't find any messages leading to "Network Listen" activities. According to the nanobts product spec. "Network Listen" is an ip.access specific message, so when looking at 0xfe (ipaccess) I only see the Ping/Pong messages.
you are misreading the product spec. network listen is implemented as 'perform test' and 'test report', well within 12.21. the 12.21 spec just doesn't tell you what the test numbers are, and how the result data is formatted.
you are misreading the product spec. network listen is implemented as 'perform test' and 'test report', well within 12.21. the 12.21 spec just doesn't tell you what the test numbers are, and how the result data is formatted.
Ahaa, ok thank you for clarifying me. Thnx for your time.
Hi,
according to the wiki for the nanobts:
* 0x00 RSL messages as per GSM 08.58 * 0xfe ip.access specific messages * 0xff OML messages as per GSM 12.21
I assume this is the so called SAPI? Cause I read some Abis articles that for RSL and OML is resp. 0 and 62. I just want to be sure there are some value differences. thank you.
Holger Freyther schreef:
On Wednesday 29 July 2009 17:31:03 Nordin wrote:
Hello Harald,
Should the plugin you added for Wireshark decode almost all messages or not? Cause on the OML layer a lot of OML messages are not decoded, is this behaviour normal?
Feel free to upload your pcap file somewhere so we can take a look.
On Thu, Jul 30, 2009 at 01:00:46PM +0200, Nordin wrote:
Hi,
according to the wiki for the nanobts:
- 0x00 RSL messages as per GSM 08.58
- 0xfe ip.access specific messages
- 0xff OML messages as per GSM 12.21
I assume this is the so called SAPI?
no. SAPI only exists in E1 based A-bis.
Cause I read some Abis articles that for RSL and OML is resp. 0 and 62. I just want to be sure there are some value differences.
A-bis over E1 is what the BS-11 uses. ip.access has their own proprietary protocol stacking and A-bis dialect. There is no public documentation about it, apart from what we deducted from protocol traces and implemented in OpenBSC / wireshark and put into the OpenBSC wiki.
In any case, the Layer 2 (Q.921 on E1, with TEI and SAPI) is completely uninteresting. All you should care about is layer 3 (12.21 OML and 08.58 RSL).
Whatever is below is the transport layer and does not actually have any actual impact on the GSM netwokr
no. SAPI only exists in E1 based A-bis.
Pfff, I was going crazy...
A-bis over E1 is what the BS-11 uses. ip.access has their own proprietary protocol stacking and A-bis dialect. There is no public documentation about it, apart from what we deducted from protocol traces and implemented in OpenBSC / wireshark and put into the OpenBSC wiki.
Damn, did you had a lot of cola and chips? :p
In any case, the Layer 2 (Q.921 on E1, with TEI and SAPI) is completely uninteresting. All you should care about is layer 3 (12.21 OML and 08.58 RSL).
Yeah, I kind of figured that out now.
-
Harald Welte -
Holger Freyther -
Nordin -
Nordin Bouchtaoui