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!