wireshark, viewing Abis communication

historical

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!

-- 
- Harald Welte <laforge at gnumonks.org>           http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
                                                  (ETSI EN 300 175-7 Ch. A6)