On Aug 19, 2017, at 5:23 PM, Guy Harris wrote:
> 1) Filter expressions that compare an OUI field against a 24-bit
> integral value might become invalid - but you might be able to make that work
> by allowing FT_OUI be represented, in filters, either as an integral value or
> as 3 octets
On Aug 19, 2017, at 4:18 PM, Richard Sharpe wrote:
> I have a change up for review that introduces a new type, FT_OUI.
>
> It works. However, the big question is that it changes the current
> practice from the OUI being an INT24 to being BYTES.
>
> This breaks backward compatibility I imagine.
Hi folks,
I have a change up for review that introduces a new type, FT_OUI.
It works. However, the big question is that it changes the current
practice from the OUI being an INT24 to being BYTES.
This breaks backward compatibility I imagine.
Is this a big issue?
--
Regards,
Richard Sharpe
(何以
On Sat, Aug 19, 2017 at 8:43 AM, Michael Mann via Wireshark-dev
wrote:
> If you want I can take a look. I've added a few FT_ types in the past.
I was going to give it a try for a couple of days ...
BTW, is that your mailer, my mailer or the list handler doing the following?
> -Original Mes
If you want I can take a look. I've added a few FT_ types in the past.
-Original Message-
From: Richard Sharpe
To: Developer support list for Wireshark
Sent: Sat, Aug 19, 2017 11:29 am
Subject: Re: [Wireshark-dev] Making oui_base_custom available more generally
On Sat, Aug 19, 2017
On Sat, Aug 19, 2017 at 8:10 AM, Michael Mann via Wireshark-dev
wrote:
> I don't know exactly how far BASE_CUSTOM goes back, but it is for "custom"
> display of a field. But if there are enough fields with the same "custom"
> formatting, it's probably time to make it a field type (or add BASE_ ty
I don't know exactly how far BASE_CUSTOM goes back, but it is for "custom"
display of a field. But if there are enough fields with the same "custom"
formatting, it's probably time to make it a field type (or add BASE_ type)
-Original Message-
From: Richard Sharpe
To: Developer supp
On Sat, Aug 19, 2017 at 5:19 AM, Michael Mann via Wireshark-dev
wrote:
> If you're talking about oui_base_custom(), I think the better idea would be
> to create a field type (FT_OUI) for it.
This is an idea I like. However, how far back does BASE_CUSTOM go?
> -Original Message-
> From: R
I think there may be 2 types of OUIs (so I may need help distinguishing them)
There is oui_vals (in epan/oui.h) which could useFT_UINT24 + VALS(), but then
there is the code in packet-ieee80211.c that integrates
get_manuf_name_if_known() (and treats FT_UINT24 as a byte array). I had
presumed F
On Sat, Aug 19, 2017 at 2:19 PM, Michael Mann via Wireshark-dev <
wireshark-dev@wireshark.org> wrote:
> If you're talking about oui_base_custom(), I think the better idea would
> be to create a field type (FT_OUI) for it.
>
Yes it is a idea but a BASE_OUI with VALS() (and use FT_UINT24) will be
wo
If you're talking about oui_base_custom(), I think the better idea would be to
create a field type (FT_OUI) for it.
-Original Message-
From: Roland Knall
To: Developer support list for Wireshark
Sent: Sat, Aug 19, 2017 7:16 am
Subject: Re: [Wireshark-dev] Making oui_base_custom avai
Which OUI are we talking about? Generally speaking, a wsutil/oui_handler.?
could be useful, as for instance, openSAFETY uses OUI-24 as well. So it
could be made the case, to move the OUI handling outside of the dissector
and into a generic wsutil or epan structure.
cheers,
Roland
On Sat, Aug 19,
I don't think that's enough. The linker should be able to resolve the
symbol this way, but the compiler shouldn't. Then you'd have to declare it
extern. But the right thing to do is to create a .h file that holds the
public declaration of the .c file, and include it. This is a best practice
general
13 matches
Mail list logo
