I'm looking at the same issue for my company and came to similar
conclusion. At present we've gone down the route of (c) for a quick try,
but I think it will soon be coming unstuck - it certainly isn't general
enough to feed back yet. We haven't yet got any MAC/RLC dissection, but
would be happy to work with somebody to do so - even if we only leave
the glue to transports as proprietary for now.
BTW is anyone planning on hooking RRC NAS message IEs into gsm_a_dtap ?
Since RRC is from the ASN.1, I've not tried it yet, but any pointers
appreciated.
Neil
________________________________
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Martin
Mathieson
Sent: 08 January 2008 11:26
To: Developer support list for Wireshark
Subject: Re: [Wireshark-dev] 3GPP RLC and MAC protocols support
Hi,
I don't know of anyone working on MAC or RLC dissectors.
FP is currently only available for Catapult DCT2000 and
Tektronix K12 file formats, since those formats include the information
needed to interpret the message payloads. This amounts to using
Wireshark as a different log viewer, rather than as a passive network
analyser.
In order to decode the MAC and RLC layers, you'd need to either:
(a) use a file format that gives you this information directly
(as above), OR
(b) infer the FP/MAC/RLC layer configuration/state using
information gleaned from RRC configuration messages, OR MAYBE
(c) guess from the message size/timing/contents that common
transport formats have been used, e.g. there are standard settings using
with AMR co-ordinated channels? OR EVEN LESS LIKELY
(d) get all of this information from preference settings. I
think this is probably a non-starter since so much of the information is
per-channel or even per-frame.
I'd love to see someone do this, but know that it isn't trivial
- my company (Catapult) built such an analyser (using (b) - before I
joined).
I could have extended the approach of (a) for the DCT2000
format, i.e. dissect our own proprietary primitive headers then use this
and other information in the file format to hand off to pure MAC or RLC
dissectors (that would use attached information, as the FP dissector
does), but this would still just be using Wireshark as a different log
viewer, I don't know of any other file formats that would then be able
to take advantage of these dissectors in the same way (possibly K12
again...). I believe the headers for MAC and RLC are quite short, and
that it would take more effort to dissect the proprietary headers than
it would for the actual protocol headers.
Regards,
Martin
On Jan 8, 2008 10:41 AM, Anders Broman
<[EMAIL PROTECTED]> wrote:
Hi,
An RRC dissector (packet-rrc.c) exists but only partly
used. Some time
ago some one
asked about MAC and probably did something with it but
nothing was
commited back to WS.
These are somewhere in the middle of the tread
http://www.wireshark.org/lists/wireshark-dev/200708/msg00121.html
http://www.wireshark.org/lists/wireshark-dev/200708/msg00275.html
Regards
Anders
-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf
Of
[EMAIL PROTECTED]
Sent: den 8 januari 2008 15:35
To: Developer support list for Wireshark
Subject: [Wireshark-dev] 3GPP RLC and MAC protocols
support
Hi,
Is anybody working on dissectors for 3GPP-UMTS- RLC and
MAC protocols ?
Or are these dissectors already available somewhere ?
Thanks & Regards,
Munish
*********************** Aricent-Unclassified
***********************
"DISCLAIMER: This message is proprietary to Aricent and
is intended
solely for the use of the individual to whom it is
addressed. It may
contain privileged or confidential information and
should not be
circulated or used for any purpose other than for what
it is intended.
If you have received this message in error, please
notify the originator
immediately. If you are not the intended recipient, you
are notified
that you are strictly prohibited from using, copying,
altering, or
disclosing the contents of this message. Aricent accepts
no
responsibility for loss or damage arising from the use
of the
information transmitted by this email including damage
from virus."
_______________________________________________
Wireshark-dev mailing list
[email protected]
http://www.wireshark.org/mailman/listinfo/wireshark-dev
_______________________________________________
Wireshark-dev mailing list
[email protected]
http://www.wireshark.org/mailman/listinfo/wireshark-dev
_______________________________________________
Wireshark-dev mailing list
[email protected]
http://www.wireshark.org/mailman/listinfo/wireshark-dev
