Wireshark-dev: Re: [Wireshark-dev] 3GPP RLC and MAC protocols support
From: munish.dayal@xxxxxxxxxxx
Date: 09-Jan-2008 10:42:42 ZE5B
Hi, My requirement is basically the whole stack (no ciphering for the time being). RRC RLC MAC FP UDP Could you pls share the details of the approach you took with FP. What kind of "filled-in-struct", and how it can be filled from NBAP configuration messages. For RLC/MAC also, I am more interested in a generalised solution (approach (b)), where configuration info can be gleaned from RRC messages, and filled in a "filled-in-struct". Regards, Munish "Martin Mathieson" <martin.r.mathies To on@xxxxxxxxxxxxxx "Developer support list for > Wireshark" Sent by: <wireshark-dev@xxxxxxxxxxxxx> wireshark-dev-bou cc nces@xxxxxxxxxxxx g Subject Re: [Wireshark-dev] 3GPP RLC and MAC protocols support 01/09/2008 12:19 AM Please respond to Developer support list for Wireshark <wireshark-dev@wi reshark.org> On Jan 8, 2008 6:05 PM, Neil Piercy <Neil.Piercy@xxxxxxxxxxxx> wrote: 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. If it were to be done, I'd like to use the approach as I took with FP, where a filled-in-struct is attached to each frame with the info the dissector needs to know. As you say, this can be filled in from wherever it is available or can be guessed. I'd be interested in discussing what these fields should be if you like.. The FP dissector has been very useful to me - I'm not convinced that MAC and RLC would be as useful to me (one reason is that we have separate primitives/frames for the messages exchanged between the layers, so its not obvious how I'd be able to associate the frames and show the whole stack, i.e. RLC MAC FP UDP or AAL in one Wireshark frame. Ciphering is another complication. Regards, Martin 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: wireshark-dev-bounces@xxxxxxxxxxxxx [mailto: wireshark-dev-bounces@xxxxxxxxxxxxx] 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 <anders.broman@xxxxxxxxxxxx> 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: wireshark-dev-bounces@xxxxxxxxxxxxx [mailto:wireshark-dev-bounces@xxxxxxxxxxxxx ] On Behalf Of munish.dayal@xxxxxxxxxxx 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 Wireshark-dev@xxxxxxxxxxxxx http://www.wireshark.org/mailman/listinfo/wireshark-dev _______________________________________________ Wireshark-dev mailing list Wireshark-dev@xxxxxxxxxxxxx http://www.wireshark.org/mailman/listinfo/wireshark-dev _______________________________________________ Wireshark-dev mailing list Wireshark-dev@xxxxxxxxxxxxx http://www.wireshark.org/mailman/listinfo/wireshark-dev _______________________________________________ Wireshark-dev mailing list Wireshark-dev@xxxxxxxxxxxxx http://www.wireshark.org/mailman/listinfo/wireshark-dev *********************** 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."
- Follow-Ups:
- Re: [Wireshark-dev] 3GPP RLC and MAC protocols support
- From: Martin Mathieson
- Re: [Wireshark-dev] 3GPP RLC and MAC protocols support
- References:
- Re: [Wireshark-dev] 3GPP RLC and MAC protocols support
- From: Martin Mathieson
- Re: [Wireshark-dev] 3GPP RLC and MAC protocols support
- Prev by Date: [Wireshark-dev] ENC: Wireshark-dev: Re: RTCP frame length error indication in RTCP with a Bye chunk
- Next by Date: Re: [Wireshark-dev] ENC: Wireshark-dev: Re: RTCP frame length error indication in RTCP with a Bye chunk
- Previous by thread: Re: [Wireshark-dev] 3GPP RLC and MAC protocols support
- Next by thread: Re: [Wireshark-dev] 3GPP RLC and MAC protocols support
- Index(es):