Re: [Wireshark-dev] Reusing the code for various things in ieee802.11 in other dissectors ...

[Richard Sharpe]

On Mon, Oct 16, 2017 at 7:09 AM, Richard Sharpe
 wrote:
> On Sun, Oct 15, 2017 at 7:36 PM, Michael Mann via Wireshark-dev
>  wrote:
>>
>>
>>
>> -Original Message-
>> From: Richard Sharpe 
>> To: Developer support list for Wireshark 
>> Sent: Sat, Oct 14, 2017 1:47 pm
>> Subject: [Wireshark-dev] Reusing the code for various things in ieee802.11
>> in other dissectors ...
>>
>>> Hi folks,
>>>
>>> I am almost finished a dissector for the IEEE1905 Multi-AP technical
>>> specification draft from August 2017. The work was done for an
>>> organization in the industry. It is pretty complete and has undergone
>>> testing with real traffic.
>>>
>>> Unfortunately, they make references to elements in IEEE802.11 2016.
>>>
>>> One specific item is 9.4.2.22.7 Beacon Reports from IEEE802.11 2016.
>>> There is another such reference as well.
>>
>> I'm not familiar enough with the protocols to know where exactly this is in
>> the dissector.  I recently created a dissector table for tagged fields
>> ("wlan.tag.number").  I'm guessing this is where the beacon stuff is, so yes
>> existing dissector tables should handle this.
>
> The problem with this is likely to be point 3 below because the
> structure as used by IEEE1905 is not tagged (although it does contain
> TLVs ...)

It's worse than I thought :-) The structure I am interested in is
dissected as part of the function ieee80211_tag_measure_rep in the
802.11 dissector ...

I guess I could break it out and make another dissector table.

However, there is also the issue of filter fields as well ...

>>>
>>> These raise problems:
>>>
>>> 1. I don't want to duplicate code
>>> 2. The code in the current packet-ieee80211.c dissector is incomplete
>>> WRT the 2016 version of the spec. (Eg, it does not handle Vendor
>>> specific  or Wide Bandwidth Channel Switch optional sub-elements.)
>>
>> I also created a few dissector tables in packet-ieee80211.c for vendor
>> specific extensions.  Most of the cases involved multiple vendors that were
>> already in the dissector.  I think a few more could probably be created.
>> Most of the ones I left only had OUI_WFA as the only vendor, so I lost
>> interest in the conversion to adding more dissector tables.
>>
>>> 3. The references in IEE1905 are to the underlying structures not the
>>> tagged structures.
>>> 4. The code in packet-ieee80211.c is declared static so I can't call
>>> it if I wanted to.
>>
>> Again, specifics about the code are more helpful to me.
>>
>>>
>>> We have mechanisms for dealing with this. One is dissector tables.
>>> Another is to declare certain functions non-static and put the
>>> definitions in header files. There might be others.
>>>
>>> Are there any suggestions?
>>
>> Without seeing the code, I would lean towards suggesting dissector tables as
>> the solution for most of it.  Removing "static" from functions and declaring
>> them in header files should be more of a last resort.
>> You can put your patch up for review, even if it is just a WIP.  Marking
>> where you don't want to duplicate code or where you want to call (currently
>> static) packet-ieee80211.c functions would be helpful.
>
> It will be coming as a patch soon ... :-)
>
> --
> Regards,
> Richard Sharpe
> (何以解憂？唯有杜康。--曹操)



-- 
Regards,
Richard Sharpe
(何以解憂？唯有杜康。--曹操)
___
Sent via:Wireshark-dev mailing list 
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] Reusing the code for various things in ieee802.11 in other dissectors ...

[Richard Sharpe]

On Sun, Oct 15, 2017 at 7:36 PM, Michael Mann via Wireshark-dev
 wrote:
>
>
>
> -Original Message-
> From: Richard Sharpe 
> To: Developer support list for Wireshark 
> Sent: Sat, Oct 14, 2017 1:47 pm
> Subject: [Wireshark-dev] Reusing the code for various things in ieee802.11
> in other dissectors ...
>
>> Hi folks,
>>
>> I am almost finished a dissector for the IEEE1905 Multi-AP technical
>> specification draft from August 2017. The work was done for an
>> organization in the industry. It is pretty complete and has undergone
>> testing with real traffic.
>>
>> Unfortunately, they make references to elements in IEEE802.11 2016.
>>
>> One specific item is 9.4.2.22.7 Beacon Reports from IEEE802.11 2016.
>> There is another such reference as well.
>
> I'm not familiar enough with the protocols to know where exactly this is in
> the dissector.  I recently created a dissector table for tagged fields
> ("wlan.tag.number").  I'm guessing this is where the beacon stuff is, so yes
> existing dissector tables should handle this.

The problem with this is likely to be point 3 below because the
structure as used by IEEE1905 is not tagged (although it does contain
TLVs ...)

