[<smit.rastogi@xxxxxxxxx>]

Hi,

The IEEE TLV's currently appear WITHIN some specific messages decoded by WIMAXASNCP. I guess that is something to do with profile B of the ASN part of the Network Reference Model, which groups the BS along with the ASN gateway, and thus passes on certain IEEE TLV's embedded within NWG defined TLV's (though I am not entirely sure about this).

For the second part, YES, they are in EXACTLY the same format - in fact, the WIMAXASNCP plugin wiki page points to the exact TLV's in the IEEE 802.16 specifications. The downside indeed might be filters, but I think it can be overlooked, considering that people filtering on WIMAXASNCP will not concern themselves much with the Air Interface part (they're just a few TLV's).

I share your concern regarding it working on all platforms. I am currently testing it on FC6 on which it works well (yet to fuzz test it, though), and don't have access to a Windows system.

I'll probably send in a patch next week for a look, after testing it as properly as I possibly can. Also, I will try to test it on Windows.

Thanks again.
Regards,
Smit Rastogi
Wipro Technologies

-----Original Message-----
From: wireshark-dev-bounces@xxxxxxxxxxxxx on behalf of Martin Mathieson
Sent: Fri 6/20/2008 2:58 PM
To: Developer support list for Wireshark
Subject: Re: [Wireshark-dev] Improvement to WIMAXASNCP for decoding IEEE802.16e specified TLV's

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@xxxxxxxxx>
> 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
>
>


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

<<winmail.dat>>