Wireshark-dev: Re: [Wireshark-dev] Improvement to WIMAXASNCP for decoding IEEE 802.16e specifie
On Fri, Jun 20, 2008 at 5:55 AM, <
smit.rastogi@xxxxxxxxx> wrote:
Hi there,
Firstly, a big thank you for your replies, especially as they were very prompt.
The find_dissector() function works perfectly, as I discovered that the Intel WiMAX plugin registers the dissector as "wmx", and therefore allows itself to be checked.
The WiMAX air interface TLV's are quite different than those implemented in WIMAXASNCP plugin. I guess the WIMAXASNCP plugin is only meant to decode those TLV's that are present in the NWG (Network Working Group) document and NOT those referred from the IEEE 802.16 air interface specification. As the TLV's have exact same structure in the NWG doc (Type: 2 bytes, Length: 2 bytes) the WIMAXASNCP plugin can decode all the TLV's in one function itself (dissect_wimaxasncp_tlvs()). However, IEEE TLV's have type as 1 byte, and length as 1 byte, which will make it tough to be decoded in WIMAXASNCP. Also the IEEE TLV's required to be decoded in the WIMAXASNCP plugin are considerably complex, and the people at Intel can probably vouch for that.
So you're saying that sometimes the air interface TLVs can appear in messages on other interfaces, and their structure is different from all of the other TLVs?
I therefore think it is inappropriate to implement the dissection of the IEEE TLV's within the WIMAXASNCP plugin.
If they are in exactly the same format as they would appear on the air interface, then yes, it'd be better if it could call the existing code. One downside might be that the filters for the added items will be different, but this may not matter.
The way we have gone about is like this...
- Added a single decoder type to the WIMAXASNCp plugin named WIMAXASNCP_TLV_IEEE_80216
- Added a case to the dissect_wimaxasncp_tlv_value() for the specified decoder.
- Checked for existence of Intel WiMAX plugin
- If the WiMAX plugin existed, called appropriate functions fowithin the Intel WiMAX plugin.
Will this work on all platforms? I'm thinking particularly of Windows...
Which platform did you test this on?
- If not, it decoded as hex dump (as done originally)
This provides for minimal code changes (as low as 50 lines in WIMAXASNCP and 1 line in WiMAX).
My question really is, is this approach acceptable?
In case it isn't, is it possible for anyone to guide me in the correct direction?
I think send in the patch, and we can have a look. My main concern at the moment is whether calling the entry point to dissect the TLVs in the air interface plugin will work on all platforms.
Maybe someone with a better understaning of how linking with plugins works could comment on this?
Regards,
Martin
Thanks in Advance!
Regards
Smit Rastogi
Wipro Technologies
-----Original Message-----
From: wireshark-dev-bounces@xxxxxxxxxxxxx on behalf of Martin Mathieson
Sent: Wed 6/18/2008 9:07 PM
To: Developer support list for Wireshark
Subject: Re: [Wireshark-dev] How to check whether a plugin is installed frominside a dissector ?
On Wed, Jun 18, 2008 at 4:20 PM, Jeff Morriss <jeff.morriss.ws@gmail.com>
wrote:
>
>
> smit.rastogi@xxxxxxxxx wrote:
> >
> > Hi all,
> >
> > I am currently trying to decode the IEEE 802.16E TLV's that WIMAXASNCP
> > is unable to, and I found out that the corresponding TLV's are already
> > dissected in the Intel WiMAX plugin.
> >
> > I have been trying to link up the two plugins so that the IEEE specified
> > TLV's are dissected in WIMAXASNCP plugin using the functions available
> > in the WIMAX plugin, while they still retain the necessary independence
> > from each other.
> >
> > For this, I am thinking of decoding only if I find a given plugin
> > installed.Is there any way to check from inside a dissector whether a
> > plugin is installed or not?
>
> Would find_dissector() work?
Even if you could detect that another dissector is present, could one plugin
dissector access data exported from another plugin?
Would a preferred approach be to:
- move wimaxasncp to a builtin dissector
- export its dictionary object to plugins
- add the missing TLVs into the XML file that wimaxasncp parses
- use the exported dictionary in the wimax plugin contributed by Intel ?
I don't know how much commonality there is between the TLVs seen on the air
interface and those on the other interfaces (whose messages are decoded by
wimaxasncp). Also, wimaxasncp is still at version 1.0 of the protocol - I
don't know if one dictionary file could serve all interfaces and versions
simultaneously (I don't really know WiMAX).
Martin
>
> _______________________________________________
> Wireshark-dev mailing list
> Wireshark-dev@xxxxxxxxxxxxx
> https://wireshark.org/mailman/listinfo/wireshark-dev
>
Please do not print this email unless it is absolutely necessary.
The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s) and may contain proprietary, confidential or privileged information. If you are not the intended recipient, you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately and destroy all copies of this message and any attachments.
WARNING: Computer viruses can be transmitted via email. The recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email.
www.wipro.com
_______________________________________________
Wireshark-dev mailing list
Wireshark-dev@xxxxxxxxxxxxx
https://wireshark.org/mailman/listinfo/wireshark-dev