>>
>> These raise problems:
>>
>> 1. I don't want to duplicate code
>> 2. The code in the current packet-ieee80211.c dissector is incomplete
>> WRT the 2016 version of the spec. (Eg, it does not handle Vendor
>> specific  or Wide Bandwidth Channel Switch optional sub-elements.)
>
> I also created a few dissector tables in packet-ieee80211.c for vendor
> specific extensions.  Most of the cases involved multiple vendors that were
> already in the dissector.  I think a few more could probably be created.
> Most of the ones I left only had OUI_WFA as the only vendor, so I lost
> interest in the conversion to adding more dissector tables.
>
>> 3. The references in IEE1905 are to the underlying structures not the
>> tagged structures.
>> 4. The code in packet-ieee80211.c is declared static so I can't call
>> it if I wanted to.
>
> Again, specifics about the code are more helpful to me.
>
>>
>> We have mechanisms for dealing with this. One is dissector tables.
>> Another is to declare certain functions non-static and put the
>> definitions in header files. There might be others.
>>
>> Are there any suggestions?
>
> Without seeing the code, I would lean towards suggesting dissector tables as
> the solution for most of it.  Removing "static" from functions and declaring
> them in header files should be more of a last resort.
> You can put your patch up for review, even if it is just a WIP.  Marking
> where you don't want to duplicate code or where you want to call (currently
> static) packet-ieee80211.c functions would be helpful.

It will be coming as a patch soon ... :-)

-- 
Regards,
Richard Sharpe
(何以解憂？唯有杜康。--曹操)
___
Sent via:Wireshark-dev mailing list 
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] Reusing the code for various things in ieee802.11 in other dissectors ...

[Michael Mann via Wireshark-dev]

 
 
 
-Original Message-
From: Richard Sharpe 
To: Developer support list for Wireshark 
Sent: Sat, Oct 14, 2017 1:47 pm
Subject: [Wireshark-dev] Reusing the code for various things in ieee802.11 in 
other dissectors ...

> Hi folks,
> 
> I am almost finished a dissector for the IEEE1905 Multi-AP technical
> specification draft from August 2017. The work was done for an
> organization in the industry. It is pretty complete and has undergone
> testing with real traffic.
> 
> Unfortunately, they make references to elements in IEEE802.11 2016.
> 
> One specific item is 9.4.2.22.7 Beacon Reports from IEEE802.11 2016.
> There is another such reference as well.

I'm not familiar enough with the protocols to know where exactly this is in the 
dissector.  I recently created a dissector table for tagged fields 
("wlan.tag.number").  I'm guessing this is where the beacon stuff is, so yes 
existing dissector tables should handle this.

> 
> These raise problems:
> 
> 1. I don't want to duplicate code
> 2. The code in the current packet-ieee80211.c dissector is incomplete
> WRT the 2016 version of the spec. (Eg, it does not handle Vendor
> specific  or Wide Bandwidth Channel Switch optional sub-elements.)

I also created a few dissector tables in packet-ieee80211.c for vendor specific 
extensions.  Most of the cases involved multiple vendors that were already in 
the dissector.  I think a few more could probably be created.  Most of the ones 
I left only had OUI_WFA as the only vendor, so I lost interest in the 
conversion to adding more dissector tables.

> 3. The references in IEE1905 are to the underlying structures not the
> tagged structures.
> 4. The code in packet-ieee80211.c is declared static so I can't call
> it if I wanted to.

Again, specifics about the code are more helpful to me.

> 
> We have mechanisms for dealing with this. One is dissector tables.
> Another is to declare certain functions non-static and put the
> definitions in header files. There might be others.
> 
> Are there any suggestions?

Without seeing the code, I would lean towards suggesting dissector tables as 
the solution for most of it.  Removing "static" from functions and declaring 
them in header files should be more of a last resort.
You can put your patch up for review, even if it is just a WIP.  Marking where 
you don't want to duplicate code or where you want to call (currently static) 
packet-ieee80211.c functions would be helpful.


> 
> -- 
> Regards,
> Richard Sharpe
> (何以解憂？唯有杜康。--曹操)


___Sent 
via:Wireshark-dev mailing list Archives:
https://www.wireshark.org/lists/wireshark-devUnsubscribe: 
https://www.wireshark.org/mailman/options/wireshark-dev 
mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
___
Sent via:Wireshark-dev mailing list 
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

[Wireshark-dev] Reusing the code for various things in ieee802.11 in other dissectors ...

[Richard Sharpe]

Hi folks,

I am almost finished a dissector for the IEEE1905 Multi-AP technical
specification draft from August 2017. The work was done for an
organization in the industry. It is pretty complete and has undergone
testing with real traffic.

Unfortunately, they make references to elements in IEEE802.11 2016.

One specific item is 9.4.2.22.7 Beacon Reports from IEEE802.11 2016.
There is another such reference as well.

These raise problems:

1. I don't want to duplicate code
2. The code in the current packet-ieee80211.c dissector is incomplete
WRT the 2016 version of the spec. (Eg, it does not handle Vendor
specific  or Wide Bandwidth Channel Switch optional sub-elements.)
3. The references in IEE1905 are to the underlying structures not the
tagged structures.
4. The code in packet-ieee80211.c is declared static so I can't call
it if I wanted to.

We have mechanisms for dealing with this. One is dissector tables.
Another is to declare certain functions non-static and put the
definitions in header files. There might be others.

Are there any suggestions?

-- 
Regards,
Richard Sharpe
(何以解憂？唯有杜康。--曹操)
___
Sent via:Wireshark-dev mailing list 
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe