On Wed, Jun 05, 2002 at 05:12:53PM -0700, Chris Waters wrote:
> Perhaps I misunderstood the reason that the new encapsulation type had been
> added. I had assumed that Ethereal could already handle 802.11 captures from
> programs like Airopeek and Sniffer Wireless,
Yes, it could do so before the new encapsulation type was added,
*but*...
> and that the new encapsulation
> type was to support some new capture mechanism that someone else had
> invented.
...the new encapsulation type wasn't added to support a new capture
mechanism, it was added when Sniffer Wireless support was added.
Prior to that, there was a special encapsulation type for AiroPeek
captures, but, as Sniffer Wireless and AiroPeek put the same radio
information into their captures, the special AiroPeek encapsulation was
discarded in favor of an "802.11 plus radio information" encapsulation
type.
> Is the {data rate, channel, signal strength} header common to
> programs other than these two?
I don't currently know of any other programs that use it, but that
doesn't mean there aren't any.
> I am writing a program for making 802.11 captures and need a way save the
> extra header information that the chipset makes available. Adding a new
> encapsulation type is not a problem, I just didn't want to add a new
> encapsulation type if it was going to immediately obsolete the old one
> (again, these shows that I was missing something because I assumed that
> since the WTAP_ENCAP_IEEE_802_11_WITH_RADIO encapsulation type had just been
> added, its use is not yet entrenched).
>
> If I add a new encapsulation type, is this patch otherwise acceptable?
Yes, as long as the patch also includes changes to Wiretap to *use* that
encapsulation type for the files from your program, i.e. to, for some
type of files, return that as the encapsulation type.
If your program doesn't write out capture files in any of the
currently-supported formats, the patch would also have to include
changes to Wiretap to read those capture files.
