Hi,
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, and that the new encapsulation
type was to support some new capture mechanism that someone else had
invented. Is the {data rate, channel, signal strength} header common to
programs other than these two?
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?
Regards,
Chris.
----- Original Message -----
From: "Guy Harris" <gharris@xxxxxxxxx>
To: "Chris Waters" <chris@xxxxxxxxxxxx>
Cc: "EtherealDev" <ethereal-dev@xxxxxxxxxxxx>
Sent: Tuesday, June 04, 2002 10:45 PM
Subject: Re: [Ethereal-dev] 802.11 Radio Header
> On Tue, Jun 04, 2002 at 10:30:55PM -0700, Chris Waters wrote:
> > I sent an email a week or so ago about making the new 802.11 radio
header
> > more flexible. I have implemented it the idea I described against the
latest
> > sources.
>
> I don't see any change to anything other than the 802.11 dissector; what
> changes arrange that the TLV header is inserted into the frames read
> from capture files?
>
> > I could have implemented this feature with a new WTAP encapsulation
type,
> > but I feel that the small, fixed header than was recently checked in
against
> > the WTAP_ENCAP_IEEE_802_11_WITH_RADIO encapsulation type would quickly
> > become obsolete. Therefore it makes sense to remove it now. Of course,
> > whoever submitted that patch would need to change the program that they
are
> > making the captures with, and I can understand that that might be a
problem.
>
> Given that the programs (plural) that make those captures are commercial
> programs, and that I neither work at Network Associates (creators of one
> of those programs, Sniffer Wireless) or at WildPackets (creators of the
> other of those programs, AiroPeek), to say that it "might be a problem"
> would be a bit of an understatement. :-) (Even if I *did* work there, I
> suspect they wouldn't be very receptive to a change whose primary
> purpose is to make it easier for a free-software competitor to read
> their captures. :-))
>
> I.e., Ethereal does *NOT* have control over all the capture file formats
> it reads. It must be able to deal with whatever capture file formats
> from various commercial non-modifiable capture programs supply.
>
> One way to handle this might be to supply the TLVs as part of a
> pseudo-header (given that they really *aren't* part of an 802.11
> packet), although if we had a WTAP_ENCAP_IEEE_802_11_WITH_RADIO_TLVs
> encapsulation type, and mapped all the radio-information-enhanced 802.11
> capture formats (of which there are currently at least two - the Prism
> one, which Ethereal reads, and the Aironet one in FreeBSD, which
> Ethereal doesn't currently read, but which it will read at some point,
> time permitting) to that type, that'd make it a bit tricky to write out
> those captures, as the code in Ethereal to write the captures couldn't
> tell Wiretap which of the formats to use.
>
