31 Jul
2009
31 Jul
'09
10:19 p.m.
Hi Nordin.
On Fri, Jul 31, 2009 at 10:30:05AM +0200, Nordin wrote:
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.
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.
Even on Windows you can take wireshark sources, patch them and compile them!
--
- 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)
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. 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.
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.
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
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 :) 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.